Proactive Auto Scaling Based on Marginal Request Change Analysis for Reducing Tail Latency in Kubernetes Cluster

CPU가 임계값에 도달한 뒤에는 대응이 늦었습니다

CPU 기반 HPA는 현재 사용률과 목표 임계값을 비교해 파드 수를 조정합니다. 임계값이 낮으면 일찍 확장하지만 자원을 더 쓰고, 높으면 부하가 충분히 오른 뒤에야 확장합니다.

실험 환경에서 CPU 지표는 15초마다 수집됐습니다. 그 사이 요청이 급증하면 기존 파드에 부하가 쌓인 뒤 확장이 시작될 수 있었습니다. CPU 임계값만 조정하기보다, 요청의 증가 속도를 함께 보고 더 일찍 파드를 준비하는 방법을 검토했습니다.

요청량의 증가 속도를 먼저 확인했습니다

p-HPA는 요청이 얼마나 빠르게 늘고 있는지 살핍니다. 현재 CPU 사용률만으로는 놓치기 쉬운 급증을 요청 변화량으로 먼저 감지하고, CPU가 임계값에 도달하기 전에 파드를 추가하도록 했습니다.

Istio에서 서비스별 요청 수를 수집해 Prometheus로 전달했습니다. p-Analyzer는 이 지표로 추가 Replica 수를 계산하고, p-Caller는 Kubernetes API로 확장을 요청합니다. 두 모듈은 기존 HPA와 함께 동작하도록 배치했습니다.

요청 변화량을 비교 가능한 범위로 바꿨습니다

요청 증가분을 그대로 사용하면 큰 값이 들어올 때 판단 기준도 크게 흔들립니다. arctan으로 증가분을 제한된 각도 범위로 변환해, 요청이 얼마나 가파르게 증가하는지 비교하도록 했습니다.

급증할수록 최근 요청에 집중했습니다

긴 관측 구간은 급증에 늦게 반응하고, 짧은 구간은 일시적인 변화에 민감합니다. 최근 요청부터 과거로 구간을 넓히다가 누적 변화가 기준에 도달하면 평균을 구하도록 했습니다. 급증할 때는 짧은 구간으로 빠르게 판단하고, 완만할 때는 더 긴 구간을 참고합니다.

증가 속도와 현재 부하로 추가 파드 수를 정했습니다

요청이 같은 속도로 늘어도 현재 CPU 사용률에 따라 필요한 파드 수는 달라집니다. 평균 기울기와 CPU 사용률을 곱해 증가 속도와 현재 부하를 함께 반영했습니다.

p-HPA는 급증을 감지한 경우에만 파드를 먼저 추가합니다. 그 외에는 기존 HPA가 파드 수를 조정하도록 두어, 선제적 확장 기능을 기존 제어에 덧붙였습니다.

사전 학습보다 짧은 급증에 대한 대응을 택했습니다

LSTM·Bi-LSTM 기반 예측에는 학습 데이터를 모으고 모델을 학습하는 과정이 필요합니다. 이 연구에서는 장기 패턴을 예측하기보다, 사전 학습 없이 현재 들어오는 요청의 급증을 감지하는 데 집중했습니다. 요청 변화량과 현재 CPU 사용률로 추가 파드 수를 정했고, 그 결과 지연은 줄었지만 평균 자원 사용은 약 13% 늘었습니다.

결과

Intel Xeon Cascade Lake(4 vCPU·16GB) cluster에서 CPU 집약적인 PHP 행렬곱 application에 linear·sinusoidal·exponential 형태로 분당 0~2,000 request를 인가하며, 기본 HPA를 threshold 70·80·90에서 비교했습니다.

실험한 모든 부하·임계값 조합에서 tail latency와 P95가 낮아졌습니다. CPU 임계값 90%의 지수형 부하에서는 tail latency가 HPA 1,106.6ms에서 p-HPA 879.8ms로 줄었습니다. 아래 표는 보관 원문의 측정값을 같은 임계값 조건으로 비교한 것입니다.

평균 자원 사용은 HPA보다 약 13% 많았습니다. 지연을 줄이기 위해 파드를 더 일찍 준비한 데 따른 비용입니다. 검증 범위는 선형·주기·지수형으로 만든 CPU 집약 부하이며, 다른 병목을 가진 서비스에 적용하려면 추가 실험이 필요합니다.

이 연구는 제가 제1저자로 수행했습니다. 후속 과제로 남긴 time series(ARIMA) 기반 예측과 최적 threshold 자동 결정은 이후 online ARIMA와 adaptive threshold를 갖춘 LARE-HPA로 이어졌습니다.