バックエンドの設計とスケール：マイクロサービスかモノリスか

バックエンドの設計は、その日の仕事がどれだけ戦いになるかを決める。アプリが育つにつれて、最初の選択のひび割れが目に見えてくる。そしていつか、方向を決めないといけない時が来る。モノリスを維持するのか。それとも全部マイクロサービスに分解するのか。

銀の弾丸はない。どちらの手法にも居場所はある。正しい選択は、純粋な技術面よりも、チームの構成と事業の段階に左右されることが多い。この記事では、主要な2つの選択肢と、実際によく機能する現実的な中間案を見ていく。

1. 候補たち

マイクロサービスアーキテクチャ

マイクロサービスの考え方は単純だ。巨大なアプリを1つ作る代わりに、小さく独立したサービスを集めて作る。それぞれが1つのことをうまくこなす。

分散したチームを思い浮かべてほしい。各サービスは自分のデータベースを持ち、準備ができたら他に許可を取らずにいつでもデプロイできる。請求チームがGoを使い、認証チームがRustを好んでも、どちらも譲る必要がない。その自由が人を速くする。少なくとも理論上は。

実際には、これは500人の開発者がいる中で1回のリリースを調整するのが悪夢になるような大組織に向いている。

図：マイクロサービスアーキテクチャ

モノリスアーキテクチャ

モノリスは伝統的な手法だ。コードベースも1つ、アプリも1つ、デプロイも1回。ユーザーインターフェースからビジネスロジック、データアクセスまで、すべてが一緒に生きている。

「モノリス」という言葉は、一部の界隈ではほとんど汚い言葉になりつつある。それでも実際の利点はある。単純だ。関数がどこで定義されているかを探すのに地図は要らない。デプロイは1つのスクリプトで済む。小規模から中規模のチームにとって、その単純さは超能力だ。インフラの複雑さに埋もれずに、速く進める。

図：モノリスアーキテクチャ

2. トレードオフ

なぜマイクロサービスを選ぶのか

スケールすべきものをスケールする： 動画処理がCPUを酷使している一方でログインページが遊んでいるとき、動画サービスだけにサーバーを追加できる。
スタックの自由： 5年前に下した技術の選択に縛られない。新しいサービスはモダンなツールを使える。
耐障害性： うまくいけば、おすすめサービスが落ちても、チェックアウトを含むサイトの他の部分は動き続ける。

マイクロサービスのコスト

運用の複雑さ： コードの複雑さをインフラの複雑さに置き換える。何十ものサービスにまたがるリクエストを監視し、ログを取り、トレースしなければならない。
レイテンシ： メモリ上の関数呼び出しはナノ秒だ。別のサービスへのネットワーク呼び出しはミリ秒かかる。それが積み重なる。
分散システムは難しい： 複数のサービスにまたがるトランザクションは頭痛の種だ。データの整合性を保つには丁寧な設計が要る。

なぜモノリスに留まるのか

単純さが勝つ： コードをたどるのは簡単だ。「定義へ移動」のようなIDEツールも実際に機能する。
パフォーマンス： 内部呼び出しにはネットワークのオーバーヘッドがない。すべてがプロセス内で完結する。
テストが楽： ノートPCでアプリ全体を立ち上げて、インターネット全部をモックせずにE2Eテストを回せる。

モノリスの限界

スケールの痛み： ボトルネックが1つの部分だけでも、アプリ全体をスケールしなければならない。
結合： すべてがすべてに依存するスパゲッティコードを作りやすい。悪いコミット1つでアプリ全体が壊れうる。
デプロイへの恐怖： 巨大なモノリスのデプロイは遅く、リスクもある。それがデプロイへの恐怖を生み、リリースサイクルを遅くする。

「サービスが多すぎる」罠

中小企業でよくあるアンチパターンが、エンジニアの数よりマイクロサービスの数が多くなることだ。100人のエンジニアで300以上のサービスを維持しようとしている組織を見たことがある。結果はカオスだ。

そのラインを越えると、多くのサービスがオーナーを失うか、オーナーが組織再編のせいで文脈を知らないサービスを引き継ぐことになる。また、すべてのリポジトリで依存関係を更新して脆弱性を潰すのに時間を取られる。マイクロサービスをうまくやるには、専任のプラットフォームチームと、ツールへの本格的な投資が必要だ。ほとんどのスタートアップにはそのインフラを用意する余裕がなく、「アジャイル」なはずの設計が保守の悪夢に変わる。

3. どちらが合うか

流行だからという理由で設計を選んではいけない。実際に抱えている問題を解決するから選ぶべきだ。トレンドは判断に入れるべきではない。

こんなときはマイクロサービス：

大規模なエンジニア組織、50人以上の開発者を抱えていて、チームを分離する必要がある。
重いMLパイプラインと単純なCRUDアプリのように、リソース要求が大きく異なるコンポーネントがある。
モノリスでは到底扱えないスケールの限界にぶつかっている。

こんなときはモノリス：

スタートアップや小規模チームだ。イテレーションの速さが最も重要な指標。
ドメインが密結合している。ある機能を変えるとほぼ必ず別の機能も変わるなら、分離するのは痛みを増やすだけだ。
プロトタイプの段階だ。まだドメインの境界が分かっていない。早すぎるサービス分割は典型的な失敗だ。

4. 現実的な道：モジュラーモノリスと段階的な分割

ここに秘密がある。マイクロサービスにいきなり飛びつく必要はない。おそらく飛びつくべきではない。

モジュラーモノリスは堅実な中間案だ。デプロイ単位は1つだが、内部ではモジュール間に厳しい境界を設ける。Module AのコードはModule Bのコードを直接インポートできない。定義された公開インターフェースを通す必要がある。マイクロサービスのコード整理の利点を、インフラのオーバーヘッドなしで得られる。

アプリが育つにつれて、独立が必要な部分を切り離していけばいい。

進化のさせ方：

継ぎ目を見つける： 別々の製品のように振る舞うアプリの部分を見つける。「ユーザー認証」や「画像処理」がよくある候補だ。
書き直さず抽出する： そのコードを別のサービスに移す。ロギングやメトリクスの設定のような共通ライブラリは共有したままで、一貫性を保てる。
段階を踏む： 一度に全部を分割しない。主要なモノリス1つと、特定のタスク用の小さなマイクロサービス2つだけで十分なこともある。
共有コードに注意： サービス間でデータベースのテーブルを共有するのは罠だ。サービスを分割したら、原則としてそのデータは自分で所有すべきだ。

図：ハイブリッドアプローチ

まとめ

マイクロサービス対モノリスの論争は、だいたい本題を外している。問題はどちらの設計が理論的に優れているかではない。今の自分がどのトレードオフのセットと共存できるかだ。

マイクロサービスは独立性と狙いを絞ったスケールをもたらす。その代償として複雑さを払う。
モノリスは単純さと速さをもたらす。ただし規模が大きくなると扱いにくくなる。
ハイブリッド／進化的な設計は、単純に始めて、必要な時だけ複雑になることを許してくれる。

きちんと構造化されたモノリスから始めよう。痛みが出た時にだけ分割すればいい。未来の自分とDevOpsチームが感謝してくれる。