스케일링 정책
경로: 클러스터 > 워크로드 최적화 > 스케일링 정책
워크로드에 적용할 최적화 정책을 생성하고 관리합니다. 하나의 정책에 VPA, HPA, 스팟, 제로 스케일링 4가지 기능을 통합 설정할 수 있습니다.
개요
스케일링 정책은 Skuber⁺ Cost Optimize의 핵심 개념입니다.
기존 방식에서는 워크로드마다 개별적으로 최적화 설정을 하지만, Skuber⁺에서는 정책을 한 번 정의하고 여러 워크로드에 일괄 적용합니다.
화면 구성
정책 목록 테이블
| 컬럼 | 설명 |
|---|---|
| 정책 이름 | 정책 이름 |
| VPA | VPA 활성화 여부 (ON/OFF) |
| HPA | HPA 활성화 여부 (ON/OFF) |
| 스팟 | 스팟 인스턴스 활성화 여부 (ON/OFF) |
| 제로 리소스 | 제로 스케일링 활성화 여부 (ON/OFF) |
| 작업 | 수정 / 삭제 |
정책 생성
"정책 생성" 버튼을 클릭하여 새 정책을 생성합니다.
공통 입력 필드
| 필드 | 타입 | 필수 여부 | 설명 |
|---|---|---|---|
| 스케줄 이름 | 텍스트 입력 | 필수 | 정책을 식별하는 고유한 이름입니다. 여러 워크로드에 이 정책을 적용할 때 이 이름으로 선택하게 되므로, 용도나 환경을 쉽게 파악할 수 있는 이름을 사용하세요. (예: prod-vpa-spot, dev-zero-scale) |
| 정책 설명 | 텍스트 입력 | 선택 | 정책의 목적이나 적용 대상을 자유롭게 기술합니다. 팀원들이 정책의 의도를 파악할 수 있도록 간략한 설명을 입력하는 것을 권장합니다. |
정책 탭 선택
정책에서 사용할 기능을 체크박스로 선택합니다. 복수 선택이 가능하며, 선택한 탭에 해당하는 설정 화면이 활성화됩니다.
| 탭 | 설명 |
|---|---|
| VPA | 워크로드의 실제 사용 패턴을 분석하여 CPU/메모리 리소스를 자동으로 조정합니다. (Vertical Pod Autoscaler) |
| HPA | CPU 사용률 등 메트릭을 기반으로 Pod 수를 자동으로 늘리거나 줄입니다. (Horizontal Pod Autoscaler) |
| SPOT INSTANCE | 온디맨드 대신 저렴한 Spot 노드에 워크로드를 배치하여 비용을 절감합니다. |
| ZERO RESOURCE | 트래픽이 없는 워크로드를 Pod 0개로 축소하고, 트래픽 발생 시 자동으로 복구합니다. |
VPA (수직 Pod 오토스케일러) — 스마트 리소스 조정
워크로드의 실제 사용 패턴(최근 7일)을 분석하여 최적의 CPU/메모리 리소스를 자동 설정합니다.
과도하게 할당된 리소스를 줄여 비용을 절감하고, 부족한 리소스를 늘려 안정성을 확보합니다.
리소스 활성화
조정할 리소스 유형을 선택합니다. CPU와 메모리를 독립적으로 활성화할 수 있습니다.
| 필드 | 타입 | 기본값 | 설명 |
|---|---|---|---|
| CPU 자동 조정 | 토글 | ON | ON: VPA가 워크로드의 CPU 사용 패턴을 분석하여 requests.cpu와 limits.cpu를 자동으로 조정합니다. OFF: CPU 리소스는 기존 설정값을 그대로 유지합니다. CPU 사용량이 안정적이고 이미 적절히 설정되어 있다면 OFF로 두어도 됩니다. |
| Memory 자동 조정 | 토글 | ON | ON: VPA가 워크로드의 메모리 사용 패턴을 분석하여 requests.memory와 limits.memory를 자동으로 조정합니다. OFF: 메모리 리소스는 기존 설정값을 그대로 유지합니다. OOM 이력이 있는 워크로드는 반드시 ON으로 설정하세요. |
POLICY CONFIGURATION
VPA가 권장값을 워크로드에 반영하는 방식과 주기를 설정합니다.
적용 방식 — 변경된 리소스를 워크로드에 반영하는 방법입니다
| 옵션 | 설명 |
|---|---|
Rolling (파드 재시작) |
리소스 변경 시 기존 Pod를 종료하고 새 Pod를 생성하여 적용합니다. 모든 Kubernetes 버전에서 지원되며, 변경 사항이 확실하게 반영됩니다. 순간적인 재시작이 허용되는 워크로드에 적합합니다. |
In-place Resizing (무중단 변경) |
Pod를 재시작하지 않고 실행 중인 컨테이너의 리소스를 직접 변경합니다. Kubernetes 1.34 이상에서만 지원됩니다. 최초 적용 시 대상 워크로드의 모든 Pod가 1회 재시작되며, 이를 방지하려면 워크로드의 resizePolicy 및 resource requests/limits (Guaranteed 또는 Burstable QoS 보장)를 사전에 설정해야 합니다. 재시작 없이 리소스를 조정해야 하는 워크로드에 적합합니다. |
적용 빈도 — VPA 권장값을 워크로드에 반영하는 주기입니다
| 옵션 | 설명 |
|---|---|
Normal (24시간 주기) |
24시간마다 한 번씩 VPA 권장값을 검토하고 반영합니다. 리소스 변화가 느리고 안정적인 프로덕션 환경에 적합합니다. Pod 재시작 빈도를 최소화합니다. |
Aggressive (6시간 주기) |
6시간마다 VPA 권장값을 검토하고 반영합니다. 트래픽 패턴이 자주 바뀌거나 리소스 최적화를 빠르게 달성하고 싶은 경우에 적합합니다. 단, Pod 재시작 빈도가 높아집니다. |
리소스 여유율
VPA가 계산한 권장값에 안전 버퍼를 추가하여 실제 적용값을 결정합니다.
갑작스러운 트래픽 스파이크나 측정 오차에 대비하는 역할을 합니다.
| 필드 | 타입 | 기본값 | 설명 |
|---|---|---|---|
| Request 여유율 (%) | 슬라이더 | 20 | requests 값에 추가하는 버퍼 비율입니다. 예를 들어 VPA 권장 CPU가 100m이고 여유율이 20%이면 실제 requests.cpu는 120m으로 설정됩니다. requests는 노드 스케줄링의 기준이 되므로, 너무 낮으면 Pod가 노드에 배치되지 못할 수 있습니다. 일반적으로 10~30% 사이를 권장합니다. |
| Limit 여유율 (%) | 슬라이더 | 50 | limits 값에 추가하는 버퍼 비율입니다. 예를 들어 VPA 권장 메모리가 128MiB이고 여유율이 50%이면 실제 limits.memory는 192MiB로 설정됩니다. limits는 컨테이너가 사용 가능한 최대 리소스를 제한하므로, 너무 낮으면 CPU 쓰로틀링이나 OOM이 발생할 수 있습니다. Request 여유율보다 높게 설정하는 것을 권장합니다. |
최소 보장 리소스
VPA가 아무리 낮은 권장값을 내놓아도 이 값 이하로 내려가지 않도록 하한선을 설정합니다.
예상치 못한 VPA 오분석이나 순간 부하에 대비하는 안전망 역할을 합니다.
| 필드 | 타입 | 단위 | 기본값 | 설명 |
|---|---|---|---|---|
| CPU 최소 | 숫자 입력 | m (millicores) | 0 | CPU 리소스의 최솟값입니다. VPA 권장값이 이 값보다 낮더라도 반드시 이 만큼은 보장합니다. 0으로 설정하면 VPA 권장값이 그대로 적용됩니다. 서비스 응답성이 중요한 워크로드는 최소한의 CPU를 보장하도록 설정하세요. (예: Java 애플리케이션은 최소 100m 이상 권장) |
| Memory 최소 | 숫자 입력 | MB | 0 | 메모리 리소스의 최솟값입니다. VPA 권장값이 이 값보다 낮더라도 반드시 이 만큼은 보장합니다. 0으로 설정하면 VPA 권장값이 그대로 적용됩니다. JVM 기반 애플리케이션처럼 기본 메모리 소비가 큰 워크로드는 충분한 최솟값을 설정하여 OOM을 방지하세요. |
OOM 범프업
OOM(Out of Memory) Kill이 발생했을 때 메모리 리소스를 자동으로 증가시키는 기능입니다.
OOM Kill이 반복되면 설정한 비율만큼 메모리 limit을 즉시 올려 서비스 중단을 방지합니다.
| 필드 | 타입 | 기본값 | 설명 |
|---|---|---|---|
| OOM 범프업 비율 (%) | 슬라이더 | 80 | OOM Kill 발생 시 현재 메모리 limit에서 이 비율만큼 증가시킵니다. 예를 들어 현재 limit이 256MiB이고 범프업 비율이 80%이면, OOM 발생 후 limit이 460MiB로 증가합니다. 값이 높을수록 OOM 재발 가능성이 낮아지지만 메모리 과할당이 발생할 수 있습니다. |
계산 미리보기
현재 설정된 여유율과 최솟값을 기반으로 최종 적용 리소스를 미리 확인할 수 있는 읽기 전용 테이블입니다.
| 컬럼 | 설명 |
|---|---|
| Resource | 리소스 유형 (CPU / Memory) |
| VPA Rec. | VPA가 분석한 권장값 (예: 50m / 128MiB) |
| +Margin | 적용될 여유율 (예: +20% / +50%) |
| Min | 설정된 최소 보장값 |
| Final | 여유율과 최솟값을 모두 반영한 최종 적용값 (예: 60m / 192MiB) |
VPA 추천값이 제공되면 최종 리소스가 자동으로 계산됩니다.
오버헤드 전략 가이드
| 전략 | CPU 여유율 | 메모리 여유율 | 특징 | 권장 대상 |
|---|---|---|---|---|
| Conservative | 30% | 30% | 안정성 최우선 | 프로덕션 핵심 서비스 |
| Balanced | 20% | 20% | 균형 잡힌 접근 | 일반 프로덕션 |
| Aggressive | 10% | 10% | 최대 비용 절감 | 개발/테스트 환경 |
| Minimal | 5% | 5% | 극한 절감 | 비핵심 배치 작업 |
HPA (수평 Pod 오토스케일러)
CPU 사용률을 기반으로 Pod 수를 자동으로 늘리거나 줄입니다.
VPA가 각 Pod의 리소스 크기를 최적화한다면, HPA는 Pod의 수를 조정합니다. 두 기능을 함께 사용하면 더 효과적인 비용 절감이 가능합니다.
| 필드 | 타입 | 기본값 | 범위 | 설명 |
|---|---|---|---|---|
| 최소 레플리카 | 숫자 입력 | 1 | 1~100 | HPA가 아무리 축소해도 유지해야 할 최소 Pod 수입니다. 0으로 설정하면 트래픽이 없을 때 Pod가 완전히 제거될 수 있으므로 서비스 가용성을 고려하여 최소 1 이상을 권장합니다. |
| 최대 레플리카 | 숫자 입력 | 10 | 1~1000 | 트래픽이 급증해도 이 수를 초과하여 Pod를 추가하지 않습니다. 클라우드 비용 상한을 제어하는 역할을 하므로, 예상 최대 부하와 비용 한도를 함께 고려하여 설정하세요. |
| 목표 CPU 사용률 (%) | 숫자 입력 | 70 | 10~100 | HPA가 유지하려는 목표 CPU 사용률입니다. 전체 Pod의 평균 CPU 사용률이 이 값을 초과하면 Pod를 추가하고, 이 값보다 낮아지면 Pod를 줄입니다. 너무 낮게 설정하면 불필요하게 많은 Pod가 유지되고, 너무 높게 설정하면 스케일 업이 늦어져 응답 지연이 발생할 수 있습니다. 일반적으로 60~80% 사이를 권장합니다. |
SPOT INSTANCE
온디맨드 인스턴스 대신 저렴한 Spot 인스턴스에 워크로드를 배치하여 비용을 절감합니다.
Spot 인스턴스는 클라우드 제공자의 유휴 컴퓨팅 자원을 활용하기 때문에, 온디맨드 대비 최대 90%까지 저렴합니다.
ⓘ SPOT INSTANCE 탭을 활성화하면 비용 절감을 위해 Spot 노드를 활용합니다. 별도의 추가 설정 항목은 없습니다.
클라우드별 할인율
| 클라우드 | 명칭 | 할인율 |
|---|---|---|
| AWS | 스팟 인스턴스 | 최대 90% |
| Oracle | Preemptible Instance | 최대 50% |
⚠️ 주의사항
- Spot 인스턴스는 클라우드 제공자에 의해 언제든 회수될 수 있습니다. 회수 시 해당 노드의 Pod는 다른 노드로 재스케줄링됩니다.
- 스테이트리스 워크로드에만 적용을 권장합니다.
- 데이터베이스, 메시지 큐 등 상태를 유지해야 하는 스테이트풀 워크로드에는 사용하지 마세요.
ZERO RESOURCE (제로 스케일링)
트래픽이 없는 워크로드를 자동으로 Pod 0개로 축소하고, 트래픽 발생 시 자동으로 복구합니다.
개발/스테이징 환경이나 간헐적으로 사용되는 서비스에서 유휴 시간의 리소스 낭비를 근본적으로 없앱니다.
⚠️ 제한사항: 현재 감지 가능한 트래픽은 HTTP만 지원합니다. 또한 워커 노드의 커널(Kernel) 버전이 5.8 이상이어야 합니다.
WAKE-UP WINDOW
트래픽 발생을 감지하여 스케일 업을 판단하는 관측 설정입니다.
Pod가 0개인 상태에서 sensing pod이 요청을 감지하면, Wake-up Window 동안 요청 수를 측정하여 스케일 업 여부를 결정합니다.
| 필드 | 타입 | 단위 | 기본값 | 범위 | 설명 |
|---|---|---|---|---|---|
| Wake-up Window | 숫자 입력 | 초 | 60 | 60~3600 | 스케일 업을 판단하기 위해 트래픽을 관측하는 시간 윈도우입니다. 이 시간 동안 수신된 요청 수가 Wake-up Threshold 이상이면 Pod를 스케일 업합니다. 값이 짧을수록 빠르게 깨어납니다. |
| Wake-up Threshold | 숫자 입력 | 건 | 1 | 1~ | Wake-up Window 동안 수신되어야 스케일 업을 트리거하는 최소 요청 수입니다. 1로 설정하면 요청이 1건이라도 들어오면 즉시 스케일 업을 시작합니다. |
KEEP-ALIVE WINDOW
현재 실행 중인 Pod를 유지할지, 0으로 축소할지를 판단하는 관측 설정입니다.
이 윈도우 동안 트래픽이 Threshold 미만으로 유지되면 Pod를 0개로 축소합니다.
| 필드 | 타입 | 단위 | 기본값 | 범위 | 설명 |
|---|---|---|---|---|---|
| Keep-alive Window | 숫자 입력 | 초 | 600 | 60~86400 | 스케일 다운 여부를 판단하기 위해 트래픽을 관측하는 시간 윈도우입니다. 이 시간 동안 RPS가 계속 Keep-alive Threshold 미만이면 Pod를 0으로 축소합니다. 값이 클수록 보수적으로 동작하여 불필요한 스케일 다운을 방지하지만, 그만큼 유휴 비용이 발생합니다. |
| Keep-alive Threshold | 숫자 입력 | RPS | 1 | 1~ | Pod를 유지하기 위한 최소 RPS(초당 요청 수)입니다. Keep-alive Window 동안 측정된 RPS가 이 값 미만이면 스케일 다운 대상으로 판단합니다. |
MIN REPLICAS
활성 상태(Pod가 1개 이상인 상태)일 때 유지해야 할 최소/최대 Pod 수를 설정합니다.
"미지정" 체크박스를 선택하면 서버 기본값을 사용합니다.
| 필드 | 타입 | 기본값 | 범위 | 설명 |
|---|---|---|---|---|
| 미지정 (Min Replicas) | 체크박스 | 체크됨 | - | 체크 시 서버 기본값(1)을 사용합니다. 체크 해제 시 아래 Min Replicas 값을 직접 입력할 수 있습니다. |
| Min Replicas | 숫자 입력 | 1 | 1~1000 | 워크로드가 활성 상태일 때 유지해야 할 최소 Pod 수입니다. 스케일 다운 시에도 이 수 이하로 내려가지 않습니다. 0으로 완전히 축소되기 전, 최소한으로 유지할 Pod 수를 의미합니다. |
| 미지정 (Max Replicas) | 체크박스 | 체크됨 | - | 체크 시 서버 기본값(10)을 사용합니다. 체크 해제 시 아래 Max Replicas 값을 직접 입력할 수 있습니다. |
| Max Replicas | 숫자 입력 | 10 | 1~1000 | 트래픽이 급증해도 이 수를 초과하여 Pod를 추가하지 않습니다. 비용 상한을 제어하는 역할을 합니다. |
목표 RPS / REPLICA
HPA 계산의 기준이 되는 값으로, Pod 1개가 안정적으로 처리할 수 있는 초당 요청 수(RPS)를 설정합니다.
| 필드 | 타입 | 단위 | 기본값 | 범위 | 설명 |
|---|---|---|---|---|---|
| 목표 RPS / Replica | 숫자 입력 | RPS | 1 | 1~100000 | Pod 1개가 처리해야 할 목표 RPS입니다. 현재 전체 RPS를 이 값으로 나눈 결과가 필요한 Pod 수가 됩니다. 예를 들어 전체 RPS가 100이고 목표 RPS/Replica가 20이라면 HPA는 Pod를 5개로 맞춥니다. 워크로드의 실제 처리 능력을 측정하여 적절한 값을 설정하세요. |
작동 흐름
- eBPF 기반으로 워크로드의 HTTP RPS를 15초 주기로 수집합니다.
- Keep-alive Window 동안 RPS가 Keep-alive Threshold 미만이면 KEDA가
Active=False로 판정합니다. - 오토스케일러가 Pod 수를 0으로 조정합니다.
- 트래픽 재발생 시 sensing pod이 요청을 감지하면 즉시 wake-up하여 Pod를 증설합니다.
ℹ️ 메트릭 수집 주기는 시스템 고정값 15초입니다. (사용자 설정 불필요)
⏱ 실제 스케일링 반응 시간
Keep-alive Window가 경과하여 스케일 다운 판정이 시작된 후, 실제 Pod가 0개로 내려가기까지 최대 45초가 추가로 소요될 수 있습니다. 이 지연은 다음 3단계로 구성됩니다.
| 단계 | 최대 지연 | 이유 |
|---|---|---|
| 메트릭 수집 주기 대기 | ~15초 | eBPF 메트릭이 15초 주기로 수집되므로, 부하 감소가 저장소에 반영되기까지 다음 수집 주기를 기다려야 합니다. |
| 오토스케일러 평가 주기 대기 | ~15초 | 오토스케일러(KEDA)가 15초마다 한 번씩 상태를 평가하므로, 다음 평가 시점까지 대기가 필요합니다. |
| 스케일 다운 실행 | ~15초 | 오토스케일러가 Pod 수를 0으로 조정하는 명령이 실제로 반영되기까지의 전파 시간입니다. |
예: Keep-alive Window = 600초 설정 시, 부하 중단 후 실제 Pod 0개 도달까지 총 600~645초 소요.
💡 이 45초 오버헤드는 쿠버네티스 오토스케일링 파이프라인의 구조적 지연이며, 사용자 설정으로 단축할 수 없습니다. Keep-alive Window를 길게 설정할수록 이 오버헤드가 상대적으로 작게 느껴집니다.
Cold Start
Pod가 0에서 1로 스케일 업될 때 3~15초의 지연이 발생합니다.
Cold Start 최소화 방법:
- 컨테이너 이미지 크기 최적화 (100MB 이하 권장)
- readinessProbe 타임아웃 최소화
- Init Container 사용 최소화
- 애플리케이션 시작 시간 최적화
정책 관리
수정
정책 목록에서 수정 버튼을 클릭합니다.
⚠️ 주의: 이미 워크로드에 적용된 정책을 수정하면, 해당 워크로드에 변경 사항이 즉시 반영됩니다.
삭제
정책 목록에서 삭제 버튼을 클릭합니다.
⚠️ 주의: 워크로드에 적용 중인 정책은 삭제할 수 없습니다. 먼저 모든 워크로드에서 정책을 해제하세요.