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

# Amazon SQS のメッセージ重複排除とグループ化
<a name="best-practices-message-deduplication"></a>

このトピックでは、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 での一貫性のないメッセージ処理の回避
<a name="avoiding-inconsistent-message-processing"></a>

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 の使用
<a name="using-messagededuplicationid-property"></a>

[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 を提供する場合
<a name="providing-message-deduplication-id"></a>

プロデューサーは、次のシナリオでメッセージ重複排除 ID を指定する必要があります。
+ 同一のメッセージ本文を送信する際に、それらを個別のものとして扱う必要がある場合。
+ 同じコンテンツを含み、メッセージ属性が異なるメッセージを送信し、各メッセージが個別に処理されるようにする場合。
+ コンテンツが異なるメッセージを送信し (メッセージ本文の再試行カウンターなど)、Amazon SQS にそれらを重複として認識させる必要がある場合。

# Amazon SQS でのシングルプロデューサー/コンシューマーシステムにおける重複排除の有効化
<a name="single-producer-single-consumer"></a>

プロデューサーとコンシューマーがそれぞれ単一であり、本文にアプリケーション固有のメッセージ 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 での停止復旧シナリオ
<a name="designing-for-outage-recovery-scenarios"></a>

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 での可視性タイムアウトの設定
<a name="working-with-visibility-timeouts"></a>

信頼性の高いメッセージ処理を行うには、可視性タイムアウトを 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 の使用
<a name="using-messagegroupid-property"></a>

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 での複数の順序付けされたメッセージグループのインターリーブ
<a name="interleaving-multiple-ordered-message-groups"></a>

単一の 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 でのマルチプロデューサー/マルチコンシューマーシステムにおける重複処理の防止
<a name="avoding-processing-duplicates-in-multiple-producer-consumer-system"></a>

メッセージの順序付けが優先されない高スループットかつ低レイテンシーのシステムでは、プロデューサーは各メッセージに一意の [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 に対する大量のメッセージバックログを避ける
<a name="avoid-backlog-with-the-same-message-group-id"></a>

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 の再利用を避ける
<a name="avoiding-reusing-message-group-id-with-virtual-queues"></a>

共有ホストキューで仮想キューを使用する場合は、異なる仮想キュー間で同じ [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 の使用
<a name="using-receiverequestattemptid-request-parameter"></a>

受信リクエスト試行 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 を使用して再試行する。