사용자 정의 지표(RPS)로 HPA 설정하기

CPU나 메모리 대신 서비스 요청량을 기준으로 Kubernetes HPA를 동작시키기 위해 Istio, Prometheus, prometheus-adapter를 연결한 과정을 설명한다. 요청 수를 파드별 RPS로 가공해 Custom Metrics API로 노출하고, CPU와 RPS 중 더 많은 파드를 요구하는 값을 선택하도록 HPA를 구성한다.

핵심 포인트

HPA는 현재 파드 수와 현재·목표 지표의 비율로 원하는 파드 수를 계산하고 Deployment나 StatefulSet의 replica를 바꾼다.
Resource, Custom, External Metric은 서로 다른 API를 사용하므로 HPA 앞에 알맞은 Metric API Server가 필요하다.
I/O 병목이 많고 핵심 API가 하나인 모델 서버는 CPU보다 RPS가 실제 부하를 더 잘 나타낸다고 판단했다.
Istio의 누적 요청 지표를 PromQL `rate()`로 변환하고 ready 파드 수로 나눠 파드당 RPS를 만든다.
prometheus-adapter가 이 값을 Custom Metrics API에 노출하고 HPA가 RPS 30, CPU 80% 목표를 함께 평가한다.

상세 정리

스케일러 구분: Cluster Autoscaler는 파드를 수용할 노드를, HPA는 동일한 파드 수를, VPA는 개별 파드의 request·limit을 조절한다.
HPA 선택: Stateless 서버는 파드 재시작 없이 수평 확장하기 쉬워 VPA보다 HPA가 적합하다. 개별 노드의 물리적 한계도 피할 수 있다.
계산식: 원하는 파드 수는 `ceil(현재 파드 수 × 현재 지표 / 목표 지표)`다. 올림으로 확장 후 지표가 목표 이하가 되게 한다.
API 계층: Metric Source가 원시 값을 제공하고 Collector가 수집하며 Metric API Server가 Kubernetes API 형식으로 노출한다.
기본 지표: kubelet의 cAdvisor가 CPU·메모리를 수집하고 metrics-server가 Resource Metrics API를 제공한다. 설치 후 `kubectl top`으로 확인한다.
사용자 지표: cAdvisor가 모르는 값은 Prometheus 같은 collector와 별도 adapter가 필요하다. 이 사례는 prometheus-adapter를 썼다.
RPS 선택 이유: 모델 서버는 I/O, thread, network 병목이 섞여 CPU만으로 부하를 표현하기 어렵고 대부분 요청이 단일 답변 API로 모인다.
원천 지표: 각 애플리케이션에 계측 라이브러리를 넣는 대신 이미 설치된 Istio의 `istio_requests_total`을 사용했다.
중복 제거: Istio가 source와 destination 양쪽에서 요청을 기록하므로 `reporter="destination"` 조건으로 한쪽만 집계한다.
PromQL 변환: 2분 구간의 `rate()`를 합산하고 `kube_deployment_status_replicas_available`로 나눠 ready 파드당 RPS를 계산한다.
Recording rule: PrometheusRule에서 계산 결과를 `test_requests_per_second`라는 새 지표로 기록하고 namespace와 service label을 붙인다.
Adapter 설치: prometheus-operator Helm values에서 prometheus-adapter를 활성화하고 Prometheus URL과 포트를 지정한다.
노출 확인: `/apis/custom.metrics.k8s.io/v1beta1`을 조회해 `services/test_requests_per_second`가 namespaced metric으로 보이는지 검증한다.
HPA 정의: Custom Metric은 Object 타입으로 Service를 가리키고 목표값을 30으로 둔다. CPU는 Resource 타입과 평균 사용률 80%를 사용한다.
복수 지표: HPA는 각 기준이 계산한 파드 수 중 가장 큰 값을 택한다. RPS나 CPU 어느 한쪽이 병목이어도 충분히 확장된다.