클러스터 비용이 통제 불능이 되는 순간
Kubernetes 클러스터를 운영하다 보면 어느 시점부터 클라우드 청구서가 예측을 벗어나기 시작한다. 워크로드는 늘어나고, 팀마다 넉넉한 리소스를 요청하며, 노드는 계속 추가된다. 이 글은 노드 사이징, 스팟 인스턴스, 오토스케일링 세 가지 전략축을 기준으로 TCO(총소유비용)를 비교 분석한다. 끝까지 읽으면 자사 워크로드에 맞는 비용 최적화 조합을 설계할 수 있다.
Kubernetes 클러스터 운영 비용이 폭증하는 근본 원인은 무엇인가
오버프로비저닝의 구조적 관성
많은 조직이 처음 클러스터를 구축할 때 “넉넉하게”라는 원칙을 세운다. 문제는 이 관성이 굳어진다는 점이다. CNCF 연간 설문에 따르면 Kubernetes 사용 조직의 약 68%가 리소스 요청값을 실제 사용량보다 2배 이상 높게 설정하고 있다. CPU 요청은 400m인데 실사용은 120m 수준인 Pod가 수백 개 돌아가면, 노드 절반은 사실상 유휴 상태로 비용만 소모한다.
단일 인스턴스 타입 고정의 함정
m5.xlarge 하나로 모든 워크로드를 감당하려는 접근도 흔하다. 메모리 집약형 작업에는 r 계열이, 배치 처리에는 c 계열이 가성비가 높다. 그런데 인스턴스 타입 다양화 없이 범용 타입만 쓰면 vCPU당 비용이 15~30% 비효율적으로 책정된다. 노드 사이징 문제는 결국 워크로드 프로파일링 부재에서 시작된다.
노드 사이징 스팟 인스턴스 오토스케일링, 전략별 TCO는 얼마나 차이 나는가
세 전략의 비용 구조 비교
AWS 기준으로 m5.2xlarge 10대 클러스터를 가정하면, 온디맨드 월 비용은 약 $2,800이다. 여기에 전략을 적용하면 결과가 극적으로 달라진다.
- 노드 사이징 최적화: 워크로드별 인스턴스 타입을 분리하고 bin-packing 효율을 높이면 노드 수를 7~8대로 줄일 수 있다. 월 약 $700 절감.
- 스팟 인스턴스 혼합: 비상태성 워크로드 60%를 스팟으로 전환하면 해당 부분에서 60~70% 할인이 적용된다. 월 $900~$1,100 절감 가능. 단, 중단 리스크가 따른다.
- 오토스케일링 고도화: Cluster Autoscaler 또는 Karpenter를 도입해 야간·주말 트래픽 저점에 노드를 축소하면 유휴 시간 비용 30~40%를 회수한다.
세 전략을 조합하면 원래 비용 대비 45~60% 절감이 현실적인 목표치다. 실제 적용 사례를 살펴보면, 50인 규모 스타트업이 세 전략을 병행해 월 클러스터 비용을 $8,200에서 $3,400으로 낮춘 사례가 있다.
전략 조합 시 우선순위
어디서부터 손대야 할까? 가장 즉각적인 효과는 노드 사이징이다. kubectl top nodes로 실사용률을 확인하고 오버프로비저닝부터 잡는 것이 첫 단계다. 그다음 스팟 전환, 마지막으로 오토스케일링 튜닝 순서가 리스크 대비 효과 면에서 합리적이다. 예약 인스턴스와 스팟 인스턴스의 비용 구조 차이를 함께 파악해두면 판단이 더 명확해진다.
전략 도입 시 반드시 점검해야 할 리스크
스팟 중단과 워크로드 안정성
스팟 인스턴스의 최대 약점은 2분 전 경고 후 강제 회수된다는 것이다. Stateful 워크로드나 장시간 배치 작업을 스팟에 올리면 데이터 유실 위험이 있다. Kubernetes 공식 문서의 Eviction 정책에서 권장하는 대로 PodDisruptionBudget을 반드시 설정해야 한다. 또한 다중 AZ, 다중 인스턴스 패밀리로 스팟 풀을 분산하지 않으면 동시 회수 확률이 높아진다.
오토스케일링의 지연 문제
Cluster Autoscaler는 Pod가 Pending 상태가 된 뒤에야 노드를 추가한다. 이 지연이 3~5분 걸릴 수 있어 트래픽 급증 시 서비스 지연이 발생한다. Karpenter는 이 문제를 상당 부분 개선했지만, 완전한 해결은 아니다. 버퍼 노드를 1~2대 유지하거나 Priority Class를 활용한 선점 전략을 병행해야 한다.
모든 워크로드에 스팟을 적용하려는 시도는 위험하다. 데이터베이스, 메시지 큐, 상태 저장 서비스는 반드시 온디맨드 또는 예약 인스턴스로 분리해야 한다.
비용 최적화, 어디서부터 시작해야 실패하지 않는가
단계별 실행 로드맵
한꺼번에 모든 전략을 도입하면 장애 원인 추적이 어려워진다. 검증된 접근 순서는 다음과 같다.
- 1단계: 현황 파악 — Kubecost나 OpenCost로 네임스페이스별 실사용 비용을 측정한다. 데이터 없이 최적화하면 엉뚱한 곳을 건드리게 된다.
- 2단계: 리소스 요청값 조정 — VPA 권장값을 참고해 CPU·메모리 요청을 실사용 기반으로 재설정한다. 이것만으로 노드 1~3대를 줄이는 조직이 많다.
- 3단계: 스팟 파일럿 — 비핵심 워크로드(CI/CD 러너, 개발 환경, 배치 작업)부터 스팟으로 전환한다.
- 4단계: 오토스케일링 튜닝 — scale-down 지연시간, utilization threshold를 워크로드 패턴에 맞게 조정한다.
지속적인 거버넌스 체계
비용 최적화는 일회성 프로젝트가 아니다. 월 1회 비용 리뷰 회의, 팀별 리소스 쿼터 정책, 비용 이상 알림 설정이 뒷받침되어야 절감 효과가 유지된다. 클라우드 거버넌스 체크리스트를 참고하면 체계를 잡는 데 도움이 된다.
결론
Kubernetes 클러스터 비용 최적화의 핵심을 정리하면 세 가지다. 첫째, 노드 사이징을 워크로드에 맞게 재조정하는 것이 가장 안전하고 즉각적인 절감 수단이다. 둘째, 스팟 인스턴스는 강력하지만 적용 범위를 신중히 한정해야 한다. 셋째, 오토스케일링은 유휴 비용을 회수하는 마지막 퍼즐이다.
오늘 당장 kubectl top nodes 명령어로 클러스터 실사용률부터 확인해보자. 노드별 CPU·메모리 사용률이 50% 미만이라면, 이 글에서 다룬 전략들이 즉시 효과를 낼 수 있는 상태다.