【SQSの役割（耐障害性と高可用性）】
目次
🔍 1. 結論
💎 一言でいうと Amazon SQS（Simple Queue Service）は、システム間に「キュー（メッセージの待ち行列）」を挟むことで、前段と後段のシステムを疎結合（Decoupling）にし、一方の障害や過負荷が他方に波及するのを防ぐ（弾力性をもたらす）サービスです。
- 突発的なアクセス増（スパイク）が来ても、SQSがメッセージを一時保存（バッファリング）するため、バックエンドのDB等がパンクしない。
- 処理に失敗したメッセージは DLQ（デッドレターキュー） に隔離し、正常な処理を止めない。
📈 2. SAAで出やすいポイント
- バッファリングによる耐障害性: Web層（EC2やAPI Gateway）とワーカー層（DBや重い画像処理）の間にSQSを配置します。ワーカー層が一時的にダウンしても、リクエスト（メッセージ）はSQS内に安全に保持されるため、ワーカーが復旧次第、処理を再開できます（メッセージの取りこぼしゼロ）。
- デッドレターキュー (DLQ): 何度リトライしてもエラーになる（プログラムのバグや形式エラー等）メッセージを、別のSQSキュー（DLQ）に自動的に移動させる機能。これにより「毒入りのメッセージ」がキューに詰まって全体の処理が停止するのを防ぎます。
- 可視性タイムアウト (Visibility Timeout): あるEC2がメッセージを取り出して処理している間、他のEC2からそのメッセージが見えなくなる時間。処理が終わる前にタイムアウトすると別のEC2が同じ処理をしてしまうため、処理時間より長めに設定します。
🗝 3. キーワードでの判断
| 問題文のキーワード | 疑う機能・構成 |
|---|---|
| 🛡️ 「スパイク負荷を吸収したい」「バックエンドの過負荷を防ぐ」 | SQS (バッファリング) |
| 🧩 「システムを疎結合にしたい」「非同期で処理する」 | SQS |
| 🚨 「何度も処理に失敗するエラーメッセージを調査用に分けたい」 | SQS デッドレターキュー (DLQ) |
| ⏱️ 「一部の処理が2回実行されてしまう（重複実行を防ぐ）」 | SQS 可視性タイムアウトの延長 または FIFOキュー |
⚠️ 4. ひっかけポイント
🚫 よくある誤答パターン – 「リアルタイムでの同期処理にSQSを使う」 → SQSは「後で処理してね」という非同期処理用です。ユーザーがその場で結果を待つような同期処理には向いていません（その場合はELBやAPI Gatewayを直結させます）。 – 「SNSと混同する」 → SNSは「全員に一斉にお知らせ（Pub/Sub）」。SQSは「1件ずつ並んで順番に処理（キューイング）」です。
💡 5. 覚え方
🧠 暗記ショートカット – SQS = 「人気ラーメン店の行列整理チケット」。 – 店（DB）の席数は決まっているので、一気に客（リクエスト）が来てもチケット（キュー）を渡して待たせる。これで店はパンクしない（バッファリング）。 – チケットの番号が呼ばれても来ない客（エラー）は、別の待合室（DLQ）に移動してもらう。
📚 6. 関連サービス
| アイコン | サービス名 | SQSとの連携 |
|---|---|---|
| 📢 | Amazon SNS | 1つの通知をSNSで受け取り、複数のSQSに分岐させる（Fan-out構成） |
| ⚡ | AWS Lambda | SQSにメッセージが入ったことをトリガーに、自動で処理を実行する |
🗒️ 7. Obsidian管理メモ
- 見返すタイミング: マイクロサービスアーキテクチャ、非同期処理の学習時
- 関連ノート候補:
AWS_SAA_SQS_vs_SNS,AWS_SAA_Decoupling
8. HTMLファイル名:
AWS_弾力性設計_SQS.html
