HEART: Heterogeneous-Aware Traffic Allocation in Multi-Replica Deployments on Kubernetes

같은 요청 비율이 같은 부하를 뜻하지 않았습니다

마이크로서비스는 같은 컴포넌트를 여러 파드로 실행합니다. 이때 요청을 고르게 나누더라도 노드마다 처리 성능이 다르면 느린 파드에 과부하가 생길 수 있습니다. 노드 간 통신 지연까지 다르면 일부 요청은 더 느린 경로를 거칩니다. HEART는 이 두 차이를 함께 반영해 P99 지연을 줄이는 연구입니다.

노드 간 지연이 1ms 미만인 환경에서도 기본 분배 방식의 P99는 100 RPS에서 최대 4,010ms였습니다. 활성 요청 수를 기준으로 분배하는 Istio Least Request는 293ms로 낮았지만, 느린 노드에서는 CPU 사용률이 순간적으로 100%를 넘었습니다. 요청당 CPU 사용량도 약 12.3% 변동해, 현재 부하뿐 아니라 다음 구간의 변화도 반영할 필요가 있었습니다.

통신 지연을 고려한 이전 연구 LATA도 느린 링크를 남기는 경우가 있었습니다. 링크 하나를 제외하자 가장 오래 걸리는 경로의 지연이 100ms에서 80ms로 줄어, 요청 비율을 계산하기 전에 느린 링크를 걸러보기로 했습니다. 동시에 Replica 수가 100개에서 400개로 늘 때 계산 시간이 8.8ms에서 98.1ms로 증가하는 문제도 줄여야 했습니다.

처리 여력과 통신 비용을 나눠 계산했습니다

HEART는 30초마다 두 단계로 요청 비율을 갱신합니다. ATPM은 노드의 처리 여력에 따라 그룹별 요청 비율을 정하고, NTAM은 그 비율을 충족하면서 통신 지연이 작은 경로를 선택합니다. 처리 성능과 네트워크 조건을 나눠 계산하도록 구성했습니다.

Metric Collector는 Prometheus exporter로 파드별 CPU 사용량, 요청 수, 노드 간 지연, 컴포넌트 간 호출 관계를 수집합니다. 이 지표를 두 단계에서 함께 사용해 같은 정보를 중복 수집하지 않도록 했습니다.

ATPM · 부하 추세로 분배 비율을 정했습니다

같은 컴포넌트의 파드를 배치된 노드별로 묶었습니다. 개별 파드 대신 그룹 단위로 계산하면 다음 단계에서 다뤄야 할 링크 수를 줄일 수 있습니다. 부하는 요청당 CPU 사용량으로 구하고, 처리한 요청이 없는 파드는 해당 계산에서 제외했습니다.

최근 부하에 얼마나 비중을 둘지에 따라 예측이 늦어지거나 일시적인 변화에 과민하게 반응할 수 있습니다. EWMA의 가중치를 고정하지 않고 최근 변동성에 따라 조정했습니다. 여러 후보를 비교해 가중치 범위를 정하고, 매 주기 그 범위 안에서 갱신했습니다.

추정 부하가 큰 그룹에는 요청을 적게 배정합니다. 유효한 관측이 없는 기존 그룹은 직전 EWMA를, 새 그룹은 다른 유효 그룹의 평균을 사용합니다. 전체 값이 0이면 균등 분배해 관측값이 없는 경우에도 요청을 배정할 수 있도록 했습니다. 계산은 컴포넌트별로 병렬 처리했습니다.

NTAM · 느린 경로를 줄이고 할당 가능성을 확인했습니다

ATPM에서 정한 비율을 실제 통신 경로에 배분하는 단계입니다. 최소 비용 흐름(MCF)으로 전체 비용을 낮춰도 일부 느린 링크 때문에 P99가 높게 남았습니다. 먼저 느린 링크를 제거하고, 남은 경로에서 비율을 계산하도록 순서를 바꿨습니다.

k-means로 링크를 지연이 큰 그룹과 작은 그룹으로 나눴습니다. 지연이 큰 링크가 적으면 먼저 모두 제거하고, 많으면 느린 링크부터 하나씩 제거합니다. 다만 경로를 없애면 필요한 요청을 모두 전달하지 못할 수 있습니다. Maximum Flow로 그룹별 송수신량을 충족하는지 확인하고, 부족하면 링크를 복구하거나 직전 구성으로 돌아가도록 했습니다.

요청을 모두 전달할 수 있는 경로가 확보되면 MCF로 트래픽 양과 지연시간을 곱한 총비용을 최소화합니다. 그룹에 배정한 요청은 그룹 내 파드에 균등하게 나눕니다. 느린 링크를 걸러내는 단계만 적용한 비교에서도 P99가 평균 7.5% 줄었습니다.

요청 지연과 계산 비용을 함께 줄였습니다

단순한 pairwise application에서 HEART는 기본 scheduler 대비 P99를 약 95.2% 낮췄고, Least-Request 대비로도 293ms에서 194ms로 줄였습니다. RPS를 50에서 200까지 올려도 안정적이었으며, 성능이 낮은 node replica의 CPU 사용률이 거의 균등해져 load balancing이 실제로 동작함을 확인했습니다. high-latency Scenario B의 50 RPS에서 OptTraffic 502ms·LATA 440ms인 반면 HEART는 357ms였습니다.

component가 연결된 DAG application에서 차이는 더 커졌습니다. latency 1ms 미만·400 RPS에서 기본 scheduler 30620ms, Least-Request 768ms, OptTraffic 1580ms, LATA 1450ms일 때 HEART는 82ms였습니다. RPS를 200→400으로 올려도 HEART는 60→82ms로 22ms만 증가한 반면 기본 scheduler는 약 61배 증가했습니다. CPU 사용률 편차도 기존 기법이 최저 27%·최고 103%로 벌어질 때 HEART는 최대-최소 차이가 약 3%였습니다.

설계 요소를 제거하는 ablation 실험으로 부하 추세 분석의 효과를 확인했습니다. 추세를 반영했을 때 Scenario A의 P99는 366ms에서 176ms로 약 51.9%, Scenario B는 528ms에서 241ms로 약 54.4% 줄었습니다. 복합 부하에서도 CPU 사용률의 최대·최소 차이는 추세 반영 시 약 15%p, 제거 시 약 75%p였습니다.

Replica를 100개에서 400개로 늘렸을 때 LATA의 스케줄링 계산 시간은 8.8ms에서 98.1ms로, HEART는 6ms에서 9.4ms로 증가했습니다. 계산 단위를 개별 Replica에서 노드별 그룹으로 줄이고, 컴포넌트·컴포넌트 쌍 단위로 병렬 처리한 효과입니다. Go 1.22.6로 구현했고 마스터 1대·워커 5대의 이기종 Kubernetes 1.27.5 환경에서 검증했습니다. 저는 LATA에 이어 공동 설계·구현에 참여했으며, IEEE CLOUD 2025에 게재됐습니다.

이번 실험은 안정적인 노드 환경에서 최대 400개 Replica를 대상으로 수행했습니다. 30초 주기 갱신 사이에 발생하는 장애에는 즉시 대응하기 어려워, 장애 이벤트 연동과 오토스케일링 결합을 후속 과제로 남겼습니다.