導入
コンポーネント同士を直接呼び合う設計は、片方が落ちるともう片方も引きずられます。SAPが繰り返し問う「疎結合」の基本は、間にメッセージングサービスを挟んで互いの生存に依存しない構成にすることです。
説明
Amazon SQS（Simple Queue Service） はキューで、送信側と受信側の間にバッファを作ります。受信側が一時的に遅くても、落ちていても、メッセージはキューに溜まったまま残ります。
| SQSの種類 | 特徴 | 向いている用途 |
|---|---|---|
| 標準キュー | ほぼ無制限のスループット、順序は保証されない、まれに重複配信 | 大量の非同期ジョブ、順序を問わない処理 |
| FIFOキュー | 送信順を厳密に保証、重複排除、スループットに上限 | 決済処理など、順序と一意性が必須の処理 |
Amazon SNS（Simple Notification Service） はPub/Sub型の通知サービスで、1つのメッセージを**複数の購読先に同時配信（ファンアウト）**できます。
flowchart LR
P["注文サービス"] --> T["SNSトピック"]
T --> Q1["SQS: 在庫更新"]
T --> Q2["SQS: メール送信"]
T --> Q3["SQS: 分析基盤"]
SNSとSQSを組み合わせる「Fanout（ファンアウト）パターン」は、1つのイベントを複数の独立した処理に配信しつつ、各処理はそれぞれのキューで自分のペースで処理できる、疎結合の定番構成です。
- 「急なスパイクで後段のワーカーが処理落ちする」→ SQSでバッファリングし、ワーカー側はキューから引き取れる分だけ処理する
- 「1つのイベントを複数のシステムに配信したい」→ SNS→複数SQSのファンアウト
- 「順序と重複排除が必須」→ SQS FIFOキュー
読んでみよう
「疎結合にしたい」という要件文を見たら、まず同期呼び出しをやめてSQS/SNSを挟めないかを考える癖をつけましょう。SAPでは、既存のポイントツーポイント（直接API呼び出し）構成をSNS/SQSに置き換える改修問題も頻出です。