Chiko IT
AWS

EKS 비용 최적화 실전: Karpenter, Spot, 리소스 요청 3단계 비교

Chiko
11min read

목차

EKS 청구서가 6개월 만에 세 배 가까이 뛰었다. Karpenter 전환, Spot 혼합, 리소스 요청 튜닝을 3단계로 당긴 결과 월 EC2 비용을 약 40% 줄였고 운영 안정성은 오히려 조금 올라갔다.

과정에서 가장 오래 고민한 건 "뭘 먼저 해야 효율이 좋은가"였다. 결과적으로 순서가 가장 중요했고, 조합을 이해하지 못한 채 하나씩 시도했다면 같은 숫자가 안 나왔을 가능성이 크다. 이 글은 그 비교 과정을 최대한 기준 중심으로 정리한다.

EKS 비용 최적화, 어디가 새는지부터 본다

먼저 청구서를 쪼갰다. Cost Explorer에서 EKS 관련 리소스만 필터링하면 EC2-Instance, EC2-Other(EBS·데이터 전송), ELB 순으로 비중이 나뉜다. 손댈 수 있는 건 당연히 EC2-Instance 쪽이 가장 크다.

클러스터 구성은 평범했다. m5.xlarge On-demand 10~15대, Managed Node Group 하나, HPA만 붙은 상태. 문제는 세 가지였다.

첫째, 야간과 주말에도 피크 시간대와 같은 노드 수가 돌고 있었다. Cluster Autoscaler는 ASG 기반이라 스케일 다운이 굼뜨고, 노드 하나를 줄일지 말지 판단하는 주기도 보수적이다. 둘째, 대부분의 Pod가 requests 값이 비슷하게 설정돼 있어 노드 하나당 실제 사용량 대비 50% 정도만 채워졌다. 셋째, Spot 인스턴스를 전혀 쓰지 않았다.

각 레버의 기여도는 나중에 분리해서 쟀다. 의외로 리소스 요청 튜닝 > Spot 전환 > Karpenter 순이었다. 처음엔 Karpenter만 갈아 끼워도 확 떨어질 줄 알았는데 실측은 다르게 나왔다.

비교 기준을 먼저 정한다

도구를 고를 때 기준이 없으면 "요즘 뜨는 것"으로 가게 된다. 2026년 4월 기준으로 내가 실제로 검토한 후보는 세 개였다.

  • Cluster Autoscaler(이하 CA) + ASG 조합: 오랫동안 기본값 자리를 지킨 방식
  • Karpenter v1.2: AWS가 밀고 있는 Kubernetes-native 오토스케일러
  • EKS Auto Mode: 2024년 말 GA된 관리형 옵션

비교 기준은 다섯 가지로 잡았다.

  1. 노드 프로비저닝 속도 (Pod Pending → Ready까지 시간)
  2. 인스턴스 타입 유연성
  3. Spot 인스턴스 통합 난이도
  4. 초기 설정 비용(IAM, 네트워킹, Helm)
  5. 장애 발생 시 디버깅 여지

다섯 번째가 실용주의자 관점에서 가장 중요했다. 관리형이 편해 보여도 블랙박스가 커지면 문제가 터졌을 때 할 수 있는 게 줄어든다. "잘 되면 안 건드린다"는 원칙을 지키려면 역설적으로 터졌을 때 들여다볼 수 있어야 한다.

세 후보 항목별 비교

기준별로 정리한 결과가 아래 표다.

항목 Cluster Autoscaler Karpenter EKS Auto Mode
프로비저닝 속도 1~3분 (ASG 의존) 30초~1분 30초~1분
인스턴스 타입 유연성 ASG 단위 제한 NodePool로 매우 유연 AWS가 자동 선택
Spot 통합 별도 ASG 필요 NodePool에서 바로 기본 포함
초기 설정 복잡도 복잡 (IAM, ASG 분리) 중간 (Helm + CRD) 매우 간단
운영 블랙박스 낮음 낮음 높음
업그레이드 방식 수동 수동 또는 EKS Add-on 자동

Auto Mode는 매력적이었지만 두 가지가 걸렸다. 노드 레벨 커스터마이징 범위가 좁고(커스텀 AMI 불가, 특정 커널 파라미터 조정 제한), 장애 발생 시 관리 영역 경계에서 AWS 지원에 의존해야 하는 구간이 생긴다. 사내 컴플라이언스상 특정 에이전트를 노드에 올려야 하는 요구가 있어서 탈락했다.

CA는 익숙하지만 ASG마다 인스턴스 타입을 하나만 쓰는 구조가 기본이라 Spot과 On-demand를 섞으려면 ASG가 두세 배로 늘어난다. 운영 복잡도가 올라가는 만큼 얻는 이득이 크지 않았다.

결국 Karpenter로 갔다. 설정 복잡도는 중간이지만 Spot 통합과 bin-packing 효율에서 가장 앞섰고, 무엇보다 오픈소스라 문제가 터졌을 때 소스와 이슈 트래커를 직접 볼 수 있다.

Karpenter 전환에서 걸렸던 것들

Karpenter는 v1.0(2024-08)부터 API가 안정화됐고 2026년 4월 기준 v1.2.x 대가 최신이다. v1 이전(v0.32 이하)에서 올라오는 경우 Provisioner·AWSNodeTemplate에서 NodePool·EC2NodeClass로 옮기는 마이그레이션이 필요하다(출처: Karpenter Release Notes v1.0).

NodePool 범위는 넓게 잡는 게 낫다

NodePool은 "어떤 노드를 띄울 수 있는지"를 정의한다. 처음에는 c5.large, c5.xlarge만 허용하도록 좁게 잡았는데 특정 AZ에서 Spot 가용성이 떨어지면 노드가 안 떠서 Pod가 Pending으로 쌓였다. 범위를 넓혀 c·m·r 세대 5 이상 전부 허용하자 Karpenter가 가장 싼 조합을 알아서 고르기 시작했다.

# NodePool 요구사항 핵심 부분
requirements:
  - key: karpenter.k8s.aws/instance-category
    operator: In
    values: ["c", "m", "r"]  # compute/general/memory 모두 허용
  - key: karpenter.k8s.aws/instance-generation
    operator: Gt
    values: ["4"]  # 5세대 이상
  - key: karpenter.sh/capacity-type
    operator: In
    values: ["spot", "on-demand"]

Spot과 On-demand를 같은 NodePool에 두고 가중치만 조정하면 Spot이 먼저 시도되고, 용량이 없을 때 On-demand로 자연스럽게 폴백한다. 별도 ASG를 만들지 않아도 되는 부분이 가장 크게 체감됐다.

Consolidation이 진짜 비용 레버다

Karpenter의 Consolidation은 Pod 분포가 비효율적일 때 노드를 합쳐준다. consolidateAfter를 너무 짧게 잡으면 불필요한 재배치가 반복되고, 너무 길면 비어 있는 노드를 오래 잡고 있게 된다. 체감상 30초~1분이 무난했다.

다만 Consolidation이 돌기 시작하면 Pod가 생각보다 자주 이사간다. PDB(PodDisruptionBudget)를 핵심 워크로드에 걸어두지 않으면 체감 장애가 난다. Karpenter의 문제가 아니라 원래 있어야 할 설정인데, 평소에는 트리거될 일이 없어서 숨어 있던 지뢰다. 전환 직후 처음 하루는 PDB 누락 Pod를 찾아 채우느라 시간을 꽤 썼다.

Spot을 안전하게 섞는 법

Spot 인스턴스는 On-demand 대비 최대 90% 할인(AWS 공식 수치, 인스턴스 타입·리전별 상이)이지만 2분 전 중단 통지가 온다는 제약이 있다. 이걸 견디도록 워크로드를 설계해야 한다.

핵심은 세 가지다.

첫째, stateful 워크로드는 Spot에 올리지 않는다. RDS를 쓰고 있으면 괜찮지만 Kafka 브로커, Redis 클러스터 같은 것들이 노드에 떠 있다면 taint와 toleration으로 On-demand NodePool에 격리한다. 한 번의 Spot 중단으로 데이터 복구 절차를 타는 게 훨씬 비싸다.

둘째, 인스턴스 타입 다양성을 확보한다. 같은 AZ에서 c5.xlarge만 쓰면 해당 풀이 고갈됐을 때 Pod가 우르르 끊긴다. 최소 10개 이상 타입을 허용하면 중단 확률이 체감상 확연히 떨어진다. Karpenter는 여기서도 편한데, NodePool에 범용 조건만 걸어두면 알아서 다변화된다.

셋째, 중단 통지를 미리 받아 graceful하게 옮긴다. Karpenter가 SQS Interruption Queue를 구독하도록 설정하면 EventBridge의 Spot 중단 이벤트를 바로 받아 Pod를 드레인한다. 공식 문서의 Interruption Handling 섹션에 설정 절차가 있다(출처: Karpenter Docs, Interruption).

운영 2개월 동안 Spot 중단은 주당 평균 3~5건 정도였고 대부분 새벽 시간대에 몰렸다. 사용자 영향은 관측되지 않았다. 중단 이벤트 자체를 Datadog로 모니터링 해두면 분기별로 패턴을 확인할 수 있다.

리소스 요청 튜닝이 사실 제일 컸다

가장 의외였던 부분이다. Karpenter와 Spot을 다 붙이고도 청구서가 기대만큼 안 떨어졌다. 원인을 뜯어보니 노드는 잘 줄어드는데 노드 안이 반쯤 비어서 돌고 있었다.

requests가 실측과 동떨어져 있었다

개발자들이 안전하게 간다고 requests: 2Gi로 잡아둔 Pod의 실제 사용량을 측정하니 평균 400Mi 수준이었다. 스케줄러 입장에서는 노드가 거의 꽉 차 있어 보이고 그래서 새 노드를 띄운다. 실제로는 빈 공간이 가득한 상태로 돈다.

VPA(Vertical Pod Autoscaler)의 updateMode: Off 옵션으로 recommender만 돌렸다. 적용은 하지 않고 추천값만 뽑아내는 모드다. 일주일 정도 돌리면 p50, p90, p95 기준 사용량이 나오고, 그 값을 참고해 requests는 p50~p75 사이, limits는 p95 근처에 다시 배치했다.

둥근 숫자가 오히려 낭비를 만든다

requests: 1Gi처럼 깔끔한 숫자를 선호하는 관행이 있는데 이게 오히려 빈 공간을 만든다. requests: 600Mi 같은 실측 기반 값이 노드 팩킹을 훨씬 잘 풀어낸다. 작은 차이 같지만 Pod 수백 개가 돌면 노드 대수가 눈에 띄게 줄어든다.

이 부분은 간단하다. 실측하고 거기에 맞춰 적는다. 끝이다. 다만 limits를 너무 타이트하게 잡으면 OOMKilled가 터지니 여유는 둬야 한다.

실제 비용 변화와 EKS 비용 최적화 우선순위

단계별 월 EC2 비용을 기준값 100으로 놓고 비교했다.

단계 주요 조치 상대 비용
0단계 CA + 전체 On-demand 100
1단계 Karpenter 전환, 아직 On-demand 92
2단계 Spot 70% / On-demand 30% 64
3단계 리소스 요청 튜닝 + Consolidation 정교화 57

1단계 8% 절감은 Karpenter의 bin-packing이 CA보다 낫기 때문으로 보인다. 2단계 Spot 전환이 가장 큰 폭이고, 3단계 리소스 튜닝이 10% 가까이 더 줄였다. 순서를 바꿔 리소스 튜닝을 가장 먼저 했다면 1·2단계에서 줄일 수 있는 폭이 더 커졌을 것이다. 노드가 비어 있는 상태에서 Spot을 붙여도 절감액 자체는 있지만 비율로는 덜 선명해진다.

Data Transfer 비용은 이번 범위에서 건드리지 않았다. VPC Endpoint, PrivateLink, Cross-AZ 트래픽 최적화로 줄일 여지가 분명히 있다. 아직 측정만 해본 상태라 여기서 숫자를 자신 있게 말하긴 어렵다.

앞으로 실험해볼 것

당장 실행할 수 있는 액션 세 개로 정리한다.

  1. Cost Explorer에서 EKS 태그 기준으로 리소스별 비용을 먼저 분리해봐라. 어디가 새는지 확인 없이 튜닝부터 하면 엉뚱한 데를 깎게 된다.
  2. Karpenter를 도입하기 전에 기존 워크로드의 PDB부터 점검해라. Consolidation이 돌기 시작하면 PDB 없는 Pod는 언제든 쫓겨난다.
  3. VPA recommender로 일주일 사용량을 측정하고 requests를 실측 기반으로 다시 잡아라. 숨어 있는 가장 큰 레버다.

다음엔 Graviton 기반 인스턴스(ARM)로 워크로드를 옮겨보려고 한다. 같은 성능 대비 20% 정도 싸다고 알려져 있지만 이미지 빌드 파이프라인을 multi-arch로 바꾸는 작업이 남아 있다. 실제로 굴려본 뒤에 수치를 정리해볼 생각이다.

관련 글

More posts