部分的なバッチレスポンス実装のベストプラクティス - AWS 規範ガイダンス

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

部分的なバッチレスポンス実装のベストプラクティス

以下は、Amazon SQSイベントソース の部分的なバッチレスポンスを設定するためのベストプラクティスです。

  • デッドレターキューを設定して、サーバーレスアプリケーションのアーキテクチャにスノーボールアンチパターンが発生するのを防ぎます。詳細については、このガイドの「Avoiding snowball anti-patterns」のセクションを参照してください。

  • 失敗したメッセージのみを表示するように Lambda 関数のイベントソースマッピングを設定します。これを行うには、イベントソースマッピングを設定するときに ReportBatchItemFailures 値をFunctionResponseTypesリストに含める必要があります。詳細については、「 AWS Lambda デベロッパーガイド」の「部分的なバッチレスポンスの実装」を参照してください。

  • メッセージがデッドレターキューに移動する前にソースキューに送信される回数を定義します。最も可能性の高い障害の原因とその推定復旧時間を特定して、定義する値がアプリケーションのユースケースにフィットすることを確認してください。再試行回数を定義するには、ソースキューの に maxReceiveCount値を設定する必要がありますRedrivePolicy。詳細については、「Amazon SQSAPIリファレンスSetQueueAttributes」の「」を参照してください。 AWS ブログの「ソースキューに Amazon Simple Queue Service デッドレターキューリドライブを導入する」も参照してください。

  • Lambda 関数コードが冪等性で、メッセージを複数回処理できることを確認してください。これにより、Amazon SQS メッセージバッチ内の個々のジョブをサポートする関数のコードが準備されます。開始点として、イベントソースマッピング設定ReportBatchItemFailuresに を組み込むことをお勧めします。詳細については、「AWS Lambda デベロッパーガイド」の「バッチアイテムの失敗をレポートする」を参照してください。また、「Amazon SQSメッセージが Lambda 関数を複数回呼び出さないようにするにはどうすればよいですか?」も参照してください。

  • aws-embedded-metricsPowertools for AWS Lambda (Python) などのツールの使用を検討してください。これらのツールを使用すると、ビジネスメトリクスを関数コードに組み込んで、失敗したジョブやそのジョブの詳細を追跡できます。

  • この機能を先入れ先出し (FIFO) キュー で使用している場合、関数は最初の失敗後にメッセージの処理を停止し、 で失敗したメッセージと未処理のメッセージをすべて返す必要がありますbatchItemFailures。これは、キュー内のメッセージの順序を維持するのに役立ちます。

注記

部分的なバッチ処理を使用するアプリケーションの全体的なパフォーマンスを追跡するには、コードレベルのパフォーマンスの追跡が必要です。部分的なバッチ処理を設定すると、バッチ処理の結果にかかわらず、Lambda 関数の呼び出しはほとんど常に成功します。

スノーボールアンチパターンの回避

Lambda と Amazon SQSは、アップストリームマイクロサービスが Amazon SQSキューに書き込むメッセージを制御できません。処理できないメッセージがある場合、Lambda は別のデッドレターSQSキューが設定されていない限り、未処理のメッセージをソース Amazon キューに返します。 https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.htmlこれらの未処理のメッセージは、次の各 Amazon SQS メッセージバッチで Lambda 関数によって再試行され、失敗し、再試行のためにキューに戻ります。デッドレターキューが存在しない場合、Amazon SQSキューに返される未処理のメッセージの数は、最終的にキュー内の有効なメッセージの数を上回ります。

このタイプのスノーボールアンチパターンは、Lambda 関数を連続して呼び出すことで問題を悪化させ、さらに以下の問題を引き起こす可能性があります。

  • ジョブの処理に通常よりも時間がかかること、またはまったく処理されないことによる質の低いユーザーエクスペリエンス

  • Amazon キュー内のメッセージ数とメッセージの再試行回数が指数関数的に増加することに伴うコストの増加 SQS

  • 関数の呼び出しリクエストに制限がない場合、アプリケーションまたは AWS アカウント全体の Lambda コンピューティング性能の低下

Amazon で部分的なバッチレスポンスを設定するときに Snowball アンチパターンを作成しないようにするにはSQS、デッドレターキューも作成することをお勧めします。この個別のキューに正常に処理されなかったメッセージを格納できるため、アプリケーションの未処理メッセージのライフサイクルをより適切に管理できます。

手順については、「Amazon SQS デベロッパーガイド」の「デッドレターキューの設定 (コンソール)」を参照してください。