導入
注文処理システムで、注文を受け付けるWebサーバーと、注文を処理するバックエンドを直接つなぐとどうなるでしょうか。バックエンドが落ちていたら注文も受け付けられません。バックエンドの処理が遅ければWebサーバーも詰まります。この「直結による共倒れ」を防ぐのが 疎結合（Loose Coupling） という考え方です。
説明
Amazon SQS（Simple Queue Service） は、コンポーネント間に キュー（メッセージの待ち行列） を挟むフルマネージドサービスです。送信側はキューにメッセージを置くだけ、受信側は自分のペースでキューから取り出して処理します。両者は互いの状態を知る必要がなく、一方が落ちても他方は影響を受けません。
flowchart LR
P["注文を受け付けるWebサーバー<br/>（プロデューサー）"] -->|"メッセージを送信"| Q["SQSキュー"]
Q -->|"自分のペースで取得"| C["注文処理バックエンド<br/>（コンシューマー）"]
急なアクセス集中があっても、キューがメッセージを溜め込んで バッファ の役割を果たすため、バックエンドは自分の処理能力の範囲でゆっくり処理できます（スパイク吸収）。
SQSには2種類のキューがあります。
| 種類 | 特徴 | 使いどころ |
|---|---|---|
| 標準キュー（Standard） | ほぼ無制限のスループット、順序は保証されない、まれに重複配信 | とにかく大量・高速に処理したい（順序不問） |
| FIFOキュー | 送信順を厳密に保証、重複排除、スループットに上限あり | 注文処理など「順番」が重要な処理 |
覚えておくべき重要な仕組みが2つあります。
- 可視性タイムアウト（Visibility Timeout）：あるコンシューマーがメッセージを取得すると、そのメッセージは一定時間「他のコンシューマーから見えなく」なります。処理が時間内に完了しないと、メッセージは再びキューに戻り、二重処理のリスクが生まれます。
- デッドレターキュー（DLQ）：規定回数処理に失敗し続けたメッセージを隔離する、専用の別キューです。「処理できないメッセージ」がキューに滞留して他の処理を妨げるのを防ぎます。
具体例
チケット販売サイトの「注文処理」で、SQSの各仕組みが効く場面を追ってみましょう。
- 発売開始でアクセス殺到（スパイク吸収） … 1秒に数千件の注文が来ても、Webサーバーは注文をキューに入れるだけで即応答。処理バックエンドは自分の能力の範囲でキューから取り出してさばく。バックエンドが一時的に落ちても、注文はキューに残るので失われない。
- 「先に申し込んだ人を先に処理」したい（順序） … 標準キューは順序を保証しない。抽選でなく先着順なら、FIFOキューで送信順を厳密に守る。
- 決済で必ず失敗する“毒メッセージ”がキューに居座る … あるメッセージが、無効なカード情報のせいで処理のたびに失敗し、キューを詰まらせる。→ 規定回数失敗したらデッドレターキュー（DLQ）へ隔離し、他の正常な注文の処理を止めない。
- 可視性タイムアウトの注意 … 取得中のメッセージは一定時間他から見えなくなるが、処理がそれを超えると再びキューに戻り二重処理の恐れ。タイムアウトは処理時間に合わせて設定する。
「疎結合・スパイク吸収＝SQS、順序＝FIFO、失敗メッセージの隔離＝DLQ」がSAAの頻出セットです。
読んでみよう
「システムを疎結合にしたい」「トラフィックのスパイクをバッファリングしたい」「一部の障害を全体に波及させたくない」——これらのキーワードが出たらまずSQSを検討してください。「順序が重要」ならFIFOキュー、「処理に何度も失敗するメッセージを隔離したい」ならDLQ、と覚えましょう。