microservices

マイクロサービスと分散システム

マイクロサービスアーキテクチャでは、システムをそれぞれが独立してデプロイ可能なサービスに分割し、各サービスがビジネス機能を担います。モノリスのシンプルさと引き換えに、スケーリング、デプロイ、技術選択の柔軟性を得られます。この選択がメリットをもたらすのは、組織面と技術面の複雑さを正当化できる場合に限られます。

マイクロサービスとモノリスの使い分け

判断は、チームの規模、ドメインの複雑さ、運用の成熟度によって変わります。

要素	モノリスが適する場合	マイクロサービスが適する場合
チームの規模	小規模なチーム（開発者が10人未満）	独立したリリースサイクルを必要とする複数の自律的なチーム
ドメインの複雑さ	シンプル、または十分に理解されていないドメイン	明確な境界づけられたコンテキストを持つ、十分に理解されたドメイン
デプロイの頻度	リリースの頻度が低くても問題ない	システムの各部分を異なる速度でリリースする必要がある
スケーリングのニーズ	アプリケーション全体で負荷が均一	特定のコンポーネントを個別にスケーリングする必要がある
運用の成熟度	インフラストラクチャの自動化が限られている	CI/CD、監視、コンテナオーケストレーションが成熟している
データの分離	共有データベースを管理できる	サービスごとに独立したデータストアとスキーマが必要

明確な理由がない限り、まずはモノリスから始めましょう。 適切に構成されたモジュラーモノリスは、後から分解できます。時期尚早なマイクロサービスアーキテクチャは、それに見合うメリットがないまま、分散システムの複雑さを増やします。

---

サービス分割の戦略

サービスの境界を定めるのは最も難しい作業です。間違えると、分散のコストばかりかかり、メリットがない分散モノリスになってしまいます。

ビジネス機能ごとに分ける

ソフトウェアの構造ではなく、組織が何をしているかに合わせてサービスを分けます。各サービスは、注文管理、在庫、請求、通知といったビジネス機能に対応します。サービスは、それが表すビジネス機能が変わるときに変更されます。

サブドメインごとに分ける（ドメイン駆動設計）

ドメイン駆動設計の境界づけられたコンテキストを使って、自然な境界を特定します。それぞれの境界づけられたコンテキストは、独自のユビキタス言語と内部モデルを持ちます。請求コンテキストの「顧客」は、配送コンテキストの「顧客」とは異なる属性を持つ場合があります。それで問題ありません。

ストラングラーフィグ移行

モノリスから移行する際は、一度にすべてを書き換えるのではなく、サービスを一つずつ切り出します。ファサードを経由してトラフィックをルーティングし、デフォルトではモノリスに処理を委譲しつつ、新しいサービスの構築に合わせて特定の機能をそちらに振り向けます。時間をかけてモノリスを縮小し、最終的に廃止できる状態にします。移行中は、腐敗防止層によって旧モデルと新モデルの間を変換します。

分割の目安

• 候補間の結合度が高い：一緒にしておきましょう。同じサービスである可能性が高いです
• 変更頻度が異なる：個別にデプロイできるよう、分けましょう
• スケーリングの特性が異なる：必要なリソース配分が異なるため、分けましょう
• データが共有されている：二つの候補が常に同じテーブルを読み書きするなら、分割してもメリットはなく、ネットワーク通信が増えるだけです

---

通信パターン

サービスは相互に通信する必要があり、同期通信と非同期通信のどちらを選ぶかによって、システム全体の動作が変わります。

スタイル	仕組み	長所	短所
同期リクエスト／レスポンス	REST、gRPC、GraphQL	仕組みが分かりやすく、即座に応答が得られる	時間的な結合、障害の連鎖
非同期メッセージング	メッセージキュー（ポイントツーポイント）	送信側と受信側を分離でき、負荷時にバッファリングできる	インフラの追加、結果整合性
イベント駆動型	イベントバス、パブリッシュ／サブスクライブ	疎結合で、複数のコンシューマーが利用できる	デバッグが難しく、イベントの順序に関する課題がある

目安： 即時の回答が必要なクエリには同期呼び出しを使用します。送信側が結果を待つ必要のないコマンドやイベントには、非同期メッセージングを使用します。

API ゲートウェイ、サービスディスカバリー、gRPC、サービスメッシュ、サイドカーパターンについては、通信パターンのリファレンスを参照してください。

---

分散システムにおけるデータ管理

各サービスは自身のデータを所有する必要があります。データベースの共有は、サービスの独立性を損なう隠れた結合を生み出します。データを所有すると、一貫性やサービス間トランザクションに関する新たな課題が生じます。

主な原則

• サービスごとにデータベースを用意する：各サービスは独自のデータストアを持ち、アクセスはその API 経由に限ります
• データベースを直接共有しない：別のサービスがデータを必要とする場合は、データを所有するサービスのインターフェースを通じて要求します
• 結果整合性が標準です：サービス間で強い一貫性を実現するには分散トランザクションが必要ですが、壊れやすく低速です
• データストアをサービスに合わせる：アクセスパターンに応じて、サービスごとに異なるデータベース技術を使用できます

主なデータパターン

パターン	目的
CQRS	読み取りモデルと書き込みモデルを分離し、それぞれを個別に最適化します
イベントソーシング	現在の状態を上書きするのではなく、不変イベントのシーケンスとして状態を保存します
Saga	補償アクションを伴う一連のローカルトランザクションを使って、複数サービスにまたがるトランザクションを調整します
Outbox	同じデータベーストランザクション内でローカルテーブルにイベントを書き込むことで、イベントを確実に公開します
結果整合性	サービス間のデータは即時に一貫するのではなく、時間の経過とともに収束することを受け入れます

複数の言語による実装例については、データパターンのリファレンスを参照してください。

---

レジリエンスパターン

分散システムでは障害が発生します。ネットワークの分断、依存先の遅延、サービスの過負荷は、通常の運用状態です。レジリエンスパターンは、局所的な障害がシステム全体に連鎖するのを防ぎます。

パターンの概要

パターン	目的
サーキットブレーカー	障害が発生している依存先への呼び出しを停止し、迅速に失敗させて復旧の時間を確保します
バルクヘッド	リソースプールを分離し、遅い依存先がほかの処理に必要なリソースを使い果たすのを防ぎます
バックオフ付きリトライ	一時的な障害に対して、待機時間を延ばしながらランダムなジッターを加えて再試行します
タイムアウト	応答を待つ時間の上限を設定し、無期限にブロックされないようにします
フォールバック	依存先を利用できない場合に、機能を縮小しながらも動作する処理を提供します
ヘルスチェック	生存確認と準備状態のエンドポイントを公開し、オーケストレーターがトラフィックを振り分けたり、異常なインスタンスを再起動したりできるようにします

複数の言語による実装例については、レジリエンスパターンのリファレンスを参照してください。

---

リファレンスファイル

リファレンス	内容
データパターン	CQRS、イベントソーシング、サーガのオーケストレーションとコレオグラフィ、アウトボックスパターン、結果整合性（複数の言語の例を含む）
レジリエンスパターン	サーキットブレーカー、バルクヘッド、バックオフを伴うリトライ、タイムアウト、フォールバック、ヘルスチェック（複数の言語の例を含む）
通信パターン	REST、gRPC、GraphQL フェデレーション、メッセージキュー、API ゲートウェイ、サービスディスカバリー、サイドカー、サービスメッシュ（複数の言語の例を含む）

---

他のスキルとの連携

状況	推奨スキル
ドメインモデリングと境界づけられたコンテキストの設計	clean-architecture
マイクロサービスのテスト（コントラクトテスト、統合テスト）	testing
サービスインターフェースの API 設計	api-design
個々のサービスのパフォーマンスチューニング	performance