導入
注文を受け付けるサーバーが、決済サーバーを直接呼び出しているとします。決済サーバーが一時的に落ちたら、注文の受け付けまで巻き添えで止まってしまいます。この「巻き添え」を防ぐのがキューです。
説明
密結合（みつけつごう）とは、AとBが直接つながっていて、片方が止まればもう片方も止まる状態です。反対に疎結合は、AとBのあいだにクッションを置き、相手の都合に左右されない状態にすることを指します。
Amazon SQS（Simple Queue Service）は、そのクッションの役割をするフルマネージドのメッセージキューです。送り手（プロデューサー）はキューにメッセージを置くだけ、受け手（コンシューマー）は自分のペースでキューから取り出して処理します。
- 送り手と受け手が同時に動いている必要がない … 受け手が止まっていても、メッセージはキューに残る（最大14日間保持できる）。
- 急な負荷を吸収できる（バッファリング） … セール時に注文が殺到しても、キューに溜めておいて後ろでゆっくり処理できる。
- 取り出されるまで消えない … 処理が終わったら受け手が明示的に削除する。処理に失敗すればメッセージは再び取り出せる状態に戻る。
- キューの種類 … 順番は保証しないが超高速な標準キューと、順番と「1回だけ処理」を保証するFIFOキューの2種類がある。
flowchart LR
P["注文サーバー（送り手）"] -->|メッセージを送る| Q["SQSキュー"]
Q -->|自分のペースで取り出す| C1["決済ワーカー1"]
Q -->|取り出す| C2["決済ワーカー2"]
SQSは1つのメッセージを1つの受け手が処理する仕組みです（複数のワーカーで手分けはするが、同じメッセージが二重に処理されないようにする）。この「仕事の依頼書を置いておく箱」というイメージを持っておくと、次のレッスンのSNSとの違いがはっきりします。
具体例
通販サイトの「注文 → 決済」を、密結合と疎結合で比べてみましょう。
密結合（キューなし） … 注文サーバーが決済サーバーを直接呼び出す設計。ある日、決済サーバーがメンテで数分落ちた瞬間、注文サーバーもエラーになり、お客さんは注文すらできなくなった。セール中で注文が殺到したときも、決済が処理しきれずタイムアウトが続出。
疎結合（SQSを挟む） … あいだにSQSキューを置く設計に変更。
- 注文サーバーは「決済してね」という依頼書をキューに入れるだけで即座に「注文受付完了」を返す
- 決済ワーカーは自分のペースでキューから取り出して処理する
- 決済ワーカーが落ちても、依頼書はキューに最大14日間残るので注文は1件も失われない。復旧後に溜まった分を処理すればよい
- セールで注文が殺到しても、いったんキューに溜めて後ろでさばくので、注文受付そのものは止まらない（バッファリング）
「相手の都合で巻き添えにならない」——これが疎結合の威力で、その定番の道具がSQSです。
読んでみよう
「片方が止まっても巻き添えにしない＝疎結合」「その道具がSQS（メッセージを溜める箱）」。試験では「システムを疎結合にするには？」と問われたら、まずSQSを思い出しましょう。