【ITニュース解説】Keeping Services Loosely Coupled: A Practical Guide

システム開発において、複数のサービスが連携して動作するシステムは珍しくない。しかし、これらのサービスが互いに密接に結びつきすぎていると、一つの変更が予期せぬ場所で問題を引き起こし、開発の速度を著しく低下させてしまうことがある。これを「密結合」と呼び、この問題を解決し、変更に強く、柔軟なシステムを構築するための考え方が「疎結合」である。疎結合なシステムを目指すことは、開発者が不必要な週末の作業から解放され、より効率的に開発を進めるための鍵となる。

結合とは、サービス間で互いがどれだけ内部を知っているか、という「知識」の問題である。単に同じコードを共有しているかどうかではなく、あるサービスに変更があった際に、その変更が自身の本来の業務とは関係なく、他のサービスの変更を必要としてしまう場合に、そのサービス間に結合があると言える。もちろん、全く結合がない「ゼロ結合」は現実的ではない。私たちが目指すべきは、常に変化するサービスの内部的な詳細に依存するのではなく、安定した「契約」に基づいてサービス間が連携するシステムを構築することだ。

具体的に疎結合を実現するための最初の方法は、「契約」を通じてサービスが対話することである。例えば、サービスAがサービスBの内部で使われているデータ構造（構造体など）を直接インポートしてしまうと、サービスAはサービスBのフィールド名や型、デフォルト値といった内部実装の詳細を知ってしまう。もしサービスBでフィールド名が変更されれば、サービスAはコンパイル時にエラーとなり、修正が必要になる。これは確かに正直な結合ではあるが、変更のコストは高い。より良いアプローチは、サービスAが必要とする機能だけを定義した「インターフェース」をサービスA自身が宣言することだ。例えば、「ユーザーIDからメールアドレスを取得する」という機能が必要であれば、その機能を持つインターフェースをサービスAが定義し、サービスBはそのインターフェースを満たす形で実装を提供する。これにより、サービスAはサービスBの内部データ構造を知ることなく、必要な機能の「契約」のみに依存する形となり、サービスBの内部変更がサービスAに影響を及ぼしにくくなる。

次に、ネットワークを通じてサービス間でデータを受け渡す場合、そのデータの形式がサービス間の「契約」となる。この際、最初からデータに「バージョン」のフィールドを含めることが非常に重要である。そして、一度定義したフィールドを削除する際には、すぐに削除するのではなく、しばらくの間は古いバージョンもサポートする「非推奨期間」を設けるべきだ。データを受け取る側のサービスは、自分が知らない新しいフィールドがあったとしても、それを無視して処理を続行できるように設計する。また、データを送る側のサービスは、一度使ったフィールド名を異なる意味で再利用してはならない。これらのルールを守るだけで、サービス間の予期せぬ障害を大幅に減らすことができる。

サービス間の連携には、同期的な呼び出しと非同期的な呼び出しがある。同期的な呼び出しは、あるサービスが別のサービスを直接呼び出し、その応答を待つ方式である。これは連携が分かりやすい反面、呼び出されたサービスが停止してしまうと、呼び出し元のサービスも処理を進められなくなるという「実行時結合」を生み出す。例えば、決済サービスがダウンすれば、注文のチェックアウト処理も停止してしまう。この問題を避けるために、「非同期イベント」の利用が推奨される。これは、あるサービスが何らかのイベント（例えば「注文が完了した」）を「発行」し、その情報をバス（メッセージキューのようなもの）に送る。イベントを発行したサービスは、その後何が起こるかを気にせず次の処理へ進む。そのイベントに興味がある他のサービスは、バスからそのイベントを「購読」して、それぞれの処理を行う。これにより、イベントの発行元は誰がそのイベントを聞いているかを知る必要がなくなり、サービス間の独立性が高まる。ただし、非同期イベントはすぐに結果が得られない「結果整合性」という特性や、問題が発生した際のデバッグが同期呼び出しに比べて難しくなるというトレードオフもあるため、そのワークフローが許容する場合に活用すべきである。

もし複数のサービス間で共通のデータ型を共有する必要がある場合は、直接手書きのモデルコードを共有するのではなく、「スキーマ」を共有することが望ましい。JSON Schema、Protobuf、Avroのようなスキーマ定義言語を使ってデータ構造を記述し、そのスキーマ定義から各プログラミング言語に対応するコードを自動生成するのである。これにより、各サービスは共通のスキーマ定義に基づいて型安全なコードを使えるようになり、手書きのモデルコードを更新するたびにすべてのサービスを同時にリリースするといった、共有リリースサイクルに縛られることがなくなる。

結合は、コードの中にだけ存在するわけではない。むしろ、コードの外に潜む「偶発的な結合」こそが、見過ごされがちで厄介な問題となる。例えば、複数のサービスが同じデータベースの同じテーブルに直接書き込みを行う場合、それは分散されたシステムでありながら、実質的には一つの巨大なシステム「分散モノリス」と化している。この場合、そのテーブルを所有するサービスを一つだけ定め、他のサービスはAPIを通じてそのサービスにデータを操作してもらうか、読み取り専用のレプリカからデータを取得するべきだ。また、複数のサービスが同じ名前の設定キー（例えば「チェックアウト_v2」という機能フラグ）を読み込む場合、それらのサービスは特定のリリース計画に結合してしまう。さらに、サービスAがサービスBの不安定さのために何度もリトライを繰り返すロジックを持っていると、サービスAはサービスBの障害パターンを知ってしまっていることになる。このような場合は、サービスB自体の安定性を向上させるか、メッセージキューのような仕組みを使って、サービスAがBの内部事情を知らずに済むようにすべきである。そして、一つのウェブページを表示するために、複数のサービスに対して次から次へと連続して何度も呼び出しを行うような「チャッティーな呼び出し」が多い場合も、それは実質的にそれらのサービスが一つにまとまるべき兆候である。

自分が開発しているシステムが疎結合であるかを手軽に確認するための「クイックテスト」がある。「もし明日このサービスを削除したら、何が壊れるだろうか？」という問いを自分に投げかけてみてほしい。もし、そのサービス自身が管理するデータと、そのサービスを直接呼び出す上流のサービス以外にも、多くのものが壊れると答えるなら、それは高い結合度を示している。別のテストとして、「これら二つのサービスを金曜日にそれぞれ独立してデプロイできるだろうか？」と自問してみるのも良い。もしできないとすれば、その理由を考えることで、隠れた結合点を見つけ出すことができるはずだ。

最終的に、私たちが実践すべきことは以下の通りだ。サービスが必要とするインターフェースは、そのサービス自身（消費者側）が定義する。サービス間のメッセージには必ずバージョンを含める。サービス境界を越える連携には、デフォルトで非同期イベントを使うことを検討する。データベースのテーブルには、書き込みを行うサービスを一つだけとする。そして、これらの実践がうまくいっているかの真のテストは、「サービスを独立してデプロイできるか」である。疎結合は、一度設計すれば終わりというものではない。それは、プルリクエスト（コード変更の提案）ごとに実践されるべき日々の習慣であり、あるサービスが他のサービスの内部事情を覗き見することを許さない、チーム全体の規律が求められるのである。