95. HPA (Horizontal Pod Autoscaler) - CPU 기반 파드 자동 스케일링

핵심 인사이트 (3줄 요약)

1. 본질: HPA (Horizontal Pod Autoscaler)는 트래픽 증가에 대응하여 쿠버네티스 파드 (Pod)의 개수를 동적으로 늘리거나 줄이는 수평 스케일링 자동화 컨트롤러다.
2. 가치: 인프라 팀의 수동 개입 없이 트래픽 폭주 시 서비스 중단을 막고, 유휴 시에는 자원 사용량을 줄여 클라우드 비용을 최적화한다.
3. 판단 포인트: 메트릭 서버 (Metrics Server)와 파드 단위의 자원 요청량 (resources.requests) 설정이 필수 전제조건이며, 플래핑 (Flapping) 현상 방지를 위해 쿨다운 설정을 병행해야 한다.

Ⅰ. 개요 및 필요성

HPA (Horizontal Pod Autoscaler)는 쿠버네티스 (Kubernetes) 환경에서 애플리케이션 파드의 개수를 CPU 사용률이나 메모리 등 특정 메트릭에 따라 자동으로 조절하는 기능이다. 관리자가 설정한 목표 자원 사용률을 유지하기 위해 파드의 레플리카 (Replica) 수를 지속적으로 계산하고 조정한다.

이 개념이 등장한 이유는 트래픽의 예측 불가능성 때문이다. 고정된 파드 수로는 새벽 시간대의 자원 낭비나 이벤트 시점의 트래픽 폭주로 인한 서버 다운을 막을 수 없다. 단일 서버의 스펙을 올리는 수직 스케일링 (VPA, Scale-up)은 서비스 중단이 불가피하고 물리적 한계가 존재하기 때문에, 무중단으로 무한정 복제하여 부하를 분산시키는 수평 스케일링 (Scale-out) 방식인 HPA가 필수적인 클라우드 생존 전략이 되었다.

• 📢 섹션 요약 비유: 식당에 갑자기 손님이 몰릴 때 주방장 한 명에게 억지로 요리를 더 시키지 않고, 대기실에 있던 알바생을 즉각 투입하여 요리를 분담시키는 지능형 점장과 같다.

Ⅱ. 아키텍처 및 핵심 원리

HPA는 내부적으로 제어 루프 (Control Loop)를 돌며 보통 15초 단위로 메트릭을 수집하고 파드 개수를 계산한다. 이를 위해서는 파드들의 상태를 실시간 수집하는 메트릭 서버가 클러스터에 배포되어 있어야 하며, 각 파드는 YAML 파일에 자신의 기초 체력인 resources.requests를 명시해야 한다.

┌──────────────────────────────────────────────────────────────┐
│           HPA 제어 루프: 15초 주기의 메트릭 평가 및 조정        │
├──────────────────────────────────────────────────────────────┤
│ [파드 부하 증가] ─▶ [Metrics Server 수집] ─▶ [HPA 수식 계산]  │
│                                                     │        │
│    (목표 레플리카 = 현재 레플리카 × 현재 메트릭 / 목표 메트릭)    │
│                                                     │        │
│ [부하 분산 안정화] ◀─ [Deployment/ReplicaSet 개수 갱신] ◀───┘
└──────────────────────────────────────────────────────────────┘

HPA는 "목표 파드 수 = 올림(현재 파드 수 * (현재 메트릭 / 목표 메트릭))"이라는 수학적 공식을 통해 몇 개의 파드가 추가로 필요한지 도출한다. requests 값이 없으면 HPA는 기준점을 잡지 못해 스케일링을 멈추게 된다.

• 📢 섹션 요약 비유: 점장이 알바를 투입하려면 주방장들의 스마트워치(메트릭 서버) 심박수 정보와 원래 처리 가능한 요리 수(requests) 기준이 있어야 계산이 가능하다.

Ⅲ. 비교 및 연결

스케일링 방식은 대상의 특성과 확장 방향에 따라 수직 스케일링(VPA)과 수평 스케일링(HPA), 그리고 노드 자체를 늘리는 클러스터 오토스케일러(CA)로 나뉜다.

최근에는 단순 CPU/RAM을 넘어 카프카(Kafka) 큐에 쌓인 메시지 수 같은 비즈니스 지표를 기반으로 동작하는 커스텀 메트릭(Custom Metrics, 예: KEDA)으로 HPA의 범위가 확장되고 있다. HPA가 파드를 늘렸는데 노드에 공간이 없으면 그때 CA가 작동하여 물리 서버를 늘리는 식으로 연계된다.

• 📢 섹션 요약 비유: HPA는 식당 내부의 요리사를 늘리는 것이고, VPA는 요리사의 프라이팬 크기를 키우는 것이며, CA는 식당 건물 자체를 증축하는 것이다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서 HPA 적용 시 가장 주의해야 할 점은 스케일 인 플래핑 (Scale-in Flapping) 현상이다. 트래픽이 일시적으로 줄어들 때 파드를 급격히 삭제하면, 곧이어 발생하는 트래픽에 대응하지 못하고 서버가 마비될 수 있다.

실무 체크리스트

1. 쿨다운 (Cooldown) 설정: 파드를 늘릴 때는 즉시 반응하되, 줄일 때(Scale-in)는 최소 5분(안정화 윈도우) 이상 기다린 후 천천히 줄이도록 설정했는가?
2. resources.requests 검증: 모든 대상 파드에 CPU/RAM 요청량이 정확하게 할당되어 있는가?
3. 병목 지점 확인: 앱 서버(파드)는 HPA로 늘어났는데, 뒤단 DB의 커넥션 풀이 감당하지 못해 뻗어버리는 아키텍처 결함은 없는가?

안티패턴

• requests와 limits를 엉터리로 설정해 HPA가 아예 동작하지 않는 상태로 방치하기

• DB와 같이 상태가 강하게 결합된 워크로드에 HPA를 무리하게 적용하여 데이터 정합성 깨기

• 📢 섹션 요약 비유: 손님이 잠깐 줄었다고 알바생을 즉시 퇴근시키면 다음 단체 손님 때 식당이 망한다. 현명한 점장은 5분 정도 대기시킨 후 퇴근시킨다.

Ⅴ. 기대효과 및 결론

HPA를 올바르게 구성하면 운영자는 트래픽 폭주로 인한 새벽 장애 알람에서 해방될 수 있다. 애플리케이션은 스스로 부하를 감지하고 유연하게 크기를 조절하며, 불필요한 클라우드 요금 지출을 원천적으로 차단한다.

하지만 HPA는 만능이 아니며, 인프라의 여유 공간(노드 자원)과 외부 의존성(DB 커넥션 등)이 함께 받쳐줄 때만 완벽하게 동작한다. 미래에는 KEDA와 같은 이벤트 기반 자동 스케일링이 기본이 되어, CPU 수치가 아닌 실제 비즈니스 부하 지표를 중심으로 HPA가 더욱 정교해질 것이다. HPA는 "클라우드 네이티브의 탄력성(Elasticity)을 완성하는 가장 기초적인 심장박동"으로 기억해야 한다.

• 📢 섹션 요약 비유: HPA는 평소에는 작은 식당을 운영하다가, 축제 기간에만 거대한 뷔페로 변신하고 다시 원래대로 돌아오는 마법의 건축술과 같다.

📌 관련 개념 맵

📈 관련 키워드 및 발전 흐름도

메트릭 서버 (Metrics Server) 수집
    │
    ▼
HPA (Horizontal Pod Autoscaler)의 CPU/RAM 기반 스케일링
    │
    ▼
스케일 인 플래핑 (Flapping) 방지 및 쿨다운 튜닝
    │
    ▼
KEDA (Kubernetes Event-driven Autoscaling) 커스텀 메트릭
    │
    ▼
CA (Cluster Autoscaler)와의 유기적 연동 (서버 자동 증설)

이 흐름도는 "상태 측정 → 기본 스케일링 → 안정성 확보 → 비즈니스 지표 확장 → 물리 인프라 확장"으로 개념이 진화하는 과정을 보여준다.

👶 어린이를 위한 3줄 비유 설명

1. HPA는 쿠버네티스 성을 지키는 마법사 점장님이에요.
2. 성에 몬스터(트래픽)가 많이 쳐들어와서 병사 한 명(파드)이 힘들어하면, 뿅 하고 똑같은 병사들을 여러 명 복제해서 도와줘요.
3. 몬스터가 다 도망가면 복제된 병사들을 다시 돌려보내서 식량(클라우드 비용)을 아껴준답니다!