SQSのStandardとFIFOのシナリオ判断

在庫更新と注文イベントを題材に、順序の単位、グループの並行性、送信の再試行、業務副作用を具体的に判断します。

この単元で学ぶこと

1. 商品ごとの更新順同じ商品の「在庫を10へ設定」「在庫から2を引く」の順序が逆になると結果が変わります。FIFOで商品IDをグループへ対応させると、その商品の系列を保てます。ただし生産者自体が誤った順序で送れば期待した業務順序にはなりません。送信側の順序とキュー内の順序を合わせて確認します。

2. 全商品を一列にしない商品AとBの更新が独立なら、Aの遅い処理がBを止める必要はありません。商品ごとにグループを分けます。反対に同じ商品の更新ごとにランダムなグループを割り振れば順序制約を壊します。並列化する単位は、業務上独立しているかで決めます。

3. 通信結果が不明な送信送信要求の応答が失われると、生産者はキューへ入ったか判断できません。同じ業務の再試行には同じ重複排除IDを使い、FIFOの重複排除期間内で二重投入を抑えます。新しいIDを毎回発行すると再試行が別の送信として認識されます。期間を越える再試行も業務側で扱います。

4. 本文が共通の通知すべての本文を「更新」とし、商品IDだけを属性に入れている場合、本文ハッシュによる重複排除では別商品も同じ内容と見なされ得ます。業務IDを明示的な重複排除IDへ使う等、別の仕事と同じ仕事を正しく区別します。グループIDだけを設定してもこの識別問題の代わりにはなりません。

5. 決済完了後の再受信消費者が外部決済を成功させた後に停止すると、キューの再受信が必要になる場合があります。外部決済にも同じ冪等キーを渡す等、再実行を安全にします。FIFOの送信重複排除は、外部決済の状態を自動判定して補償する仕組みではありません。どの境界で失敗したかを記録します。

6. 先頭エラーへの対応同じ商品の更新1が失敗し、更新2が待つ状況では、先頭を単にDLQへ外すと更新2が先に適用される問題があります。順序必須なら該当系列を止めて修復する、スキップを業務が許容するか確認する等の方針が必要です。全キューの停止が必要か、該当グループだけでよいかも検討します。

7. 順序不要なら簡素化独立した商品画像のサムネイル生成は、別画像との順序を必要としません。重複処理を安全に扱う設計でStandardを使えばよい場合があります。何でもFIFOへ統一する前に、順序の利点とグループ設計・処理能力・運用の負担を比較します。現在のクォータと負荷試験で能力も確かめます。

8. 配信保証の範囲を確認「FIFOなので一度だけ」と書かれた設計書を見たら、送信重複、受信再試行、DB更新、外部APIの各境界を分けます。どの保証に任せ、どこを業務IDで防ぐかを明記します。異常系試験では、送信応答喪失、処理中停止、更新成功直後停止、DLQ再投入をそれぞれ試します。

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

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