翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Pub/sub パターン
プラットフォームが成長すると、異なるマイクロサービスが相互依存を生じることなく相互作用することが難しくなることがあります。パブリッシュ/サブスクライブ (pub/sub) パターンでは、Amazon SQS、Lambda、Amazon Simple Storage Service (Amazon S3) などの複数の AWS サービス間で、相互依存を発生させることなく非同期通信を提供します。このパターンでは、マイクロサービスはイベントをメッセージとしてチャネルに公開し、サブスクライバーはそれをリッスンすることができます。例えば、ファクトリーは pub/sub パターンを使用して、機器が問題や障害をチャネルに公開できるようにすることができ、サブスクライバーはその後、これらの機器の問題を表示し、ログとして記録することができます。
このパターンの使用を検討すべきなのは、次のような場合です。
-
イベント駆動型のアーキテクチャを採用しています。
-
疎結合アーキテクチャを有効にできます。
-
呼び出し元のシステムにレスポンスを返す前に、トランザクションのすべての操作部分を完了させる必要はありません (特定の操作は非同期にすることが可能です）。
-
従来のデータセンターの能力を超えるボリュームに拡張する必要があります。このレベルのスケーラビリティは、主に並列操作、メッセージキャッシュ、ツリーベースのルーティング、および pub/sub モデルに組み込まれているその他の機能によるものです。
このパターンの使用には、いくつかの欠点があります。例えば、Amazon Simple Notification Service (Amazon SNS) のような特定のサービスは、サブスクライバーのサブセットに対してまさに 1 回限りの配信を提供することができますが、pub/sub パターンは通常、すべてのサブスクライバータイプへのメッセージ配信を保証することはできません。もう 1 つの欠点は、パブリッシャーが、実際にはそうでないにもかかわらず、サブスクライバーがチャネルをリッスンしていると想定してしまうことです。
ユースケース
このユースケースでは、SNS トピックを使用して、保険システム内の複数の従属マイクロサービスにイベントを公開します。カスタマーが毎月の支払いを行った後、「Customer」や「Sales」などのサブシステムで情報を更新し、支払い確認を記載した電子メールをカスタマーに送信する必要があります。このパターンは、Amazon SNS または Amazon EventBridge のいずれかを使用して実装できます。
EventBridge は、複数のサブスクライバー間のイベントをフィルタリングします。EventBridge の実装には、次の 2 つのオプションが用意されています。
-
イベントタイプが異なる 3 つのイベントを送信します。遠くのターゲットは、イベントルールに基づいてそれらをピックアップします。
-
同じイベントタイプをリッスンしている 3 つのイベントルールで 1 つのメッセージを送信します。特定のターゲットが呼び出される前に、不要なデータはフィルタリングされます。
Amazon SNS の実装
次の図は、Amazon SNS を使用して pub/sub パターンを実装する方法を示しています。ユーザーが支払いを行うと、「Payments」Lambda 関数によって SNS メッセージが「Payments」SNS トピックに送信されます。この SNS トピックには 3 人のサブスクライバーがいて、メッセージのコピーを受信して処理します。
Amazon EventBridge の実装
以下の図では、EventBridge を使用して、イベントルールの使用によってサブスクライバーを定義する pub/sub パターンのバージョンを構築しています。ユーザーが支払いを行うと、「Payments」Lambda関数は、異なるターゲットを指す 3 つの異なるルールを持つカスタムスキーマに基づくデフォルトのイベントバスを使用して、EventBridge にメッセージを送信します。各マイクロサービスはメッセージを処理し、必要なアクションを実行します。
