Amazon SQS メッセージの操作

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

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

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

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

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

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

  重要

  最大可視性タイムアウトは、Amazon SQS がReceiveMessageリクエスト. 可視性タイムアウトを延長しても、12 時間という最大時間はリセットされません。コンシューマーが 12 時間以上必要とする場合は、Step Functions 使用を検討してください。

リクエストエラーの処理

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

• あなたが使用する場合AWSSDK では、既に自動再試行とバックオフあなたの処分でロジック。詳細については、「」を参照してください。でのエラーの再試行とエクスポネンシャルバックオフAWS()Amazon Web Services 全般的なリファレンス。

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

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

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

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

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

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

重要

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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