Kubernetes 환경에서는 Application Traffic이 일정하지 않습니다.
예를 들어 쇼핑몰 Application은 이벤트 기간에 사용자 요청이 급증할 수 있고, 일반적인 시간에는 적은 Resource만 필요할 수 있습니다.
이때 항상 최대 규모의 Pod를 유지하면 불필요한 비용이 발생하고, 반대로 적은 수의 Pod만 운영하면 Traffic 증가 시 서비스 성능 문제가 발생할 수 있습니다.
Kubernetes에서는 이러한 문제를 해결하기 위해 Horizontal Pod Autoscaler(HPA)를 제공합니다.
HPA는 CPU, Memory 사용량 또는 Custom Metric을 기준으로 Pod Replica 개수를 자동으로 증가하거나 감소시키는 Kubernetes 자동 Scaling 기능입니다.
| 구성 요소 | 역할 |
|---|---|
| HPA | Pod 개수 자동 조절 |
| Deployment | Replica 관리 |
| Metrics Server | Resource 측정 |
| Pod | Application 실행 |
HPA 구조를 이해하면 Kubernetes 환경에서 Traffic 변화에 따라 Application 규모를 자동으로 조절하는 방법을 이해할 수 있습니다.
Kubernetes HPA란 무엇인가?
HPA(Horizontal Pod Autoscaler)는 Kubernetes에서 Pod 개수를 자동으로 조절하는 Controller입니다.
현재 Application 상태를 확인하고 설정된 기준에 따라 Replica 수를 변경합니다.
예:
현재 상태:
Pod 2개
CPU 사용률 증가
↓
HPA 감지
↓
Pod 5개 증가
↓
Traffic 분산
반대로 Traffic이 감소하면 Pod 개수를 줄여 Resource 사용량을 최적화합니다.
Kubernetes HPA가 필요한 이유
Application Traffic은 항상 일정하지 않습니다.
수동으로 Pod 개수를 조절하면 빠른 대응이 어렵습니다.
문제:
| 상황 | 문제 |
|---|---|
| Traffic 증가 | 성능 저하 |
| Traffic 감소 | Resource 낭비 |
| 수동 Scaling | 운영 부담 증가 |
| 예측 어려움 | 서비스 안정성 부족 |
HPA는 자동 Scaling을 통해 이러한 문제를 해결합니다.
Kubernetes HPA 동작 구조
HPA는 Metrics Server에서 Resource 사용량을 가져와 Replica 수를 조절합니다.
구조:
| 구성 요소 | 역할 |
|---|---|
| Metrics Server | 사용량 수집 |
| HPA Controller | Scaling 판단 |
| Deployment | Replica 변경 |
| Pod | Application 실행 |
동작 과정:
| 단계 | 내용 |
|---|---|
| 1단계 | Pod Resource 사용량 확인 |
| 2단계 | Metric 비교 |
| 3단계 | 필요 Replica 계산 |
| 4단계 | Deployment 변경 |
| 5단계 | Pod 증가 또는 감소 |
Kubernetes Controller가 자동으로 상태를 조정합니다.
Kubernetes HPA Scaling 방식
HPA는 현재 Metric과 목표 Metric을 비교하여 Replica 수를 계산합니다.
기본 공식:
원하는 Replica 수
=
현재 Replica 수 × (현재 Metric 값 / 목표 Metric 값)
예:
현재:
Pod 2개
CPU 사용률:
80%
목표:
40%
결과:
Pod 증가 필요
이 방식으로 자동 Scaling이 수행됩니다.
Kubernetes CPU 기반 HPA
가장 일반적인 HPA 방식은 CPU 사용률 기반 Scaling입니다.
예:
목표 CPU:
50%
현재 CPU:
90%
↓
Replica 증가
사용량:
30%
↓
Replica 감소
Web Server와 API Server에서 많이 사용됩니다.
Kubernetes Memory 기반 HPA
HPA는 Memory 사용량 기준으로도 Scaling할 수 있습니다.
예:
Application Memory 증가
↓
HPA 감지
↓
Pod 증가
Memory 기반 Scaling은 Memory Leak이나 Cache 증가 상황에서 활용됩니다.
Kubernetes Custom Metrics HPA
기본 CPU와 Memory 외에도 Custom Metric을 사용할 수 있습니다.
예:
| Metric | 활용 |
|---|---|
| Request 수 | Web Traffic 관리 |
| Queue Length | Message 처리 |
| Transaction 수 | 서비스 부하 확인 |
Prometheus 같은 Monitoring 시스템과 연동하여 사용할 수 있습니다.
Kubernetes Metrics Server란?
Metrics Server는 Kubernetes Cluster Resource 사용량을 수집하는 Component입니다.
HPA는 Metrics Server 데이터를 기반으로 Scaling 판단을 수행합니다.
구조:
Node
↓
Kubelet
↓
Metrics Server
↓
HPA
↓
Deployment
Metrics Server가 없으면 기본 Resource 기반 HPA는 동작하지 않습니다.
Kubernetes HPA와 Deployment 관계
HPA는 직접 Pod를 생성하지 않습니다.
Deployment의 Replica 수를 변경하여 Pod 개수를 조절합니다.
구조:
HPA
↓
Deployment replicas 변경
↓
ReplicaSet 변경
↓
Pod 생성 또는 삭제
기존 Kubernetes Controller 구조를 활용합니다.
Kubernetes HPA 설정 요소
HPA는 여러 설정 값을 사용합니다.
| 설정 | 설명 |
|---|---|
| minReplicas | 최소 Pod 개수 |
| maxReplicas | 최대 Pod 개수 |
| metrics | Scaling 기준 |
| behavior | Scaling 속도 제어 |
운영 환경에서는 적절한 범위 설정이 중요합니다.
Kubernetes HPA Scale Up 동작
Traffic 증가 상황:
사용자 증가
↓
CPU 증가
↓
HPA 감지
↓
Replica 증가
↓
새로운 Pod 생성
↓
Traffic 분산
빠른 부하 대응이 가능합니다.
Kubernetes HPA Scale Down 동작
Traffic 감소 상황:
사용자 감소
↓
Resource 사용량 감소
↓
HPA 판단
↓
Pod 감소
↓
Resource 절약
불필요한 비용을 줄일 수 있습니다.
Kubernetes HPA와 Cluster Autoscaler 차이
HPA와 Cluster Autoscaler는 역할이 다릅니다.
| 구분 | HPA | Cluster Autoscaler |
|---|---|---|
| 대상 | Pod | Node |
| 확장 단위 | Container Instance | Server Node |
| 기준 | Metric | Resource 부족 |
| 목적 | Application Scaling | Infrastructure Scaling |
두 기능을 함께 사용하면 완전한 자동 확장 구조를 구성할 수 있습니다.
Kubernetes HPA와 VPA 차이
HPA와 VPA는 Scaling 방향이 다릅니다.
| 구분 | HPA | VPA |
|---|---|---|
| 변경 대상 | Pod 개수 | Pod Resource |
| 확장 방식 | 수평 확장 | 수직 확장 |
| 예시 | Replica 증가 | CPU Memory 증가 |
Application 특성에 따라 선택합니다.
Kubernetes HPA 활용 사례
| Application | 활용 방식 |
|---|---|
| Web Server | Traffic 증가 대응 |
| API Server | Request 기반 Scaling |
| Batch 처리 | 작업량 기반 조절 |
| Microservice | 서비스별 자동 확장 |
Cloud 환경에서 필수적인 운영 기능입니다.
Kubernetes HPA 운영 시 고려사항
HPA는 자동화 기능이지만 올바른 설정이 필요합니다.
| 항목 | 설명 |
|---|---|
| Resource Request | 정확한 기준 필요 |
| Metric 설정 | 서비스 특성 고려 |
| 최대 Replica | 비용 관리 |
| Scaling Delay | 급격한 변화 방지 |
잘못 설정하면 불필요한 Pod 증가가 발생할 수 있습니다.
Kubernetes HPA 장애 상황
HPA 문제가 발생하면 자동 Scaling이 정상 동작하지 않습니다.
주요 문제:
| 문제 | 결과 |
|---|---|
| Metrics Server 오류 | Scaling 불가 |
| Resource 설정 부족 | 잘못된 판단 |
| 권한 문제 | Metric 접근 실패 |
| Limit 설정 오류 | 성능 문제 |
Monitoring과 함께 관리해야 합니다.
Kubernetes HPA 장점
| 장점 | 설명 |
|---|---|
| 자동 Scaling | Traffic 변화 대응 |
| 비용 최적화 | 불필요한 Resource 감소 |
| 서비스 안정성 | 부하 대응 |
| 운영 자동화 | 수동 관리 감소 |
HPA는 Kubernetes 운영 자동화의 핵심 기능입니다.
자주 묻는 질문
HPA는 Pod를 직접 생성하나요?
아닙니다.
HPA는 Deployment Replica 수를 변경하고 실제 Pod 생성은 ReplicaSet이 수행합니다.
HPA는 CPU만 사용할 수 있나요?
아닙니다.
Memory와 Custom Metric도 사용할 수 있습니다.
HPA와 Cluster Autoscaler는 같이 사용할 수 있나요?
가능합니다.
HPA는 Pod를 증가시키고 Cluster Autoscaler는 필요한 Node를 추가합니다.
마무리
Kubernetes Horizontal Pod Autoscaler(HPA)는 Application 부하 변화에 따라 Pod 개수를 자동으로 조절하는 핵심 Scaling 기능입니다.
| 구성 요소 | 역할 |
|---|---|
| HPA | Pod 자동 Scaling |
| Metrics Server | 사용량 측정 |
| Deployment | Replica 관리 |
| Pod | Application 실행 |
HPA 구조를 이해하면 Kubernetes 환경에서 Traffic 변화에 자동 대응하고 효율적인 Resource 운영 환경을 구축할 수 있습니다.
다음 글에서는 Kubernetes Storage와 Application 데이터를 관리하는 Kubernetes StatefulSet 완벽 가이드! Stateful Application과 Pod Identity 관리 구조 이해하기를 알아보겠습니다.