arch-microservices

1 行の概要

システムを、それぞれがデータを所有し、ビジネス能力に沿った、独立してデプロイ可能なサービスに分割します。ネットワーク経由で通信します。自律性と独立したスケーリングを得るために、運用コストを受け入れます。

このスキルを使う場面

• 単一のコードベース／デプロイ環境で、複数のチームが互いの作業を妨げている場合。
• システムの各部分に独立したスケーリング特性が必要な場合（一方は CPU バウンド、もう一方は I/O バウンド、さらに別の部分はバースト的に負荷が増加するなど）。
• 各部分のリリース頻度が異なり、あるチームのデプロイが別のチームを妨げてはならない場合。
• 各部分の信頼性要件が異なる場合（重要な決済経路と、重要度の低い分析ダッシュボードなど）。

このスキルを使わない場面

• 1 チーム、1 製品で、スケーリングの課題がない場合 — マイクロサービスが解決する問題はありません。モノリスを維持してください。
• サービス境界を定められるほどドメインを理解していない場合 — 時期尚早な分割を元に戻すには、多大なコストがかかります。
• 運用の成熟度が不足している場合（CI/CD、オブザーバビリティ、オンコール体制がない） — マイクロサービスは運用上の負担を増幅させます。
• 履歴書のための開発。やめましょう。

主な内容

サービス境界は技術レイヤーではなく、ビジネス能力に沿って定めます。 customer-service、orders-service、pricing-service は適切です。database-service、api-service、cache-service はアンチパターンです。境界は通常、DDD の境界づけられたコンテキストに沿って定めます（ddd-bounded-context を参照）。

各サービスは自身のデータを所有します。 データベースを共有してはいけません。サービス B がサービス A のデータを必要とする場合、B は A の API を呼び出すか、A がイベントを発行し、B がそれを購読します。2 つの「マイクロサービス」の下でデータベースを共有すると、分散モノリスになります。これは両方の悪いところを併せ持つ状態です。

通信パターン。

• 同期（REST、gRPC）。 直接的で理解しやすい一方、レイテンシーが相互に影響します。呼び出し側が即座に応答を必要とする、クエリー中心のパターンに使います。
• 非同期（イベント、arch-event-driven を参照）。 時間的な結合がなく、結果整合性を前提とします。複数のサービスにまたがるワークフローに使います。

本番システムでは、ほとんどの場合、両方を組み合わせます。

エッジパターン。

• API ゲートウェイ — 外部クライアント向けの単一の入口です。認証、レート制限、ルーティング、レスポンスの組み立てを担います。クライアントと内部サービスの構成を分離します。
• Backend for Frontend（BFF） — クライアントの種類（モバイル、ウェブ、パートナー API）ごとに調整されたゲートウェイです。「1 つのゲートウェイですべてのクライアントに対応する」という落とし穴を避けます。
• サービスメッシュ（Istio、Linkerd） — トラフィック、mTLS、リトライ、オブザーバビリティを処理するサイドカープロキシです。横断的なインフラ機能をサービスの外に移します。大規模環境では正当化できますが、サービス数が約 10 未満の場合は過剰です。

アンチパターンに注意：分散モノリス。 サービスは独立してデプロイされているものの、密結合しています（データベースの共有、同期呼び出しの連鎖、同時リリースなど）。マイクロサービスの運用コストをすべて負担しながら、自律性のメリットは得られません。最も解消が困難な状態です。

判断の指針

• まずはモノリスを選びます。 マイクロサービスが解決するのは、チームの自律性、独立したスケーリング、障害の分離といった特定の問題です。そうした問題がなければ、このアーキテクチャスタイルは必要ありません。
• サービス境界は境界づけられたコンテキストに沿わせます。まず ddd-bounded-context を使い、分割を先に決めるのではなく、コンテキストを分割の指針にします。
• 独自のデータを所有しないサービスは要注意です。通常はアダプターまたはコーディネーターであり、別の場所に置くべきです。
• 1 回のユーザーリクエストに対し、3 を超えるサービスを同期的に連鎖して呼び出す場合は、分割が適切でない可能性があります。イベントを使うか、境界を見直してください。
• クライアントの種類によって要件が大きく異なる場合は BFF を使います。異ならない場合は、コンテンツネゴシエーションに対応したゲートウェイを使います。

アンチパターン

• 分散モノリス。 同時にリリースしなければならないサービスです。両方の悪いところを兼ね備えています。
• ナノサービス。 クラス単位でリリースするほど小さなサービスです。調整コストが、分割によるメリットを上回ります。
• 共有データベース。 2つのサービスが同じテーブルを読み書きしているなら、それらは分離されていません。
• 同期呼び出しの連鎖。 1つのユーザーリクエストに対して、サービスAがBを呼び、BがCを呼び、CがDを呼びます。それぞれがレイテンシと障害発生の可能性を増やし、どれか1つが失敗すれば連鎖全体が失敗します。
• Netflixが採用しているからという理由でマイクロサービスを選ぶこと。 Netflixが解決したのはNetflixの問題であり、あなたの問題とは異なります。

関連項目

• ddd-bounded-context — サービス境界は境界づけられたコンテキストに従うべきです。
• arch-event-driven — 標準的な非同期通信方式です。
• arch-saga — 分散トランザクションを調整します。
• arch-circuit-breaker — サービス間の障害を隔離します。
• arch-strangler-fig — モノリスからマイクロサービスへ移行します。

参考資料

• Richards & Ford、Fundamentals of Software Architecture、第17章（マイクロサービス）。
• Sam Newman、Building Microservices（O'Reilly）。
• Sam Newman、Monolith to Microservices（O'Reilly）。
• Khononov、Learning DDD、第14章（マイクロサービス）。