パブリッシュ – サブスクライブパターン

Intent 導入する理由適用対象問題点と考慮事項実装ブログの参考情報関連情報

パブリッシュ – サブスクライブパターンは、メッセージ送信者 (パブリッシャー) を対象となる受信者 (サブスクライバー) から切り離すメッセージングパターンのことで、pub-sub パターンとも呼ばれています。このパターンは、メッセージブローカーまたはルーター (メッセージインフラストラクチャ) と呼ばれる中間層を介してメッセージまたはイベントを発行することにより、非同期通信を実装します。パブリッシュ – サブスクライブパターンでは、メッセージ配信の責任をメッセージインフラストラクチャに移管することで、送信者は中核的なメッセージ処理に集中できるため、送信者のスケーラビリティと応答性が向上します。

分散アーキテクチャでは、システム内でイベントが発生した際、システムコンポーネントから他のコンポーネントに情報を提供する必要性が生じることがよくあります。パブリッシュ – サブスクライブパターンでは、考慮すべき事項を分離できるため、アプリケーションは中核的な機能に集中できます。メッセージルーティングや信頼性の高い配信などの通信は、メッセージインフラストラクチャにより処理されます。パブリッシュ – サブスクライブパターンは、非同期メッセージングでパブリッシャーとサブスクライバーを切り離すことを可能にします。またパブリッシャーは、サブスクライバーに関する情報を持たなくても、メッセージを送信することができます。

パブリッシュ – サブスクライブパターンは次の場合に使用します。

1 つのメッセージのワークフローが異なるので、並列処理が必要なとき。
複数のサブスクライバーにメッセージをブロードキャストしており、受信者からのリアルタイムの応答が必要ないとき。
最終的にデータや状態の一貫性が保たれるのであれば、システムやアプリケーションはそれを許容できるとき。
異なる言語、プロトコル、またはプラットフォームを使用する可能性のある他のアプリケーションまたはサービスと、アプリケーションまたはコンポーネントが通信を行う必要があるとき。

サブスクライバーとの接続性: パブリッシャーは、サブスクライバーがリスナーとして機能しているかどうかを把握しません。つまり、リスナーは機能していない可能性もあります。発行されたメッセージは一時的なものであり、サブスクライバーからの応答がない場合には、ドロップされることがあります。
メッセージの配信保証: 通常、Amazon Simple Notiﬁcation Service (Amazon SNS) などの特定のサービスで、あるサブスクライバーサブセットに対し配信できるのは 1 回限りですが、パブリッシュ – サブスクライブパターンでは、すべてのサブスクライバータイプへのメッセージの配信が保証される訳ではありません。
有効期限 (TTL): メッセージには寿命があり、その期間内に処理されないと有効期限切れになります。TTL 期間を超えてもメッセージが確実に処理されるようにするには、発行されたメッセージをキューに追加して永続化することを検討してください。
メッセージの関連性: プロデューサーは、メッセージデータの中に関連性についての時間スパンを設定でき、メッセージがこの日付を過ぎた場合はそれを破棄できます。メッセージの処理方法を決定する場合には、設計段階でコンシューマーがこの情報を検証するようにすることを検討してください。
最終的な一貫性: メッセージが発行されてからサブスクライバーがそのメッセージを消費するまでには遅延が存在します。これにより、強い一貫性が求められる場合でも、サブスクライバーデータストアの一貫性が実現されるのが、最終段階になる可能性があります。プロデューサーとコンシューマーがほぼリアルタイムのやり取りを必要とする場合も、最終的な一貫性の実現が問題になることがあります。
単方向の通信: パブリッシュ – サブスクライブパターンの通信は単方向と見なされます。返信サブスクリプションチャネルによる双方向メッセージングを必要とするアプリケーションで、応答の同期が必要な場合は、要求 – 応答パターンの使用を検討する必要があります。
メッセージの順序: メッセージの順序は保証されません。コンシューマーが順序付けられたメッセージを必要とする場合は、Amazon SNS FIFO トピックを使用して、順序を保証することをお勧めします。
メッセージの重複: メッセージ伝送インフラストラクチャによっては、重複したメッセージがコンシューマーに配信される場合があります。コンシューマーは、重複したメッセージの処理に関し冪等性を持つように設計されている必要があります。または、Amazon SNS FIFO トピックを使用すれば、配信を確実に1 回のみ行うようにもできます。
メッセージのフィルタリング: コンシューマーが関心を寄せるのは、プロデューサーが発行したメッセージのサブセットのみである、ということが良くあります。トピックやコンテンツフィルターを提供することで、サブスクライバーが受信したメッセージにフィルターをかけたり、絞り込んだりできるメカニズムを実現できます。
メッセージ再生: メッセージの再生機能は、メッセージングインフラストラクチャにより異なってきます。また、ユースケースに応じ、カスタム実装を提供することもできます。
デッドレターキュー: 郵便システムでは、配達不能な郵便物を処理するための施設である、デッドレターオフィスがあります。pub/sub のメッセージングにおいては、サブスクライブ済みのエンドポイントに配信できないメッセージのためのキューとして、デッドレターキューが存在します。

パブリッシュ – サブスクライブパターンでは、メッセージブローカーまたはルーターと呼ばれる非同期メッセージングサブシステムが、サブスクリプションを追跡します。プロデューサーがイベントを発行すると、メッセージングインフラストラクチャは各コンシューマーにメッセージを送信します。サブスクライバーに送信されたメッセージは、メッセージインフラストラクチャから削除されるので再生はできなくなり、対象のイベントは新しいサブスクライバーには表示されません。メッセージブローカーまたはルーターは、以下の方法でイベントプロデューサーをメッセージコンシューマーから切り離します。

メッセージにパッケージ化されたイベントを発行するための入力チャネルを、定義されたメッセージ形式を使用してプロデューサーに提供する。
サブスクリプションごとに個別の出力チャンネルを作成する。サブスクリプションとは、特定の入力チャンネルに関連するイベントメッセージを受信するための、コンシューマーの接続です。
イベントが発行されたときに、すべてのコンシューマーに対し、メッセージを入力チャンネルから出力チャンネルにコピーします。

Amazon SNS

Amazon SNS は、分散したアプリケーションを分離するために、アプリケーションからアプリケーションへ (A2A) のメッセージ伝送を提供する、完全マネージド型のパブリッシャー – サブスクライバーサービスです。またこのサービスでは、SMS、E メール、その他のプッシュ通知を送信するために、アプリケーションから個人へ (A2P) のメッセージ伝送も行えます。

Amazon SNS では、標準と、先入れ先出し (FIFO) の、2 種類のトピックを提供しています。

標準トピックでは、1 秒あたりのメッセージ数を上限なくサポートし、また順序付けと重複排除はベストエフォートになります。
FIFO トピックでは、厳密な順序付けと重複排除が行われます。また、FIFO トピックごとに 1 秒あたり 300 件のメッセージ、または1 秒あたり 10 MB (のどちらか早く発生した方) がサポートされます。

次の図は、Amazon SNS を使用したパブリッシュ – サブスクライブパターンの実装方法を示しています。ユーザーが支払いを行うと、SNS メッセージが Payments Lambda 関数によりPayments SNS トピックに送信されます。この SNS トピックには 3 人のサブスクライバーがいます。各サブスクライバーがメッセージのコピーを受信して、その処理を行います。

Amazon EventBridge

Amazon EventBridge は、異なるプロトコルにおよぶ複数のプロデューサーからのメッセージを、サブスクライブしているコンシューマー、または直接的およびファンアウトのサブスクリプションに対して送る、より複雑なルーティングが必要な場合に使用します。また EventBridge では、コンテンツに基づいたルーティング、フィルタリング、シーケンシング、および分割や集約もサポートされています。以下の図では、パブリッシュ – サブスクライブパターンの (イベントルールを使用してサブスクライバーが定義される) バージョンを、EventBridge を使用して構築しています。ユーザーが支払いを行うと、Payments Lambda 関数は、デフォルトの (異なるターゲットを指す 3 つのルールを含むカスタムスキーマに基づく) イベントバスを使用して、EventBridge にメッセージを送信します。各マイクロサービスはメッセージを処理し、必要なアクションを実行します。