lander.log

K8s HPA 설정 고려사항

5 min read

K8s HPA 설정 고려사항

Referenced by

정의 (Definition)

HPA(Horizontal Pod Autoscaler) 설정 고려사항은 “목표 메트릭으로 레플리카를 자동 조정”한다는 기능을 서비스 SLO/비용/안정성 관점에서 깨지지 않게 운영하기 위해 확인해야 하는 경계 조건 들의 집합입니다.

문제가 되는 배경 (Problem Context)

HPA는 레플리카만 늘려줍니다. 하지만 병목이 CPU가 아닌데 CPU로 스케일링하거나, 메모리 기반 스케일링을 과신하거나, 노드 확장 속도와 맞지 않게 레플리카가 폭증하면 “스케일링이 도리어 장애 트리거”가 될 수 있습니다.

핵심 메커니즘 (How it Works)

  • 단일 메트릭 vs 다중 메트릭: 여러 메트릭을 지정하면 HPA는 보통 “가장 많은 레플리카가 필요한 메트릭” 기준으로 확장합니다.
  • 메모리 기반 스케일링의 특성: 메모리 사용량은 GC/캐시/버퍼에 의해 완만하거나 히스테리시스가 커서, 레플리카를 늘려도 기존 파드의 메모리가 즉시 줄지 않을 수 있습니다.
  • request와의 결합: CPU/메모리 “사용률(%)” 기반 HPA는 request 값을 분모로 삼습니다. 즉 request를 낮게 잡으면 작은 사용량에도 쉽게 scale out이 발생할 수 있습니다.
  • 동작 안정화(behavior): 플래핑을 막기 위해 behavior의 안정화 창과 정책을 사용합니다.

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

  • 보장: HPA는 레플리카 수를 조정합니다.
  • 비보장: 레플리카 증가가 곧바로 처리량 증가를 보장하지는 않습니다(외부 의존성, 락 경합, DB 병목, 노드/쿼터 제약).
  • 경계: HPA는 수평 확장만 다루며, 개별 파드의 리소스 한계(예: 메모리 OOM)를 직접 해결하지 않습니다.

비유 (Analogy)

HPA는 “직원을 더 채용하는” 정책이고, request/limit은 “직원 1명이 쓸 수 있는 자리/장비”에 가깝습니다. 채용만 늘려서는 장비 부족(메모리 OOM) 문제를 해결할 수 없습니다.

실무적 함의 (Operational Implications)

  • 주 병목 메트릭을 먼저 정의: CPU, 큐 길이, 요청률, p95 latency 등 서비스 특성에 맞는 메트릭이 스케일링 신호가 되어야 합니다.
  • 노드 확장과 정합성: HPA가 빨리 늘어도 노드가 늦게 늘면 Pending이 쌓입니다. behavior.scaleUp 정책으로 상승률을 제한하는 설계가 필요합니다.
  • 메모리 스케일링은 보조로: 메모리 기반 HPA는 “OOM 직전 회피” 장치로 과신하기보다는, 서비스 특성에 따라 보조 신호로 사용하는 편이 안전합니다.

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

  • “메모리가 차면 HPA가 늘려서 OOM이 안 난다”: 레플리카 증가가 기존 파드의 메모리를 즉시 줄이지 못하면 OOM은 그대로 발생할 수 있습니다.
  • request를 낮게 잡고 HPA로 커버: request는 스케줄링·HPA 분모에 동시에 영향을 주므로, 낮게 잡으면 플래핑/노드 폭증을 유발할 수 있습니다.

References

Recent Posts