【疎結合の役割（設計のベストプラクティス）】
目次
🔍 1. 結論
💎 一言でいうと 疎結合（Loose Coupling）は、システムの一部が故障しても、他の部分が影響を受けずに稼働し続けるようにする 設計原理です。コンポーネント間に「緩衝材」を挟むことで、独立したスケーリングや非同期処理が可能になります。
- SAAで「疎結合」という単語が出たら、真っ先に SQS / SNS / ELB を探す。
- 同期処理（直接呼び出し）から 非同期処理（キュー経由など） への変更が定番。
📈 2. SAAで出やすいポイント
- キューイングによるバッファリング: 処理能力を超えるリクエスト（スパイク）が来た際、間に Amazon SQS を挟むことでリクエストを一時保存し、バックエンドが自分のペースで処理できるようにする。
- Pub/Subメッセージング: 1つのイベントを複数のシステムに同時に通知したい場合、直接呼び出すのではなく Amazon SNS や EventBridge を挟む（ファンアウト構成）。
- ロードバランサーの活用: ELB を挟むことで、クライアントはバックエンドの具体的なIPや台数を意識する必要がなくなり（名前解決の分離）、EC2の増減が自由になる。
graph LR
subgraph "❌ 密結合（Tightly Coupled）"
A[Web Server] -->|直接API呼出| B[Worker Server]
end
subgraph "✅ 疎結合（Loosely Coupled）"
C[Web Server] -->|メッセージ送信| D((SQS Queue))
D -->|ポーリング| E[Worker Server]
end
style D fill:#f96,stroke:#333🗝 3. キーワードでの判断
| 問題文のキーワード | 疑うサービス・構成 |
|---|---|
| 🧩 「コンポーネントの分離」「疎結合化」 | Amazon SQS, Amazon SNS |
| 🛡️ 「スパイクの吸収」「ピーク負荷の緩和」 | Amazon SQS (キューイング) |
| 📢 「複数のシステムへ同時に通知」 | Amazon SNS (Fan-out), EventBridge |
| 🚪 「バックエンドの変更を隠蔽したい」 | API Gateway, ELB |
⚠️ 4. ひっかけポイント
🚫 よくある誤答パターン – 「EC2のスペックを上げる（垂直スケーリング）」 → 負荷対策にはなるが「疎結合化」にはならない。 – 「処理を同期的に待つ」 → SAAでは、ユーザーを待たせないために 非同期処理（SQSに投げてすぐ返す） が推奨される。
💡 5. 覚え方
🧠 暗記ショートカット – 密結合 = 「手渡し」 → 相手が不在だと渡せない。相手が遅いと自分も待つハメになる。 – 疎結合 = 「郵便ポスト（SQS）」 → ポストに入れておけば完了。相手は好きな時に取り出せる。 – 疎結合の三銃士: SQS（キュー）, SNS（通知）, ELB（負荷分散）。
📚 6. 関連サービス
| アイコン | サービス名 | 役割 |
|---|---|---|
| 📨 | Amazon SQS | システム間にキュー（待ち行列）を挟み、非同期・疎結合を実現 |
| 📢 | Amazon SNS | 1つのメッセージを複数ターゲットへ配信（Pub/Sub） |
| 🚪 | API Gateway | フロントとバックエンドを分離するAPIのエンドポイント |
| ⚖️ | ELB | トラフィックの窓口となり、背後のサーバー群を抽象化 |
🗒️ 7. Obsidian管理メモ
- 見返すタイミング: アプリケーション統合（SQS/SNS）の学習時
- 関連ノート候補:
AWS_SAA_SQS,AWS_SAA_SNS
8. HTMLファイル名:
AWS_設計原理_疎結合.html
