Auto Scaling Groups (ASG) とは
Amazon EC2 の台数を需要に合わせて自動で増減させる仕組み
アプリケーションの可用性を高めつつ、コスト最適化が可能。
ASG = 「EC2インスタンスの集合を、ポリシーに基づいて自動管理する仕組み」
ASGの主要コンポーネント
-
Launch Template / Launch Configuration
- EC2の起動設定（AMI, インスタンスタイプ, セキュリティグループ, キーペアなど）
- Launch Configuration は古い仕組み、現在は Launch Template 推奨
-
Minimum / Desired / Maximum Capacity
- 最小数 (min)：必ず確保するインスタンス数
- 希望数 (desired)：通常維持するインスタンス数（デフォルトの稼働数）
- 最大数 (max)：スケールアウトできる上限
- 希望数 (desired)から始まり、負荷状況に応じて最小数 (min)～最大数 (max)まで変化
-
Scaling Policies（スケーリングポリシー）
- ターゲット追跡スケーリング：例）CPU利用率50%を維持するよう自動調整
- ステップスケーリング：閾値を超えた度合いに応じて台数増減
- スケジュールスケーリング：曜日・時間指定で台数変更
- 手動スケーリング：運用者が直接指定
-
Health Check
- インスタンスの死活監視（EC2ステータスチェック、またはELB経由）
- ASGはELBでunhelthyと判断されたインスタンスを終了することができる
- 新規追加されたEC2は自動でターゲットグループに追加され、ELBのヘルスチェック対象になる
- 異常があれば自動的にインスタンスを置き換える
- インスタンスの死活監視（EC2ステータスチェック、またはELB経由）
-
ELB（ロードバランサー）との連携
- ASGでスケーリングしたインスタンスを、ALB/NLBに自動登録可能
- 高可用性アーキテクチャを実現
動作の流れ
スケールイン/スケールアウト
- Desired=2、Min=2、Max=4 のASGを設定
- CPU使用率が70%超 → CloudWatch Alarm発火
- ASGがScaling Policyに従って1台追加（EC2合計3台）
- 負荷が下がれば自動でスケールイン（EC2を削除）
ELB + Auto Scaling
- ALB
- ALB がターゲットグループの EC2 に対してヘルスチェックを実行
- 判定条件：指定回数の連続成功/失敗（例：2回失敗で「unhealthy」） - ALB が「Unhealthy」判定をターゲットグループに反映、このEC2インスタンスへのリクエストは停止
- ASG が ALB の状態を参照して自動的に終了＆新しいインスタンスを起動
- ALB がターゲットグループの EC2 に対してヘルスチェックを実行
- NLB
- NLB がターゲットグループの EC2 に対して TCP レベルのヘルスチェックを実施
- TCP接続に応答しないインスタンスは「Unhealthy」にターゲットグループの状態を更新
- 厳密に実施する場合は「CloudWatch Alarm + ASG」のヘルスチェック連携
その他
- ASG Default Termination Policy
- スケールインする際はインスタンスが最も多いAZ内から起動テンプレートが最も古いものを削除
- ASGライフサイクルフック
- 起動時や終了時をフックに何かしらの処理を実施できる
ポイント
-
ASGは可用性＋コスト最適化の要
-
スケーリングの種類を区別できることが重要
- ターゲット追跡（もっとも一般的）
- ステップスケーリング（閾値ごとに増減）
- スケジュール（時間指定）
-
ELBと組み合わせてヘルスチェック → 自動リカバリ
-
Multi-AZに配置して耐障害性を確保するのがベストプラクティス
まとめる
ASGは「EC2インスタンスの台数を需要に合わせて自動調整するサービス」であり、スケーリングポリシーの種類や、ELBとの連携による高可用性が試験でよく問われます。