Amazon SQSを理解する

SQSを仕事の待合室として理解し、送信、受信、処理、削除を順に追います。順序、重複、失敗時の再試行を別々に考えると、キューが保証する部分とアプリで管理する部分を区別できます。

この単元で学ぶこと

SQSの受信から削除までの流れを説明する
StandardとFIFOの特性を区別する
可視性・再試行・冪等性・DLQを組み合わせる

本文解説

1. 生産者と消費者生産者は処理依頼を送る側、消費者は受信して処理する側です。例えば注文受付がPDF請求書作成の依頼をSQSへ送り、作成ワーカーが順次受信します。受付側と作成側を直接同期させず、急増した仕事を待たせられます。ただし、キューの保持期間や処理能力には条件があり、永久に無制限の仕事をためる設計ではありません。

2. 受信と削除は別ワーカーが受信してもメッセージは直ちに削除されません。まず処理し、成功後に削除することで完了を示します。SDK等が成功後の削除を扱う場合もあります。先に削除してから作成処理が失敗すると、キューには再試行する依頼が残らないため、処理成功と削除の順を設計することが大切です。

3. 可視性タイムアウト受信後に他の消費者から一時的に見えなくする時間です。可視性が60秒なら、通常その時間内に処理と削除を終える設計にします。処理に90秒かかるのに延長しなければ、削除前に再び受信可能になる場合があります。時間を長くしすぎると、ワーカーが停止した際に次の試行まで待つ時間が増えます。

4. Standardの性質 Standardキューは少なくとも1回の配信であり、同じ依頼が再度届く場合があります。順序はベストエフォートなので、送信した順のまま全件処理される保証はありません。独立した画像処理等で、重複に備え、順序に依存しない設計と相性があります。可視性を設定しても重複可能性そのものをなくす保証とは考えません。

5. FIFOの適用範囲 FIFOキューでは同じメッセージグループ内の順序を扱い、送信の重複排除も提供します。例えば注文番号ごとに同じグループIDを使うと、その注文内の処理順を整理できます。異なるグループ間まで全体で一列の順序にするものではありません。また、外部への課金とキュー削除を一つの取引にする機能ではないため、業務の二重実行への対策は別に考えます。

6. 冪等性の具体例注文123の請求書作成依頼を二度受けても、二通分の請求を増やさないようにします。処理済みの注文IDを確認し、結果を再利用する等の方法が冪等性の考え方です。外部処理の成功後にワーカーが停止し、削除できなかった場合も再受信し得ます。単に受信回数を数えるだけでなく、業務の一意な識別子と結果を管理します。

7. 再試行とデッドレターキュー入力形式が不正な依頼は、同じコードで繰り返しても成功しないことがあります。DLQは設定した受信回数等の条件に従い、そのようなメッセージを隔離して調査する用途です。DLQへ移っただけでデータが修正されたり、業務が完了したりするわけではありません。原因を直し、再投入時の重複や順序への影響を確認します。

8. 負荷と運用毎分100件到着し毎分80件しか完了できない状態が10分続くと、初期0件・重複や失敗なしの単純計算で200件の未完了が増えます。キューは速度差を吸収しますが処理能力そのものを増やしません。滞留件数や古い依頼の待ち時間を見て、ワーカー数、処理内容、下流の制約を確認します。ロングポーリングは空の受信を減らす手段です。

図解

成功と失敗で分かれるメッセージの流れ — 可視性が業務の二重実行を完全に防ぐものではないため、冪等性も設計します。

重要ポイント

受信、業務成功、削除を区別する。
可視性は一時的な非表示で、重複排除とは別。
FIFOの順序はグループ内、業務の二重実行対策は別。

間違えやすい点

削除を先に行ってから失敗してもキューが復旧すると考える。
DLQを自動修復や成功済みメッセージ置場と考える。

用語解説

可視性タイムアウト: 受信したメッセージを一時的に他の消費者から見えなくする時間。
冪等性: 同じ処理依頼を繰り返しても意図する結果が重複して増えない性質。
メッセージグループ: FIFOで順序を管理する単位。
DLQ: 処理に失敗し続けるメッセージ等を隔離し調査するキュー。

参考資料

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。