REL04-BP01 依存する分散システムの種類を特定する

分散システムには、同期、非同期、またはバッチの 3 つの種類があります。同期システムは、リクエストをできるだけ早く処理し、HTTP/S、、RESTまたはリモートプロシージャコール (RPC) プロトコルを使用して同期リクエストとレスポンスコールを実行して相互に通信する必要があります。非同期システムは、個々のシステムを結合することなく、中間サービスを介して非同期的にデータを交換することによって相互に通信します。バッチシステムは大量の入力データを受け取り、人の介入なしに自動データプロセスを実行し、出力データを生成します。

望ましい結果: 同期、非同期、バッチの依存関係と効果的に相互作用するワークロードを設計します。

一般的なアンチパターン:

• ワークロードは依存関係からの応答を無期限に待つため、リクエストが受信されたかどうかが不明なまま、ワークロードクライアントがタイムアウトすることがあります。

• ワークロードは、相互に同期呼び出しを行う一連の依存システムを使用しています。これには、チェーン全体で正常に処理が行われる前に、各システムが利用可能な状態にあり、システムでリクエストを正常に処理する必要があるため、動作が脆弱になり、全体的な可用性が損なわれる可能性があります。

• ワークロードは依存関係と非同期で通信し、重複したメッセージを受信する場合が多いのにもかかわらず、1 回のみのメッセージ処理が保証されるという概念に基づいています。

• 適切なバッチスケジューリングツールを使用していないため、ワークロードは同じバッチジョブを同時に実行します。

このベストプラクティスを活用する利点: 特定のワークロードでは、同期、非同期、バッチのいずれかの通信スタイルを 1 つ以上実装するのが一般的です。このベストプラクティスは、それぞれの通信スタイルに関連するさまざまなトレードオフを特定し、ワークロードが依存関係の中断に耐えられるようにするのに役立ちます。

このベストプラクティスを活用しない場合のリスクレベル: 高

実装のガイダンス

以下のセクションでは、各種類の依存関係に関する一般的な実装ガイダンスと固有の実装ガイダンスの両方について説明します。

一般的な質問、または機能要望

• 依存関係が提供するパフォーマンスと信頼性のサービスレベルの目標 (SLOs) が、ワークロードのパフォーマンスと信頼性の要件を満たしていることを確認します。

• AWS オブザーバビリティサービスを使用して応答時間とエラー率をモニタリングし、依存関係がワークロードに必要なレベルでサービスを提供していることを確認します。

• 依存関係と通信する際に、ワークロードが直面する可能性のある課題を特定します。分散システムには、アーキテクチャの複雑さ、運用上の負担、コストが増加する可能性のあるさまざまな課題があります。一般的な課題には、レイテンシー、ネットワークの中断、データ損失、スケーリング、データ複製の遅延などがあります。

• 堅牢なエラー処理とログ記録を実装して、依存関係で問題が発生した場合の問題のトラブルシューティングに役立ててください。

同期依存関係

同期通信では、ワークロードは依存関係にリクエストを送信し、応答を待っている操作をブロックします。依存関係がリクエストを受け取ると、すぐに処理を試み、応答をワークロードに送り返します。同期通信の大きな課題は、一時的な結合が発生するため、ワークロードとその依存関係を同時に利用できるようにする必要があることです。ワークロードで依存関係との同期通信が必要な場合は、以下のガイダンスを検討します。

• ワークロードが 1 つの機能を実行するために複数の同期依存関係に依存するべきではありません。リクエストを正常に完了させるためにパス内のすべての依存関係が利用可能である必要があるため、依存関係の連鎖は全体的な脆弱性を高めます。

• 依存関係が正常でない場合や利用できない場合のエラー処理と再試行戦略を決定します。バイモーダル動作の使用は避けてください。バイモーダル動作とは、通常モードと障害モードでワークロードが異なる動作を示す場合をいいます。二峰性動作の詳細については、REL11「-BP05 静的安定性を使用して二峰性動作を防ぐ」を参照してください。

• ワークロードを待機させるより、フェイルファストの方がよいことを覚えておいてください。例えば、「AWS Lambda デベロッパーガイド」では、Lambda 関数を呼び出すときに再試行や失敗を処理する方法について説明します。

• ワークロードが依存関係を呼び出す際のタイムアウトを設定します。これにより、応答を待つ時間が長すぎたり、無期限に待ったりすることを回避できます。この問題に関する有用な説明については、「レイテンシー対応の Amazon DynamoDB アプリケーションの AWS Java SDKHTTPリクエスト設定の調整」を参照してください。

• 1 つのリクエストを処理するためのワークロードから依存関係への呼び出し回数を最小限に抑えます。呼び出し回数の多さは、結合とレイテンシーの増加につながります。

非同期依存関係

ワークロードを依存関係から一時的に切り離すには、非同期で通信する必要があります。非同期アプローチを使用すると、ワークロードの依存関係や一連の依存関係からの応答の送信を待つことなく、他の処理を実行できます。

ワークロードで依存関係との非同期通信が必要な場合は、以下のガイダンスを検討します。

• ユースケースと要件に基づいて、メッセージングとイベントストリーミングのどちらを使用するかを決定します。メッセージングを使用すると、メッセージブローカーを介してメッセージを送受信することで、ワークロードが依存関係と通信できます。イベントストリーミングを使用すると、ワークロードとその依存関係は、ストリーミングサービスを使用して、できるだけ早く処理する必要のあるデータを継続的なストリームとして配信されるイベントを公開およびサブスクライブできます。

• メッセージングとイベントストリーミングではメッセージの処理方法が異なるため、以下に基づいてトレードオフを決定する必要があります。

  • メッセージ優先度: メッセージブローカーは、通常のメッセージよりも先に優先度の高いメッセージを処理できます。イベントストリーミングでは、すべてのメッセージの優先度が同じになります。

  • メッセージ消費: メッセージブローカーは、コンシューマーがメッセージを受信したかどうか確認します。イベントストリーミングのコンシューマーは、最後に読んだメッセージを常に把握しておく必要があります。

  • メッセージ順序 : メッセージングでは、（FIFO) アプローチを使用し first-in-first-outない限り、メッセージが送信される正確な順序でメッセージを受信することは保証されません。イベントストリーミングでは、データが生成された順序が常に保持されます。

  • メッセージの削除: メッセージングでは、コンシューマーはメッセージを処理した後に削除する必要があります。イベントストリーミングサービスはメッセージをストリームに追加し、メッセージの保存期間が終了するまでストリームに残ります。この削除ポリシーにより、イベントストリーミングはメッセージの再生に適したものになります。

• 依存関係がいつ作業を完了したかをワークロードがどのように認識するかを定義します。ワークロードが Lambda 関数を非同期的に呼び出すと、Lambda はリクエストをキューに入れ、追加情報を含まない成功のレスポンスを返します。処理が完了すると、Lambda 関数は成功または失敗に基づいて設定可能な送信先に結果を送信できます。

• べき等性を活用して、重複メッセージを処理するワークロードを構築します。べき等性とは、同じメッセージに対してワークロードが複数回生成されても、ワークロードの結果は変化しないことを指します。ネットワーク障害が発生した場合、または確認応答が受信されていない場合、メッセージングサービスまたはストリーミングサービスがメッセージを再配信することに注意してください。

• ワークロードが依存関係から応答を受け取らない場合は、ワークロードはリクエストを再送信します。ワークロードの CPU、メモリ、ネットワークリソースを保持して他のリクエストを処理するための再試行回数を制限することを検討してください。「AWS Lambda ドキュメント」では、非同期呼び出しのエラーを処理する方法を示しています。

• 適切なオブザーバビリティ、デバッグ、トレースツールを活用して、ワークロードの非同期通信とその依存関係を管理し運用します。Amazon CloudWatch を使用して、メッセージングおよびイベントストリーミングサービスをモニタリングできます。また、AWS X-Ray を使用してワークロードを計測し、問題のトラブルシューティングに関するインサイトをすばやく得ることもできます。

バッチ依存関係

バッチシステムは、手動操作なしで、入力データを受け取り、処理するための一連のジョブを開始し、いくつかの出力データを生成します。データサイズにもよりますが、ジョブは数分から、場合によっては数日かかることもあります。ワークロードで依存関係とのバッチ通信を行う場合は、以下のガイダンスを検討します。

• ワークロードでバッチジョブを実行する時間枠を定義します。ワークロードでは、例えば 1 時間ごとまたは月末に、バッチシステムを呼び出す繰り返しパターンを設定できます。

• データ入力と処理済みデータ出力の場所を定義します。Amazon Simple Storage Services (Amazon S3)、Amazon Elastic File System (Amazon EFS）、Amazon FSx for Lustre などのストレージサービスを選択し、ワークロードがファイルを大規模に読み書きできるようにします。

• ワークロードで複数のバッチジョブを呼び出す必要がある場合は、 AWS Step Functionsを活用して、 AWS またはオンプレミスで実行されるバッチジョブのオーケストレーションを簡素化できます。このサンプルプロジェクトは、Step Functions、AWS Batch、および Lambda を使用したバッチジョブのオーケストレーションを示しています。

• バッチジョブをモニタリングして、ジョブの完了に本来よりも時間がかかっているなどの異常がないかを確認します。CloudWatch Container Insights などのツールを使用して、 AWS Batch 環境やジョブをモニタリングできます。この場合、ワークロードによって次のジョブの開始が停止し、関連するスタッフに例外が通知されます。