lander.log

K8s HPA stabilizationWindowSeconds

3 min read

K8s HPA stabilizationWindowSeconds

정의 (Definition)

stabilizationWindowSeconds는 Horizontal Pod Autoscaler(HPA)가 스케일링 결정을 내릴 때 과거 추천치(recommendation)를 일정 시간 창으로 함께 고려 해 급격한 변동을 완화하는 시간(초)입니다.

문제가 되는 배경 (Problem Context)

메트릭은 본질적으로 노이즈가 있습니다. 특히 scale down은 “줄였다가 다시 늘리는” 왕복 비용(기동, 캐시 재구성, 커넥션 워밍업)이 크기 때문에, 짧은 하락에 즉시 반응하면 플래핑이 발생합니다.

핵심 메커니즘 (How it Works)

behavior.scaleUp과 behavior.scaleDown 각각에 대해 안정화 창을 둘 수 있습니다.

  • 일반적으로 scaleDown 에 안정화 창을 두어, 최근 일정 시간 동안의 추천치를 참고해 급격한 축소를 방지합니다.
  • scaleUp 은 즉시 대응이 필요한 경우가 많아 기본값이 0초인 설정이 흔합니다.

불변 조건과 보장 범위 (Invariants & Guarantees)

  • 보장: 안정화 창은 HPA가 레플리카를 결정하는 과정에서 “완충”으로 작동합니다.
  • 비보장: 안정화 창이 있다고 해서 트래픽 급변 시 지연/에러가 발생하지 않는다고 보장할 수는 없습니다(워크로드 특성·리소스 여유·노드 확장 지연 등).

비유 (Analogy)

stabilizationWindowSeconds는 센서 노이즈를 줄이기 위해 사용하는 저역통과 필터(평활화) 에 가깝습니다. 단기 변동은 무시하고 추세를 봅니다.

실무적 함의 (Operational Implications)

  • 워밍업/캐시 비용이 큰 서비스는 scaleDown.stabilizationWindowSeconds를 길게 잡는 것이 일반적으로 안정적입니다.
  • 반대로 이벤트성 트래픽(짧고 큰 스파이크)을 빠르게 흡수해야 한다면 scaleUp에 안정화 창을 두는 것은 신중해야 합니다.

주의사항 / 오해 (Pitfalls & Misconceptions)

  • 안정화 창을 키우면 플래핑은 줄지만,축소가 느려져 비용이 증가 할 수 있습니다.
  • 안정화 창만으로는 스케일 속도(변화율)를 제한하지 못합니다. 변화율 제한은 K8s HPA policies가 담당합니다.

References

Recent Posts