マイクロサービスにおける非同期メッセージングを考える 


# はじめに

最近、国内企業において、長期間使用したシステムをマイクロサービスアーキテクチャとしてシステムを刷新するといった記事があり、DXへ関心を持つ企業が増えるとともにマイクロサービスに対する関心も高まっていることと思います。
@takahashisansan の記事[「マイクロサービスが開発・運用コストの削減にどう貢献するか考えてみた件」](https://qiita.com/takahashisansan/items/7470a14e45aee2b6739f)で、マイクロサービス間の連携と独立性の担保、に記載された疎結合なマイクロサービスを設計するためのポイントに、適切な非同期メッセージングは疎結合に効果があるといったことが挙げられています。また、@tsukmrの記事[「ドメイン駆動設計を用いてマイクロサービスに分割することを考える」](https://qiita.com/tsukmr/items/1f8f68f7d9f28cd20380)に、ドメインの専門の方と設計者、開発がともにドメインやマイクロサービスを設計していくことを記載しています。
いくつかの記事を参考にして、マイクロサービス間のインターフェースに関する非同期メッセージングについて整理してみました。

# 非同期メッセージング

SoEに関した領域に対してマイクロサービスアーキテクチャや分散アーキテクチャを整理するときに、サービス間の連携における非同期メッセージングが話題の一つとして挙がると思います。

いくつかの記事をチェックしたところ、メッセージングプラットフォームKafka (OSS)を活用しサービス間の連携をする事例が多くありました。
Apache Kafka (OSS)は、Linkedin社で発生していた大量のストリームデータ（ソーシャルデータ等）を処理するために開発されOSS化されたものです。
Kafkaは、メッセージングプラットフォームとしてクラスタを構成する複数のマシーンにインストールするOSSで、クラスタのノード間の協調はZookeeperを使用して行います。
Zookeeperはクラスタ（複数ノード）の構成を共有するサービスで、ノード、トピック等の構成の追跡、障害ノードの復元に使用されます。
Kafkaのメッセージジングプラットフォーム上では、データの生産者(Producer)から、Kafkaのトピックにメッセージが送られると、それらのデータの消費者(Consumer)が読んで処理（マイクロサービス、アプリケーション処理）できます。

メッセージングプラットフォームで扱う非同期メッセージングの利用シーンについて検討しました。

## マイクロサービス間連携における非同期メッセージングの利用シーン

マイクロサービス間連携で非同期メッセージングを使う利用シーンは以下の２パターンが想定されます。

### マイクロサービス間で応答などが必要なコミュニケーション
マイクロサービス間のコミュニケーションにメッセージングを使用する場合、リモート通信プロトコル（Webサービス、HTTP/REST等）と同様な利用シーンが想定されます。
あるマイクロサービスのメッセージをマイクロサービス（1対1）に送る場合を想定すると、publish/subscribeによるメッセージング方法によって、マイクロサービス(publish)からのメッセージをトピックに設定するとマイクロサービス(subscribe)が読むことができます。
メッセージングプラットフォームのメッセージブローカーやメッセージのトピックを設定し、複数のマイクロサービスの中からあるマイクロサービスへ中継して送る場合も考えられます。<br>

### マイクロサービスで起きたイベントによって、他のマイクロサービスが連携し動作するようなマイクロサービスの統合
1対1に限らず、あるマイクロサービスのメッセージを複数のマイクロサービス(1対N)に送る場合も想定でき、同じようにpublish/subscribeによるメッセージング方法で、メッセージのトピックに関して、複数のマイクロサービス(subscribe)が関連する場合があります。<br>

## 非同期メッセージングで扱うべきイベント
前章で述べた「マイクロサービスで起きたイベントによって、他のマイクロサービスが連携し動作するようなマイクロサービスの統合」においては、[「ドメイン駆動設計を用いてマイクロサービスに分割することを考える」](https://qiita.com/tsukmr/items/1f8f68f7d9f28cd20380)で述べられたドメインの専門家とともに業務やマイクロサービスを設計することが必要です。
ここでは、マイクロサービス間をつなぐ非同期メッセージングのイベントについて整理します。

「Microsoft docs ドメイン イベント: 設計と実装」、によれば、マイクロサービス間の非同期メッセージングで扱うイベントを次のように説明しています。

 - コミットされたトランザクションや更新を他のサブシステムに伝達すること
 - 複数のマイクロサービス (他の境界コンテキスト) 間または外部システム/アプリケーション間の非同期通信に基づいている
 - リモート サービス間でのプロセス間分散通信を可能にする何らかのインフラストラクチャが必要

Microsoftのドキュメントでは、ドメイン内に閉じたイベントにも言及していますが、本記事では割愛します。

# さいごに

マイクロサービス間のインターフェースに関する非同期メッセージングを整理してみました。

はじめに、に記載したように、インターフェースに非同期メッセージングが使用できると、マイクロサービスの独立性や疎結合、分散して連携したサービスに効果が見込め、また、サービス間の影響が小さくなると、故障に対してシステムが停止しにくいなどの非機能面の効果を考えることができます。

非同期メッセージが行えるプラットフォームは、クラウドベンダーのPaasなど複数ありますが、メッセージングに関して、Kafkaに限らず参考になると思いますので、下記の関連記事をあわせて参照して頂き、参考になれば幸いです。

引用・参考、関連記事
[Kafka Introduction - great introduction to Kafka from official documentation](https://kafka.apache.org/intro)
[Microsoft docs ドメイン イベント: 設計と実装](https://docs.microsoft.com/ja-jp/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/domain-events-design-implementation)
[マイクロサービスが開発・運用コストの削減にどう貢献するか考えてみた件](https://qiita.com/takahashisansan/items/7470a14e45aee2b6739f)
[デジタルトランスフォーメーションにおけるシステムの俊敏性とは？を考える](https://qiita.com/atsuo0o/items/979257bc39bbe8cc20a6)
[ドメイン駆動設計を用いてマイクロサービスに分割することを考える](https://qiita.com/tsukmr/items/1f8f68f7d9f28cd20380)