【SQSの役割（パフォーマンス最適化）】
目次
🔍 1. 結論
💎 一言でいうと SQSのパフォーマンス設計における最大の焦点は、「無限のスループットを持つ『標準キュー』を選ぶか、順番保証はあるが速度に上限がある『FIFOキュー』を選ぶか」 のトレードオフです。
- とにかく大量のメッセージを爆速で処理したい（順番は問わない） → 標準キュー (Standard)
- 処理の順番を絶対に守りたい（株の取引など） → FIFOキュー
- 処理の効率化とコスト削減には バッチ処理 を使う。
📈 2. SAAで出やすいポイント
- 標準キュー (Standard Queue): 1秒あたりのAPI呼び出し回数（スループット）が「ほぼ無制限」です。高性能アーキテクチャにおいて、システムに送られてくる数百万件のログやリクエストを処理遅延なく受け止める場合はこちらが正解です。ただし、メッセージの順序は「ベストエフォート（入れ替わる可能性がある）」であり、「少なくとも1回（重複の可能性がある）」の配信となります。
- FIFOキュー (First-In-First-Out): 送信された順番を厳密に守り、絶対に「1回だけ（Exactly-Once）」処理させます。しかし、スループットには上限（デフォルトで1秒あたり300回、バッチを使えば3000回）があります。
- バッチ処理の活用: Lambdaなどのワーカーがメッセージを取得する際、1件ずつ取得するのではなく 最大10件まとめて取得（バッチ取得） することで、APIの呼び出し回数を減らし、パフォーマンス向上とコスト削減を同時に達成できます。
🗝 3. キーワードでの判断
| 問題文のキーワード | 疑うキューの種類・設定 |
|---|---|
| 🚀 「1秒間に数万件のメッセージ」「スループットを最大化したい」 | SQS 標準キュー (Standard Queue) |
| 🔢 「順序を厳密に保証する」「重複処理を絶対に防ぐ」 | SQS FIFOキュー |
| 💰 「SQSのポーリングコストを下げつつ処理効率を上げたい」 | ロングポーリング / メッセージのバッチ処理 |
⚠️ 4. ひっかけポイント
🚫 よくある誤答パターン – 「パフォーマンスを上げるためにFIFOキューを採用する」 → 完全に逆です。FIFOキューは「順番を守るため」に設計されており、パフォーマンス（スループット）は標準キューに圧倒的に劣ります。「処理能力」が問われているのか「正確性」が問われているのかを問題文から読み取ってください。 – 「標準キューで順序を保証するカスタムロジックを組む」 → 実務ではあり得ますが、試験の解答としては「要件に合わないためFIFOに切り替える」が正解です。
💡 5. 覚え方
🧠 暗記ショートカット – 標準キュー = 「人気アトラクションの列」。 – 列の整理は適当だが、数万人が一気に乗れる（超高スループット）。たまに順番が前後したり、同じ人が2回乗ったりする。 – FIFOキュー = 「銀行のATMの列」。 – 1列に並んで順番を絶対に守る（正確）。その代わり処理できる人数（スループット）には限界がある。
📚 6. 関連サービス
| アイコン | サービス名 | 高性能化における連携 |
|---|---|---|
| ⚡ | AWS Lambda | SQSのイベントソースマッピングで、バッチサイズを指定して一気に処理させる |
| 📢 | Amazon SNS | SNS（Pub/Sub）とSQSを組み合わせることで、高スループットなファンアウト構成を作る |
🗒️ 7. Obsidian管理メモ
- 見返すタイミング: メッセージングアーキテクチャの比較（Standard vs FIFO）学習時
- 関連ノート候補:
AWS_SAA_SQS_Standard_vs_FIFO
8. HTMLファイル名:
AWS_高性能設計_SQS.html
