インフラレベルでの結合
エピックサーガやおとぎ話サーガのように、マイクロサービス間の通信が同期通信の形態を主としている場合、それはアプリケーションレベルではサービスが分割されていても、実質的に「インフラ部分（特にネットワーク層）で密結合」の状態に陥っていると言えます。
これは、マイクロサービスアーキテクチャにおける一般的なアンチパターンである「分散モノリス」の典型的な症状の一つです。
だからといって、エピックサーガやおとぎ話サーガがダメなわけではないです。
理想形に段階的に近づけるうえで、これらの一定期間分散モノリス構造を取ることは、理にかなっているからです。
エピックサーガやおとぎ話サーガは、アプリケーションという上物としては、確かに独立性が高まっています。
おとぎ話サーガに関していうのなら、
【上物としては、確かに単独でデプロイ可能】と言える状態です。
【インフラまで含めたら単独デプロイ不可能】という状態。
今回は、同期通信だと、なぜインフラレベルで蜜結合なのか？について説明していきます。
なぜ同期通信だとインフラレベルで密結合になるのか？
1. ネットワークの可用性・パフォーマンスへの直接依存
密結合のメカニズム
同期通信（例: REST APIの直接呼び出し）では、サービスAがサービスBを呼び出した際、
サービスBからの応答が返ってくるまでサービスAは処理をブロックして待ち続けます。
インフラ結合
このとき、サービスAの処理の可否やパフォーマンスは、
サービスBの可用性（Bがダウンしていないか）、Bのパフォーマンス（Bの応答が遅くないか）、そしてサービスAとB間のネットワークの安定性（ネットワーク遅延や障害がないか）に直接依存してしまいす。
結果
ネットワークのどこかで問題が発生したり、呼び出し先のサービスが応答しなかったりすると、呼び出し元のサービスがハングアップしたり、タイムアウトしたりして、障害が連鎖的に波及しやすくなります。
これは、インフラ（ネットワークやサービスインスタンスの健全性）が原因で、アプリケーションの処理が停止するという密結合の状態です。
2. デプロイ時の結合
密結合のメカニズム
同期通信は、呼び出し元と呼び出し先のAPIの互換性を強く要求します。
呼び出し先のサービスBがAPIの破壊的変更を伴う新しいバージョンにデプロイされた場合、
呼び出し元のサービスAも、その変更に対応するバージョンにデプロイされていなければ、通信が破綻します。
しかもこれは、サービスAは常にサービスBのバージョンを気にしながら
という２つのチームのコミュニケーション調整コストも増大させます。
インフラ結合
この依存関係は、デプロイメントパイプラインにおいて、
サービスAとサービスBが同時に、あるいは特定の順序でデプロイされる必要がある
というインフラレベルの制約を生み出します。
つまり、各サービスが独立してデプロイできるというマイクロサービスの大きなメリットが失われます。
3. スケーリングの制約
密結合のメカニズム
同期通信では、呼び出し元サービスの負荷が増大すると、それに比例して呼び出し先サービスの負荷も増大します。
インフラ結合
サービスAのインスタンスを増やしても、サービスBのキャパシティが不足していれば、
そこのパフォーマンスがボトルネックになります。(TOC制約理論)
インフラのパフォーマンス改善のためには、両方のインスタンスを増やす必要があるため、シンプルにコストも増大します。
これにより、個々のサービスを独立してスケールするという柔軟性が失われ、サービス間のインフラキャパシティが結合されてしまいます。
4. 単一障害点（SPOF）化のリスク
密結合のメカニズム
同期呼び出しのパスが連鎖すると、そのパス上のどこか一つでも障害が発生すると、
全体の処理が停止する可能性があります。
インフラ結合
サービス間のネットワーク経路や、呼び出されるサービスの特定のインスタンスが、事実上の単一障害点となり、アプリケーションレベルでの回復力（リトライ、サーキットブレーカーなど）が実装されていないと、脆弱になります。
正しい疎結合の追求
マイクロサービスアーキテクチャでは、アプリケーションのロジックだけでなく、
インフラレベルでもサービスが疎結合であることを目指します。
これを実現するためには、以下のようなアプローチが推奨されます。
非同期通信の採用
可能な限り、イベント駆動アーキテクチャ（メッセージキューやイベントバス経由）を導入し、サービス間の直接的な同期依存を減らします。
そのために、以下のように段階的に非同期にしていく、段階的サーガの進化というものがあると思ってください。
堅牢なAPI設計とバージョニング
各マイクロサービスを担当するチームは破壊的変更を避け、後方互換性を考慮したAPI設計と厳格なバージョニングを行うことで、デプロイ時の結合を緩和します。
適応度関数の導入によって、各サービスがどこまでなら単独で進化してもいいのか？
というガードレールの設計がされていると、全体を統治するアーキテクトには負荷がかかるものの、各マイクロサービスの担当チームは、より自分たちのプロダクトを磨き上げることに専念できますね。
回復力のパターン実装
アプリケーションコードでリトライ、サーキットブレーカー、タイムアウトなどの回復力パターンを実装するか、サービスメッシュ（サイドカー）によってインフラレベルでこれらのパターンを透過的に適用します。
個人的には、運用を楽にするためにも、高いかもしれないですが、
サービスメッシュを導入してしまった方が良いと感じます。
サービスメッシュの活用
サービスメッシュは、サービス間の同期通信が避けられない場合でも、その通信の信頼性、可観測性、セキュリティ、回復力をインフラレベルで提供することで、アプリケーションコードからの結合を分離し、より健全な疎結合を支援します。
サービスメッシュを使うと、
コードに変更を加えることなくアプリケーションに耐障害性機能を追加することができる
ため、関心も分離されており超便利です。
メッシュの提供する回復機能、耐障害性機能にはタイムアウト、タイムアウトを伴う
リトライ、サーキットブレーカー、ヘルスチェック、フォールトインジェクションなどがあります。(これらのフレームワークみたいなもんですね)
オブザーバビリティツールの提供するデータを便利に取得できることもあり、
チームトポロジーを使った組織構造変化
例として、おとぎ話サーガにおける組織構造を見て見ましょう。
図中では、サービスの所有する業務DBは端折ってます
おとぎ話サーガにおける組織構造
この段階では、まだ各種マイクロサービスチーム内には、インフラを担当する人はいません。
この段階では、プラットフォームチーム内部では、必死にプラットフォーム内の
境界付けられたコンテキストを探しているために、コミュニケーションが蜜状態で、
一種の混乱期と言えるでしょう。
そうする中で、この青いプラットフォームチーム内でも、
徐々に連携が疎で安定した部分が浮き彫りになってきて、そこがインフラ上の境界、
プラットフォームチーム内でのストリームアラインドチームの境界となります。
パラレルサーガにおける組織構造
この状態から、最終的には、以下のようなパラレルサーガにした際には、
各種マイクロサービスチーム内には、それぞれのマイクロサービス内部のインフラコンポーネントになるサイドカーの設定やらをしてくれるインフラメンバーが吸収されることになります。
そして、サービスメッシュという複数のマイクロサービスの土台となる部分を
組織全体から見たプラットフォームチームが担当することになるのです。
よって、
まとめ
以上のことから、同期通信を主体とするマイクロサービス間連携は、
アプリケーション上の独立性とは裏腹に、ネットワークというインフラの共有基盤を介して密結合を作り出してしまい、マイクロサービスのメリットを享受しにくくなります。
ですが、いきなりインフラレベルでの疎結合を目指すのではなく、
段階的にアプリも疎結合に ⇒ インフラも疎結合に という風に進化させてみてください。
またその際には、組織構造の進化も必須です。
是非、チームトポロジーやダイナミックリチーミングを手に取って、実践してみてください。