第8章
疎結合アーキテクチャ — SQS・SNS・EventBridge・Step Functions
約3分
学習者APIで直接呼び出せばシンプルなのに、なぜわざわざSQSやSNSを挟むんですか？
システム同士を直接呼び合う構成は、片方の障害や負荷がもう片方へ伝わりやすくなります。SAA-C03の「スケーラブルで疎結合なアーキテクチャ」では、SQS、SNS、EventBridge、Step Functionsがよく登場します。
疎結合にする理由
直接同期呼び出しだけで構成すると、次の問題が起きます。
- 呼び出し先が落ちると呼び出し元も失敗する
- 一時的なアクセス増加を吸収しにくい
- 処理が長いとユーザー応答が遅くなる
- サービス追加時に既存システムへの影響が大きい
キューやイベントを挟むと、処理を非同期化し、負荷を平準化できます。
SQS、SNS、EventBridgeの使い分け
| サービス | 得意なこと | 典型例 |
|---|---|---|
| SQS | キューで処理をためる | 注文処理、画像変換、バッチ連携 |
| SNS | 複数の購読者へ通知する | メール通知、SQSへのfan-out |
| EventBridge | イベントルーティング | SaaS連携、AWSイベント連携、ドメインイベント |
| Step Functions | ワークフロー制御 | 承認、リトライ、分岐、複数Lambdaの制御 |
DLQとリトライ
非同期処理では、失敗したメッセージをどう扱うかが重要です。SQSでは DLQ（Dead Letter Queue） を設定し、何度も失敗したメッセージを退避できます。
実務で見るべき項目:
- Visibility Timeoutは処理時間より長いか
- リトライ回数は適切か
- DLQに溜まったメッセージを監視しているか
- 冪等性を考慮しているか
同じメッセージが複数回処理されても壊れないように、処理側は冪等に設計します。
まとめ
疎結合設計では、同期呼び出しを減らし、キューやイベントで依存を弱めます。
- 処理の順番待ちや非同期化にはSQSを使う
- SNSは通知のfan-out
- EventBridgeはイベントルーティング
- Step Functionsはワークフロー制御
- DLQ、リトライ、冪等性をセットで設計する
次の章では、ELB、Auto Scaling、Multi-AZを使った可用性とスケーラビリティを扱います。
AWSクイズに挑戦するこの章で学んだAWSの知識を、4択クイズでアウトプットして定着させよう