Auto Scaling 정책: Target Tracking vs Step vs Scheduled, 언제 무엇을 사용할까?

핵심 요약 (BLUF)

대부분의 경우 Target Tracking을 사용하세요. 목표 지표(예: CPU 50%)를 설정하면 자동으로 인스턴스 수를 조정합니다. Step Scaling은 경보 크기에 따른 단계별 대응, Scheduled Scaling은 예측 가능한 트래픽 패턴, Predictive Scaling은 ML 기반 사전 확장에 사용합니다.

시험 팁

시험 핵심: Target Tracking = 가장 권장 + 자동, Step = 단계별 + CloudWatch 경보, Scheduled = 예약 + 알려진 패턴, Predictive = ML + 사전 확장

Auto Scaling 그룹이란?

Auto Scaling 그룹(ASG)은 동일한 설정의 EC2 인스턴스 모음으로, 트래픽에 따라 자동으로 인스턴스 수를 조정합니다.

Auto Scaling 그룹 구조:

         ┌─────────────────────────────────────┐
         │        Auto Scaling Group           │
         │                                     │
         │   최소: 2  │  희망: 4  │  최대: 10   │
         │                                     │
         │  ┌───┐ ┌───┐ ┌───┐ ┌───┐          │
         │  │EC2│ │EC2│ │EC2│ │EC2│  ← 현재 4개 │
         │  └───┘ └───┘ └───┘ └───┘          │
         └─────────────────────────────────────┘
                        ↑
              조정 정책이 인스턴스 수 결정

ASG 핵심 설정

설정	설명
최소 용량 (Min)	항상 유지할 최소 인스턴스 수
희망 용량 (Desired)	현재 목표 인스턴스 수
최대 용량 (Max)	확장 가능한 최대 인스턴스 수

Auto Scaling 정책 유형 한눈에 비교

정책 유형	작동 방식	적합한 상황	복잡도
Target Tracking	목표 지표 자동 유지	대부분의 경우 (권장)	낮음
Step Scaling	경보 크기별 단계 대응	세밀한 제어 필요	중간
Simple Scaling	단일 조정 + 쿨다운	단순한 요구사항	낮음
Scheduled Scaling	예약된 시간에 조정	예측 가능한 패턴	낮음
Predictive Scaling	ML 기반 사전 확장	주기적 트래픽 패턴	낮음

Target Tracking Scaling (대상 추적 조정)

작동 방식

Target Tracking은 온도 조절기처럼 작동합니다. 목표 지표(예: CPU 50%)를 설정하면 Auto Scaling이 자동으로 인스턴스 수를 조정하여 해당 값을 유지합니다.

Target Tracking 작동 예시:

목표: CPU 사용률 50%

현재 CPU 70% → 인스턴스 추가 (스케일 아웃)
현재 CPU 30% → 인스턴스 제거 (스케일 인)
현재 CPU 50% → 유지

지원 지표

사전 정의 지표:

ASGAverageCPUUtilization - 평균 CPU 사용률
ASGAverageNetworkIn - 평균 네트워크 수신량
ASGAverageNetworkOut - 평균 네트워크 송신량
ALBRequestCountPerTarget - ALB 대상당 요청 수

사용자 정의 지표:

애플리케이션별 CloudWatch 지표 사용 가능

Target Tracking 장점

간단한 설정: 목표 값만 지정
자동 CloudWatch 경보: 경보 자동 생성/관리
점진적 스케일 인: 가용성 우선 보장
적응형 조정: 트래픽 패턴에 자동 적응

시험 팁

시험 포인트: Target Tracking은 스케일 인 시 보수적으로 동작합니다. 트래픽 변동 시 가용성을 우선 보장하기 위해 점진적으로 인스턴스를 제거합니다.

Target Tracking 적합한 경우

대부분의 웹 애플리케이션
CPU/네트워크 기반 워크로드
ALB 뒤의 애플리케이션
단순하고 효과적인 스케일링 필요

Step Scaling (단계별 조정)

작동 방식

Step Scaling은 경보 위반 크기에 따라 다른 조정을 수행합니다. CloudWatch 경보를 먼저 생성하고, 경보 심각도에 따른 단계별 조정을 정의합니다.

Step Scaling 단계 예시:

CloudWatch 경보: CPU 사용률

CPU 50-60%  → 인스턴스 2개 추가
CPU 60-75%  → 인스턴스 4개 추가
CPU 75-90%  → 인스턴스 6개 추가
CPU > 90%   → 인스턴스 10개 추가

Step Scaling vs Target Tracking

항목	Target Tracking	Step Scaling
경보 관리	자동	수동
조정 크기	자동 계산	단계별 지정
스케일 인	보수적 (점진적)	즉각적
설정 복잡도	낮음	중간
세밀한 제어	제한적	가능

Step Scaling 적합한 경우

부하 크기에 따라 다른 대응이 필요한 경우
빠른 스케일 인이 필요한 경우
세밀한 조정 제어가 필요한 경우
Target Tracking과 혼합 사용 (고급)

Simple Scaling (단순 조정)

작동 방식

Simple Scaling은 경보 발생 시 고정된 양만큼 조정하고, 쿨다운 기간 동안 추가 조정을 차단합니다.

Simple Scaling 작동:

경보 발생 → 인스턴스 2개 추가 → 쿨다운 (300초) → 추가 조정 가능
                                    ↑
                            이 기간 동안 조정 차단

Simple Scaling의 한계

쿨다운 중 급격한 트래픽 증가에 대응 불가
Step Scaling보다 유연성 부족
AWS는 Step Scaling 또는 Target Tracking 권장

시험 팁

시험 포인트: Simple Scaling은 쿨다운(Cooldown) 기간이 있어 연속 조정이 불가능합니다. 빠른 대응이 필요하면 Step Scaling을 사용하세요.

Scheduled Scaling (예약 조정)

작동 방식

Scheduled Scaling은 예측 가능한 트래픽 패턴에 따라 미리 정해진 시간에 용량을 조정합니다.

Scheduled Scaling 예시:

매주 월-금:
  08:00 → 최소 용량 10개로 증가 (업무 시작)
  20:00 → 최소 용량 2개로 감소 (업무 종료)

매주 토-일:
  종일 → 최소 용량 2개 유지

Scheduled Scaling 적합한 경우

정해진 업무 시간 패턴
예정된 마케팅 이벤트
배치 처리 시간대
알려진 트래픽 피크 시간

설정 예시

일정: 매일 오전 8시
Min: 5, Max: 20, Desired: 10

일정: 매일 오후 8시
Min: 2, Max: 10, Desired: 2

Predictive Scaling (예측 조정)

작동 방식

Predictive Scaling은 머신 러닝을 사용하여 과거 트래픽 패턴을 분석하고, 미래 용량을 예측하여 사전에 확장합니다.

Predictive Scaling 작동:

과거 2주 데이터 분석
        ↓
일별/주별 패턴 학습
        ↓
향후 2일 수요 예측
        ↓
트래픽 증가 전 사전 확장

Predictive Scaling 특징

과거 데이터 필요: 최소 24시간 (권장: 14일)
예측 주기: 매일 업데이트, 향후 2일 예측
동적 스케일링과 병용: Target Tracking과 함께 사용 가능

Predictive Scaling 적합한 경우

주기적 트래픽 패턴 (업무 시간, 주말 패턴)
반복적인 온/오프 워크로드
초기화 시간이 긴 애플리케이션
사전 확장으로 지연 시간 최소화 필요

시험 팁

시험 포인트: Predictive Scaling은 신규 애플리케이션에 부적합합니다. 최소 24시간의 과거 데이터가 필요하며, 충분한 데이터가 없으면 예측 정확도가 떨어집니다.

조정 정책 조합 사용

권장 조합

1. Target Tracking + Predictive Scaling

Predictive: 예측된 트래픽에 맞춰 사전 확장
Target Tracking: 예측과 다른 실제 부하에 대응

2. Target Tracking + Scheduled Scaling

Scheduled: 알려진 이벤트 시 용량 증가
Target Tracking: 이벤트 중 실제 부하에 따른 추가 조정

3. Target Tracking (스케일 아웃) + Step Scaling (스케일 인)

Target Tracking: 부하 증가 시 부드러운 확장
Step Scaling: 부하 감소 시 빠른 축소

여러 정책 충돌 시 동작

스케일 아웃: 가장 큰 용량을 제공하는 정책 우선
스케일 인: 가장 많은 인스턴스를 유지하는 정책 우선

→ 항상 가용성을 우선시함

시나리오별 정책 선택

시나리오 1: 일반 웹 애플리케이션

요구사항: CPU 기반 자동 확장
권장: Target Tracking (CPU 50%)
이유: 간단하고 효과적, 대부분의 경우 충분

시나리오 2: 전자상거래 블랙프라이데이

요구사항: 예정된 대규모 트래픽 급증
권장: Scheduled Scaling + Target Tracking
이유: 이벤트 전 사전 확장 + 실제 부하 대응

시나리오 3: 콜센터 애플리케이션

요구사항: 업무 시간(9-6시) 트래픽 패턴
권장: Predictive Scaling + Target Tracking
이유: ML로 패턴 학습 + 예외 상황 대응

시나리오 4: 게임 서버 (급격한 부하 변동)

요구사항: 부하 크기에 따른 빠른 대응
권장: Step Scaling
이유: 단계별로 다른 크기의 조정 가능

시나리오 5: 배치 처리

요구사항: 매일 새벽 2시 대규모 처리
권장: Scheduled Scaling
이유: 처리 시작 전 용량 확보, 완료 후 축소

ASG 헬스 체크

Auto Scaling은 비정상 인스턴스를 자동으로 교체합니다.

헬스 체크 유형

유형	확인 대상	사용 시점
EC2	EC2 인스턴스 상태	기본값
ELB	로드밸런서 헬스 체크	ELB 사용 시 권장
Custom	외부 헬스 체크 시스템	고급 시나리오

시험 팁

시험 포인트: ELB와 함께 사용할 때는 ELB 헬스 체크를 활성화하세요. EC2 헬스 체크만으로는 애플리케이션 수준의 문제를 감지하지 못합니다.

비용 최적화 팁

1. 적절한 최소 용량 설정

평상시 부하를 처리할 수 있는 최소 인스턴스 수
너무 높으면 비용 낭비, 너무 낮으면 시작 지연

2. 스팟 인스턴스 혼합

혼합 인스턴스 정책으로 스팟 + 온디맨드 조합
비용 절감과 가용성 균형

3. 인스턴스 워밍업 시간 설정

새 인스턴스가 부하를 받을 준비가 될 때까지 대기
불필요한 추가 확장 방지

SAA-C03 시험 출제 포인트

✅ 정책 선택: 대부분 Target Tracking 권장, 세밀한 제어는 Step Scaling
✅ Simple vs Step: Simple은 쿨다운 있음, Step은 즉각 대응
✅ Predictive Scaling: ML 기반, 최소 24시간 데이터 필요
✅ Scheduled Scaling: 예측 가능한 패턴에 사전 대응
✅ 헬스 체크: ELB 사용 시 ELB 헬스 체크 활성화
✅ 다중 정책 충돌: 가용성 우선 (최대 용량 정책 적용)

시험 팁

시험 문제 예시: "웹 애플리케이션의 평균 CPU 사용률을 60%로 유지하면서 자동으로 확장/축소하려고 합니다. 가장 적합한 Auto Scaling 정책은?" → 정답: Target Tracking Scaling (목표 지표 자동 유지, 권장 정책)