「横に割ってダメなら縦に割りましょう」　データベースの“大きな泥だんご“状態解消に向けた垂直分割

横に割ってダメなら縦に割りましょう

田中晋太朗氏：ここまでで試したこと、現状の課題の話をしてきたわけですが、じゃあここまでの課題を踏まえて、今後、私がどういうところを模索していこうかなと思っているかというところについて少し話させてください。

ここまでの話とこの会の趣旨で完全にわかることなんですが、水平分割をやってきた次に何をすべきかというと、垂直分割ですね。横に割ってダメなので縦に割りましょうという話で、モジュラモノリスっぽくなってきました。

先ほど言った、垂直分割を最初は避けていた理由みたいなところを軽く触れると、on the Railsで開発を進めていこうとすると、自ずとモノリスなアーキテクチャに普通はなっていきますがRailsはやはりActive Recordとか非常に便利なので、Railsの良さをできるだけ残して作っていきたいみたいな思いがあったんですね。

それから、マイクロサービス疲れみたいな話もありましたが、「マイクロサービス、安直に手を出したらけっこうまずいらしいぞ」みたいな話もあって。

「じゃあ今の課題に対してミニマムで対応できる方法って何かな？」ということでいろいろ試してきたみたいなところがあるので、垂直分割はわざと遠ざけながらやってきたというところです。

ですがここまでやってみて、回り回ってやはり垂直分割かなというところ。そういう気持ちに今なっていますというところですね。

結局、1つのデータソースに対して複数のサービスが際限なくアクセスできるみたいなところがこの問題の根源なのかなと思って、ドメインベースの垂直分割を進めていこうと思っています。

垂直分割の4つのパターン

といっても、どれぐらいのレベル感で垂直分割するのかはいくつか選択肢があるなと思っていて。パッと考えるだけでも4パターンぐらいあるのかなと思いました。詳しくは後述しますが、1つ目がいわゆるマイクロサービスですね。2つ目がいわゆるモジュラモノリスだと思います。mountableなengineで作るモジュラモノリス①です。

2つ目は「モジュラモノリス②」と書いてあります。4つ目も「モジュラモノリス③」と書いてありますが、これに関しては使えるかどうかわからんなというところですが、ちょっと詳しく見ていきましょう。

1つ目はいわゆるマイクロサービスアーキテクチャというところで、マイクロサービスの単位ごと、サーバーインスタンスごと、まあプロセスごと……。プロセスも別だし、多くの場合はサーバーのインスタンスごと分けちゃうようなアプローチです。

メリットは話すまでもないかなとも思いますが、「ほかのサービスのことを気にせずにどんどんデプロイできますよ」みたいなところがある一方で、「ドメインの境界の見直しが発生した時に、コードのお引越しはすげー大変だよね」という話がデメリットとして大きいというところがあります。

2つ目です。これは自分の中では素直に出てくるモジュラモノリスの形かなと思っていますが、例えばRailsでいえば、mountableなengineとしてモジュールを切り出すみたいなパターン。

（スライドを示して）レイヤーの名前が書いてないのでフワッとした図ですが、例えばこれはRailsのルーターごと分割されているというイメージで捉えてもらえればいいかなと思ってます。

これをうまく依存関係の統制をしながら作っていくと非常に可搬性が高いというか、「じゃあ、このサーバーじゃないところにこのエンジンmountしてサーブするようにしよう」みたいな変更とかも非常にやりやすいなとは思いますが、エンジンとして作ろうと思うとちょっと新しく学ばないといけないことがあったり、それから、やはりルーターも分かれているので、このあとに述べる形よりはちょっと境界の見直しのコストが高そうだなというところがデメリットとしてあるかなと思っています。

3つ目は、結論「これ採用」と思っているんですが、mountableなエンジンとして切り出せないけれど、Application Service以下の部分で垂直分割しちゃおうということを考えています。

これがどちらかというと良いとこ取りかなと思っていて。ベースは基本的なRailsのアプリケーションの構成とそんなに変わらないので覚えることが少ないし、境界の見直しにも対応しやすいと思っています。

最後の4つ目は、Domain Service以下を垂直分割しようと思っていたんですが、これって結局いろんなサービスが際限なく1つのデータソースにアクセスできるみたいなもので、「ほとんど解決しなくない？」というところで、却下かなというふうに思っております。

じゃあ結局今後どの方法をベースに進めていくのか

というところで、「じゃあ結局今後どの方法をベースに進めていくの？」というところで考えたわけなんですが、一番念頭に置いたのは、可逆的に漸進的にやることができるような方法にしましょう、と思っています。

境界の見極めってやはり難しくて、作っていく中で繰り返し調整をかけていくものだと思うので、そこを念頭に置いて方針を決めました。

結論、Application Serviceレイヤー以下を垂直分割する、モジュラモノリス②のパターンです。先ほどの4つのパターンでいうと、②のパターンを基本としたいと思っています。

ということで、基本方針は今しゃべったとおりですが、細かいことを考え始めると、ほかにもいろいろ考えないといけないことがあると気づきます。

少しだけそういった細かいtipsの話もすると……。でも、これはアレですね。今までのお二方も触れたところです。

Active Recordは抜け穴なのでどうしようと思っているかというと、今のところは公開インターフェースはPORO（Plain Old Ruby Object）なオブジェクト、シンプルなRubyのオブジェクトを返すようなことをすることで、Active Recordの抜け道を使わせないような方法をいったんやらざるを得ないんじゃないかなと思っています。やっていく中で、一部の機能だけ生かしておくような可能性もあるかなと思っています。

それから「データベースは分割しないの？」という話もあるかと思いますが、これもやはり「境界の見直しが発生すると切り戻し大変ですよね」というところがあるので、今はやらないという判断をしていたりはします。

モジュラモノリス化を可逆的に、漸進的にやりながら検証していく

というところで、ちょっと長くなってしまいましたが、最後のまとめに入っていければと思っています。

ワンキャリアのもともとの課題感として大きな泥だんごになっていましたというところで、水平分割でトライしましたが、やはり垂直分割になりました。

大きな流れには逆らえなかったなと思うんですが、垂直分割、モジュラモノリス化を可逆的に漸進的にちょっとずつやりながら検証をして、「こうやればうまくいく」みたいなのをこれから見つけていくフェーズです。

ここに関してはやってみないとわからないことも多いし、もしかしたら自分がぜんぜん見えていないハードルみたいなものがあるかもしれないので、懇親会とかでいろいろ議論、情報交換できたらなと思っています。

というところで、これが最後のスライドです。最近ちょっとX（旧Twitter）のアカウントの運用を強化していたりとかEntranceBookの公開とかをしているので、よかったらぜひぜひ見てもらえればと思っています。

本日はありがとうございました。