오토스케일링 정책, 언제 뭘 써야 하나

트래픽은 하루 종일 균일하지 않다. 업무 시간과 심야, 평일과 주말, 블랙 프라이데이 같은 이벤트성 급증까지 감안하면 피크 시간 기준으로 서버를 항상 대기시켜 두는 건 낭비다. 오토스케일링은 이 문제를 사람이 개입하지 않고 실시간으로 풀기 위한 기능이다. CPU 사용률, 메모리, 네트워크 트래픽, 요청 수 같은 메트릭을 모니터링하다가 정의된 정책에 따라 인스턴스를 Scale Out(추가)하거나 Scale In(제거)한다.

⤢✕

왜 수평 스케일링이 기본값인가

스케일링에는 서버 개수를 늘리는 수평 스케일링(Scale Out/In)과 서버 사양 자체를 바꾸는 수직 스케일링(Scale Up/Down) 두 갈래가 있다. 수평 스케일링은 로드 밸런서만 있으면 이론상 무한히 확장할 수 있고 Stateless 애플리케이션에 잘 맞는다. 수직 스케일링은 하드웨어 상한이 있고 대체로 재시작이 필요하다는 점에서 Stateful 애플리케이션 쪽에 어울린다. 오토스케일링이 주로 수평 스케일링을 자동화 대상으로 삼는 이유는 단순하다 — 무중단으로 인스턴스를 추가·제거할 수 있고, 클라우드 인스턴스 자동화와 로드 밸런서 통합이 훨씬 쉽기 때문이다.

정책별로 언제 무엇을 쓰나

타겟 추적 스케일링(Target Tracking Scaling)은 CPU 사용률 50% 유지처럼 특정 메트릭의 목표값을 정해두고, 메트릭이 목표보다 높으면 Scale Out, 낮으면 Scale In을 자동으로 반복한다.

{
  "TargetValue": 50.0,
  "PredefinedMetricSpecification": {
    "PredefinedMetricType": "ASGAverageCPUUtilization"
  }
}

단계 스케일링(Step Scaling)은 임계값을 넘은 정도에 따라 조정 폭을 달리한다. CPU가 50~~60%면 인스턴스 1개, 60~~70%면 2개, 70% 이상이면 3개를 추가하는 식으로, 급격한 부하 변화에 세밀하게 대응할 수 있다. 예약된 스케일링(Scheduled Scaling)은 매일 오전 9시에 인스턴스를 늘리고 오후 6시에 줄이는 것처럼 예측 가능한 패턴에 맞춰 정기적으로 스케일링한다. 배치 작업처럼 부하 시점이 뻔한 경우에 알맞다. 예측 스케일링(Predictive Scaling)은 과거 트래픽 패턴을 머신러닝으로 분석해 부하가 오기 전에 미리 자원을 준비하는 방식으로, AWS가 이를 서비스로 제공한다. 부하가 실제로 몰리기 전에 대응한다는 점에서 응답 시간 개선에 유리하다.

AWS·Azure·GCP는 각자 다른 이름으로 같은 일을 한다

AWS는 Auto Scaling Group(ASG)으로 EC2 인스턴스 그룹의 최소·최대·희망 인스턴스 수를 관리하고 Health Check로 비정상 인스턴스를 자동 교체한다. ASG는 인스턴스 설정을 담은 Launch Template, 실제 스케일링 규칙인 Scaling Policy, 메트릭을 공급하는 CloudWatch, 부하를 분산하는 Elastic Load Balancer가 조합된 구조다.

최소: 2개
최대: 10개
희망: 4개
정책: CPU 평균 50% 유지

Azure는 Virtual Machine Scale Sets(VMSS)로 VM 집합을 자동 관리하며 메트릭 기반·스케줄 기반·웹훅 기반 규칙을 지원하고, App Service Autoscale은 Web App·API App을 요청 수나 응답 시간 기준으로 스케일링한다. Google Cloud는 Managed Instance Group(MIG)이 Compute Engine 인스턴스의 자동 복구와 배포를 맡고, CPU 사용률·HTTP 로드 밸런싱·Cloud Monitoring 커스텀 메트릭을 스케일링 근거로 쓴다. Autopilot GKE는 Pod 요구사항에 따라 Kubernetes 노드 자체를 자동으로 추가·제거한다.

Kubernetes는 계층별로 따로 스케일링한다

Kubernetes 환경에서는 스케일링 대상이 Pod 개수, Pod 자원, 노드 수 세 층으로 나뉜다. HPA(Horizontal Pod Autoscaler)는 CPU·메모리 사용률이나 요청 수·큐 길이 같은 커스텀 메트릭을 기준으로 ReplicaSet·Deployment·StatefulSet의 Pod 개수를 조정한다.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50

VPA(Vertical Pod Autoscaler)는 개수가 아니라 Pod 하나하나의 CPU·메모리 요청/제한을 조정한다. Off 모드는 권장 사항만 제공하고, Initial 모드는 생성 시점에 적용하며, Auto 모드는 런타임에 자동 조정하되 재시작이 필요하다. Cluster Autoscaler는 더 위 레벨에서 노드 수 자체를 늘리거나 줄인다 — Pod가 스케줄링되지 못하고 Pending 상태에 머물면 노드를 추가하고, 활용률이 낮은 노드는 Pod를 재배치한 뒤 제거한다.

⤢✕

무엇을 기준으로 스케일링할 것인가

기본 메트릭인 CPU 사용률은 가장 일반적이고 컴퓨팅 집약적 애플리케이션에 적합하며, 메모리 사용률은 캐시 서버나 데이터베이스처럼 메모리 집약적인 워크로드에, 네트워크 트래픽은 대역폭이 병목인 서비스에 쓰인다. 다만 인프라 메트릭만으로는 실제 사용자 경험을 충분히 반영하지 못할 때가 많아, 요청 수(RPS)나 응답 시간(Latency, 예: P95 목표치 유지), 메시지 큐의 큐 길이(Queue Depth), 동시 사용자 수 같은 비즈니스 특화 커스텀 메트릭을 함께 쓰는 경우가 많다.

스케일링을 안정적으로 운영하는 법

메트릭이 순간적으로 튀는 것만 보고 계속 인스턴스를 늘렸다 줄였다 하면 오히려 불안정해진다. Scale Out/In 이후 일정 시간 대기하는 Cool-down 기간과, 새 인스턴스가 트래픽을 받기 전 초기화·Health Check를 마칠 시간을 주는 Warm-up 기간이 이 진동을 막는다. 스케일 아웃은 한 번에 많은 인스턴스를 추가하기보다 단계적으로 늘려 비용 폭증과 급격한 부하 분산을 피하고, 스케일 인은 트래픽이 다시 늘어날 가능성을 감안해 더 신중하고 느리게 진행하는 게 일반적이다. 비용을 더 줄이려면 AWS Spot Instance나 Azure Low-Priority VM처럼 종료 위험이 있지만 최대 90%까지 저렴한 자원을 오토스케일링으로 보완해 쓸 수도 있다.

Stateless가 전제조건이다

세션 정보를 서버에 두지 않는 Stateless 애플리케이션은 오토스케일링에 이상적이다. 세션을 Redis나 데이터베이스 같은 외부 저장소로 빼두면 인스턴스가 제거돼도 영향이 최소화된다. 오토스케일링 그룹은 로드 밸런서와 반드시 통합돼야 하는데, 새 인스턴스는 자동으로 등록되고 Health Check를 통과하지 못하면 제거되는 흐름이 갖춰져야 한다. 이 조건이 갖춰지지 않은 Stateful 애플리케이션 — 데이터베이스나 캐시 서버 같은 — 은 오토스케일링이 어려워 수직 스케일링이나 샤딩으로 접근하는 게 일반적이다.

비용은 저절로 줄지 않는다

오토스케일링은 비용을 줄이는 기능이지만, 잘못 설정하면 정반대로 작동한다. 버그로 메트릭이 계속 임계값을 넘으면 무한 스케일 아웃이 일어날 수 있어 최대 인스턴스 수 제한과 비용 알람은 선택이 아니라 기본값으로 걸어둬야 한다. 컨테이너 이미지를 경량화하고 애플리케이션 초기화를 최소화해 새 인스턴스가 빨리 트래픽을 받게 만드는 것도, 결국 스케일 아웃 구간에서 비효율적으로 낭비되는 시간을 줄이는 실무적인 최적화다.

전자상거래는 평상시 타겟 추적으로 CPU 60%를 유지하다가 할인 이벤트 전에는 예약된 스케일링으로 미리 인스턴스를 늘리고 최대치를 넉넉히 잡아두는 조합을 쓴다. 미디어 스트리밍은 동시 시청자 수 같은 커스텀 메트릭으로 빠르게 스케일 아웃하며 CDN과 함께 운영하고, 배치 처리는 작업 시간 전 예약된 스케일링과 큐 길이 기반 조정을 함께 쓴다 — 정책 하나로 모든 상황을 처리하기보다, 워크로드 성격에 맞춰 두세 가지 정책을 겹쳐 쓰는 쪽이 실무에서는 더 흔하다.