変更要約: 軸B網羅: 構築ブロック(コンピュート/DB/ストレージ/ネットワーク=s4、分析/ML/IoT/メディア/統合=s5)のカタログ節を追加
2.2スケーラブルで疎結合なアーキテクチャ
弾力性と疎結合の設計——Auto Scaling／ELB、SQS/SNS/EventBridge による分離、サーバーレス（Lambda／API Gateway／Step Functions）、キャッシュ——を理解します。需要変動に強く、障害を局所化します。
大規模設計の要は疎結合と水平スケールです。コンポーネントをキューやイベントで分離し、Auto Scaling で需要に追従します。
2.2.1疎結合とスケーリング
- Auto Scaling＋ELB：複数 AZ に分散し、需要に応じて水平スケール。耐障害性も向上。
- SQS：生産者と消費者をキューで分離。スパイクを吸収し、再試行で信頼性を高める。
- SNS/EventBridge：イベントを複数の購読者へファンアウト（pub/sub・イベント駆動）。
- サーバーレス：Lambda/API Gateway/Step Functions でインフラ管理なしにイベント駆動処理。
「スパイク吸収・生産者/消費者分離＝SQS」「1 対多のファンアウト＝SNS/EventBridge」「需要追従の水平スケール＝Auto Scaling」「ワークフロー連携＝Step Functions」 は SAP-C02 で頻出です。同期的に密結合した処理は、キュー/イベントで非同期・疎結合に置き換えると回復力が上がります。
順序保証や重複排除が必要なら SQS FIFO、巨大なファンアウトやイベントルーティングには EventBridge（ルール/ターゲット）が適します。読み取り負荷の高い DB は ElastiCache で前段キャッシュします。
疎結合の要は「同期の密結合呼び出し」を「非同期のキュー/イベント」に置き換えること。SQS は 標準（高スループット・最低 1 回・順序保証なし）と FIFO（順序保証・重複排除）があり、可視性タイムアウト・DLQ（デッドレターキュー）・ロングポーリング で信頼性を高めます。1 対多は SNS（プッシュ型 pub/sub）や EventBridge（イベントバス＋ルールで属性ベースルーティング・SaaS/スケジュール連携・スキーマレジストリ）。SNS+SQS ファンアウト（各購読 SQS にバッファ）も定番。スケールは Auto Scaling（ターゲット追跡/ステップ/予測スケーリング・複数 AZ）＋ ELB（ALB＝L7/パスベース、NLB＝L4/超低遅延・静的IP）。サーバーレスは Lambda（同時実行・予約/プロビジョンド同時実行でコールドスタート緩和）＋API Gateway＋Step Functions（標準/Express・状態/再試行/分岐）。読み取り負荷は ElastiCache（Redis/Memcached・キャッシュアサイド）で軽減。SAP では「密結合の同期処理を SQS/SNS/EventBridge で非同期・疎結合化し、スパイク吸収・部分障害の局所化・再試行で回復力を上げる」が王道です。
| サービス | モデル | 向く用途 |
|---|---|---|
| SQS | キュー（1 消費者グループ） | スパイク吸収・生産者/消費者分離 |
| SNS | プッシュ型 pub/sub | 1 イベントを多数へファンアウト |
| EventBridge | イベントバス＋ルーティング | 属性ベース振り分け・SaaS/スケジュール |
| Step Functions | ステートマシン | 多段ワークフローの可視化/再試行 |
シナリオ： 注文イベントを「在庫」「請求」「通知」の 3 つの独立サービスに配り、各サービスは自分のペースで処理し、障害時も取りこぼさないようにしたい。→ EventBridge（または SNS）で注文イベントをファンアウトし、各サービスの前段に SQS を置いてバッファ＋再試行＋DLQ。処理ワーカーは Auto Scaling/Lambda で需要追従します。
FAQ： Q. SQS と SNS の違いは？ → A. SQS はキュー（消費者が引き取る・1 グループが処理）、SNS は pub/sub（1 メッセージを多数へプッシュ）。両方組み合わせてファンアウト＋バッファも定番。Q. SQS 標準と FIFO は？ → A. 標準は高スループットだが順序非保証・最低 1 回、FIFO は順序保証＋重複排除（スループットは制限あり）。
ひっかけ： 「1 イベントを複数サービスへ同時配信するのに SQS 標準キュー 1 本を使う」は誤りです。1 本のキューは基本 1 消費者グループが取り合うため、ファンアウトは SNS/EventBridge（＋必要なら各購読 SQS）。また「順序保証に SQS 標準で十分」も誤り（順序保証は FIFO）。
2.2.2この節のまとめ
- 疎結合＝SQS（キュー）／SNS・EventBridge（ファンアウト）
- スケール＝Auto Scaling＋ELB／サーバーレス＝Lambda/API GW/Step Functions
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 注文を受け付けるフロントと、時間のかかる処理ワーカーを分離し、急なスパイクでもリクエストを失わないようにしたい。何を使いますか？
Q2. 1 つのイベントを、複数の異なるサービス（メール通知・ログ保存・分析）に同時に配信したい。何を使いますか？
Q3. 複数の Lambda 関数からなる長時間のビジネスワークフローを、状態・再試行・分岐付きで可視化して制御したい。何を使いますか？