マイクロサービスの通信手法

モノリスからマイクロサービスに移行することで、それまでモノリスの中の暗黙的に存在していた複雑性が明らかになり、通信に関する課題が指数級数的に増加する — Michael Plöd氏は、GeeCON 2018でのプレゼンテーションでこのように述べ、マイクロサービス間の通信に関するさまざまな手法について説明した。

InnoQのプリンシパルコンサルタントであるPlödは最近、経験豊富な氏のチームが、マイクロサービスを既定のアーキテクチャとして見ていることが多い点に気付いた。分散システムは難しいシステムだ、と氏は強調する — 必要がなければ、そのためだけに苦労するのは避けるべきだ。そのような状況では、適切に構築されたモノリスの方がよい選択肢であることも少なくないのだ。

モノリスでは不十分であるためにマイクロサービスが採用されている場合は、それらは統合されていなくてはならない。これは単に技術的な問題ではなく、他の分野にも関連する、とPlöd氏は言う。

• 政治やガバナンスの問題につながる統合上の問題を解決する上で、通信が必要になることは少なくない。
• カップリング。サービス間の疎結合を達成することは極めて重要である。さもなくば、単なる分散型モノリスで終わることになる。
• 品質基準。一貫性やパフォーマンス、拡張性、堅牢性に関する真の要件が何かを見出すためには、アプリケーションの早期評価を行う必要がある。
• テクノロジ。一般的にはRESTが使用されるが、これが通信手段として唯一の選択肢という訳ではない。

通信とカップリングの管理を支援する手段としてビジネスレベルのバウンダリ、すなわちコンテキスト境界(bounded context)を見つけるためには、ドメイン駆動設計(DDD)が非常に有用である、とPlöd氏は指摘する。これらのコンテキストは、一般的に、さまざまな方法で相互に作用する。これを記述する手段としては、コンテキストマップが使用可能だ。相互作用のパターンには、次のようなものがある。

• オープンホストサービス 。サービスがどのように使用されるかを、RESTなどのプロトコルで規定する。
• 共有カーネル。相互作用を定義したコードあるいはライブラリをサービス間で共有する。
• カスタマ/サプライヤ。ひとつのサービスが別のサービスのカスタマとなることで、その実装に影響を与える場合がある。
• 破損防止(anticorruption)レイヤ。サービスの利用において、相互作用する相手サービスの影響を最小限に抑えるためのアダプタを作成する。

通信の技術的側面として、Plöd氏はまず、より一般的な通信の分類である、オーケストレーションとコレオグラフィ(choreography)について説明した。オーケストレーションでは、ひとつのマイクロサービスが自身のタスクを達成するためにプロセスを認識し、他のサービスを積極的に呼び出す。一方のコレオグラフィでは、ひとつのマイクロサービスがイベントを発行し、他のサービスの反応と行動を促す。Plöd氏にとってこれは重要な違いであり、システムが動作する上で望ましい方法をアーキテクチャ上から判断すべきだ、と考えている。氏はまた、マクロとマイクロの両アーキテクチャを検討することを推奨している。マイクロサービスとは、チームが好きなものを選ぶということではない。そんなことをすれば、システム全体がカオスになってしまう。つまり、すべてのチームが従うルールを持ったマクロアーキテクチャが必要である。マイクロアーキテクチャの意義とは、実装スタイルを選択する自由がチームにあることなのだ。

通信に関する技術的選択肢として、Plöd氏は４つのタイプを挙げている。

• RESTfulなリソース
• メッセージング
• ドメインイベント
• フィード

RESTは今日では広く理解されているが、Plöd氏の経験からは、特にハイパーメディアや複数の表現に関して、十分に使いこなしている開発チームはほとんどない。RESTfulなリソースの呼び出しの実装は今日では非常に簡単になったが、マイクロサービス環境での使用に耐える堅牢な実装は極めて難しい、と氏は指摘する。次のような、気をつけなければならない落とし穴や課題がたくさんあるのだ。

• サービスディスカバリ。通信を行うサービスのURLを見つけ出す手段である。
• レジリエンス。エラーやダウンタイムの対処方法を含む。サービスの穏やかな低下は、サービスの機能不全によるアプリケーション全体のダウンを防ぐ上で重要なものだ。
• 負荷の増大に対処するためのロードバランシング。アプリケーションを実行する環境に応じて、さまざまな実現方法がある。

もうひとつの選択肢は、一般的にはメッセージブローカを通じて、マイクロサービス同士がメッセージの送受信を行なうメッセージングである。この場合は、RESTについて説明した課題は関係しない。

• サービスはメッセージングシステムのみを意識するので、サービスディスカバリはもはや重要ではない。
• レジリエンスは主としてメッセージングシステムによって処理される。中心的なリスクは、エラーやダウンタイムによるレイテンシの増加だ。
• ロードバランシングは、メッセージングシステムの拡張やメッセージコンシューマの数を増やすことによって行われる。

Plöd氏の挙げる3つめの選択肢はドメインイベントである。ドメインイベントは、ビジネスレベルで過去に発生したことに関する事実を表すものだ。通信にドメインイベントを使うということは、今日では非常にポピュラーなアーキテクチャスタイルとなったイベント駆動マイクロサービスにつながる。通信にイベントを用いる場合について、氏は、イベントで使用するペイロードの選択肢をいくつか説明している。

• フルペイロード。イベントを扱う上で必要なすべてのデータ、例えば顧客に関する全データをイベントに格納する。これはコンシューマにとっては楽だが、結合度も高くなる。
• REST URL。イベントを表すURLをイベントのみとする。
• 空(Empty)。イベント自体に関するデータのみ。従ってコンシューマは、必要なデータを見つける手段を持たなくてはならない。
• ミックス。例えば、一部のデータと、追加データを取得するためのURLを格納する。Plöd氏はこれを、ほとんどの場合において望ましい方法としている。

最後に挙げる選択肢は、Atomフィードを使用したRESTとイベントの組み合わせである。サービスがイベントと合わせてフィードを公開することで、コンシューマはサブスクライブと非同期な読み込みを行うことができる。HTTPを使用することで、ほとんどの環境で通信が極めて容易になるとともに、ETagsやLast Modified、ページネーション、リンクといった機能の活用が可能になる。フィードを公開するサービスがコンシューマと完全に隔離されることも、メリットのひとつだ。適合すると思われるフィードを読み込み、すでにコンシュームされたイベントを記録するのは、すべて各コンシューマの責任になる。

フィードを提供するためには、イベントが永続化される必要がある。このためにはイベントソーシングが使用される。これらのイベントをメインの永続化モデルとして使用することで、CQRSを使用して、最適化された読み取りモデルとしてのビューをイベントから派生することが可能になる。ただしCQRSとイベントソーシングは、システム内の特定の部分でのみ機能するソリューションであって、システムのあらゆる場所で利用可能なアーキテクチャを表すものではない、とPlöd氏は強調している。

統合について詳しく学ぶ手段として、Plöd氏は、Gregor Hophe、Bobby Wolf両氏による書籍“Enterprise Integration Patterns”を強く推奨している。