Amazon SQS メッセージの使用

次のガイドラインは、Amazon SQS を使用して効率的にメッセージを処理するのに役立ちます。

タイムリーな方法でのメッセージの処理

可視性タイムアウトの設定は、アプリケーションがメッセージを処理し、削除するのにかかる時間によって異なります。たとえば、アプリケーションでメッセージを処理するには 10 秒必要だが、可視性タイムアウトを 15 分に設定した場合、前のメッセージ処理に失敗すると、再度処理されるまでに長時間待つ必要があります。または、アプリケーションでメッセージを処理するには 10 秒必要だが、可視性タイムアウトを 2 秒に設定した場合は、元のコンシューマーがメッセージを処理している間に別のコンシューマーより重複メッセージが送信されます。

メッセージの処理に十分な時間があることを確認するには、次のいずれかの方法を使用します。

• メッセージの処理にかかる時間がわかっている (または合理的に見積もることができる) 場合は、メッセージの可視性タイムアウトを、メッセージの処理と削除にかかる最大時間に拡張します。詳細については、「」を参照してください。可視性タイムアウトの設定。

• メッセージの処理に要する時間がわからない場合は、ハートビートコンシューマプロセスの場合：初期可視性タイムアウト（2 分など）を指定し、コンシューマがメッセージで作業している限り、可視性タイムアウトを 1 分ごとに 2 分延長します。

  重要

  最大可視性タイムアウトは、Amazon SQS がReceiveMessageリクエスト. 可視性タイムアウトを延長しても、12 時間という最大時間はリセットされません。

  さらに、個々のメッセージのタイムアウトを 12 時間（例：43,200 秒）に設定できない場合があります。ReceiveMessageリクエストはタイマーを開始します。たとえば、メッセージを受信し、すぐに最大12時間を設定すると、ChangeMessageVisibilityを使用したの呼び出しVisibilityTimeout43,200秒に等しい場合は、おそらく失敗します。ただし、43,195 秒の値を使用すると、によるメッセージの要求の間に大きな遅延がない限り機能します。ReceiveMessage可視性タイムアウトの更新を行います。コンシューマーが 12 時間以上必要とする場合は、Step Functions の使用を検討してください。

リクエストエラーの処理

リクエストのエラーを処理するには、次の方法のいずれかを使用します。

• を使用した場合AWSSDK、既に自動があります再試行とバックオフあなたの処分で論理。詳細については、アマゾン ウェブ サービス全般のリファレンスの AWS でのエラーの再試行とエクスポネンシャルバックオフを参照してください。

• を使用しない場合AWS再試行とバックオフの SDK の機能では、再試行前に、一時停止 (たとえば、200 ms) してから、ReceiveMessageAmazon SQS からメッセージ、タイムアウト、またはエラーメッセージを受信しなかった後のアクション。同じ結果が得られる ReceiveMessage をそれ以降に使用するには、それよりも長い一時停止 (たとえば、400 ms) を許可します。

ロングポーリングのセットアップ

の待機時間がReceiveMessageAPI アクションが 0 より大きい場合、ロングポーリングが有効です。長いポーリングの最大待機時間は 20 秒です。ロングポーリングは、空のレスポンスの数を減らすことによって Amazon SQS の使用コストを削減するのに役立ちます。ReceiveMessagerequest）と偽の空の応答（メッセージは利用可能だが応答に含まれない場合）。詳細については、「Amazon SQS ショートポーリングとロングポーリング」を参照してください。

最適なメッセージ処理を行うには、次の方法を使用します。

• ほとんどの場合、ReceiveMessage 待機時間を 20 秒に設定します。アプリケーションの設定時間として 20 秒が長すぎる場合は、ReceiveMessage 待機時間の値を小さくします (最小 1 秒)。を使用しない場合AWSAmazon SQS にアクセスするための SDK、またはAWS待機時間を短くするには、長いリクエストを許可するように、またはロングポーリングに短い待機時間を使用するように Amazon SQS クライアントを変更する必要がある場合があります。

• 複数のキューにロングポーリングを実装する場合は、すべてのキューに単一スレッドを使用せずに、キューごとに 1 つのスレッドを使用します。キューごとに 1 つのスレッドを使用した場合は、メッセージが使用可能になると、アプリケーションはキューごとにメッセージを処理できるのに対し、複数のキューを単一スレッドでポーリングすると、使用可能なメッセージがないキューを待機 (最大 20 秒) している間、アプリケーションは他のキューで使用可能なメッセージを処理できません。

重要

HTTP エラーを回避するには、の HTTP レスポンスタイムアウトを確認してください。ReceiveMessageリクエストは、WaitTimeSecondsパラメータ。詳細については、「」を参照してください。ReceiveMessage。

問題のあるメッセージのキャプチャ

処理できないすべてのメッセージをキャプチャし、正確に収集するにはCloudWatchメトリック、設定デッドレターキュー。

• Redrive ポリシーは、ソースキューがメッセージの処理の失敗を指定回数繰り返した後に、デッドレターキューにメッセージをリダイレクトします。

• デッドレターキューを使用するとメッセージ数が減少し、ポイズンピルメッセージ (受信されたが処理できないメッセージ) が発生する可能性が低下します。

• キューにポイズンピルメッセージを含めると、ポイズンピルメッセージの誤った経過期間を指定することで、ApproximateAgeOfOldestMessage CloudWatch メトリクスが正しくなくなる可能性があります。デッドレターキューを設定すると、このメトリクスを使用する場合の誤ったアラームの回避に役立ちます。

デッドレターキューの保持の設定

メッセージの有効期限は常に元のエンキューのタイムスタンプに基づきます。メッセージがデッドレターキューに移動された場合、エンキューのタイムスタンプは変更されません。ApproximateAgeOfOldestMessage メトリクスは、メッセージがデッドレターキューに移動した時刻を示しており、メッセージが最初に送信された時刻ではありません。たとえば、メッセージがデッドレターキューに移動される前に元のキューで 1 日留まると仮定します。デッドレターキューの保持期間が 4 日である場合、メッセージは 3 日後にデッドレターキューから削除され、ApproximateAgeOfOldestMessage は 3 日です。したがって、デッドレターキューの保持期間を、元のキューの保持期間よりも長く設定することがベストプラクティスです。

メッセージ処理の不整合の回避

Amazon SQS は分散システムであるため、Amazon SQS がメッセージを配信済みとマークしても、コンシューマーはメッセージを受信しない可能性があります。ReceiveMessageAPI メソッド呼び出し。この場合、Amazon SQS は、コンシューマーがメッセージを受信していないにもかかわらず、少なくとも 1 回はメッセージを配信済みとして記録します。これらの状況ではメッセージの配信は再試行されないため、デッドレターキューの最大受信数を 1 に設定することはお勧めしません。

リクエストと応答システムの実装

リクエストと応答またはリモートプロシージャ呼び出し (RPC) システムを実装するときは、次のベストプラクティスに留意してください。

• メッセージごとに返信キューを作成しない。代わりに、起動時にプロデューサーごとに返信キューを作成し、相関 ID メッセージ属性を使用して返信をリクエストにマッピングします。

• プロデューサーで返信キューを共有しない。共有した場合、プロデューサーは他のプロデューサー向けの応答メッセージを受信する可能性があります。

Temporary Queue Client を使用したリクエスト/応答パターンの実装の詳細については、「リクエスト–レスポンスメッセージングパターン(仮想キュー)」を参照してください。