SQSのStandardとFIFOを理解する

StandardとFIFOの選択は、速さの印象ではなく、重複と順序の要件で判断します。送信の重複排除と業務処理の一回性が異なることまで学びます。

この単元で学ぶこと

  • StandardとFIFOの保証の違いを説明する
  • グループIDと重複排除IDを使い分ける
  • 業務順序と並行処理の設計条件を判断する

本文解説

1. Standardの配信特性 Standardは分散したキューとして多くの独立した仕事を扱えます。ただし同じメッセージが複数回届くことがあり、送信順と受信順が入れ替わる可能性もあります。写真ごとの縮小処理のように他の仕事との順序が不要なら、業務IDで重複に対応して活用できます。

2. FIFOが必要な順序 FIFOは同じメッセージグループの順序を保ちます。口座の「入金後に出金」など順序が結果に影響する処理では、どの単位に順序が必要かを決めます。キュー全体のすべての仕事を必ず一列にするのではなく、独立した系列を分けられる点が重要です。

3. グループID MessageGroupIdは順序を保つ系列です。口座Aと口座Bが独立なら、それぞれ別グループにして並行処理を可能にできます。同じ口座の操作を無作為なグループへ割り振ると、必要な順序を失います。逆に全口座を同じグループにすると、独立した処理まで直列になり並行性を制限します。

4. 重複排除ID MessageDeduplicationIdは送信再試行が同じ仕事かを識別します。FIFOの重複排除期間内に同じIDで再送すると重複投入を抑えます。グループIDが「どの系列か」を示すのに対し、このIDは「どの仕事か」を示します。異なる仕事へ同じIDを使えば、必要な送信を重複扱いする危険があります。

5. 本文による識別 コンテンツベースの重複排除を使う場合、本文から算出したハッシュを識別に用います。メッセージ属性はこのハッシュの対象ではありません。本文が同じでも属性で別の業務を表している設計なら、意図しない重複扱いを避けるため本文や明示IDの設計を見直します。

6. 処理の一回性との境界 FIFOの送信重複排除は、外部DBの更新とキューの削除を一つのトランザクションにする機能ではありません。更新後、削除前に停止すれば同じ仕事を再受信して扱う必要があります。業務側も冪等にし、再試行が安全であることを確認します。「FIFOならどの副作用も必ず一回」は不正確です。

7. 失敗と順序 同じグループの未完了メッセージは後続の進行に影響します。可視性タイムアウト、処理時間、削除を整えます。失敗メッセージをDLQへ外すと後続が先へ進み、業務上必要だった順序関係を崩す場合があります。厳密な系列では隔離後に止める範囲や復旧の順番まで設計します。

8. 選択の手順 最初に順序が必要か、必要ならどの単位かを確認します。次に重複送信と再実行をどう防ぐか、独立グループはいくつあるか、想定スループットが現在のクォータ内かを評価します。FIFOにも性能条件があり、Standardにも重複対策が必要です。サービス名だけで業務要件が自動的に満たされるわけではありません。

図解

系列と仕事のID
順序の単位と一つの仕事の識別子は役割が違います。

重要ポイント

  • Standardは重複と順序入替えを前提にする
  • FIFOの順序はメッセージグループ単位
  • 送信重複排除と外部副作用の冪等性を分ける

間違えやすい点

  • グループIDを仕事の一意IDと混同しない
  • 属性だけ異なる本文をコンテンツ重複排除で必ず別物と考えない
  • FIFOにすればDLQ使用後も業務順序が無条件で守られると思わない

用語解説

FIFO
グループ内で先に送ったメッセージの順序を維持し、送信重複の排除を提供するキュー種別。
重複排除ID
一定の重複排除期間内で同じ送信を識別する値。
メッセージグループ
FIFOで順序をそろえる一連のメッセージ。異なるグループは独立して扱える。

関連教材

参考資料

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

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