[AWS] Auto Scaling: EC2 ASG, target tracking, predictive

Auto Scaling Group, ASG, Target Tracking, Step Scaling, Predictive Scaling, Scheduled Scaling

정의

Auto Scaling Group (ASG) = EC2 instance 자동 증감. desired / min / max + scaling policy.

구조

flowchart TB
    ASG[Auto Scaling Group<br/>min=2, max=20, desired=5]
    ASG --> LT["Launch Template<br/>(instance type, AMI, SG, ...)"]
    ASG --> Tg["Target Group<br/>(ALB/NLB)"]
    ASG --> Az[Multi-AZ<br/>az-a, az-b, az-c]
    ASG --> Policy[Scaling Policy]
    Policy --> TT[Target Tracking]
    Policy --> Step[Step]
    Policy --> Sched[Scheduled]
    Policy --> Pred[Predictive]

Scaling Policy 4종

1. Target Tracking (권장)

TargetTrackingConfiguration:
  PredefinedMetricSpecification:
    PredefinedMetricType: ASGAverageCPUUtilization
  TargetValue: 50.0

“CPU 평균 50% 유지하도록 알아서 증감”.

2. Step Scaling

CPU 70-80% → +1
CPU 80-90% → +2
CPU 90%+   → +5

세밀 제어. 복잡.

3. Scheduled

# 매일 오전 9시에 desired=10
aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name web \
  --schedule "cron(0 9 * * ? *)" \
  --desired-capacity 10

예측 가능한 트래픽 (예: 직장인 사용 패턴, 새벽 light).

4. Predictive Scaling

머신러닝으로 과거 패턴 예측 → 미리 증가. AWS managed.

Lifecycle

sequenceDiagram
    ASG->>EC2: Launch
    EC2->>EC2: bootstrap (UserData)
    EC2->>ALB: 등록
    Note over ALB,EC2: ALB health check
    ALB-->>ASG: in service
    Note over ASG: 정상 동작
    ASG->>EC2: Terminate (scale-in)
    EC2->>ALB: deregister
    Note over EC2: graceful shutdown<br/>(connection draining)
    EC2->>EC2: stop

Lifecycle Hooks

LifecycleHook:
  LifecycleTransition: autoscaling:EC2_INSTANCE_LAUNCHING
  HeartbeatTimeout: 300
  NotificationTargetARN: arn:aws:sns:...

• Launching: instance 시작 직후, 트래픽 받기 전. 데이터 워밍업, init.
• Terminating: terminate 직전. log flush, draining.

Cooldown vs Warmup

	Cooldown	Warmup
의미	다음 scaling 까지 대기	instance 가 준비되기 까지
기본	300s	0 (Target Tracking 자동)

ASG + Spot

MixedInstancesPolicy:
  InstancesDistribution:
    OnDemandBaseCapacity: 2          # 최소 on-demand
    OnDemandPercentageAboveBaseCapacity: 25
    SpotAllocationStrategy: capacity-optimized-prioritized
  LaunchTemplate:
    Overrides:
      - InstanceType: m6i.large
      - InstanceType: m6a.large
      - InstanceType: m6g.large

2 on-demand 보장 + 나머지 70% spot 비용 절감.

EC2 Auto Scaling vs Application Auto Scaling

항목	EC2 ASG	Application Auto Scaling
대상	EC2 인스턴스	ECS Task, DynamoDB, Aurora, Lambda, AppStream 등
정책 유형	동일 (Target Tracking, Step, Scheduled, Predictive)	동일
스케일 단위	인스턴스 수	Task 수 / 용량 단위
설정 위치	EC2 ASG 콘솔/API	Application Auto Scaling API

Application Auto Scaling 예시 (ECS)

# ECS 서비스에 스케일링 대상 등록
aws application-autoscaling register-scalable-target \
  --service-namespace ecs \
  --resource-id service/my-cluster/my-service \
  --scalable-dimension ecs:service:DesiredCount \
  --min-capacity 2 \
  --max-capacity 20

# Target Tracking 정책 (CPU 60% 유지)
aws application-autoscaling put-scaling-policy \
  --service-namespace ecs \
  --resource-id service/my-cluster/my-service \
  --scalable-dimension ecs:service:DesiredCount \
  --policy-name cpu-target-tracking \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ECSServiceAverageCPUUtilization"
    },
    "TargetValue": 60.0,
    "ScaleInCooldown": 300,
    "ScaleOutCooldown": 60
  }'

Warm Pool

Warm Pool = 미리 준비된 인스턴스 풀. Scale-out 응답 속도를 대폭 단축.

flowchart LR
    Pool["Warm Pool\n(Stopped/Running)"]
    ASG["Active ASG"]
    Demand["트래픽 증가"]
    Cold["Cold Launch\n(2-5분)"]
    Demand -->|Scale-out 트리거| ASG
    Pool -->|"즉시 이동 (30초)"| ASG
    ASG -->|"Warm Pool 부족 시"| Cold

WarmPoolConfiguration:
  MinSize: 2
  MaxGroupPreparedCapacity: 5
  PoolState: Stopped   # Stopped or Running
  InstanceReusePolicy:
    ReuseOnScaleIn: true

• Stopped 상태: 비용 절감 (스토리지만 과금), 30-60초 내 ready
• Running 상태: 즉시 ready (최대 수초), 인스턴스 비용 발생
• ReuseOnScaleIn: true: Scale-in 시 인스턴스를 Warm Pool 로 반환 (삭제 아님)

Instance Refresh

AMI 업데이트, 시작 템플릿 변경 시 기존 인스턴스를 롤링 방식으로 교체:

aws autoscaling start-instance-refresh \
  --auto-scaling-group-name web-asg \
  --preferences '{
    "MinHealthyPercentage": 80,
    "InstanceWarmup": 300,
    "CheckpointPercentages": [20, 50, 100],
    "CheckpointDelay": 600
  }'

• MinHealthyPercentage: 80 = 항상 80% 이상 healthy 유지하며 교체
• Checkpoint 로 단계별 진행, 검증 후 다음 단계
• 문제 발생 시 cancel-instance-refresh 로 중단

Health Check 유형

유형	감지 범위	설정
EC2 Health Check	인스턴스 상태 (stopped, terminated)	기본값
ELB Health Check	ALB/NLB 가 HTTP 응답 확인	HealthCheckType: ELB
Custom Health Check	외부 시스템에서 unhealthy 표시	set-instance-health API

# ALB Health Check 활성화
aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name web-asg \
  --health-check-type ELB \
  --health-check-grace-period 300

스케일링 정책 선택 가이드

flowchart TD
    Q1{"트래픽 패턴 예측 가능?"}
    Q1 -->|"예, 주기적"| Sched[Scheduled Scaling]
    Q1 -->|"예, 추세"| Pred[Predictive Scaling]
    Q1 -->|아니오| Q2{"세밀한 단계 제어?"}
    Q2 -->|예| Step["Step Scaling\n단계별 +N 인스턴스"]
    Q2 -->|아니오| TT["Target Tracking\n(권장 기본값)"]
    TT --> Metric{"지표 선택"}
    Metric --> CPU["CPU 평균 70%"]
    Metric --> ALB["ALB 요청당 처리 목표"]
    Metric --> Custom["Custom CloudWatch 지표"]

정책	추천 상황
Target Tracking	대부분의 웹 서버, API 서버
Step Scaling	갑작스런 트래픽 스파이크, 세밀한 제어 필요
Scheduled	영업시간 패턴, 배치 작업 전후
Predictive	ML 워크로드, 주기적 대용량 처리

비용 최적화

ASG + Spot 혼합 전략

MixedInstancesPolicy:
  InstancesDistribution:
    OnDemandBaseCapacity: 2
    OnDemandPercentageAboveBaseCapacity: 20
    SpotAllocationStrategy: capacity-optimized-prioritized
    SpotInstancePools: 3
  LaunchTemplate:
    LaunchTemplateSpecification:
      LaunchTemplateName: web-lt
      Version: "$Latest"
    Overrides:
      - InstanceType: m7i.large
      - InstanceType: m7a.large
      - InstanceType: m7g.large
      - InstanceType: m6i.large

비용 효과: On-Demand 100% 대비 최대 70% 절감. On-Demand 2개 보장으로 안정성 확보.

Predictive Scaling 비용 효과

Predictive Scaling 은 피크 전에 미리 증가하므로:

• 피크 초반 성능 저하 없음
• Cooldown 지연 없이 최적 용량 유지

흔한 함정

관련 위키

• aws-ec2
• aws-ec2-instance-types
• aws-alb-nlb
• aws-cloudwatch
• k8s-hpa-vpa (K8s 버전)
• Load Balancer