월 150만 유저가 사용하는 LLM Inference 인프라 안정적으로 운영하기

스캐터랩이 자체 LLM Spotwrite로 AI 엔터테인먼트 서비스 제타를 운영하며, WAU 150만·초당 3~4천 RPS의 LLM 트래픽을 8개 이상 Azure 리전의 멀티 클러스터로 처리하는 인프라 개선 여정을 다룬다. Neo Cloud 시절의 GPU 확보난·안정성·스토리지·failover 문제를 AKS와 Karmada, Istio, Terraform 조합으로 풀었다. 그 결과 서빙 비용을 20% 이상, 운영 리소스를 절반 이상 줄였다.

핵심 포인트

유저 체류가 길고 밤낮 트래픽 격차가 커서, 클라우드·컨테이너·유연한 스케일링을 만족하는 Kubernetes Native 서빙을 채택했다.
Neo Cloud는 K8s 미지원·GPU 온도 이슈·공유 스토리지 부재·통합 Control Plane 부재로 수백 모델 동시 서빙에 한계가 있었다.
H100급 GPU를 단일 리전에서 확보하기 어려워 8개 이상 리전에 각각 AKS 클러스터를 띄우는 멀티 리전 전략을 택했다.
리전 추가 반복은 Terraform IaC로, 멀티 클러스터 디스커버리·부하분산은 Istio multi-primary로, 워크로드 배치는 Karmada 단일 Control Plane으로 해결했다.
결과적으로 전체 서빙 비용 20% 이상 절감, 운영 리소스 절반 이상 절감.

상세 정리

서빙 요구사항: 모든 머신이 클라우드의 On-demand·Spot·Reserved로 구성되고, vLLM·SGLang·TensorRT-LLM 같은 컨테이너 엔진으로 배포하며, 트래픽에 맞춰 GPU 수를 조절해야 했다.
Neo Cloud 한계 하나: A40·RTX 6000은 쉽게 구했지만 KV Cache 기술 발전으로 VRAM 큰 A100·H100까지 추론에 쓰게 되면서 고사양 GPU capacity 확보가 어려웠다.
Neo Cloud 한계 둘: 온도 이슈·GPU 에러로 안정성이 낮아, GPU 온도를 실시간 감지해 Pod을 죽이는 Health Check Probe까지 직접 작성했다.
Neo Cloud 한계 셋: 수십~수백 GB 모델 Checkpoint를 리전·클라우드별로 Replication 관리할 공유 스토리지가 마땅치 않았다.
Neo Cloud 한계 넷: 통합 Control Plane이 없어 특정 클라우드 장애 시 failover와 복구가 힘들었다.
해결 방향을 안정적 GPU capacity, 리전 간 빠른 스토리지, 단일 Control Plane 세 가지로 정리하고 Azure에서 안정화했다.
문제 1 클러스터 추가 반복: Resource Group·Blob·Registry·Networking·RBAC를 매번 수동 구성하던 것을 Terraform 모듈로 템플릿화해, 변수만 바꿔 terraform apply 한 번으로 새 리전을 올린다.
문제 2 디스커버리·부하분산: Istio Multi-cluster로 N개 클러스터를 한 Mesh에 엮어 같은 이름 서비스가 하나처럼 동작하며 각 클러스터 Pod에 균일 부하분산한다. Multi-primary라 한 클러스터 장애가 Mesh 전체에 안 번진다.
문제 3 워크로드 배치: CNCF Karmada를 도입해 PropagationPolicy로 "이 모델은 eastus·westus에 3개씩, koreacentral엔 2개" 식 선언적 배포를 한다.
FederatedHPA: Karmada 자체 Metric Server가 멤버 클러스터 지표를 모아, 하나의 HPA 정의로 여러 클러스터를 트래픽에 맞춰 오토스케일한다.
스토리지: Blob Storage는 azcopy로 동일 리전이면 Checkpoint를 빠르게 로컬로 받고, 10B·30B급은 Blob에만 올려도 바로 Scale 가능했다. ACR Geo-replication으로 단일 레지스트리를 여러 리전에서 빠르게 pull한다.
향후 검토: Karmada에서 Azure Fleet Manager로 마이그레이션, Azure Managed Lustre로 수백 GPU 공유 KV Cache Sharing, KAITO·Azure ML 활용을 검토 중이다.