Amazon SQSを深く理解する 標準とFIFO・可視性タイムアウト・デッドレターキュー・ロングポーリング

SAA-C03では、SQSを「使うかどうか」だけでなく、「標準かFIFOか」「重複や失敗をどう扱うか」まで問われます。この記事では、SQSの4つの重要な設定を、要件文のどの言葉に対応するかとあわせて整理します。

覚え方は「順序・重複・失敗・待ち方」の4つ

SQSの設計は、順序＝厳密な順序が必要か、重複＝同じメッセージの二重処理を許容できるか、失敗＝処理できないメッセージをどこへ逃がすか、待ち方＝ポーリングのコストをどう抑えるか、の4つの問いで決まります。

標準キューとFIFOキュー

標準キューはほぼ無制限のスループットで、順序はベストエフォート、配信は「少なくとも1回」なので稀に重複します。FIFOキューはメッセージグループID単位で厳密な順序を保証し、5分間の重複排除IDで「正確に1回」の処理を実現しますが、スループットはキューあたり毎秒300件(バッチで3000件、高スループットモードでさらに拡張)です。「注文の処理順序を守る」「二重課金を防ぐ」ならFIFO、「大量のログをとにかく非同期で処理する」なら標準です。

可視性タイムアウトと冪等性

コンシューマーがメッセージを受信すると、可視性タイムアウト(既定30秒、最大12時間)の間は他のコンシューマーから見えなくなります。処理が終わる前にタイムアウトすると別のコンシューマーが同じメッセージを再受信するため、「処理に平均2分かかるのに同じ注文が2回処理される」という問題は可視性タイムアウトの延長で解決します。処理時間が読めない場合はChangeMessageVisibilityで延長し、標準キューでは処理側を冪等に設計するのが原則です。

デッドレターキューで失敗を分離する

デッドレターキュー(DLQ)は、最大受信回数(maxReceiveCount)を超えて処理できなかったメッセージを退避する別のキューです。「不正なメッセージが繰り返し処理を妨げる(ポイズンメッセージ)」「失敗分だけ後で調査・再処理したい」という要件で使い、CloudWatchアラームでDLQのメッセージ数を監視するのが定番です。DLQのリドライブ機能で元のキューへ戻すこともできます。

ロングポーリングでコストを下げる

ショートポーリングは即座に応答を返すため、キューが空でも大量の空受信が発生してAPIコストが増えます。ReceiveMessageのWaitTimeSecondsを最大20秒に設定するロングポーリングにすると、メッセージが到着するまで待ってから返すため、空受信が減ってコストとレイテンシの両方が改善します。「SQSのコストが高い」「空のレスポンスが多い」という要件のサインです。また、Lambdaをコンシューマーにする場合はイベントソースマッピングがポーリングとバッチ処理を代行してくれます。

チェックリスト

• ARRAY(0xa002a34f0)

まとめ

SQSは「順序・重複・失敗・待ち方」の4つの問いに答える設定を選ぶだけで、ほとんどの要件に対応できます。 理解度の確認にはクイズが便利です。試験範囲や申し込みの最新情報はAWS認定 公式ページもあわせて確認してください。