Amazon SQS可視性タイムアウト

Amazon SQSキューからメッセージを受信すると、キューに残りますが、他のコンシューマーには一時的に表示されません。この可視性は可視性タイムアウトによって制御されます。これにより、作業中に他のコンシューマーが同じメッセージを処理できなくなります。Amazon SQS には、処理後にメッセージを削除するための 2 つのオプションがあります。

• 手動削除 – DeleteMessageアクションを使用してメッセージを明示的に削除します。

• 自動削除 – 特定の でサポートされ AWS SDKs、処理が成功するとメッセージが自動的に削除され、ワークフローが簡素化されます。

可視性タイムアウトのユースケース

長時間実行されるタスクの管理 – 可視性タイムアウトを使用して、処理時間が長くなるタスクを処理します。処理時間が長くなるメッセージに適切な可視性タイムアウトを設定します。これにより、他のコンシューマーが処理中に同じメッセージを受信しないようにし、重複する作業を防ぎ、システム効率を維持します。

再試行メカニズムの実装 – 初期タイムアウト内に完了しなかったタスクの可視性タイムアウトをプログラムで延長します。タスクが最初の可視性タイムアウト内に完了しなかった場合は、タイムアウトをプログラムで延長できます。これにより、システムは他のコンシューマーに認識されることなくメッセージの処理を再試行できるため、耐障害性と信頼性が向上します。デッドレターキュー (DLQs) と組み合わせて、永続的な障害を管理します。

分散システムの調整 — SQS可視性タイムアウトを使用して、分散システム全体のタスクを調整します。さまざまなコンポーネントの予想される処理時間に合わせて可視性タイムアウトを設定します。これにより、一貫性を維持し、複雑な分散アーキテクチャでの競合状態を防ぐことができます。

リソース使用率の最適化 — SQS可視性タイムアウトを調整して、アプリケーションのリソース使用率を最適化します。適切なタイムアウトを設定することで、リソースを不必要に結び付けることなく、メッセージが効率的に処理されるようにできます。これにより、システム全体のパフォーマンスとコスト効率が向上します。

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

可視性タイムアウトは、メッセージが配信されるとすぐに開始されます。この期間中は、メッセージを処理および削除する必要があります。タイムアウトが期限切れになる前に削除しないと、メッセージはキューに再び表示され、別のコンシューマーが取得できます。キューのデフォルトの可視性タイムアウトは 30 秒ですが、アプリケーションがメッセージを処理および削除するために必要な時間に合わせて調整できます。キューの全体的な設定を変更せずに、個々のメッセージに特定の可視性タイムアウトを設定することもできます。ChangeMessageVisibility アクションを使用して、必要に応じてタイムアウトをプログラムで延長または短縮します。

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

Amazon ではSQS、処理中のメッセージは、コンシューマーによって受信されたがまだ削除されていないメッセージです。標準キューの場合、キュートラフィックとメッセージバックログに応じて、約 120,000 件の処理中のメッセージに制限があります。この制限に達すると、Amazon はOverLimitエラーをSQS返し、一部の処理中のメッセージが削除されるまで追加のメッセージを受信できないことを示します。FIFO キューの場合、制限はアクティブなメッセージグループによって異なります。

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

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

処理中のメッセージを効果的に管理するには：

1. プロンプト削除 — 処理後にメッセージ (手動または自動) を削除して、処理中の数を減らします。

2. でモニタリング CloudWatchする – 制限に達しないように、処理中の数が多いアラームを設定します。

3. 負荷を分散する – 大量のメッセージを処理している場合は、追加のキューまたはコンシューマーを使用して負荷を分散し、ボトルネックを回避します。

4. クォータの引き上げをリクエストする – 制限の引き上げが必要な場合は、 AWS サポートにリクエストを送信します。

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

標準キューと FIFO (先入れ先出し) キューの両方で、可視性タイムアウトは、複数のコンシューマーが同じメッセージを同時に処理するのを防ぐのに役立ちます。ただし、Amazon の配信モデルにより at-least-onceSQS、可視性タイムアウト期間中にメッセージが複数回配信されないという絶対的な保証はありません。

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

• FIFO キュー – FIFOキューの場合、同じメッセージグループ ID を持つメッセージは厳密な順序で処理されます。メッセージグループ ID を持つメッセージが処理中の場合、そのグループ内の後続のメッセージは、処理中のメッセージが削除されるか、可視性タイムアウトが期限切れになるまで使用できなくなります。ただし、これはグループを無期限に「ロック」しません。各メッセージは順番に処理され、各メッセージが削除されるか再び表示される場合にのみ、そのグループ内の次のメッセージがコンシューマーに利用可能になります。このアプローチにより、グループがメッセージを配信するのを不必要にロックすることなく、グループ内の順序付けられた処理が保証されます。

失敗の処理

アプリケーションエラー、クラッシュ、または接続の問題により、可視性タイムアウトが期限切れになる前にメッセージを処理および削除しない場合、メッセージはキューに再び表示されます。その後、同じコンシューマーまたは別のコンシューマーが別の処理を試みるために取得できます。これにより、最初の処理が失敗した場合でもメッセージが失われることがなくなります。ただし、可視性タイムアウトを高く設定しすぎると、未処理のメッセージの再表示が遅れ、再試行が遅くなる可能性があります。タイムリーなメッセージ処理には、予想される処理時間に基づいて適切な可視性タイムアウトを設定することが重要です。

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

ChangeMessageVisibility アクションを使用して、可視性タイムアウトを変更または終了できます。

• タイムアウトの変更 – を使用して可視性タイムアウトを動的に調整しますChangeMessageVisibility。これにより、処理ニーズに合わせてタイムアウト期間を延長または短縮できます。

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

ベストプラクティス

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

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

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

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