翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon SQS のベストプラクティス
Amazon SQS はメッセージキューを管理および処理し、アプリケーションのさまざまな部分でメッセージを確実かつ大規模に交換できるようにします。このトピックでは、空のレスポンスを減らすためのロングポーリングの使用、処理エラーに対処するためのデッドレターキューの実装、そしてセキュリティ向上のためのキュー権限の最適化といった、主な運用上のベストプラクティスを扱います。
****トピック****
+ [エラー処理および問題ありのメッセージ](best-practices-error-handling.md)
+ [メッセージ重複排除とグループ化](best-practices-message-deduplication.md)
+ [メッセージ処理とタイミング](best-practices-message-processing.md)
# Amazon SQS のエラー処理および問題ありのメッセージ
このトピックでは、リクエストエラーの処理、問題ありのメッセージのキャプチャ、メッセージの信頼性を確保するためのデッドレターキュー保持の設定など、Amazon SQS でのエラーの管理と軽減に関する詳細な手順を示します。
****トピック****
+ [Amazon SQS でのリクエストエラーの処理](handling-request-errors.md)
+ [問題ありのメッセージのキャプチャ](capturing-problematic-messages.md)
+ [Amazon SQS でのデッドレターキュー保持の設定](setting-up-dead-letter-queue-retention.md)
# Amazon SQS でのリクエストエラーの処理
リクエストのエラーを処理するには、次の方法のいずれかを使用します:
+ AWS SDK を使用する場合は、自動*再試行とバックオフ*のロジックが既に用意されています。詳細については、「*Amazon Web Services 全般のリファレンス*」の「[エラーの再試行と AWSでのエクスポネンシャルバックオフ](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)」を参照してください。
+ 再試行とバックオフに AWS SDK 機能を使用しない場合は、Amazon SQS からメッセージ、タイムアウト、エラーメッセージを受信せずに [ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html) アクションを再試行する前に一時停止 (200 ミリ秒など) してください。 Amazon SQS 同じ結果が得られる `ReceiveMessage` をそれ以降に使用するには、それよりも長い一時停止 (たとえば、400ms) を許可します。
# 問題ありのメッセージのキャプチャ
処理できないすべてのメッセージをキャプチャし、\$1CloudWatch メトリクス\$1の正確さを確保するには、[[デッドレターキュー]](sqs-dead-letter-queues.md)を設定します。
+ Redrive ポリシーは、ソースキューがメッセージの処理の失敗を指定回数繰り返した後に、デッドレターキューにメッセージをリダイレクトします。
+ デッドレターキューを使用するとメッセージ数が減少し、*ポイズンピル*メッセージ (受信されたが処理できないメッセージ) が発生する可能性が低下します。
+ キューにポイズンピルメッセージを含めると、ポイズンピルメッセージの期間が正しく表示されないため、[`ApproximateAgeOfOldestMessage`](sqs-available-cloudwatch-metrics.md)CloudWatchメトリクスが歪む可能性があります。デッドレターキューを設定すると、このメトリクスを使用する場合の誤ったアラームの回避に役立ちます。
# Amazon SQS でのデッドレターキュー保持の設定
標準キューの場合、メッセージの有効期限は常に元のエンキューのタイムスタンプに基づきます。デッドレターキューに移動すると、エンキューのタイムスタンプは変更されません。`ApproximateAgeOfOldestMessage` メトリクスは、メッセージが最初に送信されたときでは*なく*、メッセージがデッドレターキューに移動したときを示します。たとえば、メッセージがデッドレターキューに移動される前に、元のキューで1日費やすと仮定します。デッドレターキューの保持期間が4日間である場合、メッセージは3日後にデッドレターキューから削除され、`ApproximateAgeOfOldestMessage`は3日間です。したがって、デッドレターキューの保持期間を、元のキューの保持期間よりも長く設定することがベストプラクティスです。
FIFO キューでは、メッセージがデッドレターキューに移動すると、エンキューのタイムスタンプがリセットされます。`ApproximateAgeOfOldestMessage` メトリクスは、メッセージがデッドレターキューに移動した日を示します。上記の同じ例では、メッセージは 4 日後にデッドレターキューから削除され、`ApproximateAgeOfOldestMessage` は 4 日間です。
# Amazon SQS のメッセージ重複排除とグループ化
このトピックでは、Amazon SQS で一貫したメッセージ処理を確保するためのベストプラクティスについて説明します。ここでは、以下を使用する方法について説明します。
+ [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html#API_SendMessage_RequestSyntax](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html#API_SendMessage_RequestSyntax) は、FIFO キューでメッセージが重複するのを防ぎます。
+ [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) は、個別のメッセージグループ内のメッセージの順序を管理します。
****トピック****
+ [Amazon SQS での一貫性のないメッセージ処理の回避](avoiding-inconsistent-message-processing.md)
+ [メッセージ重複排除ID の使用](using-messagededuplicationid-property.md)
+ [メッセージグループ ID の使用](using-messagegroupid-property.md)
+ [受信リクエスト試行 ID の使用](using-receiverequestattemptid-request-parameter.md)
# Amazon SQS での一貫性のないメッセージ処理の回避
Amazon SQS は分散システムであるため、[https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html) API メソッドの呼び出しから正常に戻るときに Amazon SQS がメッセージを配信済みとマークしても、コンシューマーはメッセージを受信しない可能性があります。この場合、Amazon SQSはコンシューマーがメッセージを受信していない場合でも、少なくとも 1 回はメッセージを配信済みとして記録します。これらの状況ではメッセージの配信は再試行されないため、[デッドレターキュー](sqs-dead-letter-queues.md)の最大受信数を 1 に設定することはお勧めしません。
# Amazon SQS でのメッセージ重複排除 ID の使用
[https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) は、Amazon SQS の FIFO キューでのみ使用され、メッセージの重複配信を防ぐためのトークンです。これにより、5 分間の重複排除ウィンドウ内で、同じ重複排除 ID を持つメッセージの 1 つのインスタンスのみを処理および配信します。
Amazon SQS が特定の重複排除 ID を持つメッセージをすでに受け付けている場合、同じ ID を持つ後続のメッセージは受信確認されますが、コンシューマーには配信されません。
**注記**
Amazon SQS は、メッセージを受信して削除した後も、重複除外 ID を追跡し続けます。
**Topics**
+ [Amazon SQS でメッセージ重複排除 ID を提供する場合](providing-message-deduplication-id.md)
+ [Amazon SQS でのシングルプロデューサー/コンシューマーシステムにおける重複排除の有効化](single-producer-single-consumer.md)
+ [Amazon SQS での停止復旧シナリオ](designing-for-outage-recovery-scenarios.md)
+ [Amazon SQS での可視性タイムアウトの設定](working-with-visibility-timeouts.md)
# Amazon SQS でメッセージ重複排除 ID を提供する場合
プロデューサーは、次のシナリオでメッセージ重複排除 ID を指定する必要があります。
+ 同一のメッセージ本文を送信する際に、それらを個別のものとして扱う必要がある場合。
+ 同じコンテンツを含み、メッセージ属性が異なるメッセージを送信し、各メッセージが個別に処理されるようにする場合。
+ コンテンツが異なるメッセージを送信し (メッセージ本文の再試行カウンターなど)、Amazon SQS にそれらを重複として認識させる必要がある場合。
# Amazon SQS でのシングルプロデューサー/コンシューマーシステムにおける重複排除の有効化
プロデューサーとコンシューマーがそれぞれ単一であり、本文にアプリケーション固有のメッセージ ID が含まれているためメッセージが一意である場合は、次のベストプラクティスに従います。
+ キューでコンテンツベースの重複排除を有効にします (メッセージ本文がそれぞれ一意)。プロデューサーはメッセージ重複排除 ID を省略できます。
+ Amazon SQS の FIFO キューでコンテンツベースの重複排除が有効になっている場合、メッセージを重複排除 ID 付きで送信すると、[https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) 重複排除 ID により、生成済みのコンテンツベースの重複排除 ID が上書きされます。
+ コンシューマーでは各リクエストに対する受信リクエスト試行 ID は必須ではありませんが、失敗再試行シーケンスの実行が速くなるため、これがベストプラクティスです。
+ FIFOキュー内のメッセージの順序が妨げられることはないのでリクエストの送信や受信は再試行できます。
# Amazon SQS での停止復旧シナリオ
FIFOキューの重複排除プロセスでは、時間的制約があります。アプリケーションを設計するときは、プロデューサーとコンシューマーの両方が、重複を発生させたり、処理に失敗することなく、クライアントやネットワークの停止から復旧できるようにする必要があります。
プロデューサーに関する考慮事項
+ Amazon SQS は 5 分間の重複排除ウィンドウを適用します。
+ プロデューサーが 5 分後に [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) リクエストを再試行すると、Amazon SQS はそのリクエストを新しいメッセージとして扱い、重複が生じる可能性があります。
コンシューマーの考慮事項
+ 可視性タイムアウトが期限切れになる前にコンシューマーがメッセージを処理できなかった場合、別のコンシューマーがメッセージを受信して処理し、処理が重複する可能性があります。
+ アプリケーションの処理時間に基づいて可視性タイムアウトを調整します。
+ [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ChangeMessageVisibility.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ChangeMessageVisibility.html) API を使用して、メッセージの処理中にタイムアウトを延長します。
+ メッセージの処理が繰り返し失敗する場合は、メッセージを無期限に再処理するのではなく、[デッドレターキュー (DLQ)](sqs-dead-letter-queues.md) にルーティングします。
+ プロデューサーは、キューの重複排除間隔を認識する必要があります。Amazon SQS には 5 分の重複排除間隔があります。重複排除間隔の期限後に `SendMessage` リクエストを再試行すると、キューに重複メッセージが作成される場合があります。たとえば、車内からモバイルデバイスで、順番が重要なメッセージを送信するとします。確認を受信する前に車が一定時間モバイル接続を失った場合、モバイル接続が回復した後もう一度リクエストを再試行すると、重複が発生します。
+ コンシューマーには、可視性タイムアウトが切れる前にメッセージを処理できなくなるリスクを最小化する可視性タイムアウトが必要です。`ChangeMessageVisibility` アクションをコールして、メッセージが処理されている間に可視性タイムアウトを延長できます。ただし、可視性タイムアウトの期限が切れると、別のコンシューマーがすぐにメッセージの処理を開始するため、1 つのメッセージが複数回処理されてしまいます。このシナリオを回避するには、[デッドレターキュー](sqs-dead-letter-queues.md)を設定します。
# Amazon SQS での可視性タイムアウトの設定
信頼性の高いメッセージ処理を行うには、可視性タイムアウトを AWS SDK 読み取りタイムアウトよりも長く設定します。これは、ショートポーリングまたはロングポーリングの両方で [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html) API を使用する場合に適用されます。可視性タイムアウトを長くすると、元のリクエストが完了する前に他のコンシューマーがメッセージを使用できなくなるため、処理が重複するリスクが軽減されます。
# Amazon SQS FIFO キューでのメッセージグループ ID の使用
FIFO (First-In-First-Out) キューでは、[https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) はメッセージを個別のグループに整理する属性です。同じメッセージグループ内のメッセージは常に 1 件ずつ厳密な順序で処理されるため、同じグループの 2 つのメッセージが同時に処理されることはありません。標準キューでは、`MessageGroupId` を使用すると[フェアキュー](sqs-fair-queues.md)が有効になります。厳密な順序付けが必要な場合は、FIFO キューを使用します。
**Topics**
+ [Amazon SQS での複数の順序付けされたメッセージグループのインターリーブ](interleaving-multiple-ordered-message-groups.md)
+ [Amazon SQS でのマルチプロデューサー/マルチコンシューマーシステムにおける重複処理の防止](avoding-processing-duplicates-in-multiple-producer-consumer-system.md)
+ [Amazon SQS で同じメッセージグループ ID に対する大量のメッセージバックログを避ける](avoid-backlog-with-the-same-message-group-id.md)
+ [Amazon SQS で仮想キューでの同じメッセージグループ ID の再利用を避ける](avoiding-reusing-message-group-id-with-virtual-queues.md)
# Amazon SQS での複数の順序付けされたメッセージグループのインターリーブ
単一の FIFO キュー内で複数の順序付けされたメッセージグループをインターリーブするには、[https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) を各グループ (異なるユーザーのセッションデータなど) に割り当てます。これにより、複数のコンシューマーが同時にキューから読み取ることが可能になり、同一グループ内のメッセージが順序通りに処理されるようになります。
特定の `MessageGroupId` を持つメッセージが処理中で不可視になっている場合、そのメッセージが削除されるか可視性タイムアウトが期限切れになるまで、他のコンシューマーは同じグループのメッセージを処理できません。
# Amazon SQS でのマルチプロデューサー/マルチコンシューマーシステムにおける重複処理の防止
メッセージの順序付けが優先されない高スループットかつ低レイテンシーのシステムでは、プロデューサーは各メッセージに一意の [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) を割り当てることができます。これにより、Amazon SQS FIFO キューは、マルチプロデューサー/マルチコンシューマーの構成であっても重複を排除できます。このアプローチでは重複メッセージの防止は可能ですが、各メッセージが独立したグループとして扱われるため、メッセージの順序は保証されません。
複数のプロデューサーとコンシューマーを持つシステムでは、常に配信が重複するリスクがあります。コンシューマーが可視性タイムアウトの期限内にメッセージを処理できなかった場合、Amazon SQS はそのメッセージを再度利用可能にし、別のコンシューマーが取得することが可能になります。この問題を軽減するため、処理時間に基づいて適切なメッセージの確認と可視性タイムアウトの設定を確認してください。
# Amazon SQS で同じメッセージグループ ID に対する大量のメッセージバックログを避ける
FIFO キューは、最大 120,000 件の処理中メッセージ (コンシューマーが受信したがまだ削除していないメッセージ) に対応します。この制限に達した場合、Amazon SQS はエラーを返しませんが、処理に影響が出る可能性があります。これらの制限を超えた増加を希望する場合は、[AWS サポート](https://docs.aws.amazon.com/awssupport/latest/user/create-service-quota-increase.html)にリクエストしてください。
FIFO キューは、最初の 120,000 件のメッセージをスキャンして、使用可能なメッセージグループを判別します。大規模なバックログが 1 つのメッセージグループに蓄積された場合、後で送信される他のグループのメッセージは、バックログが処理されるまでブロックされたままになります。
**注記**
コンシューマーがメッセージの処理に繰り返し失敗すると、メッセージバックログが発生する可能性があります。これは、メッセージのコンテンツの問題またはコンシューマー側の障害が原因である可能性があります。メッセージ処理の遅延を防ぐには、試行が複数回失敗した場合、未処理のメッセージを移動するように[デッドレターキュー](sqs-dead-letter-queues.md)を設定します。これにより、同じメッセージグループ内の他のメッセージを処理できるようになり、システムのボトルネックを防ぎます。
# Amazon SQS で仮想キューでの同じメッセージグループ ID の再利用を避ける
共有ホストキューで仮想キューを使用する場合は、異なる仮想キュー間で同じ [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) を再利用しないでください。複数の仮想キューが同じホストキューを共有し、同じ `MessageGroupId` を持つメッセージが含まれている場合、それらのメッセージは相互にブロックされ、効率的な処理が妨げられる可能性があります。メッセージ処理を円滑に行うには、異なる仮想キュー内のメッセージに一意の `MessageGroupId` 値を割り当てます。
# Amazon SQS受信リクエスト試行 ID の使用
受信リクエスト試行 ID は、Amazon SQS での [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html) 呼び出しの重複排除に使用される一意のトークンです。アプリケーションと Amazon SQS 間のネットワーク停止や接続の問題が発生した場合のベストプラクティスは、次のとおりです。
+ `ReceiveMessage` 呼び出しを行うときに、受信リクエストの試行 ID を指定する。
+ オペレーションが失敗した場合、同じ受信リクエスト試行 ID を使用して再試行する。
# Amazon SQS のメッセージ処理とタイミング
このトピックでは、Amazon SQS でのメッセージ処理の速度と効率を最適化するための包括的なガイダンスを提供します。これには、タイムリーなメッセージ処理、最適なポーリングモードの選択、パフォーマンスを向上させるためのロングポーリングの設定などが含まれます。
****トピック****
+ [Amazon SQS でのタイムリーな方法でのメッセージ処理](best-practices-processing-messages-timely-manner.md)
+ [Amazon SQS でのロングポーリングの設定](best-practices-setting-up-long-polling.md)
+ [Amazon SQS での適切なポーリングモードの使用](best-practices-using-appropriate-polling-mode.md)
# Amazon SQS でのタイムリーな方法でのメッセージ処理
可視性タイムアウトの設定は、アプリケーションがメッセージを処理し、削除するのにかかる時間によって異なります。たとえば、アプリケーションでメッセージを処理するには 10 秒必要だが、可視性タイムアウトを 15 分に設定した場合、前のメッセージ処理に失敗すると、再度処理されるまでに長時間待つ必要があります。または、アプリケーションでメッセージを処理するには 10 秒必要だが、可視性タイムアウトを 2 秒に設定した場合は、元のコンシューマーがメッセージを処理している間に別のコンシューマーより重複メッセージが送信されます。
メッセージの処理に十分な時間を確保するために、次のいずれかの方法を使用します:
+ メッセージの処理にかかる時間がわかっている (または合理的に見積もることができる) 場合は、メッセージの*可視性タイムアウト*を、メッセージの処理と削除にかかる最大時間に拡張します。詳細については、\$1[可視性タイムアウトの構成](sqs-visibility-timeout.md#configuring-visibility-timeout)｝を参照してください。
+ メッセージの処理にかかる時間がわからない場合は、コンシューマプロセスについて*ハートビート*を作成:初期可視性タイムアウト (2 分など) を特定し、コンシューマがメッセージで作業している限り、可視性タイムアウトを 1 分ごとに 2 分延長します。
**重要**
最大可視性タイムアウトは、`ReceiveMessage`Amazon SQS がメッセージを受信してから 12 時間です。可視性タイムアウトを延長しても、12 時間の上限はリセットされません。
さらに、`ReceiveMessage` リクエストによってタイマーが開始されるため、個々のメッセージのタイムアウトは上限の 12 時間 (43,200 秒) に設定できない場合があります。例えば、メッセージを受信して、すぐに `VisibilityTimeout` を 43,200 秒に等しく設定して `ChangeMessageVisibility` コールを送信すると、失敗する場合があります。ただし、値として 43,195 秒を使用すると、`ReceiveMessage` 経由でメッセージをリクエストしてから可視性タイムアウトを更新するまでに大幅な遅延がない限り、成功します。コンシューマーが 12 時間以上必要とする場合は、Step Functionsの使用を検討してください。
# Amazon SQS でのロングポーリングの設定
待ち時間がいつになるか`[ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)`API アクションが0より大きい場合*ロングポーリング*が有効です。ロングポーリングの最大待機時間は 20 秒です。ロングポーリングは、空のレスポンス (`ReceiveMessage`リクエストに使用可能なメッセージがない場合) と偽の空のレスポンス (メッセージが使用可能でレスポンスに含まれていない場合) の数を減らすことで、Amazon SQS を使用するコストを削減します。詳細については、「[Amazon SQSショートポーリングとロングポーリング](sqs-short-and-long-polling.md)」を参照してください。
最適なメッセージ処理を行うには、次の方法を使用します。
+ ほとんどの場合、`ReceiveMessage` 待機時間を 20 秒に設定します。アプリケーションの設定時間として 20 秒が長すぎる場合は、`ReceiveMessage` 待機時間の値を小さくします (最小 1 秒)。 AWS SDK を使用して Amazon SQS にアクセスしない場合、または AWS SDK に短い待機時間を設定する場合は、長いリクエストを許可するか、長いポーリングに短い待機時間を使用するように Amazon SQS クライアントを変更する必要があります。
+ 複数のキューにロングポーリングを実行する場合は、すべてのキューに単一スレッドを使用せずに、キューごとに 1 つのスレッドを使用します。キューごとに 1 つのスレッドを使用した場合は、メッセージが使用可能になると、アプリケーションはキューごとにメッセージを処理できるのに対し、複数のキューを単一スレッドでポーリングすると、使用可能なメッセージがないキューを待機 (最大 20 秒) している間、アプリケーションは他のキューで使用可能なメッセージを処理できません。
**重要**
HTTP エラーを回避するには、`ReceiveMessage` リクエストの HTTP レスポンスタイムアウトが `WaitTimeSeconds` パラメータよりも長いことを確認してください。詳細については、「[ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)」を参照してください。
# Amazon SQS での適切なポーリングモードの使用
+ ロングポーリングにより、Amazon SQSキューからメッセージが利用可能になるとすぐに処理することができます。
+ Amazon SQS の使用でコストを削減し、空のキューでの空の受信数 (メッセージを返さない `ReceiveMessage` アクションへのレスポンス) を減らすには、ロングポーリングを有効にします。詳細については、「[Amazon SQS ロングポーリング](sqs-short-and-long-polling.md)」を参照してください。
+ 複数の受信により、複数のスレッドをポーリングする際の効率を高めるには、スレッド数を減らします。
+ ロングポーリングは、ほとんどの場合にショートポーリングよりも推奨されます。
+ ショートポーリングは、ポーリングされたAmazon SQSキューが空の場合でも、すぐにレスポンスを返します。
+ `ReceiveMessage` リクエストへの即時のレスポンスが期待されるアプリケーションの要件を満たすには、ショートポーリングを使用します。
+ ショートポーリングはロングポーリングと同じように請求されます。