モノリスに戻る勇気 — マイクロサービス疲れの現場から

1. 分割の目的を見失うと起きること

マイクロサービス化は本来、チームの自律性とデプロイの独立性を高めるための手段だった。しかし、サービスの数がチームの人数を上回り、1つの機能変更のために5つのサービスへ同時にプルリクエストを出す必要がある状態になると、分割は目的ではなく負債になる。

2. 実例で見る：Amazon Prime Videoの90%コスト削減

抽象論だけでなく、実際に統合へ舵を切った事例を見てみたい。Amazonの動画配信部門「Prime Video」のあるチームは、配信中の映像・音声品質をリアルタイムに分析する監視ツールを、サーバーレス構成のマイクロサービス群（AWS Step Functionsによるオーケストレーション）として構築していた。しかし、この構成は大規模なスケールに対してオーケストレーション層自体がボトルネックになるという問題に直面したと2023年に公表された事例で報告されている。

対応として、チームは分散していたコンポーネントを単一プロセスへと統合し、EC2・ECS上で軽量なオーケストレーション層のみを残す構成に作り替えた。この統合により、インフラコストを90%削減したと報告されている。重要なのは、これがPrime Video全体の話ではなく、あくまで特定の監視ツールというワークロードに限定した事例だという点だ。「マイクロサービスは悪、モノリスが正義」という単純な話ではなく、そのワークロードの特性（今回の場合は、すべての配信ストリームをリアルタイムに処理する必要がある高頻度・低レイテンシ処理）に対して、分散オーケストレーションのオーバーヘッドが見合っていなかった、という個別の設計判断だったと理解するのが正確だろう。

3. 統合を検討すべきサイン

• サービス間の呼び出しが同期的かつ密結合で、単独でデプロイできるサービスがほとんどない
• 障害調査のたびに複数サービスのログを手動で突き合わせる必要がある
• チームの人数がサービス数より少なく、1人が複数サービスの「なんでも屋」になっている
• Prime Videoの事例のように、オーケストレーション層自体のコスト・レイテンシが、分割によって得られるはずの柔軟性の利益を上回っている

4. 統合は後退ではなく設計判断

サービスを統合し直すことは、マイクロサービス化の失敗を意味しない。むしろ、実際のチーム構成とデプロイ頻度、そしてワークロードの特性に対して分割粒度が合っていなかったことを認め、運用コストに見合う形に設計を引き戻す、正当な設計判断である。Prime Videoの事例が示すように、この判断は「全部を戻す」のではなく、特定のコンポーネント単位で個別に見直すという粒度で行われることが多い。自社のアーキテクチャを見直す際も、システム全体を一律に評価するのではなく、コンポーネントごとに「分割のコストが利益を上回っていないか」を個別に問い直すことが実務的な出発点になる。