HPA (r1)

HPA는 쿠버네티스 클러스터에서 파드의 수를 자동으로 조정하기 위해 지속적으로 관련 메트릭을 수집하고 분석한다. 이 과정의 핵심은 목표로 하는 워크로드(예: 디플로이먼트 또는 스테이트풀셋)의 현재 메트릭 값을 실시간으로 모니터링하여, 사용자가 정의한 원하는 상태(Desired State)와 비교하는 것이다.

주로 수집하는 메트릭은 리소스 사용률이다. 가장 일반적인 것은 CPU 사용률과 메모리 사용률이다. HPA는 각 파드의 실제 리소스 사용량을 지속적으로 쿼리한다. 이 데이터는 대개 메트릭 서버와 같은 클러스터 내 모니터링 구성 요소로부터 제공받는다. 메트릭 서버는 각 노드에 설치된 kubelet의 리소스 메트릭 API를 통해 데이터를 집계한다.

수집된 메트릭 데이터는 HPA 컨트롤러에 의해 분석된다. 분석의 주요 목표는 현재 메트릭 값이 사용자가 설정한 목표값(예: CPU 사용률 50%)을 초과하거나 미달하는지를 판단하는 것이다. 계산은 일반적으로 다음 공식을 따른다.

원하는 레플리카 수 = ceil[현재 레플리카 수 * (현재 메트릭 값 / 목표 메트릭 값)]

예를 들어, CPU 사용률 목표값이 50%일 때, 현재 평균 CPU 사용률이 75%라면 계산식은 ceil[현재 파드 수 * (75 / 50)]이 된다. 현재 파드 수가 4개라면, ceil[4 * 1.5] = ceil[6] = 6으로, 파드를 6개로 스케일 아웃해야 한다고 결정한다.

이 분석은 지속적인 루프에서 이루어지며, 기본적으로 15초 간격으로 반복된다[2]. 분석 결과 목표 파드 수에 변화가 필요하다고 판단되면, HPA는 해당 워크로드 객체(예: 디플로이먼트의 레플리카 수)를 직접 수정하여 스케일링을 실행한다.

스케일링 정책은 HPA가 수집된 메트릭 데이터를 바탕으로 파드의 레플리카 수를 조정하는 구체적인 규칙과 로직을 정의한다. 이 정책은 주로 목표 평균 사용률과 최소/최대 레플리카 수로 구성된다. 예를 들어, CPU 사용률이 70%를 목표로 설정되면, HPA는 현재 평균 CPU 사용률이 이 값을 유지하도록 파드 수를 증가시키거나 감소시킨다.

정책의 핵심은 메트릭 값과 목표값의 비율을 계산하여 필요한 레플리카 수를 결정하는 알고리즘이다. 계산 공식은 원하는 레플리카 수 = ceil(현재 레플리카 수 * (현재 메트릭 값 / 목표 메트릭 값))이다. 이 계산 결과는 최소 및 최대 레플리카 수 범위 내로 제한된다. 여러 메트릭을 동시에 모니터링하는 경우, 계산된 레플리카 수 중 가장 큰 값이 최종 적용된다.

스케일 아웃(증가)과 스케일 인(감소)은 서로 다른 정책 지연 시간을 가질 수 있다. 이는 급격한 변동으로 인한 불필요한 스케일링 동작을 방지하기 위한 안정화 메커니즘이다. 예를 들어, 스케일 인은 기본적으로 5분의 쿨다운 기간을 두어, 부하가 일시적으로 떨어졌다가 다시 올라가는 상황에서 파드가 불필요하게 제거되는 것을 막는다.

메트릭 서버는 쿠버네티스 클러스터 내에서 HPA가 작동하기 위해 필요한 핵심 구성 요소이다. 이 서버는 클러스터의 각 노드에 설치된 메트릭-수집기로부터 파드와 노드의 리소스 사용량 메트릭(주로 CPU와 메모리)을 수집하고 집계하는 역할을 담당한다. 수집된 메트릭 데이터는 쿠버네티스 API 서버를 통해 메트릭 API의 형태로 제공되며, HPA 컨트롤러는 이 API를 주기적으로 조회하여 현재 부하를 평가하고 스케일링 결정을 내린다.

메트릭 서버는 리소스 메트릭 파이프라인의 기본 구현체로, 디플로이먼트나 데몬셋 형태로 클러스터에 설치된다. 주요 기능은 실시간 리소스 사용량 데이터를 수집하고 저장하는 것이며, 장기적인 히스토리 데이터를 보관하지는 않는다. 이는 모니터링과 로깅을 위한 목적이 아니라, 실시간 오토스케일링을 위한 현재 상태 정보를 제공하는 데 중점을 두기 때문이다.

메트릭 서버의 일반적인 아키텍처는 다음과 같은 구성 요소를 포함한다.

HPA가 CPU나 메모리 사용률을 기반으로 파드의 레플리카 수를 조정하려면 반드시 메트릭 서버가 클러스터에 정상적으로 실행되고 있어야 한다. 메트릭 서버가 없으면 HPA는 필요한 메트릭 데이터를 얻을 수 없어 올바른 스케일링 결정을 내릴 수 없다.

커스텀 메트릭은 HPA가 CPU 사용률이나 메모리 사용량 같은 기본 메트릭 외에 애플리케이션의 비즈니스 로직과 직접적으로 연관된 지표를 기반으로 스케일링 결정을 내릴 수 있게 해주는 기능이다. 이를 통해 트래픽 요청 수, 메시지 큐의 대기 메시지 수, 특정 API의 응답 시간, 애플리케이션별 대기열 길이 등 다양한 사용자 정의 지표를 활용할 수 있다.

커스텀 메트릭을 사용하기 위해서는 일반적으로 메트릭 서버 외에 추가적인 메트릭 파이프라인이 필요하다. 일반적인 구성은 애플리케이션에서 메트릭을 노출하고, 프로메테우스 같은 모니터링 시스템이 이를 수집하며, 쿠버네티스 클러스터에는 이 메트릭들을 HPA가 이해할 수 있는 형식으로 제공하는 커스텀 메트릭 API 서버가 배포된다. HPA는 이 API를 쿼리하여 사용자가 정의한 메트릭의 현재 값을 확인하고, 설정된 목표값과 비교한다.

HPA 매니페스트에서 커스텀 메트릭을 사용하는 예시는 다음과 같다. type을 Pods로 설정하고, metric 이름과 목표 평균값을 지정한다.

```yaml

metrics:

• type: Pods

pods:

metric:

name: requests_per_second

target:

type: AverageValue

averageValue: 100

```

커스텀 메트릭의 도입은 스케일링 정책을 보다 세밀하고 애플리케이션에 특화되게 만든다. 예를 들어, CPU 사용률이 낮더라도 초당 HTTP 요청 수가 특정 임계값을 초과하면 팟을 추가하도록 설정하여 실제 부하에 더 민감하게 대응할 수 있다. 이는 특히 이벤트 기반 아키텍처나 마이크로서비스 환경에서 중요한 장점으로 작용한다.

HPA는 쿠버네티스에서 YAML 형식의 매니페스트 파일을 통해 정의하고 구성한다. 일반적으로 HorizontalPodAutoscaler 리소스 종류를 사용하며, 대상 디플로이먼트나 레플리카셋, 스테이트풀셋의 이름, 참조할 메트릭의 종류와 목표값, 그리고 복제본 수의 최소/최대 범위를 명시한다.

다음은 CPU 사용률을 기반으로 my-app이라는 디플로이먼트를 자동 스케일링하는 기본적인 HPA 매니페스트 예시이다.

```yaml

apiVersion: autoscaling/v2

kind: HorizontalPodAutoscaler

metadata:

name: my-app-hpa

spec:

scaleTargetRef:

apiVersion: apps/v1

kind: Deployment

name: my-app

minReplicas: 2

maxReplicas: 10

metrics:

• type: Resource

resource:

name: cpu

target:

type: Utilization

averageUtilization: 70

```

위 예시에서 주요 필드는 다음과 같다.

* scaleTargetRef: 스케일링 대상 워크로드를 지정한다.

* minReplicas / maxReplicas: 파드 복제본 수의 하한과 상한을 정의한다.

* metrics: 스케일링 판단 기준이 되는 메트릭을 설정한다. type: Resource 및 name: cpu는 CPU 리소스 메트릭을 사용함을 의미한다.

* target: 메트릭의 목표 값을 설정한다. type: Utilization과 averageUtilization: 70은 모든 파드의 평균 CPU 사용률이 70%를 유지하도록 스케일링한다는 정책이다.

여러 메트릭을 조합하거나 커스텀 메트릭을 사용하는 더 복잡한 설정도 가능하다. 예를 들어, CPU 사용률과 함께 초당 요청 수(RPS)를 동시에 모니터링하는 정책은 metrics 배열에 항목을 추가하여 정의한다. 매니페스트를 작성한 후 kubectl apply -f <파일명>.yaml 명령어로 HPA 리소스를 쿠버네티스 클러스터에 생성한다.

스케일링 임계값은 HPA가 파드의 수를 조정하기 위해 사용하는 기준값이다. 이 임계값은 일반적으로 메트릭의 목표 평균 사용률(또는 목표 값)으로 정의되며, 퍼센트 또는 절대값 단위로 설정된다. 예를 들어, CPU 사용률이 70%를 초과하면 스케일 아웃하고, 30% 미만이면 스케일 인하도록 구성할 수 있다.

임계값 설정은 애플리케이션의 성능 요구사항과 리소스 효율성 사이의 균형을 고려해야 한다. 너무 높은 임계값은 시스템에 과부하가 걸릴 때까지 스케일링이 발생하지 않아 응답 지연을 초래할 수 있다. 반대로 너무 낮은 임계값은 불필요하게 자주 스케일링을 유발하여 리소스 낭비와 불안정성을 야기할 수 있다. 적절한 임계값은 애플리케이션의 부하 패턴을 모니터링하고 분석하여 결정된다.

HPA는 metrics 항목 아래에 여러 개의 메트릭과 각각의 target 값을 정의하여 복합적인 스케일링 정책을 구성할 수 있다. 각 메트릭의 현재 값이 설정된 목표 값을 기준으로 계산된 원하는 레플리카 수를 산출하며, HPA는 이 중 가장 높은 레플리카 수를 선택하여 최종 스케일링을 수행한다[4].

또한, HPA의 동작을 미세 조정하는 데 도움이 되는 행동 구성을 설정할 수 있다. behavior 필드를 통해 스케일 업/다운의 안정화 창 기간, 스케일링 폭의 제한 등을 조정하여 급격한 부하 변동에 따른 레플리카 수의 급등락을 방지할 수 있다.

CPU와 메모리 기반 스케일링은 HPA의 가장 일반적이고 기본적인 사용 사례이다. 이 방식은 애플리케이션의 자원 사용률을 지표로 삼아 파드의 레플리카 수를 자동으로 조정한다. 시스템은 메트릭 서버를 통해 각 파드의 실제 CPU 사용량과 메모리 사용량을 지속적으로 수집하며, 사용자가 정의한 목표값(예: CPU 사용률 70%)과 비교한다. 평균 사용률이 목표 임계값을 일정 시간 동안 초과하면 HPA는 레플리카 수를 증가시키는 스케일 아웃을 수행한다. 반대로 사용률이 낮게 유지되면 불필요한 리소스를 절약하기 위해 레플리카 수를 줄이는 스케일 인을 트리거한다.

구체적인 설정은 YAML 매니페스트의 metrics 필드를 통해 정의된다. CPU와 메모리 메트릭은 각각 resource 타입으로 지정되며, targetAverageUtilization(평균 사용률 퍼센트 기준) 또는 targetAverageValue(절대값 기준)를 목표로 설정할 수 있다. 아래는 CPU와 메모리 사용률을 동시에 모니터링하는 HPA 설정의 간략한 예시이다.

이 접근 방식의 주요 장점은 직관적이고 구성이 간단하다는 점이다. 대부분의 애플리케이션이 CPU나 메모리 사용량에 민감하게 반응하기 때문에, 트래픽 증가로 인한 부하를 효과적으로 분산시킬 수 있다. 그러나 단순한 자원 사용률만으로는 애플리케이션의 실제 비즈니스 상태(예: 초당 요청 수, 큐의 대기 메시지 수)를 정확히 반영하지 못할 수 있다는 한계가 있다. 또한, 메트릭 수집과 분석에 따른 짧은 지연 시간으로 인해 매우 갑작스럽고 짧은 피크 부하에는 즉각적으로 대응하지 못할 수 있다.

HPA는 기본적으로 CPU나 메모리 같은 리소스 메트릭을 기반으로 동작하지만, 애플리케이션의 비즈니스 로직과 직접적으로 연관된 지표를 사용하여 스케일링을 수행할 수도 있다. 이를 사용자 정의 메트릭 기반 스케일링이라고 한다. 예를 들어, 웹 애플리케이션의 초당 요청 수(RPS), 메시지 큐의 대기 메시지 수, 특정 에러 발생률, 또는 평균 응답 시간 같은 애플리케이션 수준의 메트릭을 기준으로 파드 수를 조정할 수 있다.

이 기능을 사용하려면 먼저 사용자 정의 메트릭을 수집하고 쿠버네티스 메트릭 파이프라인에 노출시켜야 한다. 일반적인 구성은 다음과 같다.

1. 메트릭 수집기(예: Prometheus)를 통해 애플리케이션에서 사용자 정의 메트릭을 수집한다.

2. kube-state-metrics나 애플리케이션 자체의 메트릭 엔드포인트를 통해 메트릭을 제공한다.

3. 메트릭 서버 대신 커스텀 메트릭 API 서버(예: Prometheus Adapter)를 설치하여, 수집된 사용자 정의 메트릭을 쿠버네티스 API가 이해할 수 있는 형식으로 변환하고 제공한다.

HPA 매니페스트에서는 type 필드를 Pods나 Object로 설정하고, metric 필드에 사용할 사용자 정의 메트릭의 이름을 지정한다. 예를 들어, http_requests_per_second라는 메트릭을 사용하여 평균값이 50을 초과하면 스케일 아웃하도록 구성할 수 있다. 이는 순수한 리소스 사용률이 아닌, 실제 서비스 부하를 더 정확히 반영한 스케일링을 가능하게 한다.

이 방식을 통해 트래픽 패턴이 복잡하거나, CPU 사용률과 직접적인 상관관계가 없는 애플리케이션(예: I/O 바운드 작업 또는 배치 처리)에 대해 더욱 정교하고 반응적인 오토스케일링이 구현된다.

HPA는 애플리케이션의 부하 변화에 따라 파드의 수를 자동으로 조정함으로써 운영 효율성을 극대화한다. 이 자동화는 시스템 관리자가 수동으로 모니터링하고 스케일링 명령을 내릴 필요를 크게 줄여준다. 결과적으로 운영 팀은 반복적인 인프라 관리 작업에서 벗어나 애플리케이션 개발 및 고가용성 보장과 같은 더 높은 가치의 업무에 집중할 수 있다.

효율성 측면에서 HPA는 리소스 사용률을 최적화하여 비용 절감을 도모한다. 예를 들어, 트래픽이 적은 시간대에는 필요 최소한의 파드만 운영하여 컴퓨팅 리소스를 절약하고, 트래픽이 급증할 때는 신속하게 파드를 추가하여 서비스 성능을 유지한다. 이는 클라우드 환경에서 사용한 만큼만 비용을 지불하는 종량제 모델과 특히 잘 맞아떨어진다.

자동화된 스케일링은 또한 애플리케이션의 안정성과 내결함성을 향상시킨다. 사전에 정의된 정책에 따라 시스템이 자체적으로 대응하므로, 예기치 않은 부하 급증으로 인한 서비스 장애 가능성을 줄인다. 이는 24/7 가용성이 요구되는 현대적인 서비스 운영에 필수적인 요소이다.

HPA는 지표를 수집하고 분석한 후 스케일링 결정을 내리기까지 일정 시간이 소요된다. 이 지연 시간은 메트릭 수집 주기, 쿠버네티스 컨트롤러 매니저의 동기화 주기, 파드 생성 및 준비 시간 등 여러 요소에 의해 발생한다. 결과적으로 트래픽 급증에 대한 반응이 즉각적이지 않을 수 있으며, 이는 일시적인 과부하나 서비스 지연으로 이어질 수 있다.

정확성 측면에서 HPA는 주로 과거의 평균 메트릭 데이터를 기반으로 미래의 부하를 예측하여 스케일링한다. 이는 갑작스럽고 짧은 버스트 트래픽 패턴이나 예측하기 어려운 부하에는 적절히 대응하지 못할 수 있다. 또한, 메트릭 수집 시스템 자체의 지연이나 샘플링 오류도 스케일링 결정의 정확도에 영향을 미칠 수 있다.

이러한 한계를 완화하기 위해 여러 전략이 사용된다. 스케일링 임계값을 보수적으로 설정하거나, 더 짧은 메트릭 수집 간격을 구성할 수 있다. 또한, 프로메테우스와 같은 고급 모니터링 도구와 커스텀 메트릭을 결합하여 더 세밀하고 실시간에 가까운 지표를 활용하는 방법도 있다. 일부 시나리오에서는 HPA와 예측 기반 스케일링을 결합하거나, 이벤트 기반의 즉각적인 스케일링을 처리할 수 있는 KEDA와 같은 도구를 함께 사용하기도 한다.

VPA(Vertical Pod Autoscaler)는 쿠버네티스에서 HPA와 보완적인 역할을 하는 자동 스케일링 도구이다. HPA가 파드의 개수를 조정하는 수평 스케일링을 담당한다면, VPA는 개별 파드에 할당된 CPU와 메모리와 같은 리소스의 요청량(request)과 상한량(limit)을 자동으로 조정하는 수직 스케일링을 담당한다[5]. 이는 애플리케이션의 실제 사용량을 분석하여 리소스 할당을 최적화하고, 과소 또는 과다 프로비저닝 문제를 해결하는 데 목적이 있다.

VPA는 일반적으로 세 가지 주요 컴포넌트로 구성된다. VPA Recommender는 파드의 과거 리소스 사용량 기록을 분석하여 적절한 요청량 값을 추천한다. VPA Updater는 추천된 값을 바탕으로 실행 중인 파드의 리소스 구성을 업데이트하는 역할을 하며, 이 과정에서 파드를 재시작하게 된다. VPA Admission Controller는 새로 생성되는 파드에 추천된 리소스 값을 자동으로 적용한다.

VPA의 운영 모드는 애플리케이션의 재시작 허용 여부에 따라 선택할 수 있다. 주요 모드는 다음과 같다.

VPA는 메모리 누수 방지나 안정적인 성능 보장에 유용하지만, 파드를 재시작해야 한다는 점이 가장 큰 제약이다. 따라서 무상태(stateless) 애플리케이션에 더 적합하며, 데이터베이스나 상태를 유지하는(stateful) 애플리케이션에는 신중하게 적용해야 한다. HPA와 VPA를 함께 사용할 경우, HPA는 파드 복제본 수를 관리하고 VPA는 각 파드의 리소스 크기를 조정하는 하이브리드 스케일링 전략을 구현할 수 있다. 단, 동일한 리소스(예: CPU)에 대해 HPA와 VPA를 동시에 사용하는 것은 충돌을 일으킬 수 있어 주의가 필요하다.

클러스터 오토스케일러는 쿠버네티스 클러스터에서 노드 수준의 자동 확장을 담당하는 구성 요소이다. HPA나 VPA가 개별 파드의 리소스 요구량에 따라 애플리케이션 레이어에서 스케일링을 수행하는 반면, 클러스터 오토스케일러는 인프라 레이어에서 작업자 노드 자체를 추가하거나 제거하여 클러스터의 전체 용량을 조정한다. 주된 목표는 모든 파드가 실행될 수 있는 충분한 자원을 보장하면서도 미사용 노드를 제거하여 클라우드 비용을 최적화하는 것이다.

클러스터 오토스케일러는 일반적으로 클라우드 제공업체의 API와 연동되어 작동한다. 그 동작 원리는 다음과 같다. 스케줄러에 의해 대기 중인 파드가 존재하면(즉, 요청한 리소스를 현재 노드가 수용할 수 없어 스케줄되지 못한 상태), 오토스케일러는 클라우드 플랫폼에 새 노드의 프로비저닝을 요청한다. 반대로, 노드의 리소스 사용률이 오랜 시간 동안 매우 낮게 유지되고, 해당 노드의 모든 파드가 다른 노드로 재스케줄될 수 있다고 판단되면, 노드를 안전하게 종료(drain)하고 클라우드 인프라에서 해당 노드를 삭제한다.

HPA와 클러스터 오토스케일러는 상호 보완적으로 함께 사용되는 경우가 많다. HPA가 트래픽 증가에 대응해 파드 레플리카 수를 늘리면, 새로 생성된 파드를 수용할 노드 용량이 부족해질 수 있다. 이때 클러스터 오토스케일러가 새 노드를 추가하여 인프라 용량을 확보한다. 이 조합은 애플리케이션부터 인프라까지의 전체 스택에 걸친 완전한 자동 확장성을 제공한다.