メッセージングパターンの分離

このパターンは、非同期ポーリングモデルを使用してマイクロサービス間の非同期通信を実現します。バックエンドシステムは呼び出しを受信すると、ただちに要求 ID で応答し、要求を非同期的に処理します。疎結合アーキテクチャを構築して、同期通信、レイテンシー、入出力操作 (IO) によるボトルネックを回避できます。このパターンのユースケースでは、Amazon Simple Queue Service (Amazon SQS) と Lambda を使用して、異なるマイクロサービス間の非同期通信を実装します。

このパターンの使用を検討すべきなのは、次のような場合です。

• 疎結合アーキテクチャを作りたい。

• すべての操作を 1 つのトランザクションで完了する必要はなく、一部の操作は非同期でもかまいません。

• ダウンストリームシステムでは、毎秒トランザクション (TPS) 受信レートを処理できません。メッセージはキューに書き込まれ、リソースの利用可能性に基づいて処理されます。

このパターンの欠点は、ビジネストランザクションアクションが同期的に行われることです。呼び出し元システムが応答を受信しても、トランザクションの一部はまだ下流システムで処理され続けるかもしれません。

重要

このパターンはファイアアンドフォーゲットモデルに適しているため、このサービスを呼び出すクライアントは、トランザクションステータスを取得するためにリクエスト ID を使用して実際のサービスをポーリングすべきです。

ユースケース

この使用例では、保険システムには販売データベースがあり、毎月の支払いが行われた後、カスタマー取引の詳細で自動的に更新されます。次の図は、デカップルメッセージングパターンを使用してこのシステムを構築する方法を示しています。

ワークフローは、以下の手順で構成されます。

1. フロントエンドアプリケーションは、ユーザーが毎月の支払いを行った後、支払い情報を使用して API Gateway を呼び出します。

2. API Gateway は「Customer」Lambda 関数を実行します。この関数は支払い情報を Amazon Aurora データベースに保存し、トランザクションの詳細をメッセージとして「Sales」Amazon SQS に書き込み、呼び出し元のシステムに成功メッセージで応答します。

3. 「Sales」Lambda 関数は SQS メッセージからトランザクションの詳細を取得し、売上データを更新します。売上データベースを更新するための失敗および再試行ロジックは、「Sales」Lambda 関数の一部として組み込まれています。