インフラレベルでも段階的に疎結合化
おとぎ話サーガから、結果整合かつ非同期なパラレルサーガへの移行のように、
段階的にインフラレベルまで疎結合にしていく際の
システムが疎結合になっていく過程
について、触れていきます。
同期通信の場合：物理的な近接性の重要性
同期通信（例: REST APIコール）を多用するマイクロサービス群は、インフラ層で密に連携している必要があります。
理由
同期コールは、相手からの応答を待つため、ネットワークの遅延（レイテンシー）がシステム全体のパフォーマンスに致命的な影響を与えます。
そのため、サービス群を単一のインフラ基盤（例：同じKubernetesクラスター、同じVPC内）に配置し、物理的な距離を近づけて低遅延を保つのが一般的な戦略です。
この状態でも、各アプリケーションはコンテナ化されるなどして、単独でデプロイ可能な独立性は保たれています。
非同期通信への移行：論理的な分離が物理的な分離を可能にする
ここで、間にメッセージブローカー（Kafkaなど）を挟む非同期通信に切り替えると、状況が大きく変わります。
変化
メッセージブローカーが時間的・空間的な緩衝材（バッファ）として機能するため、サービス間の通信遅延が許容されるようになります。
プロデューサーはメッセージを送ったらすぐに仕事が完了し、コンシューマーは自分のペースでメッセージを処理できます。
インフラ基盤の選択肢
①. 分離しない場合
最初は、同じインフラ基盤上で非同期サービスを運用することも全く問題ありません。
②. 分離できる場合
しかし、重要なのは、遅延が許容されるようになったことで、インフラ基盤を物理的に分離することが可能になることです。
「別のシステム」として運用されるケース
この「物理的な分離が可能になる」という特性が、より大きなアーキテクチャの実現を可能にします。
ちなみに、この段階で
どのチームがその対象システムの所有者なのか？
を必ず明らかにしておきましょう。
システムオブシステムズ
他の事業部が運用する外部システムと連携する。
ハイブリッドクラウド
オンプレミスの基幹システムと、クラウド上のマイクロサービスを連携させる。
障害影響範囲の限定
非常に重要なサービス群だけを、物理的に別のクラスターに分離して、障害の影響が波及しないようにする。
ここまでをまとめると
同期通信は、サービスを物理的に近くに配置することを強制する。
非同期通信はサービスを論理的に疎結合にし、物理的に遠くに配置することを許可
こうやって、段階的にインフラ基盤まで物理的に分離していき、独立運用可能な風にしていきましょう。
システムオブシステムズへと分割
上記でも触れたように、同期通信から非同期通信にした際に、すぐにインフラ基盤を物理的に分離するのは、アーキテクチャの可逆性担保がなされていません。
結果整合かつ非同期通信のマイクロサービスになったとしても、
しばらくはインフラ基盤は物理的には、１つの基盤にしておきましょう。
その運用期間を経て、問題なさそうであれば、インフラ基盤も分離し、一貫したポリシーの適用されたサービスメッシュ上で動かすようにすれば、
システムレベルで分離され
かつ
サービスメッシュという共通の運用ポリシーというガバナンスに沿った
システムオブシステムズとして運用できるようになります。
これは、システムの論理的な分離を、段階的に物理的な分離へと進化させ、最終的に
ガバナンスの効いた自律的なエコシステム（System of Systems）
を構築するというロードマップです。
1. 非同期化：論理的な疎結合の実現
最初のステップとして非同期・結果整合に移行することで、サービスは時間的・空間的に疎結合になります。
これにより、あるサービスの一時的な遅延や障害が、他のサービスに直接的な影響を与えにくくなります。
しかし、この段階ではまだインフラという運命共同体にいます。
インフラ層（例: Kubernetesクラスター、ネットワーク）で大規模な障害が発生すれば、全てのサービスが影響を受ける可能性があります。
2. インフラ分離 ＋ サービスメッシュ：物理的な分離とガバナンスの両立
運用が安定し、サービスが成熟した次のステップとして、インフラ分離とサービスメッシュ導入を行います。これは2つの重要な問題を同時に解決します。
どうやって障害影響範囲を完全に分離するか？ → インフラ分離
サービス（あるいは密接に関連するサービス群）を、図のようにそれぞれ独立したインフラ基盤（別のクラスター、別のVPC、あるいは別のクラウドプロバイダー）に配置します。
これにより、インフラレベルの障害が他のサービスにまで波及する
Blast Radius（爆風範囲）を完全に分離
できます。 さらに、システムは物理的にも疎結合になります。
物理的に独立したシステムをどう統治するか？ → サービスメッシュ
物理的に分離されただけでは、各システムがバラバラのセキュリティポリシーや運用ルールを持つ「サイロ」になってしまいます。
これがよく縦割りした組織で、各部署ごとに大量の似たようなシステムができ、
運用基盤が一貫していないというケースの１つの要因です。
そこでサービスメッシュが横断的なガバナンス層として機能します。
共通の観測性
どのインフラ上で動いていても、ログ、メトリクス、トレースを標準的な方法で収集します。
共通のセキュリティ
サービス間の通信は全てmTLSで暗号化する、といったポリシーを中央で強制します。
共通のトラフィック制御
カナリアリリースやサーキットブレーカーといった高度なトラフィック制御を、一貫した方法で適用します。
ここのまとめ：System of Systemsの実現
このアプローチは、システムの成熟度に合わせて、段階的に自律性と耐障害性を高めていく、現実的かつ強力な方法です。
この最終的な状態は、まさに
システムレベルで分離され、かつサービスメッシュという共通の運用ポリシーというガバナンスに沿ったSystem of Systems
そのものです。