モノリスからマイクロサービスへ — 移行判断のフレームワーク
マイクロサービスアーキテクチャは2010年代半ばから普及し、Netflix、Amazon、Uber などの成功事例が広く引用されてきた。しかし2020年前後から、逆方向 ── マイクロサービスからモノリスへの部分回帰、あるいは「モジュラーモノリス」への統合 ── の事例が公表され始めた。Amazon Prime Video、Segment、Airbnb などの技術ブログが、それぞれの文脈での再統合を報告している。本稿は、モノリスとマイクロサービスの選択を、単一の「正解」ではなく組織状況に応じた判断の枠組みとして扱う。
要点
マイクロサービスは組織スケーリングの副作用として採用されるべきであり、技術的優雅さそれ自体が目的ではない。移行判断の中心変数は組織構造、運用能力、既存モノリスの内部モジュール性である。近年の再統合事例は、マイクロサービスの敗北ではなく、「早すぎた分解」の是正として理解するのが妥当である。
マイクロサービスが解決しようとした問題
Sam Newman の「Building Microservices」（第2版、2021）や Chris Richardson の「Microservices Patterns」（2018）が繰り返し強調しているのは、マイクロサービスはスケーラビリティの問題を解決するというよりも、独立したチームが独立にデプロイできる状態を作る、という組織的目標のための構造だという点である。
この観点で、Conway’s Law（1968）は本質的に重要である。「システムの設計は組織のコミュニケーション構造を反映する」という Melvin Conway の観察は、Team Topologies（Skelton & Pais、2019）で「Inverse Conway Maneuver」として実践論に落とし込まれた。つまり、目指す組織構造に合わせてシステムを分解するアプローチである。もっとも、この操作は逆方向 ── システム分解が組織の分断を強めてしまう ── としても働くため、慎重な運用を要する。
マイクロサービスの真の恩恵は、独立したデプロイ、独立したスケール、技術スタックの部分的な多様化にある。しかし、これらの恩恵を享受するには、CI/CD、observability、分散システムのエラーハンドリングという運用能力が組織に備わっていなければならない。Netflix のような組織はこの前提を満たしていたが、多くの組織はそうではなかった。
逆行事例の分析
近年公表された「マイクロサービスから戻った」事例は、共通のパターンを示している。
- Amazon Prime Video（2023年公表）： ライブストリーミングの品質モニタリング系を、複数のマイクロサービスとサーバーレス構成から単一のモノリスへ再統合し、90% のコスト削減を報告。ただし、これは全社的な方針転換ではなく、特定サブシステムに限定した判断である。
- Segment： 分散データパイプラインをマイクロサービスから re-monolith へ移行した経緯を公表。デプロイ複雑性と runtime コストの両方を挙げている。
- Istio プロジェクト自身： control plane を4つのマイクロサービスから単一の istiod プロセスに統合した。運用簡素化が主動機。
これらの事例で共通するのは、「間違ったマイクロサービス化」の是正であって、マイクロサービス全体の否定ではない点である。Martin Fowler の「MonolithFirst」ポスト（2015）は、この結論の一部を早くから予告していた。新規プロダクトはまずモノリスで始め、境界が固まってから分解する、というアプローチである。
移行判断の変数
モノリスからマイクロサービスへの移行を検討する際、以下の変数を組み合わせて判断するのが実務的である。
- 組織の独立チーム数： 2〜3チームなら通常モノリスで十分。10チーム以上になると、モノリスのデプロイキューが実質的な組織的ボトルネックになる。
- 既存モノリスのモジュール性： 内部の関数境界、パッケージ構造、DB スキーマの結合度。モノリスがすでにモジュラーであれば、マイクロサービス化の実質コストが小さい。
- 運用組織の成熟度： 分散システムの failure mode、observability、on-call 体制。これらが弱いと、マイクロサービス化は運用負担を増やすだけになる。
- 境界の明確さ： ドメイン駆動設計の bounded context が定義できているか。定義できていない状態でサービスに分解すると、API 境界が頻繁に変化し、両サービス間の結合を保つコストが増える。
PLG からハイブリッドモデルへの移行（プロダクト・レッド・グロースの限界とハイブリッドモデル）と類比的に、モノリスからマイクロサービスへの移行も「完全転換」ではなく「段階的な部分分解」として設計するのが実務的な標準になりつつある。
モジュラーモノリスという第三の選択
近年強調されているのが、「モジュラーモノリス」というアプローチである。単一のデプロイ単位を維持しながら、内部を厳密なモジュール境界で分割する。パッケージ間の依存を制御し、DB スキーマもモジュールごとに namespace 化する。Shopify の「Shopify Rails Monolith」やその他複数の企業が採用を公表している。
モジュラーモノリスの利点は、マイクロサービスへの将来的な分解を容易にすること、そして分散システムの運用複雑性を避けられることの両面にある。もっとも、モジュラー境界を維持するには、開発チームの規律と、パッケージ間の依存を機械的に検出する仕組み（linting、依存グラフ検証）が必要である。この規律を保てない組織では、モジュラーモノリスも徐々に相互依存の網に変わる。
結論
モノリスとマイクロサービスの選択は、技術判断以前に組織判断である。マイクロサービスは組織スケーリングに対する構造的解であって、技術的な優雅さのための構造ではない。逆行事例の増加は、この認識の遅れを是正する動きとして読める。新規プロダクトはモノリスで始め、境界が固まり、組織スケーリングが必要になった段階で、必要な範囲だけ分解する ── この段階的アプローチは、実務的にほぼコンセンサスに近い水準まで支持を集めている。技術基盤の選択は、AI チップのベンダーロックイン（AI チップ選択とベンダーロックインのコスト構造）と同様に、初期投資と移行コストの非対称性を長期視点で見る必要がある。
参照
- Newman, Sam. “Building Microservices, 2nd Edition.” O’Reilly, 2021.
- Richardson, Chris. “Microservices Patterns.” Manning, 2018.
- Fowler, Martin. “MonolithFirst.” martinfowler.com, 2015.
- Skelton, Matthew, Manuel Pais. “Team Topologies.” IT Revolution Press, 2019.
- Amazon Prime Video Tech Blog. “Scaling up the Prime Video audio/video monitoring service.” 2023年公表。
- Conway, Melvin. “How Do Committees Invent?” Datamation, 1968.