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

Scatter-gather パターン

Intent

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

導入する理由

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

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

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

適用対象

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

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

ワークショップ

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

ブログの参考情報

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