SQS FIFO キュー

SQS FIFO キューとは

SQS FIFO (First-In-First-Out) キューは、メッセージの順序保証と厳密な 1 回処理 (Exactly-Once Processing) を提供する Amazon SQS のキュータイプである。標準キューが「少なくとも 1 回配信」で順序が保証されないのに対し、FIFO キューは同じメッセージグループ ID を持つメッセージを送信順に配信する。

ただし 2 つの保証にはどちらも範囲がある。順序が守られるのはグループの中だけで、異なるグループの間の前後関係は保証されない。重複が入らないのは重複排除の対象期間である 5 分間に限られ、同じ内容を 5 分より後に送り直せば別のメッセージとして受け付けられる。言い換えると FIFO キューは、順序と一意性を守りたい範囲をグループ ID で宣言させ、その範囲だけを直列化する仕組みである。

標準キューとの比較

選択の分かれ目は順序・配信保証・スループットの 3 点で、いずれも FIFO 側に制約が付く。

観点	標準キュー	FIFO キュー
順序	ベストエフォート	メッセージグループ ID 単位で送信順
配信保証	少なくとも 1 回 (重複あり)	重複排除の対象期間 (5 分) 内は重複を入れない
スループット	ほぼ無制限	API アクションあたり 300 件/秒 (1 回 10 件のバッチで 3,000 件/秒)
高スループット	切り替える設定は無い	属性 2 つを明示設定して有効化・上限はリージョン依存
キュー名	任意	.fifo サフィックス必須

メッセージグループ ID

FIFO キュー内でメッセージをグループ化し、グループ内の順序を保証する。

await sqs.send(new SendMessageCommand({
  QueueUrl: 'https://sqs.ap-northeast-1.amazonaws.com/123456789012/orders.fifo',
  MessageBody: JSON.stringify({ orderId: '123', action: 'create' }),
  MessageGroupId: 'order-123',           // 同じ注文のメッセージは順序保証
  MessageDeduplicationId: 'create-123',  // 重複排除
}));

グループ "order-123": [create] → [update] → [ship]  ← 順序保証
グループ "order-456": [create] → [cancel]            ← 別グループは並列処理

送信されたメッセージは、メッセージグループ ID をハッシュ関数に通した結果で内部のパーティションに振り分けられる。順序を直列化する単位がパーティションなので、スループットもパーティション単位で決まる。グループ ID の種類が少ないと処理が 1 か所に集まり、キューを分けても並列度は上がらない。注文 ID やユーザー ID のように値が十分に散らばるキーを選ぶのが原則である。

直列化には目詰まりが付いてくる。同じグループの先頭のメッセージが処理に失敗して可視性タイムアウトでキューへ戻ると、そのグループの後続はタイムアウトが切れるまで受信できない。順序保証が要件であっても、1 つのグループにどれだけのメッセージを流すかは待ち時間の設計と一緒に決める必要がある。

高スループットの有効化と上限

高スループットは既定では無効で、キューの属性を 2 つ変えて初めて有効になる。DeduplicationScope を messageGroup に、FifoThroughputLimit を perMessageGroupId にする (片方だけでは有効にならない)。有効化すると重複排除の判定範囲がキュー全体からメッセージグループ単位へ狭まるため、グループをまたいで同じ重複排除 ID を使っていた設計は挙動が変わる。

上限値はリージョン差が大きい。2026 年 8 月時点の公式クォータでは、東京リージョン (ap-northeast-1) はバッチを使わない場合 9,000 件/秒、10 件バッチで 90,000 件/秒。最も高いバージニア北部・オレゴン・アイルランドは 70,000 件/秒、バッチで 700,000 件/秒である。「FIFO は毎秒◯件まで」と単一の数字で覚えると、リージョンを変えた時点で前提が崩れる。処理中 (In-Flight) のメッセージ数の上限は 1 キューあたり 120,000 件で、受信したまま削除も可視性タイムアウト切れもしていないメッセージの総数がこれに当たる。

重複排除

方式は 2 つある。MessageDeduplicationId を送信側で明示する方式では、同じ ID のメッセージが 5 分間の対象期間内に届いても 2 通目以降はキューに入らない。送信 API がタイムアウトして再送した場合も、この期間内であれば重複は生まれない。コンテンツベース重複排除を有効にすると、ID を省略してもメッセージ本文の SHA-256 ハッシュが重複排除 ID として使われる。

注意したいのは、ハッシュの計算対象が本文だけで、メッセージ属性が含まれない点である。本文が同一で属性だけが異なるメッセージは重複と判定されて消える。属性に処理の分岐条件を持たせている設計では、明示的な ID を指定するほうが安全だ。

使うべきケース

注文処理 (作成 → 支払い → 発送の順序が重要)、金融取引 (取引の順序が結果に影響)、ワークフロー (ステップの実行順序を保証) に適している。

使うべきでないケース

順序が要件でないなら標準キューを選び、重複は受信側の冪等性で吸収するほうが構成は単純になる。FIFO でも高スループットを有効にすれば秒間数千から数万件を扱えるが、グループ ID の設計とリージョンごとのクォータ差を抱え込む対価がある。ログや計測値のように大量の連続データを流し、後段で並列に読み直したい用途ならストリーム型の Kinesis が向く。

FIFO キューを採用するかどうかは、順序を守る範囲をグループ ID として言葉で定義できるかで決まる。「注文ごと」「口座ごと」のように単位を言えるなら FIFO が効く。単位を言えないまま全体の順序を求めているなら、要件そのものを疑ったほうがよい。