AWS SAA 試験勉強（15日目）
投稿日：2026/03/15
- AWS SAAでは、システムの疎結合化（Loose Coupling） を実現するサービスが頻出します。
- 特定のコンポーネントが故障してもシステム全体を止めない、あるいは負荷のスパイクを柔軟に受け流す「レジリエンス（回復性）」の高い設計を理解しましょう。
1. 非同期アーキテクチャとは
同期処理のリスク
ユーザーからのリクエストを受けて、その場で全ての処理（Webサーバーでの計算、DBへの書き込みなど）を完了させる方式です。
- リスク: DBが重くなると、Webサーバーも待機状態になり、最終的にユーザーへのレスポンスがタイムアウトします。
非同期構成のメリット
処理をメッセージとして一旦「キュー」に預け、後から別のプロセス（ワーカー）が自分のペースで処理する方式です。
- 耐障害性: ワーカーが一時的にダウンしても、キューにメッセージが溜まるだけでデータは消失しません。
- スケーラビリティ: キューの溜まり具合に応じて、ワーカーの台数を Auto Scaling させることができます。
2. SQS（Simple Queue Service）：プル型のメッセージング
SQSは、メッセージを一時的に保存する「行列（キュー）」を提供するサービスです。
ワーカーが自らメッセージを取りに行く「プル型」です。
主要なキュータイプ
- 標準キュー (Standard):
- 無制限のスループット。
- 順序が前後する可能性があり、稀にメッセージが重複（少なくとも1回配信）します。
- FIFOキュー:
- 送った順番通りに処理。
- 重複なし（正確に1回配信）。
- 金融取引など正確性が求められる場合に。
試験に出る重要概念
- 可視性タイムアウト (Visibility Timeout):
- あるワーカーがメッセージを処理している間、他のワーカーからそのメッセージを見えなくする期間。
- 処理に時間がかかる場合は、この値を調整する必要があります。
- デッドレターキュー (DLQ):
- 何度試しても処理に失敗した「毒メッセージ」を隔離するための別のキュー。
3. SNS（Simple Notification Service）：プッシュ型の配信
SNSは、メッセージを複数の宛先に一斉配信する「Pub/Subモデル」のサービスです。SNS側から宛先へ送りつける「プッシュ型」です。
主要な特徴
- ファンアウト (Fan-out) 構成: 1つのトピックにメッセージを送ると、複数の SQS、Lambda、メール等に同時にコピーを配信できます。
- メッセージフィルタリング: 特定の条件に合うメッセージだけを特定のサブスクライバーに送ることができます。
4. EventBridge：サーバーレスのイベントバス
かつて CloudWatch Events と呼ばれていた機能の進化版です。
主な用途
- スケジュール実行: 「毎日○時に起動」といった cron 的な役割。
- AWSサービス間の連携: 「S3にファイルが置かれたら処理を開始する」といったイベント駆動のトリガー。
- SaaS連携: Zendesk や Datadog などの外部サービスからのイベントを AWS 内で処理。
5. 試験頻出パターン：ファンアウト設計
試験で最もよく出る「疎結合」のパターンは SNS + 複数のSQS の組み合わせです。
- ユーザーが注文を行う（SNSへメッセージ送信）。
- SNSがメッセージをコピーし、「在庫管理用SQS」と「配送指示用SQS」の両方に即座に配信。
- それぞれのワーカーが独立して処理を進める。
- メリット: 在庫管理システムがメンテナンス中でも、配送システムは影響を受けずに稼働し続けることができます。
試験での「判断基準」チェックリスト
- 「処理の順序が重要で、重複は許されない」
- 回答：SQS FIFOキュー
- 「処理が失敗した原因を調査するために、エラーデータを隔離したい」
- 回答：デッドレターキュー (DLQ)
- 「1つのイベントをきっかけに、複数の異なる処理（LambdaやSQS）を同時に動かしたい」
- 回答：SNS のファンアウト構成
- 「特定の日時に自動的に Lambda を実行したい」
- 回答：EventBridge (スケジューラ)
まとめ（15日目の振り返り）
非同期アーキテクチャの核心は、「待たせない、止めない、溜めてから処理する」 ことです。
- SQS: 1対1（プル型）で負荷を平滑化。
- SNS: 1対多（プッシュ型）で一斉通知。
- EventBridge: イベント（きっかけ）を管理。
この3つを使い分けることで、真にクラウドネイティブな高可用性システムを設計できるようになります。