트래픽이 평소의 10배로 치솟는 이벤트 날, 시스템은 버텨야 하지만 평소에는 그만한 자원을 놀릴 수 없습니다. 오토스케일링은 이 모순을 해결하는 핵심 기술이지만, 잘못 설정하면 너무 늦게 늘어 장애가 나거나 너무 민감하게 출렁여 비용이 새어 나갑니다.
운영 문제: 고정 용량의 딜레마
피크에 맞춰 자원을 고정하면 평소엔 80%가 유휴이고, 평균에 맞추면 피크에 무너집니다. 정적 용량 계획으로는 비용과 안정성 중 하나를 반드시 포기해야 합니다. 오토스케일링은 수요에 따라 용량을 동적으로 따라가게 만들어 이 딜레마를 깹니다.
세 층위의 확장
- HPA(수평 파드 오토스케일러): 부하에 따라 파드 수 조절
- VPA(수직 파드 오토스케일러): 파드의 requests/limits 자동 조정
- Cluster Autoscaler: 파드가 들어갈 노드가 부족하면 노드 추가
HPA가 파드를 늘려도 노드가 꽉 차 있으면 Pending에 걸립니다. 따라서 HPA와 Cluster Autoscaler는 반드시 한 쌍으로 설계해야 합니다.
구현: CPU만 보지 마라
CPU 기반 HPA는 직관적이지만, 큐 길이나 요청 지연 같은 커스텀 지표가 실제 부하를 더 잘 반영하는 경우가 많습니다. 예컨대 메시지 큐 소비자는 대기 메시지 수를 기준으로 확장하는 게 맞습니다.
metrics:
- type: Pods
pods:
metric: { name: queue_messages_per_pod }
target: { type: AverageValue, averageValue: "30" }
behavior:
scaleDown:
stabilizationWindowSeconds: 300 # 출렁임 방지scaleDown 안정화 윈도를 충분히 길게(예: 300초) 잡아야 트래픽이 잠깐 줄었다고 파드를 성급히 줄였다 다시 늘리는 플래핑을 막을 수 있습니다.
모니터링과 비용
오토스케일링이 잘 작동하는지는 ‘확장 지연’과 ‘평균 활용률’로 판단합니다. 스파이크 시작부터 용량 확보까지 60초 이내를 목표로 하고, 평상시 노드 활용률은 65~75% 구간을 유지하면 안정성과 비용의 균형이 좋습니다. 스팟 인스턴스를 확장 노드로 섞으면 피크 대응 비용을 추가로 크게 낮출 수 있습니다.
정리
오토스케일링의 기술은 빠르게 늘리되 천천히 줄이는 비대칭에 있습니다. 적절한 지표 선택, 플래핑 방지, HPA와 Cluster Autoscaler의 짝 맞춤이 갖춰지면 트래픽 폭증 앞에서도 비용을 지키며 잠들 수 있습니다.
