트래픽이 몰릴 때 서버가 죽고, 한가할 때 비싼 인스턴스가 그대로 돌아간다면 둘 다 손해입니다. **오토스케일링(Auto Scaling)**은 부하에 따라 인스턴스 수를 자동으로 늘리고 줄여, 가용성과 비용을 동시에 잡는 장치입니다. 다만 "켜두면 알아서 된다"가 아니라, 무엇을 기준으로 언제 얼마나 늘릴지를 직접 설계해야 제대로 동작합니다.
오토스케일링을 이루는 요소
| 요소 | 역할 |
|---|---|
| 최소/최대/희망 용량 | 인스턴스 수의 하한·상한·기준값 |
| 메트릭 | 스케일 판단 기준 (CPU·메모리·요청 수·큐 길이) |
| 정책 | "메트릭이 X면 Y만큼 조정"하는 규칙 |
| 쿨다운 | 한 번 조정 후 다음 조정까지 기다리는 시간 |
예를 들어 최소 2, 최대 10, CPU 60% 목표로 잡으면, 평균 CPU가 60%를 넘으면 인스턴스를 늘리고 한참 밑돌면 줄입니다.
스케일링 방식 구분
| 방식 | 동작 | 적합한 상황 |
|---|---|---|
| 대상 추적(Target Tracking) | 메트릭을 목표값에 맞춰 자동 조절 | 대부분의 일반 웹 서비스 |
| 단계 조정(Step Scaling) | 임계 구간별로 증감 폭 지정 | 부하 패턴이 단계적일 때 |
| 예약(Scheduled) | 시간 기준으로 미리 증감 | 출퇴근·세일처럼 예측 가능한 피크 |
가장 무난한 출발점은 대상 추적입니다. CPU 50~60% 같은 목표 하나만 정하면 나머지는 알아서 맞춰줍니다.
설정 시 흔한 함정
- 쿨다운을 너무 짧게 — 인스턴스가 막 떠서 부팅 중인데 메트릭이 아직 높다고 또 늘리면, 과잉 증설(flapping)이 일어납니다. 인스턴스 준비 시간보다 쿨다운을 길게 잡습니다.
- 헬스체크 유예 무시 — 새 인스턴스가 부팅을 끝내기 전에 헬스체크에 걸려 바로 종료·재생성되는 루프. 부팅 시간만큼 유예(grace period)를 줍니다.
- 메트릭 선택 실수 — CPU만 보다가, 실제 병목은 메모리나 외부 API 응답 지연인 경우. 부하의 진짜 원인을 메트릭으로 잡아야 합니다.
- 최소 용량 1 — 한 대만 두면 그 인스턴스 장애나 교체 중에 서비스가 끊깁니다. 여러 가용영역에 걸쳐 최소 2 이상을 권장합니다.
- 스케일 인 보호 누락 — 작업 처리 중인 인스턴스가 축소 대상으로 종료되면 작업이 유실됩니다.
TEXT
부하 증가 → 메트릭 임계 초과 → (쿨다운 확인) → 인스턴스 추가 → 헬스체크 통과 → LB 등록
요점 정리
- 오토스케일링은 최소/최대/메트릭/정책/쿨다운을 직접 설계해야 한다.
- 일반 서비스는 대상 추적 + CPU·요청 수 목표로 시작.
- flapping은 쿨다운과 헬스체크 유예로 막고, 최소 용량은 2 이상.
오토스케일링을 직접 구성하고 부하를 걸어 증감을 관찰하는 실습은 클라우드 트랙에서 회원가입 없이 무료로 할 수 있습니다.