Timing Controls

응답성과 안정성의 균형을 맞추는 타이밍 제어로 스케일링 동작을 세밀하게 조정합니다.

사용 가능한 옵션

Warming Up Time

Pod 초기화 중에는 메트릭을 무시해, 불안정한 시작 데이터로 인한 섣부른 스케일링 결정을 방지합니다.

동작 방식: Autopilot은 설정된 시간 동안 새로 생성된 Pod의 메트릭을 건너뛰어, 초기화가 끝나기 전에 scale-in이 발생하지 않도록 합니다.

기본값: 10초

사용 시점: 시작이 느린 애플리케이션(데이터베이스 연결, 캐시 warming, 모델 로딩)

권장값:

30~60초: 빠르게 시작하는 앱(Go, Node.js, stateless 서비스)
120~300초: 일반적인 앱(Python, Ruby, 대부분의 API)
300~600초: 느리게 시작하는 앱(JVM 앱, ML 모델 로딩, 대용량 캐시)

Stabilization Window

scale-in만 지연시켜, 빠른 scale-out은 그대로 허용하면서 섣부른 scale-down은 방지합니다.

동작 방식: scale-in 결정이 내려지면 Autopilot은 설정된 시간만큼 대기한 후 변경을 적용합니다. scale-out은 즉시 이루어집니다.

사용 시점: 트래픽이 갑자기 줄었다가 빠르게 회복할 수 있는 경우(피크 시간 종료, 일시적인 소강)

Control Type	Behavior	Best For
Stabilization Window	scale-in만 지연	트래픽 변동이나 일시적 스파이크가 있는 워크로드

Cooldown Period

스케일링 작업 이후 scale-in과 scale-out을 모두 지연시킵니다.

동작 방식: 스케일링 변경이 일어난 후, Autopilot은 설정된 시간만큼 대기한 다음 다시 스케일링을 결정합니다.

⚠️

사용 시점: 스케일링 이후 안정성이 필요한 워크로드(stateful 서비스, connection pool, 분산 캐시)

Control Type	Behavior	Best For
Cooldown Period	scale-in과 scale-out을 모두 지연	스케일링 이후 안정성이 필요한 워크로드

Immediate Scaling

스케일링 작업에 지연이 없습니다. 트리거되면 scale-in과 scale-out 모두 즉시 실행됩니다.

동작 방식: Autopilot이 타이밍 제한 없이 메트릭에 따라 즉시 스케일링합니다.

⚠️

사용 시점: 트래픽 패턴이 매우 일정해 빠른 스케일링이 안전한 워크로드, 또는 min replica 기준선이 높아 공격적인 스케일링도 감당할 수 있는 워크로드

Control Type	Behavior	Best For
Immediate Scaling	지연 없이 즉시 스케일링	트래픽이 일정하고 min replica 기준선이 높은 워크로드

Gradual Scale-In

목표 replica 수로 즉시 줄이는 대신 단계적으로 scale-down합니다.

동작 방식: 활성화하면 목표로 산출된 replica 수까지 한 번에 낮추지 않고, 한 번에 1개씩 줄입니다.

사용 시점: replica가 급격히 줄어들면 연결 끊김이나 데이터 재분배 문제가 생길 수 있는 stateful 워크로드나 서비스

Control Type	Behavior	Best For
Gradual Scale-In	단계적 scale-down(한 번에 1개씩)	connection draining이 필요한 stateful 서비스

적절한 설정 선택하기

💡

트래픽이 불규칙하게 튀는 워크로드: 섣부른 scale-down을 막기 위한 Stabilization Window(60~120초)

Stateful 서비스: Cooldown Period(120~300초) + Gradual Scale-In

트래픽이 일정한 경우: 적절한 min/max 범위와 함께 Immediate Scaling

비용에 민감한 경우: 스케일링이 오락가락하지 않도록 Stabilization Window(30~60초)

설정 예시

예시 1: 빠르게 시작하는 Stateless 웹 서비스

Warming Up Time: 30s
Stabilization Window: 60s (default)
Cooldown: None
Gradual Scale-In: Disabled

이유: 빠른 시작, flapping에 대한 표준적인 보호

예시 2: 데이터베이스 연결이 있는 Java 애플리케이션

Warming Up Time: 300s
Stabilization Window: 180s
Cooldown: None
Gradual Scale-In: Enabled

이유: JVM warmup이 길고, connection pool에 시간이 필요하며, gradual scale-in으로 connection storm을 방지합니다

예시 3: 백그라운드 워커(비용 최적화)

Warming Up Time: 30s
Stabilization Window: None (Immediate Scaling)
Cooldown: None
Gradual Scale-In: Disabled

이유: 시작이 빠르고, 안정성보다 비용이 중요하며, 부하가 일정해 별도 보호가 필요 없습니다

예시 4: Connection 상태가 있는 Stateful 서비스

Warming Up Time: 120s
Stabilization Window: 300s
Cooldown: None
Gradual Scale-In: Enabled

이유: 상태 설정에 시간이 필요하고, gradual scale-in으로 한 번에 너무 많은 connection을 잃지 않도록 합니다

예시 5: 고안정성 프로덕션 API

Warming Up Time: 180s
Stabilization Window: None
Cooldown: 180s
Gradual Scale-In: Enabled

이유: cooldown으로 스케일링 요동을 방지하고, 스케일링이 일어날 때는 gradual scale-in을 적용합니다

문제 해결

⚠️

Pod 시작 중에 스케일링이 발생하나요?

Autopilot이 초기화 중에 scale-up합니다

해결: Warming Up Time을 늘려 전체 시작 기간을 덮으세요

scale up/down이 자주 반복되나요?

replica가 몇 분마다 바뀝니다

해결:

Stabilization Window를 추가하거나 늘리세요(60~180초)
모든 스케일링을 막아야 한다면 Cooldown Period로 전환하세요

scale-down 중에 서비스 장애가 발생하나요?

scale-in 시 오류가 발생하거나 응답이 느려집니다

해결: Gradual Scale-In을 활성화해 Pod를 더 작은 단위로 제거하세요

scale-up이 너무 느린가요?

트래픽 증가 시 지연이 발생합니다

해결:

Cooldown이 아니라 Stabilization Window를 사용하세요
Predictive Scaling을 활성화하세요
Warming Up Time이 너무 길지는 않은지 확인하세요