Infra

Apr 2, 2026

Kubernetes HPA 가이드: Pod 수를 자동으로 늘리고 줄이는 방법

쿠버네티스를 조금 익히고 나면 자연스럽게 드는 질문이 있습니다. 트래픽이 늘어날 때 Pod 수를 사람이 직접 늘려야 할까, 아니면 자동으로 조절할 수 있을까 하는 질문입니다.

이때 자주 등장하는 리소스가 HPA(Horizontal Pod Autoscaler)입니다. 이름은 길지만 핵심은 단순합니다. 현재 부하를 보고 Pod replica 수를 자동으로 늘리거나 줄이는 기능입니다.

이 글에서는 아래 내용을 정리합니다.

HPA가 무엇인지
Deployment와 어떤 관계인지
CPU와 메모리 기준 자동 확장을 어떻게 이해하면 좋은지

핵심은 HPA는 Pod 하나를 더 강하게 만드는 기능이 아니라, Pod 개수를 수평으로 조절하는 자동화 도구라는 점입니다.

Kubernetes HPA란 무엇인가

HPA는 워크로드의 현재 리소스 사용량이나 메트릭을 보고 replica 수를 자동으로 조정하는 리소스입니다. 트래픽이 늘면 Pod를 더 만들고, 부하가 줄면 Pod 수를 줄입니다.

즉, HPA는 아래 같은 상황을 자동화합니다.

평소에는 Pod 2개로 충분하다
점심 시간에는 트래픽이 급증한다
야간에는 다시 부하가 줄어든다

이 변화를 사람이 수동으로 맞추는 대신, HPA가 일정 기준에 따라 조절하게 하는 것입니다.

왜 HPA가 필요할까

트래픽은 보통 고정되어 있지 않습니다. 특정 시간대, 이벤트, 배치 작업, 외부 요청 패턴 때문에 부하가 계속 달라질 수 있습니다.

이때 replica 수를 고정하면 두 가지 문제가 생기기 쉽습니다.

너무 적게 잡으면 피크 시간에 응답이 느려진다
너무 크게 잡으면 한가한 시간에도 자원을 낭비한다

HPA는 이 사이에서 동적으로 replica 수를 조절해 줍니다.

HPA 는 무엇을 대상으로 동작할까

보통 HPA는 Deployment 같은 워크로드 리소스를 대상으로 붙습니다. 즉, HPA가 직접 Pod를 개별적으로 관리하는 것이 아니라, Deployment의 replica 수를 조정한다고 이해하면 쉽습니다.

흐름은 보통 이렇습니다.

Deployment가 Pod를 관리한다
HPA가 Deployment의 replica 수를 조절한다

그래서 HPA를 이해하려면 Kubernetes Deployment 가이드와 같이 보는 것이 특히 좋습니다.

가장 기본적인 HPA 예시

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

이 설정은 web Deployment를 대상으로, 평균 CPU 사용률이 70%를 넘는 방향이면 replica 수를 늘리고, 낮아지면 다시 줄이는 식으로 동작하게 만듭니다.

중요한 것은:

최소 replica 수는 2
최대 replica 수는 10
기준 메트릭은 CPU

라는 운영 경계를 같이 정한다는 점입니다.

Horizontal 이라는 말은 무엇을 뜻할까

이름의 Horizontal은 “옆으로 늘린다”는 뜻입니다. 즉, 하나의 Pod에 CPU나 메모리를 더 주는 것이 아니라, 같은 Pod를 여러 개로 늘리는 방식입니다.

예를 들어:

Vertical scaling: Pod 하나를 더 크게 만듦
Horizontal scaling: 같은 Pod를 여러 개로 늘림

쿠버네티스에서는 stateless 웹 앱이나 API 서버처럼 여러 replica로 나누기 쉬운 워크로드에 HPA가 특히 잘 맞습니다.

CPU 와 메모리 기준은 어떻게 봐야 할까

입문 단계에서는 보통 CPU 기준 autoscaling부터 이해하는 편이 가장 쉽습니다. 요청량이 늘면 CPU 사용률이 같이 오르는 앱이 많기 때문입니다.

메모리 기준도 가능하지만, CPU와는 해석이 다를 수 있습니다.

CPU: 순간 부하 변화에 더 민감한 편
메모리: 사용량이 오래 유지될 수 있어서 바로 줄어들지 않을 수 있음

즉, 메모리 기준 autoscaling은 앱 특성을 더 잘 보고 써야 합니다.

HPA 가 잘 동작하려면 무엇이 필요할까

HPA는 단순히 리소스만 만든다고 끝나지 않습니다. 몇 가지 전제가 중요합니다.

1. metrics 서버가 있어야 한다

CPU, 메모리 기반 autoscaling을 하려면 클러스터가 해당 메트릭을 수집할 수 있어야 합니다.

2. resource request 가 현실적이어야 한다

HPA는 보통 request 기준 활용률을 보기 때문에, request가 너무 비현실적이면 autoscaling 판단도 왜곡될 수 있습니다.

3. 앱이 수평 확장에 맞는 구조여야 한다

세션 상태를 한 Pod 안에만 들고 있거나, replica를 늘려도 병목이 그대로면 HPA만으로는 충분하지 않을 수 있습니다.

자주 하는 오해

1. HPA를 붙이면 무조건 성능 문제가 해결된다

그렇지 않습니다. 병목이 DB, 외부 API, 락, 큐 적체에 있으면 Pod 수만 늘려도 효과가 제한적일 수 있습니다.

2. request 를 대충 잡아도 autoscaling은 똑같이 잘 된다

HPA는 request와 메트릭 가정의 영향을 크게 받습니다. 기준이 이상하면 scale 판단도 이상해집니다.

3. 상태 저장 앱도 그냥 HPA로 늘리면 된다

가능한 경우도 있지만, stateless 앱보다 고려할 점이 많습니다.

처음 공부할 때 추천하는 실습

CPU request가 설정된 Deployment 만들기
HPA를 minReplicas: 2, maxReplicas: 5로 붙이기
부하 테스트를 걸어 replica 수가 늘어나는지 보기
부하를 멈춘 뒤 다시 줄어드는지 보기

이 과정을 직접 보면 HPA가 “마법처럼 알아서 다 해 주는 기능”이 아니라, 메트릭과 운영 기준에 따라 replica 수를 조절하는 정책이라는 점이 분명해집니다.

FAQ

Q. HPA는 Service에 붙나요, Deployment에 붙나요?

보통은 Deployment 같은 워크로드 리소스에 붙습니다.

Q. CPU 말고 다른 기준도 쓸 수 있나요?

가능합니다. 다만 입문 단계에서는 CPU 기반부터 이해하는 편이 가장 쉽습니다.

Q. Pod가 늘어났는데도 느리면 HPA가 실패한 건가요?

항상 그렇지는 않습니다. 병목이 애플리케이션 밖에 있을 수도 있습니다.

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.