트래픽이 몰리면 파드가 죽고, 한산해지면 노드가 놀고 있다. 쿠버네티스를 운영하다 보면 누구나 한 번쯤 겪는 딜레마다. 오토스케일링을 도입하려고 검색하면 HPA, VPA, Cluster Autoscaler, Karpenter까지 선택지가 쏟아진다. 이름은 비슷해 보이는데 역할이 전부 다르다.
이 글을 끝까지 읽으면 네 가지 오토스케일러의 작동 원리와 차이점을 명확히 이해하고, 워크로드 특성에 맞는 조합을 직접 설계할 수 있다. 비용 절감과 안정성, 두 마리 토끼를 잡는 출발점이 바로 여기다.
가장 흔한 혼란의 원인은 단순하다. 파드 레벨 스케일링과 노드 레벨 스케일링이 별개의 메커니즘이라는 점을 간과하기 때문이다. 파드 스케일링은 애플리케이션 복제본 수나 리소스 할당량을 조절한다. 노드 스케일링은 그 파드가 올라갈 서버 자체를 늘리거나 줄인다.
레스토랑으로 비유하면 이렇다. 손님이 밀려올 때 직원(파드)을 더 투입하는 게 HPA다. 각 직원에게 더 넓은 작업 공간(CPU/메모리)을 배정하는 게 VPA다. 테이블(노드) 자체가 부족하면 Cluster Autoscaler나 Karpenter가 홀을 넓혀준다.
쿠버네티스 공식 문서에서는 HPA와 VPA를 워크로드 리소스 관리의 핵심 컴포넌트로 분류한다. 이 두 가지가 파드 안쪽을, 나머지 두 가지가 파드 바깥쪽을 담당한다고 이해하면 전체 그림이 잡힌다.
대부분의 웹 서비스나 API 서버는 HPA가 정답이다. Stateless 워크로드는 복제본을 늘리면 처리량이 선형에 가깝게 증가하고, 축소도 즉각적이다. kubectl autoscale deployment my-app --cpu-percent=60 --min=2 --max=20 한 줄이면 기본 설정이 완료된다.
반면 VPA는 파드를 재시작해야 리소스가 반영되는 구조적 한계가 있다. 그래서 ML 학습 잡이나 단일 인스턴스 데이터베이스처럼 수평 확장이 불가능한 워크로드에 적합하다. 실제 적용 사례를 살펴보면, 배치 처리 파이프라인에서 VPA를 적용해 메모리 request를 자동 튜닝한 뒤 리소스 낭비를 40% 가까이 줄인 팀도 있다.
HPA와 VPA를 같은 디플로이먼트에 동시 적용하면 충돌이 생길 수 있다. HPA가 CPU 메트릭으로 스케일링하는데 VPA가 CPU request를 변경하면 기준 자체가 흔들린다. VPA 공식 저장소에서도 CPU 기반 HPA와의 병행을 권장하지 않는다. 굳이 함께 쓰려면 HPA는 커스텀 메트릭을, VPA는 메모리만 조정하도록 분리하는 전략이 필요하다.
Cluster Autoscaler는 쿠버네티스 생태계의 오랜 표준이다. 하지만 근본적인 한계가 하나 있다. 사전에 정의된 노드 그룹(ASG) 안에서만 스케일링한다는 점이다. GPU 워크로드용, 범용 워크로드용, 메모리 집약형 워크로드용 노드 그룹을 각각 만들어야 하고, 새로운 인스턴스 타입을 추가하려면 노드 그룹 설정을 수정해야 한다.
많은 팀이 처음에는 노드 그룹 3~4개로 시작하지만, 서비스가 성장하면서 10개, 20개로 불어나는 경우가 흔하다. 관리 복잡도가 기하급수적으로 증가한다.
Karpenter는 이 문제를 정면으로 해결한다. 노드 그룹이라는 개념 자체를 없앴다. Pending 파드의 resource request, nodeSelector, toleration 등을 분석해서 가장 적합한 인스턴스 타입을 실시간으로 선택한다. 스팟 인스턴스 활용도 자연스럽게 통합되어 있어서, 스팟과 온디맨드 인스턴스의 비용 차이를 극대화하기에 유리하다.
노드 추가 속도도 차이가 크다. Cluster Autoscaler가 ASG를 거쳐 스케일링 결정까지 보통 2~5분 걸리는 반면, Karpenter는 EC2 Fleet API를 직접 호출해 60초 이내에 노드를 띄우는 경우가 많다. 다만 Karpenter는 AWS 전용이라는 점을 반드시 기억해야 한다. GCP나 Azure 환경이라면 Cluster Autoscaler가 여전히 유일한 선택지다.
오토스케일링을 도입했는데 오히려 비용이 올라갔다는 사례가 의외로 많다. 원인은 대부분 비슷하다. HPA의 minReplicas를 너무 높게 잡거나, Cluster Autoscaler의 scale-down-delay를 지나치게 길게 설정한 경우다. 트래픽이 빠진 뒤에도 노드가 30분 넘게 유지되면 그 자체가 낭비다.
팁: Cluster Autoscaler의
--scale-down-unneeded-time기본값은 10분이다. 워크로드 패턴에 따라 5분까지 줄이되, 잦은 스케일 업/다운 반복(플래핑)이 발생하지 않는지 모니터링해야 한다.
Karpenter의 장점에 끌려 무작정 도입했다가 벤더 종속에 발목 잡히는 경우도 있다. 조직이 멀티 클라우드 전략을 추진 중이라면 Cluster Autoscaler의 클라우드 중립성이 오히려 강점이 된다. 모든 도구에는 트레이드오프가 존재하며, 기술 선택은 현재 인프라 환경과 팀의 운영 역량에 맞춰야 한다.
HPA 설정의 실질적인 출발점은 이렇다. targetCPUUtilizationPercentage: 65, minReplicas: 2, maxReplicas: 현재 피크 대비 3배. 여기서 시작해서 실제 메트릭을 관찰하며 2주 단위로 조정하는 방식이 실무에서 가장 안정적이다. 노드 사이징과 스팟 전략까지 함께 최적화하면 TCO를 절반 가까이 줄인 사례도 보고된다.
HPA와 VPA는 파드 레벨, Cluster Autoscaler와 Karpenter는 노드 레벨을 담당한다. 대부분의 워크로드는 HPA + 노드 오토스케일러 조합으로 시작하면 된다. Karpenter는 빠르고 유연하지만 AWS 전용이라는 제약을 잊지 말아야 한다.
오늘 당장 할 수 있는 한 가지가 있다. 운영 중인 클러스터에서 kubectl top pods와 kubectl top nodes를 실행해보자. request 대비 실제 사용량의 괴리가 보이면, 그것이 오토스케일링 도입의 출발 신호다. 리소스 낭비 현황을 수치로 파악한 뒤, 이 글의 시나리오별 조합을 참고해 첫 번째 HPA부터 적용해보길 권한다.
예상치 못한 자금이 필요할 때 퇴직연금담보대출을 고려하는 직장인들이 늘어나고 있습니다.퇴직연금을 해지하지 않고도 적립금을 담보로 대출을…
재테크에 관심이 있는 많은 이들이 ‘절세의 아이콘’으로 알려진 개인종합자산관리계좌(ISA)에 대한 관심이 계속해서 높아지고 있습니다.다양한 금융…