서론: 클라우드의 약속, 탄력성
클라우드를 사용하는 가장 큰 이유는 **탄력성(Elasticity)**입니다. 사용자가 몰릴 때는 늘리고, 없을 때는 줄여서 비용을 아끼는 것입니다. 쿠버네티스(Kubernetes)는 이 탄력성을 구현하기 위한 가장 강력한 도구입니다.
하지만 단순히 "오토스케일링 켜주세요"라고 해서 마법처럼 동작하지 않습니다. 잘못 설정된 오토스케일링은 서비스 중단(Outage)이나 요금 폭탄으로 이어질 수 있습니다.
1. 쿠버네티스 스케일링의 3대장
HPA (Horizontal Pod Autoscaler)
- 개념: 파드(Pod)의 개수를 늘리고 줄입니다. (Scale Out/In)
- 기준: CPU 사용량, 메모리 사용량, 또는 커스텀 메트릭(예: 큐에 쌓인 메시지 수)을 기준으로 동작합니다.
- 주의점: 애플리케이션이 Stateless해야 효과적입니다.
VPA (Vertical Pod Autoscaler)
- 개념: 파드에 할당된 리소스(CPU/Memory Request & Limit) 크기를 조절합니다. (Scale Up/Down)
- 용도: 리소스 사용량을 예측하기 어려운 배치 작업이나, 스케일 아웃이 불가능한 레거시 앱에 적합합니다.
- 제약: 리소스 변경 시 파드를 재시작해야 하므로 서비스 중단이 발생할 수 있습니다. (HPA와 동시 사용 시 주의 필요)
CA (Cluster Autoscaler) / Karpenter
- 개념: 파드가 배치될 노드(Node, VM)가 부족하면 노드를 추가하고, 남으면 반납합니다.
- 최신 트렌드: 최근에는 AWS의 Karpenter가 주목받고 있습니다. 기존 CA보다 훨씬 빠르게 노드를 프로비저닝하고, 비용 효율적인 인스턴스 타입을 자동으로 선택해줍니다.
2. 실전 오토스케일링 전략
A. 우아한 종료 (Graceful Shutdown)
스케일 인(Scale In)이 발생할 때, 진행 중이던 요청이 끊기면 안 됩니다.
preStop훅과terminationGracePeriodSeconds를 설정하여, 파드가 종료되기 전에 연결을 정리할 시간을 주어야 합니다.
B. 웜업 (Warm-up) 문제 해결
트래픽이 폭주할 때 파드가 뜨는 속도가 트래픽 증가 속도를 따라가지 못하면 장애가 발생합니다.
- Over-provisioning: 약간의 여유 노드를 미리 띄워두어(Pause Pod 활용) 급격한 스케일 아웃에 대비합니다.
- HPA 민감도 조절: 스케일 아웃은 빠르게, 스케일 인은 천천히 하도록 정책을 튜닝합니다.
C. 리소스 요청(Request)과 제한(Limit)의 균형
Request를 너무 낮게 잡으면 노드에 너무 많은 파드가 구겨져서 성능 간섭(Noisy Neighbor)이 발생합니다.Limit을 설정하지 않으면 특정 파드가 노드 자원을 독점하여 다른 파드를 죽일 수 있습니다(OOMKilled).
3. CODEBLACK의 K8s 최적화
CODEBLACK은 수많은 엔터프라이즈 클러스터를 운영한 경험을 바탕으로 최적의 스케일링 전략을 제시합니다.
- 비용 최적화: Spot Instance를 적극 활용하여 클라우드 비용을 최대 70% 절감합니다.
- 안정성 확보: 부하 테스트를 통해 오토스케일링이 실제 트래픽 패턴에 맞춰 적절히 동작하는지 검증합니다.
결론
오토스케일링은 자율 주행과 같습니다. 편하지만, 믿고 맡기기 위해서는 정교한 설정과 지속적인 모니터링이 필요합니다.
트래픽의 파도에 휩쓸리지 말고, 그 파도를 타고 즐기십시오. CODEBLACK이 여러분의 서핑 보드가 되어드리겠습니다.