導入
コンポーネント同士を直接呼び合う設計は、片方が落ちるともう片方も引きずられます。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キュー
具体例
既存の通販システムが、注文サービスから在庫・メール・分析の各サービスを直接API呼び出ししていました。ある日、分析サービスが高負荷で応答しなくなると、その呼び出しで注文処理まで詰まってしまいました。1つの障害が全体を引きずる密結合の典型です。
これをSNS＋SQSのファンアウトに改修します。
- 注文サービスは「注文確定」をSNSトピックに1回発行するだけ
- 在庫更新・メール送信・分析の各SQSキューへ同時配信され、各ワーカーは自分のキューから自分のペースで処理
- 分析サービスが落ちても、そのキューにメッセージが溜まるだけで、注文・在庫・メールには一切影響しない
- 発売日のスパイクも、キューがバッファになりワーカーは捌ける分だけ引き取る
さらに、決済のように順序と重複排除が必須の処理にはFIFOキューを使います。「疎結合にしたい」「既存の直接API呼び出しを改善したい」と来たら、まず同期呼び出しをSQS/SNSに置き換えられないかを考えるのがSAPの定石です。
読んでみよう
「疎結合にしたい」という要件文を見たら、まず同期呼び出しをやめてSQS/SNSを挟めないかを考える癖をつけましょう。SAPでは、既存のポイントツーポイント（直接API呼び出し）構成をSNS/SQSに置き換える改修問題も頻出です。