マイクロサービス化の甘い罠——モノリスが正解なケースとは

「マイクロサービスにすれば解決する」という幻想

スケーラビリティ問題、チーム間のコンフリクト、デプロイ頻度の低下——こうした課題に直面したとき、「マイクロサービスへの移行」が魔法の解決策として語られることがあります。

しかし現実は違います。多くのチームにとって、マイクロサービスは問題を増やします。

マイクロサービスが持ち込む複雑性

モノリス（単一アプリ）とマイクロサービスの比較を正直に見てみましょう。

これらはすべてマイクロサービスが生む問題です。モノリスにはこれらの多くが存在しません。

マイクロサービスが本当に必要な条件

マイクロサービスが合理的な選択になるのは以下の条件が揃った場合です。

✅ チームが 50 人以上で、デプロイのコンフリクトが頻発している
✅ 機能ごとに異なるスケーリング要件がある（決済と通知では負荷特性が違う）
✅ 技術スタックを変えたい部分が特定されている（例：機械学習部分だけ Python）
✅ SRE・DevOps チームが分散システムの運用経験を持っている

逆に言えば、スタートアップや 10〜20 人規模のチームでは、ほぼ確実にモノリスの方が生産性が高い。

「マイクロサービス失敗談」のパターン

パターン A：分散モノリス

サービスを分けたが、お互いに強く依存している状態。

注文サービス ←→ 在庫サービス ←→ 顧客サービス
   ↕                                  ↕
配送サービス ←──────────────────── 通知サービス

1 サービスを変更するとき、他のサービスも同時にデプロイが必要になる。これはモノリスの欠点をすべて引き継いだ上に、分散システムの複雑さも加わっています。

パターン B：ネットワーク関数呼び出し

本来、モノリスで 1 ミリ秒以下で完了する処理が、HTTP 越しに呼び出しを繰り返すことで数百ミリ秒かかるようになる。

# モノリス（関数呼び出し）
total = calculate_price(items) + get_discount(user_id)

# マイクロサービス（ネットワーク呼び出し）
price = requests.get("http://pricing-service/calculate", json=items).json()
discount = requests.get(f"http://discount-service/user/{user_id}").json()
total = price + discount

2 回のネットワーク呼び出し + JSON シリアライズ/デシリアライズ + タイムアウト処理 + リトライ……が必要になります。

パターン C：サービス間トランザクション問題

注文確定  → 在庫を減らす → 決済処理 → 通知を送る

在庫を減らしたあと決済に失敗したら？
決済後に通知サービスが落ちていたら？

モノリスなら BEGIN; ... COMMIT; で解決できた問題が、分散環境ではSagaパターンやイベント駆動等の複雑な設計が必要になります。

モノリスを正しく育てる

多くのシステムにとって、最適解はモジュラーモノリスです。

モノリスの中を整理する：
- 注文モジュール（src/modules/order/）
- 在庫モジュール（src/modules/inventory/）
- 通知モジュール（src/modules/notification/）

ルール：モジュール間はインターフェース経由でのみ通信する

将来マイクロサービス化したくなったとき、このモジュールがサービスの境界になります。段階的な移行が可能です。

判断のフローチャート

「マイクロサービスが必要か？」

モノリスで本当に困っているか？
  → No: モノリスを続ける

具体的に何が問題か？
  → デプロイ頻度 / チームコンフリクト / スケーリング

まずモジュールの分離で解決できないか？
  → Yes: モジュラーモノリスを整備する

分散システムを運用できる SRE がいるか？
  → No: まず体制を整える

→ ここまで来たらマイクロサービスを検討

まとめ

• マイクロサービスは「小さなモノリスの集合体」ではなく、分散システムである
• 開発・デバッグ・運用の複雑さが桁違いに増す
• 10〜30 人規模なら、まずモジュラーモノリスで十分
• マイクロサービスが本当に必要な理由（チーム規模・スケーリング要件・技術スタック）を明確にしてから移行する

「アーキテクチャはツールであり、目的ではない」——この前提に立つと、適切な選択ができます。