[Cloud Computing] Auto Scaling
AutoScaling
트래픽이 몰릴 때 늘리고, 한산할 때 줄이는 것. 개념과 동작 원리부터 정책 종류, AWS ASG, Kubernetes HPA·KEDA까지.
| Category | Level | Reads | Status |
|---|---|---|---|
| Cloud Computing · Compute | 초급 ~ 중급 | 약 14분 | VERIFIED |
오토스케일링이란?
오토스케일링은 트래픽·부하에 맞춰 컴퓨팅 자원을 자동으로 늘리고 줄이는 기능이다.
식당에 비유하면 쉽다. 손님이 몰리는 점심시간엔 알바를 더 부르고, 한산한 오후엔 몇 명만 남기고 돌려보낸다. 사람이 매번 판단해서 전화를 돌리는 대신, "홀에 손님이 20명 넘으면 자동으로 한 명 더 부른다"는 규칙을 미리 정해두는 것 — 그게 오토스케일링이다.
왜 필요한가
수동으로 서버를 늘리고 줄이던 시절엔 두 가지 실패 중 하나였다. 넉넉하게 잡으면 트래픽이 없는 시간에도 서버 비용이 그대로 나가고, 빠듯하게 잡으면 갑자기 트래픽이 몰릴 때 서버가 못 버티고 장애가 난다.
클라우드의 "쓴 만큼만 낸다(Pay-as-you-go)" 모델은 오토스케일링과 만났을 때 진짜 힘을 발휘한다. 필요한 순간에만 자원을 켜고, 필요 없어지면 곧바로 끄면서 비용과 안정성을 동시에 잡을 수 있다.
동작 원리
CPU 사용률, 요청 수, 큐에 쌓인 메시지 수 같은 지표를 계속 모니터링한다.
미리 설정한 스케일링 정책(예: "CPU 70% 넘으면 확장")과 지금 상태를 비교한다.
조건을 넘으면 인스턴스를 새로 띄우거나(Scale Out), 남으면 종료한다(Scale In).
바로 다음 판단으로 넘어가지 않고 일정 시간 대기해서, 너무 자주 늘었다 줄었다 하는 걸 막는다.
스케일링이 일어난 뒤 다음 스케일링 판단까지 기다리는 대기 시간. 새로 뜬 인스턴스가 지표에 반영되기 전에 또 스케일링이 일어나는 걸 막아준다.
스케일링 방식 — 4가지를 하나씩
오토스케일링은 두 개의 축으로 움직인다. "몇 대로 할 것인가"(개수, 수평)와 "한 대를 얼마나 강하게 할 것인가"(사양, 수직). 이 두 축의 방향마다 각각 이름이 따로 있다.
인스턴스의 개수를 늘리는 것. 서버 한 대를 더 세우는 방식이다. 예: 웹서버 2대로 부족해서 5대로 늘림.
클라우드에서 가장 흔히 쓰는 방향이다. 대수를 늘리는 데 이론상 한계가 거의 없고, 한 대가 죽어도 나머지가 버텨주는 장애 격리 효과도 있다.
인스턴스의 개수를 줄이는 것. Scale Out의 반대. 예: 트래픽이 빠져서 5대였던 서버를 다시 2대로 줄임.
불필요해진 인스턴스를 종료해서 비용을 절감한다. 이때 아직 처리 중인 요청이 있는 인스턴스부터 종료하지 않도록 하는 "연결 드레이닝" 같은 안전장치가 함께 쓰인다.
인스턴스 한 대의 사양(CPU·메모리)을 올리는 것. 예: t3.medium(2 vCPU) → t3.xlarge(4 vCPU)로 인스턴스 타입 변경.
대수는 그대로 두고 "더 힘센 서버 한 대"로 바꾸는 방식이다. 대부분 인스턴스 재시작이 필요해서 그 순간 짧은 다운타임이 생기기 쉽다. 그래서 자동화보다는 계획된 변경으로 쓰이는 경우가 많다.
인스턴스 한 대의 사양을 낮추는 것. Scale Up의 반대. 예: 과도하게 큰 스펙으로 운영 중이던 서버를 realistic한 크기로 축소.
보통 "필요 이상으로 크게 잡았던 자원을 realistic하게 되돌린다"는 비용 최적화 목적으로, 자동보다는 주기적인 사용량 분석 후 수동으로 진행하는 경우가 흔하다.
스케일링 정책 종류
| 정책 종류 | 동작 방식 |
|---|---|
| Target Tracking | "CPU 평균 50% 유지"처럼 목표값을 정하면 알아서 개수를 조절 |
| Step Scaling | 지표 초과 정도에 따라 단계적으로 늘리는 양을 다르게 설정 |
| Scheduled Scaling | 매일 점심시간처럼 예측 가능한 시간대에 미리 정한 대수로 조정 |
| Predictive Scaling | 과거 트래픽 패턴을 머신러닝으로 학습해 사전에 미리 확장 |
목표 지표값만 정해두면 나머지는 알아서 계산해주는 가장 널리 쓰이는 정책. 온도조절기가 설정 온도만 맞추면 알아서 냉난방을 조절하는 것과 같은 원리다.
장단점
- 트래픽 변화에 자동으로 대응해 장애 위험을 줄임
- 불필요한 유휴 자원을 없애 비용을 절감
- 사람이 밤새 대기하며 수동 대응할 필요가 없음
- 정책을 잘못 잡으면 늘었다 줄었다를 반복하는 진동(Thrashing) 발생
- 새 인스턴스가 뜨는 데 걸리는 웜업 시간 동안은 여전히 부하가 걸림
- 상태(세션 데이터 등)를 인스턴스에 저장하는 서비스는 확장·축소가 까다로움
EC2 Auto Scaling
Auto Scaling Group(ASG)이 핵심이다. 최소·희망·최대 인스턴스 수를 정해두면, ASG가 그 범위 안에서 지표에 따라 인스턴스를 자동으로 늘리고 줄인다. 새 인스턴스를 어떤 이미지·사양으로 띄울지는 Launch Template에 미리 정의해둔다.
EC2뿐 아니라 Application Auto Scaling은 ECS, DynamoDB, Lambda 동시성 등 EC2가 아닌 다른 AWS 리소스에도 같은 방식의 오토스케일링을 적용할 수 있게 해준다.
새 인스턴스를 띄울 때 사용할 AMI(이미지), 인스턴스 타입, 보안 그룹 등을 미리 정의해둔 설정. ASG는 스케일 아웃할 때마다 이 템플릿을 그대로 복제해서 새 인스턴스를 만든다.
Kubernetes 환경의 오토스케일링
| 도구 | 무엇을 조절하나 |
|---|---|
| HPA | Pod의 개수를 CPU·메모리 등 지표 기준으로 자동 조절 (Scale Out/In) |
| VPA | Pod 하나의 CPU·메모리 할당량을 자동 조절 (Scale Up/Down) |
| Cluster Autoscaler | Pod를 놓을 자리가 부족하면 노드(서버) 자체를 자동으로 추가 |
| KEDA | CPU·메모리뿐 아니라 큐 길이, 메시지 수 같은 임의의 이벤트 지표 기준으로 확장 가능 |
실무 적용 방식
대표적인 시나리오는 세일·이벤트로 트래픽이 급증하는 경우다. 평소엔 최소 2대로 운영하다가, 요청량이 늘면 자동으로 10대, 20대까지 확장하고, 트래픽이 빠지면 다시 최소치로 돌아온다.
비용까지 고려한다면 Spot 인스턴스와 온디맨드를 섞는 전략도 흔하다. 기본 트래픽은 저렴한 Spot으로 처리하고, Spot 물량이 부족해지는 급증 구간만 온디맨드로 보충하는 식이다.
새로 뜬 인스턴스가 아직 준비 중일 때 헬스체크 실패로 오인해 바로 종료해버리지 않도록 봐주는 유예 시간. 애플리케이션 부팅 시간이 긴 서비스일수록 넉넉히 잡아야 한다.
주의할 점
- Thrashing(진동) — 임계치를 너무 타이트하게 잡으면 늘었다 줄었다를 반복하며 오히려 불안정해진다. 쿨다운과 여유 있는 임계치 설정이 중요하다.
- 웜업 시간 — 인스턴스가 뜨는 데 몇 분씩 걸린다면, 급격한 트래픽 폭증엔 대응이 늦을 수 있다. Warm Pool(미리 대기시켜둔 인스턴스)로 보완하기도 한다.
- 상태 유지 서비스 — 세션이나 데이터를 인스턴스 내부에 저장하면 스케일 인 될 때 데이터가 사라진다. 상태는 가능한 한 외부(DB, Redis 등)로 분리해야 오토스케일링이 안전해진다.
실제 트래픽을 받기 전 단계까지 미리 준비시켜둔 대기 인스턴스 풀. 스케일 아웃 시 처음부터 부팅하는 대신 이미 준비된 인스턴스를 바로 투입해 응답 속도를 높인다.