Core Configuration

이 페이지는 Autopilot의 전체 설정 항목을 정리한 레퍼런스입니다. 주요 기능에 대한 자세한 설명은 각 링크된 가이드를 참고하세요.

설정 접근 방법

웹 콘솔에서 Autopilot을 설정합니다:

1. Deployments로 이동 → 배포 선택
2. Autopilot 탭으로 이동
3. Edit을 클릭해 설정 모달을 엽니다

전체 설정 항목

설정 모달은 다음 섹션으로 구성되어 있습니다:

Scaling Mode

Autopilot이 스케일링 결정을 적용할지를 제어합니다:

참고: 모드 선택 가이드는 Getting Started를 확인하세요

Objective (왼쪽 컬럼)

Scaling Strategy

최적화 우선순위를 선택합니다:

• Optimize for Performance: 보수적으로 스케일링하며 여유 용량(헤드룸)을 유지합니다
• Optimize for Cost: 균형 잡힌 스케일링으로 불필요한 여유 용량을 최소화합니다

참고: 자세한 비교는 Cost vs Performance Optimization을 확인하세요

Application Type

워크로드의 리소스 프로파일입니다:

• CPU Intensive: 연산 위주 워크로드(웹 서버, API, 처리 작업)에 적합합니다
• Memory Intensive: 메모리 위주 워크로드(캐싱, 인메모리 데이터베이스)에 적합합니다

어떤 메트릭을 우선할지와 폴백 계산 방식에 영향을 줍니다.

CPU Utilization Basis

Wave 3.4.5+. Application Type이 CPU Intensive일 때만 표시됩니다.

이 워크로드에서 "CPU 100%"가 무엇을 뜻하는지 정합니다.

• Request(기본값): 사용률을 컨테이너의 CPU request 기준으로 잽니다. HPA와 같은 방식이며 대부분의 워크로드에 맞습니다.
• Limit: 사용률을 컨테이너의 CPU limit 기준으로 잽니다.

request를 일부러 작게 잡아 스케줄러가 Pod를 조밀하게 배치하도록 하면서도, 스케일링은 Pod가 실제로 쓸 수 있는 CPU 여유를 기준으로 하고 싶다면 Limit을 고르세요. request가 작으면 request 기준 사용률이 금방 포화되어, 실제 여유에 비해 이르게 스케일 아웃이 걸립니다. limit 기준 사용률은 그 여유를 따라가므로 같은 트래픽에서 보통 더 적은 replica로 수렴합니다.

• CPU limit이 없는 컨테이너는 자동으로 Request 기준으로 돌아갑니다.
• request와 limit이 둘 다 없는 컨테이너는 기존과 동일하게 스케일링되지 않습니다.
• Request와 Limit 사이를 전환하면 학습된 모델이 무효화됩니다. 다른 기준으로 학습된 모델을 재사용하지 않고 새 기준으로 다시 학습하므로, 변경 직후 잠깐의 워밍업 구간이 생깁니다.

Fallback Only

Wave 3.4.5+.

Autopilot이 ML 예측 단계를 아예 건너뛰고 임계값 기반 폴백 계산만으로 스케일링하도록 하는 토글입니다. 이때 모든 스케일링 이벤트는 Fallback apply type으로 기록됩니다.

모델을 끼우지 않고 빠른 반응 경로만 쓰고 싶을 때 사용하세요. 예를 들어 새 워크로드가 아직 학습 데이터를 모으는 중이거나, 설정한 임계값만으로 스케일링 동작을 온전히 설명할 수 있어야 할 때입니다.

Scaling Metrics

부하를 추적하는 기본 메트릭입니다:

• Network In: 수신 네트워크 트래픽(바이트)을 기준으로 스케일링합니다
• Requests: 요청 수를 기준으로 스케일링합니다

워크로드의 부하를 가장 잘 대표하는 지표를 선택하세요.

Predictive Scaling

시계열 포캐스팅으로 트래픽 발생 전에 미리 스케일링하는 기능을 켜는 토글입니다.

참고: 전체 가이드는 Predictive Scaling을 확인하세요

Behaviors (오른쪽 컬럼)

Min Replicas

항상 유지할 최소 Pod 개수입니다.

• 기본값: 1
• 권장값: 기준 부하와 가용성 요구사항에 맞춰 설정하세요
• 예시: 고가용성 서비스라면 3으로 설정하세요

Max Replicas

허용되는 최대 Pod 개수입니다.

• 기본값: 10
• 권장값: 예상 최대 부하와 비용 한도에 맞춰 설정하세요
• 예시: 트래픽 변동이 큰 경우 50으로 설정하세요

Fallback CPU Utilization

ML 기반 판단을 사용할 수 없을 때의 목표 CPU 사용률(%)입니다.

• 기본값: 50%
• 범위: 0% 초과. 기존의 100% 상한은 Wave 3.4.5에서 없어졌습니다. Pod를 request나 limit 기준을 넘겨 운용하다가 스케일 아웃하려는 경우 100을 넘는 값도 유효합니다.
• 측정 기준: 위에서 고른 CPU Utilization Basis(기본값 request, 또는 limit)입니다.
• 동작 방식: HPA 방식 계산을 사용합니다: desired_replicas = current_replicas * (current_cpu / target_cpu)

Fallback Memory Utilization

목표 메모리 사용률(%)입니다(Memory Intensive 워크로드에만 적용).

• 기본값: 50%
• 범위: 10~100%
• 적용 시점: Application Type이 "Memory Intensive"일 때만 적용됩니다

Warming Up Time

배포 시작 후 메트릭을 무시할 시간(초)입니다.

• 기본값: 10초
• 목적: Pod 초기화 중 스케일링 결정이 내려지지 않도록 방지합니다
• 권장값: 빠르게 시작하는 앱은 3060초, 일반 앱은 120300초, JVM 앱은 300~600초로 설정하세요

참고: 자세한 설명은 Timing Controls를 확인하세요

Scaling Adjustment Type

스케일링 작업의 타이밍을 제어합니다(하나만 선택):

• Stabilization Window (s): scale-in만 지연시킵니다(가장 많이 사용하는 옵션)
  • 지속 시간을 입력하는 필드입니다(기본값: 60초)
• Cooldown Period (s): 스케일링 이벤트 이후 모든 스케일링을 지연시킵니다(거의 필요하지 않음)
  • 선택 시 지속 시간을 입력하는 필드가 나타납니다
• Immediate Scaling: 지연 없이 즉시 적용합니다(예측 가능한 워크로드에 적합)

Gradual Scale-In

단계적 scale-down 동작을 위한 별도 토글입니다:

• 토글: 활성화/비활성화
• 활성화 시: 목표치로 한 번에 낮추지 않고 레플리카를 1개씩 줄입니다
• 사용 대상: Stateful 서비스, connection draining이 필요한 서비스, Pod를 한꺼번에 제거하면 장애가 발생하는 서비스

참고: 각 유형을 언제 사용해야 하는지는 Timing Controls를 확인하세요

Thresholds (하단 왼쪽)

메트릭이 설정한 임계값 아래로 떨어지면 긴급 scale-down을 트리거합니다. 필요에 따라 개별적으로 활성화하세요:

CPU Threshold

• 토글: 활성화/비활성화
• 값: 퍼센트(예: 10%)
• 동작: CPU가 임계값 아래로 떨어지면 즉시 min_replicas로 스케일링합니다

Memory Threshold

• 토글: 활성화/비활성화
• 값: 퍼센트(예: 15%)
• 동작: 메모리가 임계값 아래로 떨어지면 즉시 min_replicas로 스케일링합니다

Requests Threshold

• 토글: 활성화/비활성화
• 값: 요청 수(예: 100)
• 동작: 요청 수가 임계값 아래로 떨어지면 즉시 min_replicas로 스케일링합니다

목적: 부하가 완전히 사라졌을 때(예: 영업시간 외 트래픽 중단) 즉시 비용을 절감합니다.

참고: 임계값 기반 스케일링은 일반 cooldown 기간을 건너뛰지만 Stabilization Window는 그대로 따릅니다.

특정 컨테이너 메트릭 제외 (하단 오른쪽)

Container Name

메트릭 수집에서 제외할 컨테이너 이름 목록입니다.

• 사용 사례: 스케일링에 영향을 주면 안 되는 Sidecar 컨테이너(Istio proxy, 로깅 에이전트 등)
• 형식: 태그 입력 방식으로 컨테이너 이름을 입력합니다
• 예시: istio-proxy, filebeat, fluentd

설정 예시

예시 1: 트래픽이 많은 웹 API

Mode: Autopilot
Strategy: Optimize for Performance
Application Type: CPU Intensive
Scaling Metrics: Requests
Predictive Scaling: Enabled
Min Replicas: 5
Max Replicas: 30
Fallback CPU: 70%
Warming Up: 60s
Scaling Adjustment: Stabilization Window (120s)
Gradual Scale-In: Disabled
CPU Threshold: Enabled (10%)

이유: 사용자 대면 서비스라 빠른 응답이 필요하고 여유 용량을 유지합니다

예시 2: 비용 최적화된 백그라운드 워커

Mode: Autopilot
Strategy: Optimize for Cost
Application Type: CPU Intensive
Scaling Metrics: Network In
Predictive Scaling: Disabled
Min Replicas: 1
Max Replicas: 20
Fallback CPU: 80%
Warming Up: 30s
Scaling Adjustment: Immediate Scaling
Gradual Scale-In: Disabled
Thresholds: None

이유: 백그라운드 처리 작업이라 지연 시간보다 비용이 더 중요합니다

예시 3: 영업시간 서비스

Mode: Autopilot
Strategy: Optimize for Performance
Application Type: Memory Intensive
Scaling Metrics: Requests
Predictive Scaling: Enabled
Min Replicas: 3
Max Replicas: 25
Fallback CPU: 65%
Fallback Memory: 70%
Warming Up: 120s
Scaling Adjustment: Stabilization Window (180s)
Gradual Scale-In: Enabled
Memory Threshold: Enabled (15%)

이유: 메모리 사용량이 많고 영업시간 패턴이 일정한 서비스입니다

설정 모범 사례

초기 설정

프로덕션 배포

자주 쓰는 패턴

검증 및 테스트

활성화 전

활성화 후

변경 사항 테스트

문제 해결

관련 문서

• Getting Started: Autopilot 초기 설정
• Cost vs Performance: 전략 선택 가이드
• Predictive Scaling: 포캐스팅 설정
• Timing Controls: 스케일링 조정 유형과 warming up 시간
• Autopilot Scheduler: 시간 기반 설정 변경
• Min/Max Recommendations: 최소/최대 권장값 중에서 선택

Configuration API

프로그래밍 방식으로 설정하려면 API 문서(공개 예정)를 참고하거나, 웹 콘솔의 export 기능으로 설정 파일을 생성하세요.