翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 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 を使用する場合に適用されます。可視性タイムアウトを長くすると、元のリクエストが完了する前に他のコンシューマーがメッセージを使用できなくなるため、処理が重複するリスクが軽減されます。