翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 部分的なバッチレスポンス実装のベストプラクティス
このセクションでは、Amazon SQS イベントソースの部分的なバッチレスポンスを設定するためのベストプラクティスについて説明します。
+ [デッドレターキュー](https://docs.aws.amazon.com//AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)を設定して、サーバーレスアプリケーションのアーキテクチャにスノーボールアンチパターンが発生するのを防ぎます。詳細については「[スノーボールアンチパターンの回避](#snowball-anti-patterns)」セクションを参照してください。
+ 失敗したメッセージのみを表示するように Lambda 関数イベントソースマッピングを設定します。これを行うには、イベントソースマッピングを設定するときに**ReportBatchItemFailures** を **FunctionResponseTypes** リストに追加します。Lambda 関数は、SQS によって呼び出されると、部分的なバッチレスポンスを実装する必要があります。Powertools for AWS Lambda Batch Processing ユーティリティの使用を検討してください。このユーティリティは、部分バッチサポートが組み込まれた SQS メッセージを処理します。
## Batch 処理
+ SQS によって呼び出される Lambda 関数に部分的なバッチレスポンスを実装します。Powertools for AWS Lambda Batch Processing ユーティリティの使用を検討してください。このユーティリティは、部分的なバッチレスポンスのサポートが組み込まれた SQS メッセージ処理を処理します。詳細については、「 *AWS Lambda デベロッパーガイド*」の[Amazon SQSトリガーを使用した Lambda 関数のバッチ項目障害](https://docs.aws.amazon.com//lambda/latest/dg/example_serverless_SQS_Lambda_batch_item_failures_section.html)の報告」を参照してください。
** AWS Lambda バッチ処理ユーティリティの Powertools**
+ [Powertools for AWS Lambda Batch Processing Utility (Python)](https://docs.aws.amazon.com//powertools/python/latest/utilities/batch/)
+ [AWS Lambda バッチ処理ユーティリティの Powertools (Java)](https://docs.aws.amazon.com//powertools/java/latest/utilities/batch/)
+ [AWS Lambda バッチ処理ユーティリティの Powertools (.Net)](https://docs.aws.amazon.com//powertools/dotnet/utilities/batch-processing/)
+ [AWS Lambda バッチ処理ユーティリティの Powertools (TypeScript)](https://docs.aws.amazon.com//powertools/typescript/latest/features/batch/)
## べき等性
+ メッセージがデッドレターキューに移動する前にソースキューに送信される回数を定義します。最も可能性の高い障害の原因とその推定復旧時間を特定して、定義した値がアプリケーションのユースケースに適合していることを確認します。再試行回数を定義するには、ソースキューの **RedrivePolicy** で **maxReceiveCount** 値を設定します。詳細については、「Amazon SQS API リファレンス」の「[SetQueueAttributes](https://docs.aws.amazon.com//AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html)」を参照してください。また、[「Amazon Simple Queue Service デッドレターキューリドライブをソースキューに導入する](https://aws.amazon.com//blogs/compute/introducing-amazon-simple-queue-service-dead-letter-queue-redrive-to-source-queues/)」を参照してください。
+ Lambda コードがべき等であり、メッセージを複数回処理できることを確認します。べき等性を実装するには、Powertools for AWS Lambda Idempotency Utility の使用を検討してください。これにより、Amazon SQS バッチ内の個々のジョブをサポートする関数のコードが準備されます。まず、**ReportBatchItemFailures** をイベントソースマッピングに組み込みます。詳細については、「 *AWS Lambda デベロッパーガイド*[」の「部分的なバッチレスポンスの実装](https://docs.aws.amazon.com//lambda/latest/dg/services-sqs-errorhandling.html#services-sqs-batchfailurereporting)」および[Amazon SQSメッセージが Lambda 関数を複数回呼び出すのを防ぐにはどうすればよいですか？」を参照してください。](https://repost.aws/knowledge-center/lambda-function-process-sqs-messages)
**Powertools for AWS Lambda Idempotency ユーティリティ**
+ [Powertools for AWS Lambda Idempotency Utility (Python)](https://docs.aws.amazon.com//powertools/python/latest/utilities/idempotency/)
+ [Powertools for AWS Lambda Idempotency Utility (Java)](https://docs.aws.amazon.com//powertools/java/latest/utilities/idempotency/)
+ [Powertools for AWS Lambda Idempotency Utility (.Net)](https://docs.aws.amazon.com//powertools/dotnet/utilities/idempotency/)
+ [Powertools for AWS Lambda Idempotency Utility (TypeScript)](https://docs.aws.amazon.com//powertools/typescript/latest/features/idempotency/)
## メトリクス
+ ジョブの詳細と失敗したジョブを追跡するために 関数にビジネスメトリクスを組み込むには、**aws-embedded-metrics** または Powertools for AWS Lambda Metrics Utility の使用を検討してください。これにより、[埋め込みメトリクス形式で](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format_Libraries.html) SQS イベントを処理しながら運用メトリクスとビジネスメトリクスが出力されます。
** AWS Lambda メトリクスユーティリティの Powertools**
+ [Powertools for AWS Lambda Metrics Utility (Python)](https://docs.aws.amazon.com/powertools/python/latest/core/metrics/)
+ [Powertools for AWS Lambda Metrics Utility (Java)](https://docs.aws.amazon.com/powertools/java/latest/core/metrics/)
+ [AWS Lambda メトリクスユーティリティの Powertools (.Net)](https://docs.aws.amazon.com/powertools/dotnet/core/metrics/)
+ [Powertools for AWS Lambda Metrics ユーティリティ (TypeScript)](https://docs.aws.amazon.com/powertools/typescript/latest/features/metrics/)
+ First[First-In-First-Out (FIFO)](https://docs.aws.amazon.com/powertools/typescript/latest/features/metrics/) キューを使用する場合、関数は最初の失敗後にメッセージの処理を停止し、失敗したメッセージと未処理のメッセージをすべて **batchItemFailures** で返す必要があります。これにより、キューのメッセージ順序が保持されます。
**注記**
部分バッチ処理を使用するアプリケーションの全体的なパフォーマンスを追跡するには、コードレベルのパフォーマンス追跡が必要です。バッチ処理が設定されると、Lambda 関数の呼び出しは通常、処理結果に関係なく成功します。
## スノーボールアンチパターンの回避
Lambda と Amazon SQS は、アップストリームマイクロサービスが SQS キューに書き込むメッセージを制御できません。処理できないメッセージがある場合、Lambda は別の[デッドレターキューが設定されていない限り、未処理のメッセージをソース SQS キュー](https://docs.aws.amazon.com//AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)に返します。その後、未処理のメッセージは Lambda 関数によって再試行されます。デッドレターキューが存在しない場合、Amazon SQS キューに返される未処理のメッセージの数は、最終的にキューの有効なメッセージの数を上回ります。
このタイプの *Snowball* アンチパターンは、連続する各 Lambda 呼び出しが問題を悪化させるため、次の問題を引き起こす可能性があります。
+ ジョブの処理に通常よりも時間がかかるか、まったく処理されないため、**ユーザーエクスペリエンスが悪い**
+ Amazon SQS キュー内のメッセージ数とメッセージ再試行回数の急激な増加に比例する**コストの増加**
+ **アプリケーションの Lambda コンピューティング容量の削減、または AWS アカウント**関数に呼び出しリクエストの制限がない場合
部分的なバッチレスポンスを設定するときに Snowball アンチパターンを作成しないようにするには、デッドレターキューも作成することをお勧めします。この個別のキューに正常に処理されなかったメッセージを格納できるため、アプリケーションの未処理メッセージのライフサイクルをより適切に管理できます。
詳細については、[Amazon SQS デベロッパーガイド」の「Amazon SQS コンソールを使用してデッドレターキューを設定する](https://docs.aws.amazon.com//AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-configure-dead-letter-queue.html)」を参照してください。 *Amazon SQS *