Smart Sizing이란 무엇인가: Rightsizing을 넘어선 더 스마트한 클라우드

저자: Thomas Mathew (opens in a new tab) 날짜: 2025년 12월 31일

요약: Kubernetes 클러스터는 일반적으로 과도한 CPU 및 메모리 요청으로 인해 30~40%의 리소스를 낭비합니다. 개발자는 성능 문제를 피하기 위해 리소스를 과도하게 할당하여 대량의 미사용 컴퓨팅 리소스가 발생합니다. 수동 Rightsizing은 수백 개의 워크로드에 걸쳐 지속적인 분석이 필요합니다. Kubernetes VPA는 문제의 일부를 자동화하지만 중요한 한계가 있습니다. Wave Autoscale의 Smart Sizing은 더 나은 메트릭, 실행 가능한 권장 사항, 수직 + 수평 통합 스케일링으로 이러한 격차를 해결합니다.

핵심 요약

• Kubernetes 클러스터는 일반적으로 과도한 CPU 및 메모리 요청으로 인해 **30~40%**의 리소스를 낭비합니다
• 개발자는 성능 문제를 피하기 위해 리소스를 과도하게 할당하여 대량의 미사용 컴퓨팅 리소스가 발생합니다
• 수동 Rightsizing은 지속적인 메트릭 분석, 분류 및 조정이 필요합니다
• Kubernetes VPA는 문제의 일부를 자동화하지만 알려진 한계가 있습니다
• Wave Autoscale은 더 나은 메트릭, 실행 가능한 권장 사항 및 통합 스케일링으로 이러한 격차를 해결합니다

Kubernetes 리소스, 지금도 낭비되고 있을 가능성이 큽니다

대부분의 Kubernetes 클러스터는 생각보다 많은 리소스를 쓰지 못한 채 흘려보내고 있습니다.

Datadog의 컨테이너 리서치에 따르면, (opens in a new tab) 전체 컨테이너의 절반 가까이가 요청한 CPU와 메모리의 3분의 1도 사용하지 않는 것으로 나타났습니다. 즉, 클러스터 전체 기준으로 보면 30~40% 수준의 리소스가 낭비되고 있다는 의미입니다.

이런 상황은 누구의 잘못도 아닙니다. 개발자가 컨테이너 리소스를 설정할 때는 항상 안정성을 먼저 고려합니다.

• 실제로 200m면 충분한 CPU에 500m를 요청하고
• 400Mi면 되는 메모리에 1Gi를 설정

하는 일은 흔합니다. 특히 새벽에 발생하는 OOMKilled 파드를 겪어본 팀이라면 더욱 그렇습니다.

문제는 이 설정이 쌓이고 쌓인다는 점입니다. 수십, 수백 개의 워크로드에 동일한 방식이 적용되면, 결국 사용하지도 않는 컴퓨트 비용을 계속 지불하게 됩니다.

최적화를 시도하려 하면, 엔지니어는 기능 개발 대신 메트릭 분석과 설정 조정에 시간을 쓰게 됩니다.

컨테이너 리소스 설정이 잘 되었다는 기준은 무엇일까

컨테이너 리소스를 평가하는 기준은 생각보다 단순합니다.

• 실제 사용량이 요청값의 90~110% 범위에 있으면 이상적
• 90% 미만 → 리소스를 낭비하고 있는 상태
• 110% 초과 → 성능 저하나 장애 위험이 있는 상태

이 글에서는 이 기준을 바탕으로 Kubernetes 컨테이너를 제대로 Right Size 하는 방법과, 왜 규모가 커질수록 자동화가 필수가 되는지를 살펴봅니다.

수동으로 Rightsizing을 하려면 어떤 일이 필요할까

자동화 이야기를 하기 전에, 현실적으로 수동 Rightsizing이 어떤 작업을 요구하는지부터 보겠습니다.

1단계. 올바른 메트릭 수집

Sysdig's capacity planning guide (opens in a new tab)는 kube-state-metrics와 cAdvisor를 활용한 리소스 분석을 권장합니다. 컨테이너 리소스를 제대로 분석하려면 1주 이상의 데이터가 필요하며 다음과 같은 작업이 필요합니다.

• 최소 7~14일 이상의 연속 메트릭 데이터
• CPU, 메모리, 네트워크 사용량 수집
• Prometheus나 Datadog 같은 도구 설정
• 대시보드와 쿼리 직접 구성

문제점: 워크로드마다 관찰 기준이 다르다는 점입니다. 주 1회 실행되는 배치 작업과 24시간 요청을 처리하는 API를 같은 기준으로 볼 수는 없습니다.

2단계. 과거 패턴 분석

단순 평균값만 보면 안 됩니다.

• 언제 사용량이 가장 높았는지
• 주기적인 패턴이 있는지
• 일시적인 이상치인지 실제 트래픽 증가인지

지난주에 튄 그래프가 진짜 사용자 증가 때문인지, 일회성 데이터 마이그레이션인지 판단해야 합니다.

이 과정에는 생각보다 많은 분석 경험이 필요합니다.

3단계. 모든 워크로드 분류

각 컨테이너를 다음 세 가지 상태로 분류합니다.

• 과도한 리소스 할당: 실제 사용량이 요청값의 90% 미만으로, 불필요한 비용이 발생하는 상태
• 리소스 부족: 실제 사용량이 요청값의 110% 초과로, 성능 저하 위험이 있는 상태
• 적정 수준: 실제 사용량이 요청값의 90~110% 범위에 있는 이상적인 상태

컨테이너 수가 많아질수록, 이 분류 작업만으로도 며칠이 걸립니다.

4단계. 최적 요청값 계산

• P95 (95th percentile) 기준 사용량으로 시작
• 트래픽 급증 대비 여유 추가
• 가비지 컬렉션 영향 고려
• 컨테이너 시작 시 스파이크 반영

워크로드 유형에 따라 계산 방식은 달라집니다.

이 모든 과정을 거쳐 계산한 값은 다음 달 트래픽 패턴이 바뀌는 순간 다시 무효가 됩니다.

Example Formula:

Recommended CPU Request = (P95 CPU Usage × Burst Multiplier) + Startup Overhead
Recommended Memory Request = Max Memory Usage + GC Overhead + Safety Buffer

5단계. 적용과 반복

설정을 바꾸고 끝이 아닙니다.

• 점진적으로 배포하고
• 성능 이상이 없는지 지켜보고
• 문제 생기면 되돌릴 준비를 해야 합니다

애플리케이션이 바뀌면, 이 모든 과정을 다시 반복해야 합니다.

The Man-Hours Reality

VPA는 어떤 점을 개선했을까

이 문제를 해결하기 위해 등장한 것이 Kubernetes의 Vertical Pod Autoscaler입니다.

참고: 이 프로젝트는 처음에 Google 엔지니어들이 설계했으며, (opens in a new tab) 현재도 Google과 Microsoft를 비롯한 여러 기여자들이 (opens in a new tab) 활발히 유지 보수하고 있습니다.

VPA는 컨테이너의 실제 사용량을 기반으로 CPU와 메모리 요청값을 자동으로 추천하고 조정합니다.

덕분에 엔지니어가 직접 메트릭을 분석하고 값을 계산하는 부담은 줄어듭니다.

VPA의 주요 기능

• 자동 리소스 추천: 과거 사용 데이터를 분석해 적절한 CPU와 메모리 요청값을 제안
• 지속적인 조정: 워크로드 패턴이 변해도 이에 맞춰 설정을 계속 업데이트
• 수동 작업 감소: 스프레드시트 분석이나 PromQL 쿼리 작업 없이도 운영 가능

VPA 운영 모드

• Off 모드: 추천값만 제공하며, 적용은 사용자가 직접 수행
• Initial 모드: 파드 생성 시점에만 리소스를 설정
• Auto 모드: 실행 중인 파드의 리소스를 자동으로 조정. 단, 파드 재시작이 필요함

하지만 VPA로는 부족한 이유

VPA가 모든 문제를 해결했다면 더 이상의 대안은 필요 없었을 겁니다. 하지만 VPA에는 구조적인 제약이 존재합니다.

한계 1. 제한적인 메트릭

VPA는 CPU와 메모리 사용률만을 기준으로 합니다. 그러나 CPU 사용률 50%라고 해서 문제가 없다고 말할 수는 없습니다.

**CPU Pressure (PSI) (opens in a new tab)**는 성능 문제를 더 정확히 보여주는 지표입니다. 하지만 VPA는 이 지표를 사용하지 않습니다.

참고: Brendan Gregg - CPU Utilization is Wrong (opens in a new tab)

한계 2. 네트워크 인지 부족

네트워크 트래픽 증가는 CPU와 메모리 스파이크보다 먼저 나타나는 경우가 많습니다.

VPA는 이를 감지하지 못해 항상 사후 대응에 머뭅니다.

한계 3. HPA와의 충돌

VPA와 HPA는 모두 파드 설정을 바꾸는 방식이라 충돌이 발생합니다. VPA 문서에서도 (opens in a new tab) 두 기능의 병행 사용을 권장하지 않습니다.

Wave Autoscale이 제시하는 Smart Sizing 방식

Wave Autoscale은 이 한계를 근본적으로 다른 방식으로 해결합니다.

더 정확한 신호를 봅니다

Wave Autoscale은 다음을 사용합니다:

• CPU 사용률이 아니라 CPU Pressure를 봅니다
• 네트워크 트래픽을 함께 분석합니다
• 트래픽 패턴을 인지하여, 시스템이 필요한 자원 규모를 사전에 예측합니다.

이 덕분에 리소스 부족을 문제가 터진 뒤가 아니라, 터지기 전에 감지할 수 있습니다.

바로 적용할 수 있는 추천을 제공합니다

Smart Sizing은 "문제가 있을 수 있습니다"라는 경고에서 끝나지 않습니다.

• 현재 설정값과 추천값을 나란히 비교 가능
• 리소스가 얼마나 과도하거나 부족한지 즉시 파악
• Change Size 버튼으로 변경 사항을 안전하게 적용 가능

수직과 수평 스케일링을 따로 보지 않습니다

Wave Autoscale은 리소스 최적화와 파드 수 조정을 하나의 흐름으로 다룹니다. VPA와 달리 Wave Autoscale은 수직 및 수평 스케일링을 하나의 통합 플랫폼에서 처리하며, 함께 작동합니다.

클러스터 전체를 한눈에 볼 수 있습니다

Wave Autoscale은 클러스터 전체에 대한 완전한 통찰력을 제공합니다:

• 모든 컨테이너의 상태를 자동으로 분류하고
• 패턴 변화에 따라 지속적으로 업데이트하며
• 비용 절감 효과를 바로 확인할 수 있습니다

결론. 더 똑똑하게!

Kubernetes Rightsizing은 피할 수 없는 과제입니다. 하지만 방식은 선택할 수 있습니다.

수동으로 할 수도 있습니다. 다만 그 대가는 매달 수십, 많게는 수백 시간의 엔지니어링 리소스입니다. VPA는 일부를 자동화했지만, 메트릭과 확장 방식에는 분명한 한계가 있습니다.

Wave Autoscale은 이 빈틈을 채웁니다.

• 실제 성능을 반영하는 지표
• 수직과 수평 스케일링을 아우르는 구조
• 클러스터 전반의 가시성과 비용 절감

Wave Autoscale을 사용하는 팀은 머신러닝 기반 최적화를 통해 더 빠른 스케일링 반응과 최대 40%의 비용 절감을 경험하고 있습니다.

Autopilot은 예측 기반 스케일링과 Smart Sizing을 통해 운영 효율을 높이면서도, 플랫폼 팀이 통제력을 잃지 않도록 설계되었습니다.

Wave Autoscale은 ML 기반 최적화를 통해 2배 빠른 스케일링 응답과 최대 40%의 비용 절감을 제공합니다. Smart Sizing 기능은 통합된 수직 및 수평 스케일링과 함께 실행 가능한 리소스 권장 사항을 제공하면서도 팀이 제어권을 유지할 수 있도록 합니다.