【ITニュース解説】Invisible Coupling: When Your Microservices Become a Distributed Monolith

システムエンジニアを目指す皆さんにとって、現代のシステム開発で主流となる「マイクロサービス」は、システムの柔軟性や開発効率を高める強力な手法である。しかし、この手法を誤って適用すると、意図しない問題を引き起こすことがある。

記事は、ブラックフライデーのような大規模セール期間中に、最新技術を用いたマイクロサービス化された決済システムが、末端のサービス遅延によって全体的にタイムアウトする事例から始まる。これは、各サービスが独立しているように見えて、実際には裏側で密接に結びついていたために起こる。この記事では、この状態を「インビジブル・カップリング（見えない結合）」と呼び、その結果生まれたシステムを「分散モノリス（Distributed Monolith）」と定義している。

結合度（Coupling）とは、あるサービスが機能するために他のサービスにどれだけ依存しているかを示す指標である。マイクロサービス化の目的は、この結合度を低くし、各サービスの独立性を高めることにあるが、分散モノリスは、個別のサービス運用コストを支払う一方で、本来の目的である独立性を得られていない状態だ。見た目は最新のシステムでも、実態は一点の障害が全体を停止させる脆弱な構造となっている。システムを分散させても、依存関係が解消されず、かえって見えにくくなっているだけ、というのが問題の本質である。

この問題の背景には、「マイクロサービスが互いに依存し、それがさらに第三者に依存すると、遅延がコストを増大させ、システムが成り立たなくなる。特に計算負荷の高い場合、サーバーレスはコスト面で最適ではない」という議論があった。筆者は、依存関係チェーンが遅延、脆弱性、コスト増大を引き起こす点には同意するが、これを「サーバーレス技術の問題」と捉えることには異議を唱える。これはサーバーレスに限らず、システムの「アーキテクチャ設計」の問題だと指摘する。実行環境が何であれ、サービス間の連携方法が同期的な依存関係の鎖になっている限り、システムの遅延や脆弱性は根本的に解決されない。マイクロサービスの独立性は、どのような実行環境を選ぶかではなく、サービス間の「連携方法」をどのように設計するかによって決まる、というのが筆者の中心的な主張である。

問題の核心は「時間的結合（Temporal Coupling）」にある。これは、あるサービスが応答するためには、その瞬間に別のサービスが稼働し、応答を返すのを待たなければならない状態を指す。この時間的結合が生じると、チェーン内の1つのサービスの可用性や応答速度が、他のすべてのサービスに影響を及ぼし始める。例えば、決済システムで「認証→不正検知→利用限度額チェック→決済確定」といった一連の処理が同期的に直列でつながっていると想像してほしい。各ステップで数ミリ秒の遅延が発生するだけでも、全体で積もり積もって数百ミリ秒、あるいはそれ以上の遅延になる。特に、ごく一部の遅いリクエスト（上位1%や5%といった、最も遅い応答を示すパーセンタイル値）で遅延が爆発的に増加し、これが顧客離脱の決定的な原因となる。決済システムにおいては、わずかな遅延が契約違反や金融機関からのペナルティにつながることもあるため、この問題は非常に深刻だ。低負荷時には問題なく動作していても、高負荷時になると、この時間的結合による遅延が顕著になり、平均応答速度は良好でも、最悪ケースの応答速度が急激に悪化する。さらに、リトライ処理が連鎖すると、下層のサービスやデータベースへの負荷が雪だるま式に増加し、サーバーレス環境では待機中の処理にも課金されるため、コストも膨らむ。

なぜこのような「分散モノリス」が広まってしまったのか。マイクロサービス化を進める中で、「別のマイクロサービスにあるデータが必要だ」という要求に対し、「APIを公開して、それを呼び出そう」という設計が一般的な解決策となった。これは標準的な技術に基づいていたため、最初は非常に魅力的で迅速な連携を可能にしたが、システムが高遅延を許さず、高い可用性と回復性を求められるようになると、この同期的なAPI連携の限界が見えてくる。同期的な依存関係が増えるたびに、サービス間の時間的結合が強まり、マイクロサービス化の本来の目的である「疎結合」とは逆の結果を生み、管理コストの高い「見えない結合」を作り出してしまったのだ。

もし自分のシステムが分散モノリスに陥っていないか確認したい場合は、簡単な思考実験をしてみると良い。「今、システム内のとあるサービスが停止したら、他のいくつのサービスが停止するか？」「取引全体が停止する」という答えが出るなら、インビジブル・カップリングが存在する可能性が高い。あるいは、「隣接するチームに事前に通知することなく、システムのピーク時にこのサービスをデプロイできるか？」と問いかけ、答えが「ノー」ならば、そのサービスの独立性は組織図上のものでしかなく、実際には他のサービスと密接に結合していると言える。複数のサービスが同時にデプロイされる必要がある場合、それは分散モノリスであるという基準も存在する。

真の独立性は、サービス間の「連携方法」をどう設計するかによって実現される。同期的な連携チェーンがシステムを脆弱にするのに対し、その反対のアプローチとして「イベント駆動型アーキテクチャ（EDA）」が挙げられる。これは、サービスが直接相手を呼び出すのではなく、「イベント」という形で情報を発信し、それを必要とするサービスが購読して処理する仕組みだ。これにより、サービス間の直接的な依存関係を大幅に減らすことができる。また、各サービスが自身のデータを責任を持って管理する「明確なドメイン境界」を設けることや、ユーザーが直接結果を待つ必要がある処理（「ホットパス」）と、後から非同期で処理しても問題ない副次的な処理（「サイドエフェクト」：例えば分析データの記録や通知メールの送信など）を分離することが非常に重要だ。現実世界は非同期な出来事の連続であり、システム設計もそれを反映させるべき、という考え方が基本となる。

先の決済システムの例を、イベント駆動型アーキテクチャで再設計してみよう。ユーザーへの応答を最速で返す「ホットパス」には、決済承認に必要な「認証→不正検知→利用限度額チェック」のみを含める。これらの処理が完了したら、顧客に承認応答を返し、同時に「決済承認済み」というイベントを発行する。そして、このイベントを「決済確定（Settlement）」や「通知（Notification）」、「分析（Analytics）」といった他のサービスがそれぞれ購読し、並行して処理を進める。もし決済確定サービスが一時的に停止しても、承認サービスは顧客に応答を返し続け、決済確定のためのイベントはキューに保存され、サービス復旧後に処理される。このように、耐久性のあるメッセージキューやストリームを介してイベントをやり取りすることで、一つのサービスの障害がシステム全体に波及するのを防ぎ、高い回復性と可用性を実現できる。決済の仕組み自体がもともと非同期な処理であるため、イベント駆動型設計はドメインの性質にも合致しているのだ。この設計を実現するためには、Circuit Breaker、Bulkhead、Outboxといった様々な回復性パターンと、それを適切に適用する判断が必要となるが、これらには導入コストもかかる。AWS Well-Architected Frameworkの信頼性という柱でも、疎結合な依存関係を実装し、可能な限り非同期な連携を取り入れることが推奨されている。

まとめると、記事の冒頭で提起された「マイクロサービス間の依存関係がシステムを遅くし、高コストにする」という問題の根源は、サーバーレス技術にあるのではなく、同期的な連携による「時間的結合」というアーキテクチャ設計上の問題にある。サーバーレス環境で高コストになるのは、待機している間も課金されるため、同期的な処理で発生する「待機コスト」が主な原因だ。ホットパスから待機処理を排除し、イベント駆動型にすることで、このコストと遅延は大幅に削減される。

最終的にこの解説が伝えたい核となるアイデアは、以下の4点に集約される。 一つ目は、もしサービスが他のサービスの応答を待ってからでないと応答できないなら、それは分散モノリスの一部であるということ。 二つ目は、時間的結合こそが問題の元凶であり、一つのサービスの遅延や可用性の低下がチェーン全体に影響を及ぼし、平均値では見えにくい遅いリクエスト（p95/p99）で問題が顕在化すること。 三つ目は、実行環境をサーバーレスからコンテナに変えるだけでは、同期的な連携チェーンの問題は解決しないということ。重要なのは、サービス間の連携がどのように設計されているかである。 そして四つ目は、真の独立性は、イベント駆動型アーキテクチャ、明確なドメイン境界、ホットパスとサイドエフェクトの分離、そして適切な回復性パターン（Circuit BreakerやBulkheadなど）といった設計によって実現される、という点だ。

システムがブラックフライデーのような高負荷時にも耐えうるかどうかは、どのような実行環境を選ぶかではなく、サービス間の「連携方法」をいかに適切に設計するかにかかっている。