Right-Sizing vs. Auto-Scaling: EKS에서 더 많이 절감하는 방법은?

발행: (2026년 3월 31일 PM 04:20 GMT+9)
16 분 소요
원문: Dev.to

I’m happy to translate the article for you, but I need the full text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line, formatting, markdown, and any code blocks exactly as they are while translating the rest into Korean.

핵심 문제

  • EKS는 EC2 노드 용량에 대해 청구하며, 파드가 실제로 소비하는 양에 대해서는 청구하지 않습니다.
  • 노드가 실행 중이면 파드가 자원의 10 %를 사용하든 90 %를 사용하든 비용을 지불하게 됩니다.

낭비는 요청 수준에서 발생합니다. Kubernetes는 실제 사용량이 아니라 리소스 요청을 사용해 파드를 노드에 스케줄링합니다. 파드가 2 vCPU를 요청했지만 실제로는 0.3 vCPU만 사용한다면, 그 남은 1.7 vCPU는 예약된 상태이며 다른 워크로드에서 사용할 수 없습니다. 노드는 서류상으로는 가득 차 있지만 실제로는 대부분 유휴 상태입니다.

예시: us‑east‑1에서 m5.2xlarge의 비용이 시간당 $0.384일 경우, 클러스터는 노드당 8 vCPU에 대해 비용을 지불하지만 실제로는 3 vCPU 미만으로 의미 있는 작업을 수행합니다.
Cluster Autoscaler는 이를 해결할 수 없습니다. 요청(requests)이 높기 때문에 노드가 사용 중이라고 판단해 실제 사용량이 낮아도 노드를 제거하지 않습니다.

Source:

요청을 맞춤형으로 조정하기

요청이 실제 사용량을 반영하면 노드당 더 많은 파드를 배치할 수 있어 노드 수가 줄어들고, Cluster Autoscaler가 실제로 사용되지 않는 노드를 제거할 수 있습니다.

EKS의 두 단계

  1. 파드 수준 요청 – CPU와 메모리 요청을 실제 사용량의 90번째 백분위수에 가깝게 설정합니다.
  2. 노드 수준 인스턴스 크기 조정 – 파드 프로파일에 맞는 인스턴스 유형을 선택합니다.

파드 수준 맞춤형 조정

  • Vertical Pod Autoscaler (VPA)Recommendation 모드로 사용합니다.
  • VPA는 파드 메트릭을 시간에 따라 관찰하고 권장 요청 값을 제시합니다.
  • Recommendation 모드에서는 자동으로 적용되지 않으며 직접 검토하고 적용해야 합니다.

영향 예시m5.2xlarge 클러스터에서 10개의 복제본을 실행하는 서비스:

지표리사이징 전리사이징 후
파드당 CPU 요청1000 m250 m
파드당 메모리 요청2 GB512 MB
노드당 파드 수 (빈 패킹)414
10 복제본에 필요한 노드 수31
온디맨드 시간당 비용 (us‑east‑1)$1.15$0.384
월간 비용 (730 시간)$840$280

10개의 복제본은 변하지 않았습니다. 파드가 수행하는 작업은 동일합니다. 바뀐 것은 파드가 Kubernetes에 선언한 요구량뿐이며, 이 조정으로 두 개의 노드가 영구적으로 사라졌습니다.

노드 수준 맞춤형 조정

  • 실제 파드 프로파일에 맞는 인스턴스 유형을 선택합니다.
  • 메모리‑경량, CPU‑집중 서비스가 실행되는 클러스터는 r5 인스턴스에서 비용을 낭비합니다. c5 인스턴스로 전환하면 달러당 더 많은 vCPU를 얻을 수 있습니다.
  • AWS Compute Optimizer 가 관리형 노드 그룹의 CloudWatch 메트릭을 분석해 인스턴스 유형 변경을 권장합니다(무료).

결과: 맞춤형 조정은 한 번만 수행하면 되는 수정이며, 기본 청구서에 영구적인 영향을 미칩니다.

자동 스케일링은 가변 로드를 처리합니다

자동 스케일링은 파드당 낭비를 줄이지 않습니다. 현재 수요에 맞게 실행 중인 파드와 노드 수를 맞추는 것이며, 이는 전혀 다른 문제입니다.

ComponentWhat it does
Horizontal Pod Autoscaler (HPA)CPU 사용량이나 사용자 정의 메트릭을 기준으로 파드 복제본을 추가하거나 제거합니다.
Cluster Autoscaler대기 중인 파드를 스케줄링할 수 없을 때 새 노드를 프로비저닝하고, 노드 활용도가 10 분 동안 임계값 이하로 떨어지면 노드를 제거합니다. 트리거는 파드 요청이며 실제 사용량은 아닙니다.
KEDAHPA에 이벤트 기반 스케일링(큐 깊이, Prometheus 메트릭, 예약 윈도우, 외부 신호)을 확장합니다. 예시: 야간에 실행되는 배치 프로세서는 업무 시간 동안 0으로 스케일 다운하고 자정에 다시 스케일 업할 수 있습니다.

자동 스케일링이 빛을 발하는 경우

  • 가변적이거나 급증하는, 혹은 이벤트 기반 트래픽 (예: 정오에 트래픽이 자정보다 5배 많을 때).
  • 평균 부하가 훨씬 낮은 상황에서 정점 부하에 맞춰 클러스터를 정적으로 크기 지정하는 것을 방지합니다.

실패 모드: 과다 프로비저닝된 파드에 HPA를 활성화하면, 새 복제본마다 부풀린 요청이 그대로 상속됩니다. 파드 5개에서 15개로 스케일링하면 실제 복제본당 작업량은 변하지 않음에도 불구하고 클러스터 비용이 3배로 증가합니다.

비교 표

차원Right‑SizingAuto‑Scaling
트래픽 패턴안정적이거나 예측 가능한 부하가변적이고 급증하거나 이벤트 기반 부하
절감 유형기본 비용을 영구적으로 감소시킴비피크 기간 동안 비용을 감소시킴
엔지니어링 노력일회성: 측정, 적용, 검증지속적: 임계값 조정, 지연 모니터링
가치 실현 시간VPA 관찰 1–2주구성에 몇 시간; 튜닝은 몇 주가 걸릴 수 있음
주요 실패 모드요청이 너무 낮게 설정되면 Pods가 OOM‑Killed됨급격한 트래픽 급증 시 HPA 지연
최적 도구VPA Recommendation + Compute OptimizerHPA + Cluster Autoscaler + KEDA
  • Right‑sizing은 즉각적이고 영구적인 감소를 제공합니다. 트래픽 형태와 관계없이 작동하는데, 이는 Pods가 리소스를 요청하는 방식의 구조적 낭비를 교정하기 때문입니다.
  • Auto‑scaling은 가변 워크로드에 대해 비례적인 감소를 제공합니다. 이는 해당 시점에 실제로 필요하지 않은 용량을 제거하기 때문에 작동합니다.

전체 그림

두 접근 방식 중 어느 하나만으로는 완전하지 않습니다:

  • 정적 크기의 클러스터를 적정 규모로 맞추는 것은 비수기 시간대에 여전히 과다 프로비저닝된 상태를 남깁니다.
  • 적정 규모가 아닌 클러스터에 자동 스케일링을 적용하는 것은 효율적으로 상하 스케일링을 수행하지만, 각 노드에는 여전히 부풀린 pod 요청이 남아 있습니다.

자동 스케일링이 절대적으로 우위에 있는 상황: EKS Fargate. Fargate는 실제 pod 요청에 대한 vCPU‑초와 GB‑초당 요금을 부과하며, 유휴 노드 용량에 대해서는 청구하지 않습니다. 요청을 적정 규모로 맞추면 노드 관리 없이도 비용을 직접 줄일 수 있습니다. 그러나 Cluster Autoscaler는 Fargate에서는 무관합니다(관리할 노드가 없기 때문). 반면 HPA와 KEDA는 여전히 적용됩니다.

두 접근 방식 모두 적용하기

실제로는 먼저 적정 규모를 맞추는 것이 좋습니다( pod 요청을 조정하고 적절한 인스턴스 유형을 선택). 그런 다음 자동 스케일링을 레이어링하여 실제 수요 변동을 처리합니다. 이 조합은 영구적인 기본선 절감과 동적인 비용 감소를 모두 포착합니다.

Right‑Sizing & Autoscaling 시퀀스

실제 절감 효과는 다음과 같은 프로덕션 검증된 순서를 따를 때 나타납니다:

단계 1 – VPA 권장 사항으로 측정

  1. Vertical Pod Autoscaler (VPA)Recommendation 모드로 배포합니다.
  2. 워크로드를 ≥ 7 일 동안 관찰하도록 합니다.
  3. 주간 피크를 포함한 대표적인 트래픽 샘플을 포함합니다.
  4. VPA는 관찰된 퍼센타일을 기반으로 권장 CPU 및 메모리 요청을 출력합니다.

단계 2 – 적정 요청값 적용

  1. VPA 권장 값을 가져와 버스트를 위해 15‑20 % 여유를 추가합니다.
  2. 새로운 요청값을 서비스별로 (한 번에 전체가 아니라) 파드 사양에 적용합니다.
  3. 첫 24 시간 동안 OOMKilled 이벤트를 모니터링합니다.
    • OOMKill 은 메모리 요청이 실제 피크 사용량보다 낮게 설정되었음을 의미하므로 조정 후 다시 롤아웃합니다.

단계 3 – HPA 임계값 조정

  • HPA는 파드의 CPU 요청에 대한 CPU 목표 비율을 기준으로 스케일링합니다.
  • 예시:
    • 파드가 1000 mCPU 를 요청하고 HPA 목표가 70 % 인 경우, 700 mCPU 에서 스케일링이 발생합니다.
    • 요청을 250 mCPU 로 적정화하면 동일한 70 % 목표는 이제 175 mCPU 에서 트리거됩니다.
  • 워크로드가 그 낮은 수준에 도달하지 않으면 HPA는 스케일링하지 않습니다.
  • 적정화 후 목표 비율을 재조정합니다.

단계 4 – Cluster Autoscaler 동작 검증

  1. 적정화 후 파드가 더 적은 노드에 집중되어야 합니다.

  2. Cluster Autoscaler 가 사용률이 낮은 노드를 제거해야 합니다.

  3. 그렇지 않을 경우 다음 플래그를 확인합니다:

    --scale-down-utilization-threshold   # 기본값: 요청의 50 %
    • 적정화된 요청값에서는 실제 사용량 ≈ 요청량이므로 활용도가 높게 측정되어 노드가 스케일‑다운 대상이 됩니다.
  4. 필요에 따라 임계값을 약간 낮추거나 다음 옵션을 사용해 bin‑packing을 활성화합니다:

    --balance-similar-node-groups

기대 효과

  • 3‑node m5.2xlarge 클러스터에 15개의 서비스가 실행될 경우, 이 순서는 일반적으로 워크로드를 1‑2개의 노드로 집중시킵니다.
  • 시간당 EC2 비용$1.15 에서 $0.38‑$0.57 로 감소하며, 50‑67 % 절감 효과를 보입니다.
  • 자동 스케일링만 적용하면 비피크 시간대에만 비용이 감소해 월간 절감 효과가 훨씬 작게 나타납니다.

요약

  • Right‑sizing은 즉각적이고 영구적인 영향을 제공합니다.
  • Autoscaling은 동적인 효율성을 추가합니다.
  • 두 가지 모두 실행, Right‑sizing부터 시작하세요.

자동 스케일링만 하면, 비효율적인 아키텍처를 효율적으로 관리하는 셈입니다.
Right‑sizing만 하면, 트래픽에 맞춰 확장되지 못하는 간소화된 아키텍처를 운영하게 됩니다.

가장 큰 EKS 비용 절감은 Right‑Size → Bin‑Pack → Auto‑Scale 파이프라인에서 나옵니다. 먼저 파드 요청을 교정함으로써, Cluster Autoscaler에 정확한 데이터를 제공해 실제 축소를 트리거할 수 있습니다.

Action: 오늘 바로 VPA를 권장 모드로 배포하고 월별 AWS 비용이 감소하는 모습을 확인하세요.

0 조회
Back to Blog

관련 글

더 보기 »

EC2 시작

1단계: EC2 인스턴스 시작 – 이름: my-web-server 2단계: 키 페어 선택 3단계: 네트워크 설정 구성 4단계: 인스턴스 시작 5단계: 인스턴스에 연결…