TL;DR
- microservices の失敗は「分割しすぎ」「境界の誤り」「運用コスト見積もりミス」の3つに集中する。
- 判断軸は「コンウェイの法則に合っているか」「組織規模に合っているか」の2つ。
- 合わなければ モノリス回帰 は合理的な選択肢。撤退の選択肢を持たないのが一番危険。
はじめに
この記事はシリーズ「技術選定で後悔しないための判断基準」の 過剰設計の典型例 の深掘りです。 👉 技術選定で後悔しないための判断基準 流行との距離を測る
「とりあえず microservices」は2015〜2020年頃のブームでよく起きたパターンですが、AI 時代でも「とりあえず小さく分けた方がAIが扱いやすそう」という理由で同じ失敗が繰り返されています。モジュラーモノリス全盛の今こそ、失敗型を整理しておく価値があります。
1. 過剰分割の失敗パターン
サービス境界が CRUD 単位
「User Service」「Order Service」「Product Service」のように、テーブル単位でサービスを切るのは典型的な失敗です。1つの業務フローで3つのサービスを跨ぎ、分散トランザクションとサーガの実装に追われます。境界はテーブルではなく**業務能力（capability）**で引くのが原則。
サービスが20以上で7人以下のチーム
サービス数 > 人数 × 3 を超えると、オンコール・デバッグ・バージョニングが追いつきません。経験則では、1人あたり3サービスが運用の上限。それ以上は「自分が書いたコードを誰も知らない」状態に陥ります。
共有DB を残したまま分割
分割した振りをしただけで、裏で同じ DB を触っているパターン。「分散モノリス」と呼ばれ、モノリスの欠点（変更影響が広い）と microservices の欠点（通信コスト）の両取りになります。
# アンチパターン: 共有DB
services:
user-service:
env: DB_HOST=shared-pg.internal # ←これがダメ
order-service:
env: DB_HOST=shared-pg.internal # ←テーブル分けでは意味がない
分割を本当にやるなら、DB も物理的に分けて、跨ぐ時は API / event 経由のみにします。関連する責務設計の原則は AIが迷わないリポジトリ設計 も参考になります。
2. モノリス回帰の判断軸
回帰は恥ずかしいことではありません。以下のシグナルが2つ以上出たら検討します。
| シグナル | 意味 |
|---|---|
| デプロイの90%が複数サービス同時 | 境界が機能していない |
| サービスを跨ぐ障害が月3件以上 | 通信コストが品質を下回っている |
| 新人オンボーディングが3ヶ月超 | 認知負荷が組織規模を超えている |
git grep が使えない（リポが多すぎ） | コード横断の調査が困難 |
回帰先は完全なモノリスである必要はなく、モジュラーモノリス（1リポ・1デプロイだがモジュール境界明確）が現実的な落とし所です。
3. 適切な分割粒度
分割が必要なのは以下のケース:
- SLA が大きく異なる（リアルタイム処理と夜間バッチ）
- スケール特性が異なる（CPU重い / メモリ重い / I/O重い）
- チームが地理的に分散（コンウェイの法則）
逆に以下は分割しない方が良い:
- データ整合性が強く要求されるドメイン
- 認知負荷が既に高く、チーム拡大予定がない
- 監視・デプロイ基盤が未整備
分割する場合も、責務設計を先に固めることが重要です。観測の前提整理は AIガバナンスの権限マトリクス も参考に。
まとめ
microservices は「分ければ良い」ものではなく、組織とSLA に合わせて選ぶアーキテクチャ。分割を戻す選択肢を最初から持っておくのが、一番安全です。
全体像に戻る: 親記事はこちら
技術選定の運用フレームは Technology Radar の作り方｜30分会議テンプレ付 を参照（Adopt / Trial / Assess / Hold で月次運用に乗せる）。
