翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Amazon SQS メッセージの使用
次のガイドラインは、Amazon SQS を使用して効率的にメッセージを処理するのに役立ちます。
トピック
タイムリーな方法でのメッセージの処理
可視性タイムアウトの設定は、アプリケーションがメッセージを処理し、削除するのにかかる時間によって異なります。たとえば、アプリケーションでメッセージを処理するには 10 秒必要だが、可視性タイムアウトを 15 分に設定した場合、前のメッセージ処理に失敗すると、再度処理されるまでに長時間待つ必要があります。または、アプリケーションでメッセージを処理するには 10 秒必要だが、可視性タイムアウトを 2 秒に設定した場合は、元のコンシューマーがメッセージを処理している間に別のコンシューマーより重複メッセージが送信されます。
メッセージの処理に十分な時間があることを確認するには、次のいずれかの方法を使用します。
-
メッセージの処理にかかる時間がわかっている (または合理的に見積もることができる) 場合は、メッセージの可視性タイムアウトを、メッセージの処理と削除にかかる最大時間に拡張します。詳細については、「」を参照してください。可視性タイムアウトの設定。
-
メッセージの処理に要する時間がわからない場合は、ハートビートコンシューマプロセスの場合:初期可視性タイムアウト(2 分など)を指定し、コンシューマがメッセージで作業している限り、可視性タイムアウトを 1 分ごとに 2 分延長します。
重要 最大可視性タイムアウトは、Amazon SQS が
ReceiveMessage
リクエスト. 可視性タイムアウトを延長しても、12 時間という最大時間はリセットされません。さらに、個々のメッセージのタイムアウトを 12 時間(例:43,200 秒)に設定できない場合があります。
ReceiveMessage
リクエストはタイマーを開始します。たとえば、メッセージを受信し、すぐに最大12時間を設定すると、ChangeMessageVisibility
を使用したの呼び出しVisibilityTimeout
43,200秒に等しい場合は、おそらく失敗します。ただし、43,195 秒の値を使用すると、によるメッセージの要求の間に大きな遅延がない限り機能します。ReceiveMessage
可視性タイムアウトの更新を行います。コンシューマーが 12 時間以上必要とする場合は、Step Functions の使用を検討してください。
リクエストエラーの処理
リクエストのエラーを処理するには、次の方法のいずれかを使用します。
-
を使用した場合AWSSDK、既に自動があります再試行とバックオフあなたの処分で論理。詳細については、アマゾン ウェブ サービス全般のリファレンスの AWS でのエラーの再試行とエクスポネンシャルバックオフを参照してください。
-
を使用しない場合AWS再試行とバックオフの SDK の機能では、再試行前に、一時停止 (たとえば、200 ms) してから、ReceiveMessageAmazon SQS からメッセージ、タイムアウト、またはエラーメッセージを受信しなかった後のアクション。同じ結果が得られる
ReceiveMessage
をそれ以降に使用するには、それよりも長い一時停止 (たとえば、400 ms) を許可します。
ロングポーリングのセットアップ
の待機時間がReceiveMessage
API アクションが 0 より大きい場合、ロングポーリングが有効です。長いポーリングの最大待機時間は 20 秒です。ロングポーリングは、空のレスポンスの数を減らすことによって Amazon SQS の使用コストを削減するのに役立ちます。ReceiveMessage
request)と偽の空の応答(メッセージは利用可能だが応答に含まれない場合)。詳細については、「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 がメッセージを配信済みとマークしても、コンシューマーはメッセージを受信しない可能性があります。ReceiveMessage
API メソッド呼び出し。この場合、Amazon SQS は、コンシューマーがメッセージを受信していないにもかかわらず、少なくとも 1 回はメッセージを配信済みとして記録します。これらの状況ではメッセージの配信は再試行されないため、デッドレターキューの最大受信数を 1 に設定することはお勧めしません。
リクエストと応答システムの実装
リクエストと応答またはリモートプロシージャ呼び出し (RPC) システムを実装するときは、次のベストプラクティスに留意してください。
-
メッセージごとに返信キューを作成しない。代わりに、起動時にプロデューサーごとに返信キューを作成し、相関 ID メッセージ属性を使用して返信をリクエストにマッピングします。
-
プロデューサーで返信キューを共有しない。共有した場合、プロデューサーは他のプロデューサー向けの応答メッセージを受信する可能性があります。
Temporary Queue Client を使用したリクエスト/応答パターンの実装の詳細については、「リクエスト–レスポンスメッセージングパターン(仮想キュー)」を参照してください。