【スケーラビリティの役割（設計のベストプラクティス）】
目次
🔍 1. 結論
💎 一言でいうと スケーラビリティは 需要に応じてリソースを動的に増減させる能力 であり、AWS設計原理 「キャパシティの予測を排除する（Stop guessing capacity）」 の核心です。必要な時に必要な分だけリソースを確保することで、パフォーマンス維持とコスト最適化を両立します。
- 水平スケーリング（Scale-out） と ステートレス設計 の組み合わせが SAA の正解パターン
- Auto Scaling + ELB がセットで出題される
- 問題文に「急激なスパイク」「予測困難な負荷」が出たら → スケーラビリティ関連を疑う
📈 2. SAAで出やすいポイント
- 水平スケーリング（Scale-out/In） = インスタンスの
台数 を増減
- ✅ 無制限に近い拡張性、高可用性
- ⚠️ ステートレス設計が前提
- 垂直スケーリング（Scale-up/Down） = インスタンスの
スペック を変更
- ❌ 拡張に限界があり、変更時にダウンタイムが発生しやすい
- ステートレス設計: セッション情報を ElastiCache や DynamoDB に外出しし、どのサーバーでも同じ応答を返せるようにする
graph LR
subgraph "⬆️ 垂直スケーリング"
V1["🖥️ t3.micro"] -->|スペック増強| V2["🖥️ m5.xlarge"]
end
subgraph "➡️ 水平スケーリング（推奨）"
H1["🖥️ 1台"] --> H2["🖥️🖥️🖥️ 3台"]
H2 --> H3["🖥️×5台..."]
end
style V2 fill:#f96,stroke:#333
style H2 fill:#6cf,stroke:#333
style H3 fill:#6cf,stroke:#333🗝 3. キーワードでの判断
| 問題文のキーワード | 疑うサービス・構成 |
|---|---|
| ⚡ 「急激なスパイク」「トラフィック急増」 | Auto Scaling, CloudFront |
| 💰 「コスト効率よくスケーリング」 | Auto Scaling（不要時は台数削減） |
| 🧱 「ダウンタイムなしで拡張」 | 水平スケーリング + ELB |
| 🔄 「セッション維持」 | ElastiCache / DynamoDB（セッション外出し） |
⚠️ 4. ひっかけポイント
🚫 よくある誤答パターン – 「最強のインスタンスに変更する」 → 垂直スケーリングは SAA では基本的に 不正解。水平を探す。 – DBがボトルネック: Web層だけスケールしても DB が限界になる → リードレプリカ or Aurora Serverless。
💡 5. 覚え方
🧠 暗記ショートカット – 水平 = 「友達を増やす」 → 台数増加。高可用性。 – 垂直 = 「筋トレする」 → 一人でデカくなるが限界あり、着替え（再起動）が必要。 – 正解パターン = 「Auto Scaling + ELB + ステートレス」。
📚 6. 関連サービス
| アイコン | サービス名 | 役割 |
|---|---|---|
| ⚖️ | ELB | 増えたサーバーへ負荷を均等に配布 |
| 📈 | Auto Scaling | メトリクスを見て自動で台数を調整 |
| ⚡ | Lambda | リクエストに応じて自動でスケール |
🗒️ 7. Obsidian管理メモ
- 見返すタイミング: Auto Scaling の学習時
- 関連ノート候補:
AWS_SAA_Auto_Scaling,AWS_SAA_ELB,AWS_SAA_Stateless
8. HTMLファイル名:
AWS_設計原理_スケーラビリティ.html
