マイクロサービスアーキテクチャで40サービス・1リクエストが28サービスを叩く設計¶
要約¶
「40のマイクロサービスがあり、1ユーザーリクエストがそのうち28をたたく」という設計への問いかけ。リプライでは「分散モノリス」「28の障害ポイント」という批判が集まった。マイクロサービスは分割すれば良いのではなく、サービス間の依存を管理できる粒度に設計する必要がある。
ポイント¶
- 1リクエストが多数のサービスを同期呼び出しする設計は「分散モノリス」と揶揄される
- 障害ポイントが28箇所あることを意味し、可用性の計算式（0.999^28）では著しく低下する
- サービス境界設計が不十分なまま分割した結果として生じやすいアンチパターン
- 対策: ドメイン境界に沿ったサービス分割、非同期化、BFF（Backend for Frontend）などの集約層導入
考察¶
過剰な分割よりも「なぜ分割するか」の目的に立ち返る必要がある。デプロイ独立性・スケーラビリティ・チーム独立性のいずれを狙うかによって適切な粒度は変わる。