エピローグ — マイクロサービスは銀の弾丸ではない

移行プロジェクトが始まってから12ヶ月後。

ShopNovaの技術戦略ボードの前で、ミサキは発表を終えた。

「以上が、マイクロサービス移行の1年間の成果です」

1年間の成果

達成できたこと

Loading diagram...

Before: モノリス時代
  デプロイ: 月2回（深夜メンテナンス）
  障害時: サイト全体停止
  スケール: 全サーバーを増強（30分）
  デプロイ承認: リリース委員会（1週間待ち）

After: マイクロサービス時代（1年後）
  デプロイ: 1日最大10回（営業時間中も可能）
  障害時: 該当サービスのみ影響（他は継続稼働）
  スケール: 必要なサービスのみ増強（3分）
  デプロイ承認: 各スクワッドが独立して判断

あの深夜2時17分の障害は二度と起きていない。検索サービスが重くなっても、注文処理は影響を受けない。

払った代償

だが、CTOが鋭い質問をした。「成果は分かった。でも何を失ったか教えてくれ」

ミサキは正直に答えた。

複雑性の増大

# モノリスでの問題確認: 1箇所を見るだけで分かった
# log/production.log を grep するだけ
 
# マイクロサービスでの問題確認: 複数のログを横断
# CloudWatch Logs Insights でクエリ
# X-Ray でトレースを追跡
# 各サービスのメトリクスを確認
# → 障害対応のスキルセットが必要

運用コストの増大

# モノリス時代のインフラ
infrastructure:
  app_servers: 3台
  database: 1台（RDS）
  redis: 1台
  管理対象: 5台
 
# マイクロサービス時代のインフラ
infrastructure:
  ecs_services: 8サービス
  databases: 5（Aurora、DynamoDB）
  queues: 12（SQS）
  topics: 6（SNS）
  api_gateway: 1
  cloudwatch_dashboards: 4
  pact_broker: 1
  管理対象: 莫大
  月額コスト: 3.2倍に増加

開発速度の低下（初期）

新機能「ユーザーランク制度」の開発:

モノリス時代の想定:
  1人のエンジニアが3日で実装できた

マイクロサービス時代の実際:
  ユーザーサービス側: 2日
  注文サービス側（ランク計算イベント追加）: 1日
  コントラクトテスト更新: 1日
  統合テスト: 1日
  合計: 5日（複数の人間が協調必要）

WARNING

マイクロサービスへの移行直後、機能開発速度は確実に低下する。組織がアーキテクチャに慣れるまで、通常6〜12ヶ月かかる。これは避けられない「移行コスト」として経営陣と合意しておくこと。

いつマイクロサービスを選ぶべきか

「では、最初からマイクロサービスにするべきだったか？」とCTOが聞いた。

ミサキは首を横に振った。

「おそらく違います。ShopNovaが月間GMV10億円のころなら、モノリスが最適だったと思います」

マイクロサービスが有効な条件（AND条件）:

  ✓ 組織の規模: 開発チームが50人以上
    → チームが独立してデプロイできる必要がある規模

  ✓ スケール要件: 機能ごとにスケールニーズが大きく異なる
    → 検索と注文で100倍のスケール差がある

  ✓ 技術的成熟度: CI/CD、コンテナ、可観測性の基盤がある
    → 「デプロイが自動化できていない」なら先にやること

  ✓ ドメイン理解: ビジネスの境界が明確に見えている
    → 2年以上運用して、変更の頻度・パターンが分かっている

  ✗ 以下の場合はモノリスを選ぶ:
    - スタートアップ初期（ドメインが未確定）
    - チームが10人以下
    - プロダクトマーケットフィットを探している段階
    - 可観測性・CI/CDの基盤がない

モノリスの価値を再評価する

移行から1年で、ミサキはモノリスについて新しい見方を得た。

# モノリスの強み（移行してから気づいたこと）
 
# 1. デバッグのしやすさ
#    全てのコードが1プロセス → ローカルで完全再現できる
#    マイクロサービス: 8サービスをDockerで立ち上げる必要がある
 
# 2. トランザクションの簡単さ
ActiveRecord::Base.transaction do
  order = Order.create!(...)
  inventory.decrement!
  user.add_points!
  # この3行が全部成功か全部失敗 → これは本当に便利
end
# マイクロサービス: サーガパターンで500行必要
 
# 3. 新規機能開発の速さ
# モノリス: 1つのPRで完結
# マイクロサービス: 複数サービスのPRを協調してマージ
 
# 4. ローカル開発環境
# モノリス: rails server だけ
# マイクロサービス: docker-compose up で8サービス起動（重い）

モジュラーモノリス: 第三の選択肢

「最初からマイクロサービスでもなく、スパゲッティなモノリスでもない」第三の道がある。

# モジュラーモノリス: モノリスだが、内部でモジュールが独立している
# app/modules/
#   ├── user_module/
#   │   ├── models/
#   │   ├── services/
#   │   └── api/
#   ├── product_module/
#   │   ├── models/
#   │   ├── services/
#   │   └── api/
#   └── order_module/
#       ├── models/
#       ├── services/
#       └── api/
 
# モジュール間の通信はインターフェースを通じて
module OrderModule
  class OrderService
    def create(user_id:, items:)
      # ProductModuleの内部実装を知らない
      product = ProductModule::Api.find_product(items.first[:product_id])
      # ↑ 将来、これをHTTPクライアントに変えるだけでサービス化できる
    end
  end
end

INFO

「モジュラーモノリスは、マイクロサービスへの移行の前段階として最適。モジュール間の境界を先に設計しておくことで、必要になったタイミングで安全にサービス化できる」 — ミサキのチームが最終的に得た知恵。

マイクロサービス移行のロードマップ

将来の移行を計画するチームへのアドバイス：

Loading diagram...

移行ロードマップ（12-18ヶ月）:
 
Month 1-3: 基盤整備
  - CI/CD パイプラインの自動化
  - コンテナ化（Dockerファイル作成）
  - 可観測性の基盤（CloudWatch、X-Ray）
  - モジュラーモノリスへのリファクタリング
 
Month 4-6: 最初のサービス分離（検索サービス）
  - スケール要件が最も高いサービスから
  - Strangler Figパターンで段階的移行
  - コントラクトテストの整備
 
Month 7-12: 残りのサービス分離
  - ユーザーサービス、商品サービス
  - 注文・決済サービス（最も複雑 → 最後）
  - 各移行後に必ず振り返り

最終的な教訓

「マイクロサービスは技術の問題じゃなかった」

1年間を振り返って、ミサキが出した結論だ。

「組織構造の問題だった。コンウェイの法則通り、アーキテクチャは組織を映す鏡だった。チームを独立させたことで、アーキテクチャも独立できた」

コンウェイの法則:
「組織が設計するシステムは、組織のコミュニケーション構造を
 コピーしたものになる」

→ マイクロサービスにしたいなら、
  先にチームを独立させる（逆コンウェイ戦略）

この本を閉じる前に

あなたがこの本を読んだのは、ShopNovaのような問題を抱えているからかもしれない。あるいは、将来の準備として読んでいるかもしれない。

どちらの立場でも、最後にこれだけ覚えていてほしい：

マイクロサービスは「目的」ではなく「手段」だ。

目的は:
  ✓ 開発チームが自律的に動けること
  ✓ 一部の障害が全体に波及しないこと
  ✓ 必要な部分だけスケールできること
  ✓ 技術的選択の自由があること

モノリスでこれらを達成できるなら、モノリスを選べ。
マイクロサービスはコストが高い。そのコストを払う価値があるときだけ選べ。

そして、どちらを選ぶにせよ:
  - テストを書け
  - CI/CDを自動化しろ
  - 可観測性を先に作れ
  - チームの自律性を先に確保しろ

ミサキはプレゼンを終えて、窓の外の夜景を見た。

ShopNovaのサイトは今も動いている。あの夜の「サイト全体停止」は、12ヶ月前の話になった。

「次のチャレンジは何ですか？」とケンジが聞いた。

「データプラットフォーム。全サービスのデータを統合して、リアルタイム分析を——」

終わりは、いつも次の始まりだ。

参考リソース

推薦図書:
  - 「マイクロサービスパターン」Sam Newman
  - 「モノリスからマイクロサービスへ」Sam Newman
  - 「ドメイン駆動設計」Eric Evans

AWS ドキュメント:
  - ECS Best Practices Guide
  - Well-Architected Framework（マイクロサービス）
  - EventBridge ユーザーガイド

コミュニティ:
  - martinfowler.com（パターンの参照元）
  - AWS Architecture Blog

ShopNova とミサキの物語はここで終わる。

あなたの物語はここから始まる。