目次
1. 結論
SNS（Amazon Simple Notification Service）とSQS（Amazon Simple Queue Service）のファンアウト構成は、「システムの疎結合化」の鉄板構成です。SNSがメッセージを「放送」し、複数のSQSがそれを「受信・貯蔵」することで、後続の処理が個別にスケールでき、一部が停止しても他方に影響を与えない強固なシステムを作れます。
2. SAAで出やすいポイント
- 並列処理の実現: 1つのアクション（例：画像のアップロード）をトリガーに、複数の異なる処理（例：縮小版作成、顔認識、DB登録）を同時に開始できる。
- 耐障害性の向上: 後続の処理が一時的にダウンしても、SQSにメッセージが滞留するため、データが消失しない。
- スケーラビリティの確保: 各SQSの後ろにいるコンシューマー（EC2やLambda）が、それぞれの負荷に応じて個別にスケーリングできる。
- SNSフィルタリング: 特定の条件（例：注文金額が1万円以上）に合致する場合のみ、特定のSQSへメッセージを飛ばす設定が可能。
3. キーワードでの判断
| 問題文のキーワード | 疑うべきサービス/機能 | 判断理由 |
|---|---|---|
| 「疎結合（Decoupling）」 | SNS + SQS | サービス間の直接依存を排除するため |
| 「複数の後続処理を並列実行」 | SNSファンアウト | 1対多のメッセージ配信が必要 |
| 「スパイク時の負荷を吸収」 | SQSバッファリング | キューによる流量調整が必要 |
4. ひっかけポイント
- SNSのみ vs SQSのみ:
- SNSだけだと、受信側がダウンしている間にメッセージが失われる可能性がある（リトライはあるが限界がある）。
- SQSだけだと、複数のコンシューマーが同じメッセージを奪い合ってしまい、並列処理（1対多）にならない。
- Kinesisとの違い: リアルタイムなストリーミング解析ならKinesis、非同期なタスク処理ならSNS+SQS。
5. 覚え方
- 「SNSは放送局、SQSは視聴者の録画機」。
- 放送局（SNS）が流した番組を、各家庭（SQS）が録画して、好きな時間に再生（処理）するイメージ。
6. 関連サービス
| サービス名 | 関連する理由 |
|---|---|
| SQS | SNSからのメッセージを確実に受け取り、処理待ちを管理する。 |
| Lambda | SQSからメッセージを取り出して処理を実行するサーバーレスな実行環境。 |
| EventBridge | SNSよりも高度なルーティングやSaaS連携が必要な場合の選択肢。 |
7. Obsidian管理メモ
- 復習ポイント: SNSトピックにSQSをサブスクライブさせる手順と、パーミッション（SQSのアクセスポリシー）の設定を忘れがちなので注意。
- 関連ノート: メッセージングサービス比較
8. HTMLファイル名
sns-sqs-fanout-architecture.html
