Hunny's Daily

개발과 일상에서의 달콤한 순간들을 기록하며, 유용한 팁과 인사이트를 공유합니다.

오토스케일링(HPA) 기본 개념

트래픽 변화에 따라 Pod 수를 자동으로 조절하는 방법

대규모 트래픽 환경에서는 요청량이 항상 일정하지 않다. 특정 시간대에 트래픽이 급증하기도 하고, 평소에는 자원이 남는 경우도 많다. 이런 상황에서 서버를 수동으로 늘리고 줄이는 것은 비효율적이다. Kubernetes는 이를 해결하기 위해 오토스케일링, 그중에서도 HPA(Horizontal Pod Autoscaler) 를 제공한다. 이 글에서는 HPA의 기본 개념과 동작 방식을 중심으로 정리한다.

오토스케일링이 필요한 이유

트래픽이 고정되지 않은 환경에서는 다음 문제가 반복적으로 발생한다.

  • 피크 트래픽에 맞추면 평소 자원 낭비
  • 평소 기준으로 운영하면 피크 타임 장애
  • 수동 확장은 대응이 늦음

오토스케일링은 이러한 문제를 해결하기 위해 필요할 때만 자원을 늘리고, 필요 없을 때 줄이는 구조를 만든다.

HPA란 무엇인가

HPA는 Pod의 개수를 자동으로 조절하는 Kubernetes 리소스다.
CPU, 메모리 또는 사용자 정의 지표를 기준으로 Pod 수를 늘리거나 줄인다.

HPA의 핵심 역할은 다음과 같다.

  • 트래픽 증가 시 Pod 자동 증가
  • 트래픽 감소 시 Pod 자동 감소
  • 설정된 범위 내에서만 확장

즉, HPA는 Scale Out을 자동화하는 도구다.

HPA와 Scale Out의 관계

HPA는 Scale Out 전략을 자동으로 실행해주는 역할을 한다.

  • Scale Out: 서버(Pod) 수를 늘리는 전략
  • HPA: 그 결정을 자동으로 수행하는 메커니즘

HPA를 사용하면 운영자가 직접 Pod 개수를 조정할 필요가 없다.

HPA가 동작하는 기본 조건

HPA가 정상적으로 동작하려면 다음 조건이 필요하다.

  • Deployment, StatefulSet 등 스케일 가능한 리소스
  • 리소스 요청(requests) 설정
  • 메트릭 수집 환경 구성

특히 requests 설정은 필수다. HPA는 requests를 기준으로 사용률을 계산한다.

HPA의 기본 동작 방식

HPA는 주기적으로 메트릭을 수집하고 판단한다.

동작 흐름은 다음과 같다.

  1. 메트릭 서버에서 Pod 리소스 사용량 수집
  2. 현재 사용률과 목표 값 비교
  3. Pod 수 증가 또는 감소 결정
  4. Deployment에 새로운 Pod 수 반영

이 과정이 반복되며 자동 확장이 이루어진다.

가장 많이 사용하는 기준: CPU 사용률

가장 기본적인 HPA 설정 기준은 CPU 사용률이다.

예를 들면 다음과 같은 기준을 설정할 수 있다.

  • 평균 CPU 사용률 70% 유지
  • 70% 초과 시 Pod 증가
  • 70% 미만 시 Pod 감소

이 방식은 설정이 단순하고 대부분의 서비스에 적용 가능하다.

메모리 기준 오토스케일링

HPA는 메모리 사용량도 기준으로 삼을 수 있다.

다만 메모리는 다음 특성이 있다.

  • 사용량이 쉽게 줄어들지 않음
  • GC, 캐시 영향 큼

그래서 메모리 기반 오토스케일링은 신중하게 적용해야 한다.

사용자 정의 메트릭 기반 HPA

CPU나 메모리 외에도 사용자 정의 지표를 사용할 수 있다.

예시는 다음과 같다.

  • 요청 수
  • 응답 지연 시간
  • 큐 적재량

이 방식은 실제 서비스 부하를 더 정확히 반영할 수 있지만, 구성 난이도가 높다.

HPA의 최소·최대 Pod 수

HPA에는 항상 다음 두 값이 설정된다.

  • 최소 Pod 수
  • 최대 Pod 수

이 설정을 통해 무한 확장을 방지하고, 비용과 안정성을 제어한다.

HPA 사용 시 자주 발생하는 문제

HPA를 사용할 때 다음과 같은 문제가 자주 발생한다.

  • requests 미설정으로 동작하지 않음
  • 스케일링이 너무 늦게 반응
  • 잦은 스케일 인/아웃으로 불안정
  • DB나 외부 시스템이 병목이 됨

HPA는 만능 해결책이 아니다.

HPA만으로 부족한 이유

HPA는 애플리케이션 서버 확장에는 효과적이지만, 모든 문제를 해결하지는 않는다.

  • DB는 자동 확장되지 않음
  • 캐시나 큐가 병목이 될 수 있음
  • 스케일 아웃 시 초기화 비용 발생

따라서 HPA는 전체 아키텍처의 한 부분으로 봐야 한다.

언제 HPA를 도입하는 것이 좋은가

다음과 같은 환경에서 HPA의 효과가 크다.

  • 트래픽 변동이 큰 서비스
  • 무상태(stateless) 애플리케이션
  • 빠른 Scale Out이 필요한 구조

반대로 트래픽이 거의 고정된 서비스에서는 효과가 제한적일 수 있다.

정리

HPA는 Kubernetes에서 Pod 수를 자동으로 조절하는 오토스케일링 메커니즘이다. 트래픽 변화에 유연하게 대응할 수 있지만, requests 설정과 메트릭 구성 등 사전 조건이 필요하다. HPA는 Scale Out 전략을 자동화하는 도구이며, 캐시와 DB 구조까지 함께 고려해야 안정적인 대규모 트래픽 대응이 가능하다.