Pub/Subメッセージングモデルとは
主に、イベント駆動型の複数のマイクロサービス間の連携を疎結合にすることができる設計パターンやモデルのこと。マイクロサービスとは一般に、独立して機能する個々のサービス(機能やドメイン単位)を組み合わせてアプリケーションを構築するアーキテクチャ・スタイルのことを指す。
基本的な構成
ECサイトがあるとする。これを1つのサービスとして管理するのではなく、注文管理サービス、在庫管理サービス、売り上げ管理サービス、購入完了メール送信サービスに分ける（厳密にはもっとたくさんあると思う）
- トピック(イベントバス)
- 図のオレンジ色の部分。パブリッシャーとサブスクライバーを仲介することで、各サービスを疎結合にすることが可能になる
- サブスクライバー
- 図の緑色の部分。コンシューマーとも言われる。パブリッシャーによりメッセージが送信されるとそれをトリガーに特定の処理を実行する
- パブリッシャー
- ECサイトのバックエンド(API)。このサービスは商品購入というユーザーのイベントをトリガーとして商品購入トピックにメッセージを送信する。また、この図ではサブスクライバーはパブリッシャーも兼ねている
APIが叩かれるとパブリッシャー(バックエンド)から商品購入トピックにメッセージが通知される(ProductPurchacedイベント)。パブリッシャーから送信されたメッセージは，トピックという送信先に登録され、トピックに対して配信を申し込んでいた一つまたは複数のサブスクライバーに配信される。
具体的には、受注管理サービス(サブスクライバーA)では受注データの登録などが行われ、これが完了すると受注作成トピックに対してメッセージを送信し、イベント(OrderRegisterd)が発生すると、これを受けて次の在庫管理サービス(サブスクライバーB)が実行され・・・という具合に各マイクロサービス間の連携を疎結合に保ちつつ、処理が実行される(=マイクロサービスはビジネスエンティティを更新し、次のアクションをトリガーするイベントを発行)
なお、Google CloudではCloud Pub/Sub、Eventarcが該当する(AWSならAmazon SQS、EventBridge)
メリット
疎結合により、
- 不具合の影響範囲を最小限にとどめられる(障害ポイントの判別が容易)
- パブリッシャー側からサブスクライバーの種類と数を把握する必要がないので拡張性が高く、修正があった場合の影響範囲を狭めることができる(ブラックボックス化できていないと、依存されているサービスに変更があったら、その都度依存しているサービス側の修正が伴うことが多い。)
- スケーラビリティ（パブリッシャー、サブスクライバーは状態を保持していないため、スケールしやすい）
- 低レイテンシー
- パブリッシャーはメッセージを送信するだけなので、メインスレッドをブロックすることがない
- 異なるプラットフォーム、プログラミング言語、または通信プロトコルを使用するシステム間の統合をより簡単にすることが可能
- 複数の非同期処理を並列実行できる
ユースケース
マイクロサービス同士の関係が1 対多、多対 1 、多対多となるような、リアルタイムの応答が不要なサービスに特に有効。反対に、1対1もしくは数人だけしかいない場合やアプリケーションが、ほぼリアルタイムの、コンシューマーとの対話を必要とする場合はあまり向いていない
Fan-out アーキテクチャ
複数のサブスクライバーに同時にメッセージを送るようなアーキテクチャ
注意点
キューからの取り出し順序
メッセージは送信された順(メッセージが作成された順序)に登録されるが、サブスクライバーで処理される順序は保証されない。(クラウドサービスによってはオプションで順序指定が可能
At-least-once (最低1回の配信)
一般的なメッセージングサービスでは、メッセージングの配信は At-least-once (最低1回の配信) という性質で行われる。
つまり、メッセージが最低1回は配信されるが、2回以上配信される場合もある。(一時的なネットワーク障害や遅延でメッセージに対する ack (受信したことを伝えるレスポンス) がうまく伝達されない場合など)
そのため、同じメッセージが2回以上配信されてもシステム全体で不具合が起きないよう、コンシューマー側で何回同じ処理をしても、その結果としての状態が同じになるように、処理の設計を工夫する必要がある(冪等性 (べきとうせい))。
※例えばHTTPのPOSTリクエストは冪等性がない処理と言える(リクエストごとに結果(登録されたリソースの件数)が変わる)
まとめ
いかがでしたでしょうか。本記事では、イベント駆動型の複数のマイクロサービス間の連携を疎結合することができる設計パターンであるPub/Subメッセージングモデルについて紹介しました。基本的な構成や具体例、メリットやユースケース、採用する上での注意点についても併せて紹介していますので、ぜひ参考にしてみてください