LARE-HPA

들어가며

"임계값을 몇 %로 잡아야 하나요?" 오토스케일링에서 늘 정답이 없던 이 질문을, 시스템이 스스로 답하게 만들 수 없을까에서 출발했습니다.

고정된 CPU 임계값은 부하가 바뀔 때마다 성능과 자원 사용에 다른 영향을 줍니다. 요청의 변동성과 추세를 보고 확장 기준과 축소 대기 시간을 조정하는 컨트롤러를 구현했습니다.

알고리즘 유도와 실험 상세는 Publications의 LARE-HPA 논문에 있습니다.

고정 설정만으로는 부하 변화에 대응하기 어려웠습니다

HPA의 CPU 임계값을 낮게 잡으면 일찍 확장하지만 자원을 더 사용합니다. 논문 실험에서는 임계값 60%일 때 90%보다 CPU를 약 22% 더 썼습니다. 반대로 임계값을 높이면 확장이 늦어져 응답 지연이 커질 수 있습니다. 같은 설정을 계속 유지하기보다 부하 변화에 맞춰 조정할 필요가 있었습니다.

파드를 줄인 직후 요청이 다시 늘면 축소와 확장을 반복하게 됩니다. 이를 줄이려고 대기 시간을 늘리면 부하가 내려간 뒤에도 불필요한 파드가 남습니다. 확장 기준뿐 아니라 자원을 언제 줄일지도 함께 조정해야 했습니다.

부하를 예측해 대응하는 방법도 있지만, 사전 학습에 필요한 데이터가 신규 애플리케이션에는 부족했습니다. 요청 패턴이 바뀔 때 모델을 다시 학습해야 하는 부담도 있어, 실행 중 관측한 데이터로 갱신하는 방식을 택했습니다.

LARE-HPA는 온라인으로 부하를 예측하고, 요청의 변동성으로 CPU 임계값을, 추세로 축소 대기 시간을 조정합니다. 사전 학습 데이터를 따로 준비하지 않고 실행 중 쌓이는 관측값을 사용합니다.

하나의 Pod, 세 개의 프로세스

LARE-HPA는 단일 Pod 안에서 Python multiprocessing으로 세 프로세스를 실행합니다. 스케일링 결정, 임계값 조정, 쿨다운 조정을 나눠 담당하고, multiprocessing.Value로 임계값과 대기 카운터를 공유합니다.

Metrics Collector는 Prometheus에 수집된 시스템 지표와 Istio Envoy의 요청 지표를 조회합니다. Forecaster·Threshold Coordinator·CDT Decider가 이를 사용해 예측과 설정값을 갱신하고, AutoScaler가 Kubernetes API로 Deployment의 Replica 수를 조정합니다.

예측·임계값·대기 시간을 함께 조정했습니다

먼저 Forecaster는 온라인 러닝 기반 ARIMA로 다가올 부하를 예측합니다. 고전 ARIMA는 충분한 이력과 오프라인 학습이 필요하지만, 여기서는 자기회귀 계수를 Online Newton-Step으로 즉석에서 갱신합니다. 정밀도 행렬(Hessian 역행렬)을 Sherman-Morrison 방식으로 갱신하는 2차 최적화라, 배치 재학습 없이도 데이터가 들어오는 대로 계수가 따라 움직입니다. 10개 시차(lag)만 확보되면 예측을 시작하고, 음수 예측은 0으로 클램프합니다.

다음으로 Threshold Coordinator는 이 예측과 최근 이력을 임계값으로 바꿉니다. 최근 10개 구간의 요청 변화량을 과거 전체와 비교한 z-score로 변동성을 측정한 뒤, 역(inverse) 시그모이드로 5~95% 범위의 CPU 임계값에 매핑합니다. 변동성이 낮으면 임계값을 높여 파드를 촘촘히 채워 자원을 아끼고, 변동성이 높으면 임계값을 낮춰 더 일찍 스케일링해 QoS를 지킵니다.

마지막으로 CDT Decider는 쿨다운을 정합니다. 최근 60개 구간의 요청에 선형회귀를 적합해 추세의 기울기를 얻고, Durbin-Watson 통계량으로 잔차의 자기상관을 확인합니다. 설정한 판단 구간(1.616~2.384)을 만족하면 추세를 반영합니다. 상승 추세에서는 쿨다운 카운터를 최대 60구간까지 늘려 복제본을 성급히 줄이지 않고, 하강 추세에서는 1까지 줄여 자원을 더 일찍 회수합니다.

애플리케이션 수정 없이 배포하도록 구성했습니다

전체는 python:3.11-slim 이미지 위 단일 데몬으로 동작하며, 최소 권한 원칙을 지킵니다. 전용 ServiceAccount로 클러스터 내부 인증을 쓰고, ClusterRole은 deployments/scale·statefulsets/scale의 patch·get·list·watch와 pods·services의 읽기 권한만 갖습니다.

대상 애플리케이션, Prometheus 주소, CPU 목표(기본 75%), Replica 범위(1~16), 수집 주기(60초)를 ConfigMap으로 설정하고 스크립트로 배포합니다. 예측·임계값·쿨다운·오류 로그를 따로 남겨 어떤 관측값으로 확장하거나 축소했는지 추적할 수 있게 했습니다. 애플리케이션 코드는 수정하지 않되, 필요한 시스템·요청 지표가 수집되는 환경을 전제로 합니다.

결과

실측 워크로드(NASA-HTTP 트레이스, SLO 1초)의 결과입니다. LARE-HPA는 평균 지연시간을 562.8ms(기본 HPA)에서 279.5ms로 낮췄고(95퍼센타일도 1189.0ms에서 600.1ms로), SLO 만족률은 97.24%로 네 방식 중 가장 높았습니다. 자원은 638.13 millicore로 HPA(582.76)보다 약 9.5% 많지만, Bi-LSTM(875.85)·Online-BO(1274.75)보다는 훨씬 적습니다. Online-BO는 과다 프로비저닝으로 HPA의 두 배 이상을 소비했습니다.

논문 Table 2의 실측값입니다(지연 감소는 LARE-HPA 대비). ICSOC 2024 Distinguished Paper (Top 6).

마치며

이 연구는 SCIE급 최상위 학회 ICSOC 2024에서 Distinguished Paper(Top 6)로 선정됐고, 특허 출원과 소프트웨어 저작권 등록까지 마쳤으며 코드는 오픈소스로 공개돼 있습니다.

사전 학습 없이 들어오는 요청으로 예측 모델을 갱신하고, 성능과 자원 사용을 함께 비교하며 임계값과 대기 시간을 조정했습니다. 고정값을 선택하는 데 그치지 않고, 부하가 바뀔 때 설정도 따라 바뀌도록 구현한 연구입니다.