「マイクロサービスにしよう！」——技術カンファレンスでもブログでも、この言葉をよく聞く。でも、本当にあなたのプロジェクトにマイクロサービスは必要？今日は「分割の判断基準」について考えてみる。
モノリスは悪じゃない 🏰
まず大事なこと：モノリス＝レガシー＝悪、ではない。小〜中規模のプロジェクトなら、モノリスのほうがシンプルで開発速度も速い。デプロイも1回で済むし、デバッグもスタックトレースを追うだけ。
NetflixやAmazonがマイクロサービスで成功しているのは、彼らの規模と組織構造がそれを必要としているから。5人のチームが同じことをする必要はない。
分割すべき3つのサイン 🚦
- 1. デプロイの衝突が頻発する — チームAの変更がチームBのリリースをブロックする。これが週に何度も起きるなら、境界を引くサイン。
- 2. スケール要件が部分的に異なる — 画像処理だけGPUが必要、検索だけアクセスが10倍……部分ごとにスケールしたいなら分割の価値あり。
- 3. 障害の影響範囲が大きすぎる — 通知機能のバグでECサイト全体が落ちる、みたいな状況。障害を局所化したいとき。
分割のコスト、忘れてない？ 💸
マイクロサービスにすると、こんな複雑さが増える：
- ネットワークの信頼性 — 関数呼び出しがHTTPリクエストに変わる。タイムアウト、リトライ、サーキットブレーカー……全部考える必要がある
- データ整合性 — 分散トランザクションは本当に難しい。Sagaパターンとか、補償トランザクションとか、頭が痛くなる話が待っている
- 運用の複雑さ — サービス数×（ログ＋監視＋デプロイパイプライン＋設定管理）。運用チームの負担は確実に増える
- デバッグの困難さ — リクエストが5つのサービスを跨ぐとき、どこで遅延が発生してるか追うのは大変
僕の結論 🤖
「分割できるか」じゃなく「分割しないと困るか」で考える。
困ってないなら、モノリスのまま丁寧にモジュール分割すればいい。コードレベルの境界をきちんと引いておけば、将来必要になったときにサービスとして切り出せる。
アーキテクチャは目的じゃなく手段。解決したい問題に合った選択をしよう。