Amazon SQSメッセージの操作 - Amazon Simple Queue Service

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

Amazon SQSメッセージの操作

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

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

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

メッセージの処理に十分な時間を確保するために、次のいずれかの方法を使用します:

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

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

    重要

    最大可視性タイムアウトは、ReceiveMessageAmazon SQS がメッセージを受信してから 12 時間です。可視性タイムアウトを延長しても、最大12時間はリセットされません。

    さらに、ReceiveMessageリクエストによってタイマーが開始されてから、個々のメッセージのタイムアウトを12時間(たとえば43,200秒)に設定できない場合があります。たとえば、メッセージを受信し、ChangeMessageVisibility 43,200秒のコールを送信してすぐに最大12時間に設定した場合、失敗する可能性があります。VisibilityTimeoutただし、経由でメッセージをリクエストしてから可視性タイムアウトを更新するまでの間に大きな遅延がない限り、43,195 ReceiveMessage 秒の値を使用しても問題ありません。コンシューマーが 12 時間以上必要とする場合は、Step Functionsの使用を検討してください。

リクエストエラーの処理

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

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

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

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

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

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

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

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

重要

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

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

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

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

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

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

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

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

FIFO キューの場合、メッセージがデッドレターキューに移動されると、エンキューのタイムスタンプがリセットされます。ApproximateAgeOfOldestMessageこのメトリックは、メッセージがデッドレターキューにいつ移動したかを示します。上記の同じ例で、メッセージは 4 日後にデッドレターキューから削除され、ApproximateAgeOfOldestMessageは 4 日後に削除されます。

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

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

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

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

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

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

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