モノリスからマイクロサービスへの進化

はじめに

「最良」のアーキテクチャは存在しません。「現在の段階に最適な」アーキテクチャがあるだけです。 モノリスからマイクロサービスへの移行は、一足飛びのジャンプではなく、ビジネス規模とチーム規模の成長に伴う段階的な進化のプロセスです。早すぎる分割も遅すぎる分割も同じように危険です。

この記事で何を学べるのか？

この章を読み終えると、以下のことが身につきます：

• 進化の道筋：モノリスからマイクロサービスへの4つの段階を理解する
• 分割のタイミング：いつ分割すべきか、いつ分割すべきでないかを知る
• 分割戦略：ビジネスドメインに基づく分割の手法論を習得する
• 通信パターン：サービス間の同期・非同期通信の選択肢を理解する
• データ分割：データベース分割の課題とソリューションを理解する

章	内容	核心概念
第1章	アーキテクチャの進化の道筋	モノリス→モジュラーモノリス→SOA→マイクロサービス
第2章	分割のタイミングと原則	Conwayの法則、チームの自律性
第3章	分割戦略	DDDの境界付けられたコンテキスト、ストラングラーパターン
第4章	サービス間通信	REST、gRPC、メッセージキュー
第5章	データ分割	データベース分割、データ同期

---

1. アーキテクチャの進化の道筋

アーキテクチャの進化は技術主導ではなく、組織規模主導です。チームが5人から500人に成長すると、モノリスアーキテクチャの協調効率は急激に低下します。

段階	アーキテクチャ	チーム規模	特徴
起動期	モノリスアプリケーション	1~10人	すべてのコードが1つのプロジェクトにあり、デプロイがシンプル
成長期	モジュラーモノリス	10~50人	コードはモジュールごとに分割されているが、一緒にデプロイされる
拡大期	SOA（サービス指向）	50~200人	ビジネスラインごとに粗粒度のサービスに分割
規模期	マイクロサービス	200人以上	細粒度サービス、各チームが独立して開発・デプロイ

Architecture Evolution Path

Click each stage to inspect its architecture characteristics

1

Monolithic architecture

2

Modular monolith

3

Service-oriented architecture

4

Microservices architecture

Monolithic architecture

All features are packaged in one application and share one database. It is simple and suitable for early rapid iteration.

User module

Order module

Payment module

Product module

Monolith app (one process)

MySQL

Suitable scale:Team < 10 people, DAU < 100k

Core challenge:Code is tightly coupled; a bug in one module may bring down the whole system

Conwayの法則

「システムを設計する組織は、その組織のコミュニケーション構造と同等のアーキテクチャを生み出す。」——Melvin Conway

簡単に言えば、3つのチームが1つのシステムを作ると、最終的に3つのサービスになります。アーキテクチャ分割の本質は組織の分割です。

逆Conwayの法則：組織構造がシステムアーキテクチャを決めるなら、欲しいアーキテクチャに合わせてまず組織構造を調整すればよい。例えば、独立した決済サービスを分割したいなら、まず独立した決済チームを結成する。多くの企業でマイクロサービスの分割が失敗するのは、技術の問題ではなく、組織が追いついていないからです。

---

2. いつマイクロサービスに分割すべきか？

すべてのシステムがマイクロサービスを必要とするわけではありません。早すぎる分割は不要な複雑さをもたらします。

シグナル	説明	推奨
デプロイの衝突が頻発	複数チームが同じコードベースを変更し、頻繁に衝突する	分割を検討
特定モジュールが単独スケールアウトを必要とする	検索モジュールが他のモジュールの10倍のリソースを必要とする	分割を検討
技術スタックの差別化が必要	AIモジュールはPython、メインサイトはJava	分割を検討
チームが10人未満	コミュニケーションコストが低く、モノリスで十分	分割しない
ビジネスがまだ探索段階	要件の変化が激しく、境界が不明確	分割しない
DevOpsの能力がない	CI/CD、コンテナ化、監視体制がない	分割しない

---

3. 分割戦略

3.1 ビジネスドメインによる分割（DDDの境界付けられたコンテキスト）

DDD（ドメイン駆動設計）の境界付けられたコンテキスト（Bounded Context）は、マイクロサービス分割の最良の指導原則です。各境界付けられたコンテキストは独立したビジネスドメインに対応し、独自のデータモデルとビジネスルールを持ちます。

境界付けられたコンテキストとは？ 同じ言葉でもビジネスドメインによって意味が異なります。例えば「ユーザー」は、ユーザードメインでは登録情報（氏名、メールアドレス）を指し、注文ドメインでは注文者（配送先住所、支払い方法）を指し、レコメンドドメインでは行動プロファイル（閲覧履歴、嗜好タグ）を指します。境界付けられたコンテキストは、その境界内で用語とモデルが明確で統一された意味を持つように範囲を定めるものです。

┌─────────────┐  ┌─────────────┐  ┌─────────────┐
│  ユーザー    │  │  注文       │  │  決済       │
│  ドメイン    │  │  ドメイン   │  │  ドメイン   │
│             │  │             │  │             │
│ User        │  │ Order       │  │ Payment     │
│ Profile     │  │ OrderItem   │  │ Refund      │
│ Address     │  │ Cart        │  │ Transaction │
│             │  │             │  │             │
│ ユーザー    │  │ 注文        │  │ 決済        │
│ サービス    │  │ サービス    │  │ サービス    │
└──────┬──────┘  └──────┬──────┘  └──────┬──────┘
       │                │                │
       └────── API呼び出し / イベント通信 ───────┘

境界付けられたコンテキスト	コアエンティティ	対応サービス
ユーザードメイン	User、Profile、Address	ユーザーサービス
商品ドメイン	Product、Category、SKU	商品サービス
注文ドメイン	Order、OrderItem	注文サービス
決済ドメイン	Payment、Refund	決済サービス
物流ドメイン	Shipment、Tracking	物流サービス

3.2 ストラングラーパターン（Strangler Fig Pattern）

モノリス全体を一度に書き直すのではなく、ストラングラーフィグのように段階的に新しいサービスで古いモジュールを置き換えます：

1. モノリスの外部に新しいサービスを作成する
2. プロキシ層を通じて一部のトラフィックを新しいサービスにルーティングする
3. 新しいサービスの安定性を確認した後、徐々にトラフィックを移行する
4. 最終的に古いモジュールを完全に置き換える

---

4. サービス間通信パターン

方式	プロトコル	特徴	適用シナリオ
REST	HTTP/JSON	シンプルで汎用的、エコシステムが豊富	外部API、CRUD操作
gRPC	HTTP/2 + Protobuf	高性能、強い型付け	内部サービス間の高頻度呼び出し
メッセージキュー	AMQP/Kafka	非同期疎結合、ピークの平滑化	イベント通知、非同期タスク
GraphQL	HTTP/JSON	クライアントが必要なデータだけを取得	BFF層、モバイル

同期 vs 非同期の選択

• すぐに結果を返す必要がある → 同期（REST/gRPC）
• すぐに結果を返す必要がない → 非同期（メッセージキュー）
• 1つのイベントが複数のアクションをトリガーする → 非同期（パブリッシュ・サブスクライブ）

経験則：非同期で済むなら非同期にする。同期呼び出しのチェーンが長いほど、システムは脆弱になる。

---

5. データ分割：最も困難な部分

マイクロサービス分割で最も苦痛なのはコードの分割ではなく、データベースの分割です。各サービスは独自のデータベースを持つべきですが、それはサービスをまたぐクエリが困難になることを意味します。

課題	説明	ソリューション
クロスサービスJOIN	2つのサービスのテーブルを直接JOINできない	APIによる複合クエリ、データの冗長化
分散トランザクション	クロスデータベースのトランザクションをローカルトランザクションで処理できない	Saga、ローカルメッセージテーブル
データ一貫性	複数サービスのデータが一時的に不整合になる可能性	結果整合性、イベント駆動
データ移行	共有データベースから独立データベースへの移行	デュアルライト移行、データ同期ツール

---

まとめ

モノリスからマイクロサービスへの移行は段階的なプロセスであり、一足飛びの革命ではありません。

本章の主要なポイントを振り返りましょう：

1. 進化の道筋：モノリス→モジュラーモノリス→SOA→マイクロサービス、各段階には明確な推進力がある
2. 分割のタイミング：チーム規模、デプロイの衝突、スケーリングの必要性が分割のシグナル
3. 分割戦略：DDDの境界付けられたコンテキストで分割を指導し、ストラングラーパターンで段階的に移行する
4. 通信の選択：非同期で済むなら非同期にし、同期呼び出しのチェーンは短くする
5. データ分割：最も困難だが最重要であり、結果整合性を受け入れることが重要なマインドシフト

関連資料

• Building Microservices - Sam Newmanのマイクロサービスの古典
• Monolith to Microservices - 段階的移行ガイド
• Domain-Driven Design - Eric EvansのDDDの古典
• The Strangler Fig Pattern - Martin Fowlerのストラングラーパターン