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

散布図パターン

Intent

散布図パターンは、類似または関連するリクエストを複数の受信者にブロードキャストし、アグリゲータと呼ばれるコンポーネントを使用してレスポンスを 1 つのメッセージに集約することを含むメッセージルーティングパターンです。このパターンは、並列化の達成、処理レイテンシーの短縮、非同期通信の処理に役立ちます。同期アプローチを使用して散布図パターンを実装するのは簡単ですが、より強力なアプローチでは、メッセージングサービスの有無にかかわらず、非同期通信でのメッセージルーティングとして実装する必要があります。

導入する理由

アプリケーション処理では、順次処理に時間がかかるリクエストを、並列処理される複数のリクエストに分割できます。API コールを使用して複数の外部システムにリクエストを送信し、レスポンスを取得することもできます。散布図パターンは、複数のソースからの入力が必要な場合に役立ちます。Scatter-gather は、情報に基づいた意思決定やリクエストに最適なレスポンスの選択に役立つように結果を集約します。

散布図パターンは、名前が示すように、2 つのフェーズで構成されます。

散布フェーズはリクエストメッセージを処理し、複数の受信者に並行して送信します。このフェーズでは、アプリケーションはリクエストをネットワーク全体に分散し、即時の応答を待たずに実行し続けます。
収集フェーズ では、アプリケーションは受信者からレスポンスを収集し、それらをフィルタリングまたは統合レスポンスに結合します。すべてのレスポンスが収集されると、1 つのレスポンスに集約することも、さらに処理するために最適なレスポンスを選択することもできます。

適用対象

次の場合は、散布図パターンを使用します。

正確なレスポンスを作成するために、さまざまな APIsして統合する計画を立てます。このパターンは、さまざまなソースからの情報をまとまりのある全体に統合します。例えば、予約システムは複数の受信者にリクエストを行い、複数の外部パートナーから見積りを取得できます。
トランザクションを完了するには、同じリクエストを複数の受信者に同時に送信する必要があります。例えば、このパターンを使用してインベントリデータを並行してクエリし、製品の可用性を確認できます。
複数の受信者にリクエストを分散することで負荷分散を実現できる、信頼性が高くスケーラブルなシステムを実装したいと考えています。1 人の受信者が失敗したり、高い負荷がかかったりしても、他の受信者は引き続きリクエストを処理できます。
複数のデータソースを含む複雑なクエリを実装するときに、パフォーマンスを最適化する必要があります。クエリを関連するデータベースに分散し、結果の一部を収集して、包括的な回答にまとめることができます。
シャーディングとレプリケーションのために、データリクエストが複数のデータ処理エンドポイントにルーティングされるマップ削減処理のタイプを実装しています。部分的な結果がフィルタリングされ、結合されて適切なレスポンスが作成されます。
キーバリューデータベースの書き込みが多いワークロードのパーティションキースペースに書き込みオペレーションを分散したい。アグリゲータは、各シャード内のデータをクエリして結果を読み取り、それらを 1 つのレスポンスに統合します。

問題点と考慮事項

耐障害性: このパターンは、並行して動作する複数の受信者に依存するため、障害を適切に処理することが不可欠です。受信者の障害がシステム全体に与える影響を軽減するために、冗長性、レプリケーション、障害検出などの戦略を実装できます。
スケールアウト制限： 処理ノードの合計数が増えると、関連するネットワークオーバーヘッドも増加します。ネットワーク経由の通信を伴うすべてのリクエストは、レイテンシーを増加させ、並列化の利点に悪影響を及ぼす可能性があります。
応答時間のボトルネック : 最終処理が完了する前にすべての受信者を処理する必要があるオペレーションの場合、システム全体のパフォーマンスは、受信者の応答時間が最も遅くなります。
部分的なレスポンス: リクエストが複数の受信者に分散されると、一部の受信者がタイムアウトすることがあります。このような場合、実装はレスポンスが不完全であることをクライアントに伝える必要があります。UI フロントエンドを使用してレスポンス集約の詳細を表示することもできます。
データ整合性: 複数の受信者間でデータを処理する場合は、データの同期と競合解決の手法を慎重に検討して、最終的な集計結果が正確で一貫性があることを確認する必要があります。

実装

高レベルのアーキテクチャ

散布図パターンでは、ルートコントローラーを使用して、リクエストを処理する受信者にリクエストを分散します。散布フェーズでは、このパターンで 2 つのメカニズムを使用して受信者にメッセージを送信できます。

分散による散布: アプリケーションには、結果を取得するために呼び出す必要がある受信者の既知のリストがあります。受信者は、一意の関数を持つ異なるプロセスでも、処理負荷を分散するためにスケールアウトされた単一のプロセスでもかまいません。いずれかの処理ノードがタイムアウトしたり、応答の遅延が表示されたりすると、コントローラーは処理を別のノードに再分散できます。
Scatter by auction: アプリケーションは、パブリッシュ/サブスクライブパターンを使用して、関心のある受信者にメッセージをブロードキャストします。この場合、受信者はいつでもメッセージをサブスクライブしたり、サブスクリプションから脱退したりできます。

ディストリビューションによる散布

分散による散布方法では、ルートコントローラーは受信リクエストを独立したタスクに分割し、使用可能な受信者に割り当てます (散布フェーズ）。各受信者 (プロセス、コンテナ、または Lambda 関数) は、その計算で独立して並列に動作し、レスポンスの一部を生成します。受信者がタスクを完了すると、アグリゲータ (収集フェーズ) に応答を送信します。アグリゲータは部分的なレスポンスを結合し、最終的な結果をクライアントに返します。次の図は、このワークフローを示しています。

コントローラー (データファイルプロセッサ) は呼び出しのセット全体をオーケストレーションし、呼び出すすべての予約エンドポイントを認識します。タイムアウトパラメータを設定して、時間がかかりすぎるレスポンスを無視できます。リクエストが送信されると、アグリゲータは各エンドポイントからのレスポンスを待ちます。レジリエンスを実装するために、各マイクロサービスを複数のインスタンスでデプロイして負荷分散を行うことができます。アグリゲータは結果を取得し、それらを 1 つの応答メッセージに結合して、さらに処理する前に重複データを削除します。タイムアウトしたレスポンスは無視されます。コントローラーは、別のアグリゲータサービスを使用する代わりに、アグリゲータとして機能することもできます。

入札による散布

コントローラーが受信者を認識していない場合、または受信者が疎結合されている場合は、アトクション方式で散布図を使用できます。この方法では、受信者はトピックをサブスクライブし、コントローラーはトピックにリクエストを発行します。受信者は結果をレスポンスキューに発行します。ルートコントローラーは受信者を認識しないため、収集プロセスではアグリゲータ (別のメッセージングパターン) を使用してレスポンスを収集し、1 つのレスポンスメッセージに分割します。アグリゲータは一意の ID を使用してリクエストのグループを識別します。

例えば、次の図では、入札による散布法を使用して、航空会社のウェブサイトにフライト予約サービスを実装しています。このウェブサイトでは、ユーザーは航空会社のキャリアとそのパートナーのキャリアからフライトを検索して表示でき、検索のステータスをリアルタイムで表示する必要があります。フライト予約サービスは、3 つの検索マイクロサービスで構成されています。ノンストップ便、ストップ付き便、およびパートナー航空会社です。パートナー航空会社の検索では、パートナーの API エンドポイントを呼び出してレスポンスを取得します。

フライト予約サービス (コントローラー) は、検索条件をクライアントからの入力として受け取り、リクエストを処理してトピックに発行します。
コントローラーは一意の ID を使用してリクエストの各グループを識別します。
クライアントは、ステップ 6 の一意の ID をアグリゲータに送信します。
予約トピックにサブスクライブしている予約検索マイクロサービスはリクエストを受け取ります。
マイクロサービスはリクエストを処理し、指定された検索条件の座席の可用性をレスポンスキューに返します。
アグリゲータは、一時データベースに保存されているすべてのレスポンスメッセージを照合し、フライトを一意の ID でグループ化して、単一の統合レスポンスを作成し、クライアントに送り返します。

を使用した実装 AWS のサービス

ディストリビューションによる散布

次のアーキテクチャでは、ルートコントローラーは、受信リクエストデータを個々の Amazon Simple Storage Service (Amazon S3) バケットに分割し、ワークフローを開始するデータファイルプロセッサ (Amazon ECS) です。 AWS Step Functions ワークフローはデータをダウンロードし、並列ファイル処理を開始します。Parallel 状態は、すべてのタスクがレスポンスを返すのを待ちます。 AWS Lambda 関数はデータを集約し、Amazon S3 に保存します。

次の図は、 Parallel状態の Step Functions ワークフローを示しています。

での分散方式による散布の実装 AWS - Step Functions ワークフロー

入札による散布

次の図は、の分散の AWS アーキテクチャを入札方法別に示しています。ルートコントローラーフライト予約サービスは、フライト検索リクエストを複数のマイクロサービスに分散します。パブリッシュ/サブスクライブチャネルは、通信用のマネージドメッセージングサービスである Amazon Simple Notification Service (Amazon SNS) で実装されます。Amazon SNS は、分離されたマイクロサービスアプリケーション間、またはユーザーへの直接通信間のメッセージをサポートします。受信者マイクロサービスを Amazon Elastic Kubernetes Service (Amazon EKS) または Amazon Elastic Container Service (Amazon ECS) にデプロイして、管理とスケーラビリティを向上させることができます。フライト結果サービスは結果をクライアントに返します。または Amazon ECS AWS Lambda や Amazon EKS などの他のコンテナオーケストレーションサービスに実装できます。

フライト予約サービス (コントローラー) は、クライアントからの入力として検索条件を受け取り、リクエストを処理して SNS トピックに発行します。
コントローラーは一意の ID を Amazon Aurora データベースに発行して、リクエストを識別します。
クライアントは、ステップ 6 で一意の ID をクライアントに送信します。
予約トピックにサブスクライブしている予約検索マイクロサービスはリクエストを受け取ります。
マイクロサービスはリクエストを処理し、指定された検索条件の座席可用性を Amazon Simple Queue Service (Amazon SQS) のレスポンスキューに返します。アグリゲータは、すべてのレスポンスメッセージを照合し、一時データベースに保存します。
フライト結果サービスは、フライトを一意の ID でグループ化し、単一の統合レスポンスを作成して、クライアントに送り返します。

このアーキテクチャに別の航空会社検索を追加する場合は、SNS トピックをサブスクライブし、SQS キューに発行するマイクロサービスを追加します。

要約すると、散布図パターンにより、分散システムは効率的な並列化を実現し、レイテンシーを短縮し、非同期通信をシームレスに処理できます。

GitHub リポジトリ

このパターンのサンプルアーキテクチャの完全な実装については、https://github.com/aws-samples/asynchronous-messaging-workshop/tree/master/code/lab-3 の GitHub リポジトリを参照してください。

ワークショップ

デカップリングマイクロサービスワークショップの散布図ラボ

ブログの参考情報

マイクロサービスのアプリケーション統合パターン