GPU 워크로드의 자동 확장 문제는 Kubernetes가 결정을 내리지 못해서가 아니라, 결정이 너무 늦게 도착하기 때문일 수 있다. Adobe의 Ramkumar Nagaraj와 Bingi Narasimha Karthik은 중요 프로덕션 서비스가 수요 급증을 겪으면서 사용자 오류율이 15–20%까지 상승한 사례를 설명한다. Horizontal Pod Autoscaler가 확장을 시작했음에도 발생한 일이었다. 수백 개의 컨테이너가 대기 상태에 머물렀고, 새로운 GPU 노드가 준비되기까지 오랜 시간이 걸렸기 때문이다.
두 저자가 기록한 순서에 따르면 수요 급증은 06:00에 발생했고, HPA 지표는 06:05에 임계값을 초과했으며, 컨테이너 스케줄링은 06:15에 시작됐다. 그러나 첫 번째 GPU 노드의 프로비저닝이 완료된 것은 06:45로, 급증이 끝난 뒤였다. GPU 노드 프로비저닝에는 일반적으로 CPU 기반 서비스를 프로비저닝하는 시간의 3~5배가 걸린다. 펌웨어 로드, 드라이버 초기화, CUDA 준비가 필요하기 때문이다.
수요에 반응하는 것에서 수요에 대비하는 것으로
팀은 Kubernetes 내부에서 60초마다 실행되는 컨트롤러를 제안했다. 이 컨트롤러는 과거 1시간의 지표를 읽고 10분 후의 수요를 예측한다. 목표는 완벽한 예측이 아니라, 수요 급증이 도착했을 때 노드와 컨테이너가 준비되어 있을 만큼 충분히 일찍 용량 준비를 시작하는 것이다.
이 설계는 Prometheus가 수집하는 CPU 및 메모리 사용량, 응답 시간, 요청률, GPU 사용량 등의 데이터를 활용했다. 팀은 ARIMA, 지수 평활, Prophet 라이브러리, LSTM을 테스트한 뒤 64개와 32개 유닛으로 구성된 두 개의 레이어를 갖춘 Bi-LSTM 모델을 선택했다. 자료에 따르면 이 선택은 모든 경우에 이론적으로 가장 뛰어난 선택이어서가 아니라, 짧은 급증, 회복 구간, 비정상적인 고정값을 포함한 데이터 패턴에 대응하기 위한 것이었다.
모델은 매주 재학습되며, 배포된 모델은 TensorFlow Lite를 사용해 Go로 작성된 컨트롤러의 바이너리 안에서 추론 전용 모드로 실행된다. 따라서 이 설계에는 외부 머신러닝 플랫폼이나 모델 서빙 계층이 필요하지 않다.
확장을 제어하는 세 가지 계층
이 설계는 예측, 준비, 흡수라는 서로 연결된 세 가지 기능을 기반으로 한다. 모델이 수요를 예측하면 컨트롤러가 복제본을 점진적으로 늘리고, 사전에 준비된 용량이 실제 급증을 수용할 여유를 제공한다.
예측만으로 모든 돌발 상황을 처리할 수 없기 때문에 팀은 병렬로 작동하는 급증 감지기를 추가했다. 이 구성 요소는 이동 표준편차를 기반으로 한 적응형 임계값을 사용해 실제 수요와 예측을 비교한다. 수요가 정해진 신뢰 수준을 충족하는 차이만큼 예측을 초과하면 감지기가 확장 속도를 높인다. 두 저자는 이 구성 요소를 두 번째 예측 모델이 아니라 추론 기반 안전망이라고 설명한다.
점진적 확장기는 증가량을 분당 20개 컨테이너로 제한한다. 이는 스케줄러와 etcd에 부담을 주고, 이미지 풀링, 컨테이너 실행, 초기화 컨테이너 준비, 사이드카 주입 작업이 서로 밀리는 대규모 스케줄링 파동을 방지하기 위한 것이다. 목표 사용률도 100%가 아닌 70%로 설정해 급증을 흡수할 여유를 남기고, 모델이 때때로 부정확하더라도 오류가 연쇄적인 장애로 이어지지 않도록 했다.
테스트에서 입증된 것은 무엇인가?
팀은 먼저 실제 확장을 실행하지 않고 예측만 기록하는 섀도 모드로 시스템을 실행했으며, 500시간 이상의 데이터를 수집했다. 결과에 따르면 10분 후 수요 예측이 실제 수요의 ±10% 오차 범위 안에 들어간 경우 정확도는 85%였다. 또한 급증 감지기는 10번 중 9번의 급증을 포착했고 오탐은 2건이었으며, 점진적 확장기 테스트에서는 연쇄 장애나 확장의 진동 현상이 나타나지 않았다.
시스템은 HPA v2와도 충돌 없이 함께 작동했다. 통제된 개발 환경에서 일주일간 검증하는 동안 23개 테스트를 모두 통과했다. 최초 장애를 일으킨 급증 패턴을 시뮬레이션했을 때 시스템은 약 11분 전에 급증을 감지할 수 있었다.
이 접근 방식은 언제 적합한가?
예측적 확장의 가치는 노드 프로비저닝에 2~3분 이상이 걸리고, 일일 패턴이나 주간 패턴 또는 알려진 이벤트처럼 수요를 부분적으로 예측할 수 있을 때 드러난다. 또한 최소 일주일 이상의 Prometheus 지표를 포함한 우수한 모니터링 데이터가 필요하다. 반대로 노드가 30초 안에 준비되거나, 수요가 완전히 무작위이거나, 팀의 최우선 목표가 비용 절감이라면 이 아이디어의 실효성은 낮아진다. 준비된 노드를 유지한다는 것은 예비 용량 비용을 지불한다는 뜻이기 때문이다.
편집부의 해석: 여기서 실질적인 변화는 HPA를 대체하는 것이 아니라, 일반적으로 수요가 나타난 뒤 대응하는 시스템에 예측 시간을 추가하는 것이다. 이는 특히 GPU 워크로드에서 중요하다. 인프라가 컨테이너를 실행하기 전 수십 분을 필요로 한다면 확장 결정의 속도만으로는 충분하지 않기 때문이다. 그러나 제시된 근거는 아직 통제된 검증에서 나온 것이며, 여러 프로덕션 환경에서 독립적으로 수행한 대규모 측정은 아니다.
팀의 실험 자체도 중요한 제약을 보여준다. 조정된 ARIMA 모델이 더 단순한 구조로도 비슷한 결과를 낼 수 있고, 수요 패턴이 변하면 모델이 며칠 만에 낡을 수 있다. 또한 특정 수의 복제본을 예측한 이유를 설명하는 일은 여전히 어려웠으며, 최적 데이터 규모, 재학습 주기, 추론 기반 급증 감지기가 전례 없는 이벤트를 포착할 수 있는 능력에 관한 문제도 아직 해결되지 않았다.
따라서 자료는 일주일간 지표를 수집하고, 단순한 모델을 학습시키며, 섀도 모드로 실행한 뒤 확장을 활성화하기 전에 정확도를 측정할 것을 제안한다. 프로덕션으로 전환할 때는 복제본 상한을 설정하고, 명확한 비활성화 절차를 마련하며, 가능하면 전체 확장을 허용하기 전에 제한된 확장 단계를 거쳐야 한다. 두 저자가 반복해서 제시하는 결론은 실용적이다. 모델의 복잡성 자체는 장점이 아니며, 더 단순한 해결책이 성공한다면 그것을 운영하는 편이 낫다.