Amazon SQS可視性タイムアウト

コンシューマーが Amazon SQSキューからメッセージを受信すると、メッセージはキューに残りますが、他のコンシューマーには一時的に見えなくなります。この一時的な可視性は、可視性タイムアウトによって制御されます。これは、他のコンシューマーが作業中に同じメッセージを処理できないようにするメカニズムです。Amazon SQS はメッセージを自動的に削除しません。代わりに、コンシューマーは正常に処理された後、 DeleteMessageアクションを使用してメッセージを明示的に削除する必要があります。

可視性タイムアウトの設定

Amazon の可視性タイムアウトは、メッセージがコンシューマーに返されるとすぐにSQS開始されます。この間、コンシューマーはメッセージを処理および削除することが期待されます。ただし、可視性タイムアウトが期限切れになる前にコンシューマーがメッセージを削除できなかった場合、メッセージはキューに再び表示され、別のコンシューマーが取得できます。

すべての Amazon SQSキューのデフォルトの可視性タイムアウトは 30 秒ですが、アプリケーションのニーズに応じてこの設定を調整できます。通常、可視性タイムアウトは、アプリケーションがメッセージの処理と削除に必要な最大時間に合わせて設定するのが最善です。また、キューの全体的なタイムアウト設定を変更せずに、個々のメッセージの特定の可視性タイムアウトを設定することもできます。

インフライトメッセージとクォータ

Amazon ではSQS、処理中のメッセージは、コンシューマーがキューから受信したが、まだ削除されていないメッセージです。標準キューの場合、処理中のメッセージの数には制限があります。これは、キュートラフィックとメッセージバックログに応じて、最大約 120,000 件になる可能性があります。

• ショートポーリング — ショートポーリングの使用中にこの制限に達すると、Amazon SQS はOverLimitエラーを返し、一部の処理中のメッセージが削除されるまで追加のメッセージを受信できないことを示します。

• ロングポーリング – ロングポーリングを使用している場合、Amazon SQSは処理中のメッセージの制限に達したときにエラーを返しません。代わりに、処理中のメッセージの数が制限を下回るまで、新しいメッセージは返されません。

未処理のメッセージを効果的に管理し、このクォータに達しないようにするには：

1. プロンプト削除 — 処理が成功するとすぐにメッセージが削除され、処理中のメッセージが減ります。

2. Monitor with CloudWatch – Amazon CloudWatch を使用して、処理中のメッセージの数をモニタリングし、制限に近づいたときに警告するアラームを設定します。

3. 負荷を分散する – 大量のメッセージを処理している場合は、負荷を分散してボトルネックを防ぐために、キューの数を増やすことを検討してください。

4. クォータの引き上げをリクエストする – 必要に応じて、サポートリクエストを に送信します。 AWS は、アプリケーションの処理中のメッセージクォータを引き上げます。

標準およびFIFOキューの可視性タイムアウトについて

Amazon の可視性タイムアウトは、標準とFIFOキューの両方でメッセージ処理SQSを管理し、重複処理を防ぎ、メッセージの順序を維持します。

• 標準キュー – 標準キューでは、可視性タイムアウトにより、複数のコンシューマーが同じメッセージを同時に処理するのを防ぐことができます。ただし、Amazon の配信モデルは少なくとも 1 回であるためSQS、可視性タイムアウト期間中にメッセージが複数回配信されないという絶対的な保証はありません。

• FIFO キュー – FIFO (先入れ先出し) キューでは、可視性タイムアウトにより、同じメッセージグループ ID のメッセージが正しい順序で処理されます。可視性タイムアウトの期限が切れる前にコンシューマーがメッセージを削除しない場合、メッセージが再び表示されるか、削除されるまで、同じグループ ID を持つ新しいメッセージは配信されません。FIFO キューの場合、メッセージの順序と処理の整合性を維持するために、可視性タイムアウトを慎重に管理することが特に重要です。

コンシューマーがメッセージの処理に失敗した場合の対処方法

アプリケーションエラー、クラッシュ、接続の問題などの問題が原因でコンシューマーがメッセージを処理できず、可視性タイムアウトが期限切れになる前にメッセージを削除しない場合、メッセージは自動的にキューに再び表示されます。表示されると、同じコンシューマーまたは別のコンシューマーがメッセージを取得して、別の処理を試みることができます。このプロセスにより、最初の処理が失敗した場合でもメッセージが失われることがなくなります。

ただし、可視性タイムアウトの設定が高すぎると、未処理のメッセージの再表示が遅延し、再試行が遅くなる可能性があることに注意してください。タイムリーなメッセージ処理には、予想される処理時間に基づいて適切な可視性タイムアウトを設定することが重要です。

可視性タイムアウトの変更と終了

必要に応じてメッセージ処理を管理する ChangeMessageVisibilityアクションSQSを使用して、Amazon の可視性タイムアウトを変更または終了します。

• タイムアウトの変更 – 初期可視性タイムアウトが不十分な場合は、 ChangeMessageVisibilityアクションを使用して調整できます。このアクションにより、処理のニーズに基づいてタイムアウトを短縮または延長できます。

• タイムアウトの終了 – 受信したメッセージを処理しない場合は、 ChangeMessageVisibility アクションを通じて を 0 VisibilityTimeout 秒に設定することで可視性タイムアウトを終了できます。これにより、他のコンシューマーがメッセージをすぐに処理できるようになります。

ベストプラクティス

タイムアウトの設定SQS、調整、延長、デッドレターキュー () を使用した未処理のメッセージの処理など、Amazon の可視性タイムアウトを管理するには、次のベストプラクティスを使用しますDLQs。

• タイムアウトの設定と調整。まず、可視性タイムアウトを設定して、アプリケーションがメッセージの処理と削除に通常必要な最大時間を設定します。正確な処理時間がわからない場合は、短いタイムアウト (2 分など) から始めて、必要に応じて延長します。ハートビートメカニズムを実装して可視性タイムアウトを定期的に延長し、処理が完了するまでメッセージが見えないようにすることができます。これにより、未処理のメッセージの再処理の遅延が最小限に抑えられ、早期の可視性が防止されます。

• タイムアウトを延長し、12-Hourの制限を処理します。処理時間が変化したり、最初に設定されたタイムアウトを超えたりする場合は、 ChangeMessageVisibilityアクションを使用して、メッセージの処理中に可視性タイムアウトを延長します。可視性タイムアウトの最大制限は、メッセージが最初に受信されてから 12 時間であることに注意してください。タイムアウトを延長しても、この 12 時間の制限はリセットされません。処理にこの制限よりも時間がかかる場合は、 の使用を検討してください。 AWS Step Functions またはタスクを小さなステップに分割します。

  実際には、メッセージの受信とタイムアウトの更新の間に遅延がある場合、可視性タイムアウトを 12 時間の制限全体にすぐに設定できないことがあります。これを回避するには、43,195 秒など、少し低い値を使用します。

• 未処理のメッセージの処理 複数の処理試行に失敗するメッセージを管理するには、デッドレターキュー () を設定しますDLQ。これにより、複数回の再試行後に処理できないメッセージが個別にキャプチャされ、さらなる分析や処理が行われ、メインキューに繰り返し循環することが防止されます。