Kubernetes GPU 클러스터에서 오토스케일링을 구축한 사례

요약

네이버 SNOW가 NAVER ENGINEERING DAY 2025에서 발표한 AI 서비스 오토스케일링 작업. CPU 기반 서비스의 전통적 HPA로는 GPU 비용·할당 지연 때문에 그대로 쓰기 어려운 환경에서, KEDA(Event-Driven Autoscaler)를 베이스에 깔고 GPU 특화 시그널을 얹어 자체 오토스케일링 시스템 구축. 기본 HPA를 넘어선 형태로 글로벌 유저 트래픽에 동적 대응.

내용

SNOW는 글로벌 사용자가 시간대별로 몰렸다 빠지는 패턴이 큰 서비스. 이런 트래픽을 따라가려면 GPU 노드를 시간대별로 늘렸다 줄여야 하는데, GPU 기반 AI 서비스 오토스케일링은 CPU 기반과 결이 다름.

차이는 셋. 첫째, GPU 인스턴스 자체가 비싸 켜둔 채 대기시키는 비용이 크고 — CPU와 같은 감각으로 여유 자원을 두기 어려움. 둘째, GPU 노드 할당이 즉시 되지 않아(클라우드 GPU 공급, 이미지 부팅, 모델 로딩) 트래픽이 몰린 다음에야 노드를 띄우면 늦음. 셋째, 의미 있는 스케일링 신호가 CPU 사용률이 아니라 큐 깊이·요청 수·모델별 메트릭 같은 이벤트 신호 — Kubernetes 기본 HPA의 CPU/메모리 시그널만으론 모자람. 이 세 가지가 본 발표의 출발점.

해결 / 접근

KEDA를 베이스로 채택한 이유

KEDA(Event-Driven Autoscaler)는 Kafka·RabbitMQ·Prometheus 메트릭 같은 외부 이벤트를 스케일링 트리거로 끌어오는 Kubernetes 오토스케일러 프레임워크. CPU/메모리에 묶인 기본 HPA 대신 임의 메트릭으로 늘렸다 줄였다 할 수 있어, GPU 큐 깊이·요청 수·모델별 시그널을 트리거로 쓸 수 있는 베이스가 됨. 발표에서는 KEDA 도입 자체와 SNOW가 원하는 동작 간 격차도 짚음.

SNOW GPU Orchestration 시스템

KEDA 위에 SNOW가 추가로 얹은 자체 시스템. 발표 목차상 "기본 HPA보다 고도화된 방법"으로 묶이는 layer로, 사내 환경에 맞춘 스케일링 정책과 GPU 노드 라이프사이클 관리를 포함. 글로벌 트래픽의 시간대별 변동을 보고 미리 노드를 띄우거나 모델별로 달리 대응하는 구조.

결과 / 참고

• 적용 환경: 대규모 Kubernetes GPU 클러스터 위 SNOW AI 서비스
• 발표 대상: AI 서비스 운영용 GPU 기반 Kubernetes 도입 검토 엔지니어 / 기본 HPA보다 고도화된 오토스케일링이 필요한 엔지니어
• 발표 목차: SNOW가 GPU orchestration이 필요한 이유 → GPU 서비스 오토스케일링이 어려운 이유 → KEDA 소개 → SNOW GPU Orchestration 시스템
• 발표 채널: NAVER ENGINEERING DAY 2025(5월) 사내 세션, 네이버 D2에 영상 공개
• 출처: NAVER D2, "Kubernetes GPU 클러스터에서 AI 서비스 오토스케일링하기"