EC2 Auto Scaling — ライフサイクルフック・スケーリングポリシー・ヘルスチェック

Auto Scalingの基本構成

Auto Scalingグループ（ASG）は「起動テンプレート（Launch Template）」とスケーリングポリシーで構成される。

設定項目:
  最小キャパシティ: 常時稼働するインスタンスの最小数
  最大キャパシティ: スケールアウト時の上限
  希望キャパシティ: 現在の目標インスタンス数
  
  希望キャパシティは最小〜最大の範囲内で自動調整される

ライフサイクルフック

インスタンスの起動・終了の特定タイミングで独自処理を挟む仕組みだ。

起動ライフサイクル:
  Pending → [ライフサイクルフック: Pending:Wait] → Pending:Proceed → InService

終了ライフサイクル:
  InService → [ライフサイクルフック: Terminating:Wait] → Terminating:Proceed → Terminated

# 起動時のライフサイクルフック（最大60分待機）
aws autoscaling put-lifecycle-hook \
  --auto-scaling-group-name my-asg \
  --lifecycle-hook-name startup-hook \
  --lifecycle-transition autoscaling:EC2_INSTANCE_LAUNCHING \
  --default-result CONTINUE \
  --heartbeat-timeout 3600 \
  --notification-target-arn arn:aws:sqs:ap-northeast-1:123456789012:startup-queue

# Lambda/SSM経由で起動処理完了を通知
import boto3

def handler(event, context):
    instance_id = event['detail']['EC2InstanceId']
    hook_name = event['detail']['LifecycleHookName']
    asg_name = event['detail']['AutoScalingGroupName']
    
    # カスタム起動処理（設定のダウンロード、APMエージェント起動等）
    perform_startup_tasks(instance_id)
    
    # 処理完了を通知（ContinueまたはABANDON）
    autoscaling = boto3.client('autoscaling')
    autoscaling.complete_lifecycle_action(
        LifecycleHookName=hook_name,
        AutoScalingGroupName=asg_name,
        LifecycleActionResult='CONTINUE',
        InstanceId=instance_id
    )

ライフサイクルフックの典型的な用途：

起動時: APMエージェントのインストール、設定ファイルのダウンロード、暖機運転
終了時: セッションの排出（ドレイニング）、ログのS3保存、クリーンアップ

スケーリングポリシーの種類

ターゲット追跡スケーリング（推奨）

# CPU使用率50%を目標にスケーリング
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name my-asg \
  --policy-name target-tracking-cpu \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "TargetValue": 50.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ASGAverageCPUUtilization"
    },
    "ScaleOutCooldown": 60,
    "ScaleInCooldown": 300
  }'

ALBのリクエスト数に基づくスケーリング：

{
  "TargetValue": 1000.0,
  "PredefinedMetricSpecification": {
    "PredefinedMetricType": "ALBRequestCountPerTarget",
    "ResourceLabel": "app/my-alb/xxx/targetgroup/my-tg/yyy"
  }
}

ステップスケーリング

メトリクスの値に応じて異なる数のインスタンスを追加/削除する。

{
  "PolicyType": "StepScaling",
  "StepAdjustments": [
    {
      "MetricIntervalLowerBound": 0,
      "MetricIntervalUpperBound": 20,
      "ScalingAdjustment": 1
    },
    {
      "MetricIntervalLowerBound": 20,
      "MetricIntervalUpperBound": 40,
      "ScalingAdjustment": 3
    },
    {
      "MetricIntervalLowerBound": 40,
      "ScalingAdjustment": 5
    }
  ]
}

スケジュールスケーリング

# 毎朝9時にスケールアウト、毎晩22時にスケールイン
aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name my-asg \
  --scheduled-action-name scale-out-morning \
  --recurrence "0 0 * * MON-FRI" \
  --min-size 10 --max-size 50 --desired-capacity 20

aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name my-asg \
  --scheduled-action-name scale-in-evening \
  --recurrence "0 13 * * MON-FRI" \
  --min-size 2 --max-size 10 --desired-capacity 2

ヘルスチェックの種類

EC2ヘルスチェック（デフォルト）:
  EC2インスタンスのステータスチェック（System + Instance）
  障害判定 → インスタンス終了・新インスタンス起動

ELBヘルスチェック:
  ロードバランサーのターゲットグループのヘルスチェック結果を使用
  アプリレベルの障害（HTTP 200以外等）でも置き換えが発生
  → アプリケーションレベルの障害に対応するにはELBヘルスチェックを使う

# ELBヘルスチェックを使用
aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name my-asg \
  --health-check-type ELB \
  --health-check-grace-period 300

ウォームアップとクールダウン

ヘルスチェックグレース期間（Health Check Grace Period）:
  新しいインスタンス起動後、ヘルスチェックを開始するまでの時間
  アプリケーションの起動に時間がかかる場合に設定（例: 300秒）

スケールインクールダウン（Scale-in Cooldown）:
  スケールイン後の次のスケーリングまでの待機時間
  短く設定 → 頻繁にスケールイン
  長く設定 → 安定性優先

スケールアウトクールダウン:
  スケールアウト後の次のスケーリングまでの待機時間

インスタンス終了の優先順位

Auto Scalingがスケールイン時にどのインスタンスを終了するかはデフォルトポリシーに従う。

デフォルト終了ポリシー:
1. 最も多くのインスタンスを持つAZを選択
2. 起動設定が最も古いインスタンスを選択
3. 同じ場合は最も新しいインスタンスを選択

カスタム終了ポリシーも設定可能（OldestInstance, NewestInstance等）。

試験頻出ポイント

シナリオ	回答
アプリ起動前にヘルスチェックが失敗する	Health Check Grace Period を延長
起動時にデータをS3からダウンロードしたい	ライフサイクルフック（Pending:Wait）
インスタンス終了前にセッションを閉じたい	ライフサイクルフック（Terminating:Wait）
予測可能なトラフィック増加に事前対応	スケジュールスケーリング
アプリレベルの障害で置き換えたい	ELBヘルスチェックを使用

まとめ

Auto Scalingはターゲット追跡スケーリングを基本とし、ライフサイクルフックでカスタム処理を組み込むことで柔軟な運用が可能だ。ヘルスチェックにはELBを使うことでアプリケーションレベルの障害対応も実現できる。

S	公式ソース確認済み
A	成功実績多数・失敗例少数
B	賛否両論
C	動作未確認・セキュリティリスク高
Z	個人所感