Netflix가 Kueue로 배치 잡 시스템을 전환한 이유
Netflix는 수년간 자체 개발한 인하우스 배치 잡 실행 시스템을 운영해 왔다. 그러나 시간이 지나면서 이 시스템의 한계가 누적됐고, 결국 오픈소스 클라우드 네이티브 배치 잡 큐잉 시스템인 Kueue로 대부분의 배치 워크로드를 마이그레이션하는 결정을 내렸다. 핵심 판단 기준은 단순했다. Kueue가 인하우스 솔루션의 기능 수준을 넘어서는 시점이 왔다는 것이다.
이 사례는 "직접 만든 시스템이 낫다"는 관성에서 벗어나, 성숙한 오픈소스 생태계를 적극적으로 수용하는 실용적인 의사결정의 전형을 보여준다. 특히 배치 처리 인프라는 비즈니스 핵심 도메인이 아닌 경우가 많기 때문에, 직접 유지보수 비용 대비 오픈소스 전환의 이점을 냉정하게 따져볼 필요가 있다.
Kueue의 핵심 개념과 인하우스 기능 매핑 방식
Kueue는 Kubernetes 위에서 동작하는 배치 잡 큐잉 레이어로, 클러스터 자원을 효율적으로 할당하고 우선순위 기반의 잡 스케줄링을 제공한다. Netflix는 기존 인하우스 시스템에서 구현했던 기능들을 Kueue의 개념에 1:1로 매핑하는 방식으로 전환을 진행했다.
Kueue의 주요 구성 요소는 다음과 같다:
- ClusterQueue: 클러스터 전체 자원 풀을 정의하며, CPU/메모리 등의 리소스 쿼터를 관리
- LocalQueue: 네임스페이스 단위로 잡을 제출하는 진입점 역할
- ResourceFlavor: 노드 유형(예: GPU 노드, 스팟 인스턴스 등)을 추상화
- Cohort: 여러 ClusterQueue 간의 자원 공유 및 차용(borrowing) 정책 설정
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
name: batch-queue
spec:
namespaceSelector: {}
resourceGroups:
- coveredResources: ["cpu", "memory"]
flavors:
- name: "default-flavor"
resources:
- name: "cpu"
nominalQuota: "100"
인하우스 솔루션에서 자체 구현했던 우선순위 제어, 자원 쿼터 관리, 공정 스케줄링(fair scheduling) 등의 로직을 Kueue의 선언적 API로 대체할 수 있었다는 점이 전환 작업의 핵심이었다.
자체 개발 대비 오픈소스 전환의 실무적 함의
인하우스 솔루션의 가장 큰 문제는 신규 기능 도입 비용이었다. 오픈소스 커뮤니티에서 Kueue에 추가되는 기능들, 예를 들어 프리엠션(preemption) 정책이나 동적 자원 재할당 같은 고급 스케줄링 기능을 자체 시스템에 동일하게 구현하려면 상당한 엔지니어링 리소스가 필요하다. Netflix는 이러한 기능들을 Kueue 전환과 함께 추가 비용 없이 확보할 수 있었다.
백엔드 시스템 설계 관점에서 이 전환이 시사하는 바는 명확하다:
- 인하우스 솔루션은 초기에는 통제권과 유연성을 주지만, 시간이 지날수록 유지보수 부채가 쌓인다
- 오픈소스 솔루션이 성숙해지는 시점을 지속적으로 모니터링하고, 전환 타이밍을 판단하는 것 자체가 엔지니어링 역량이다
- 전환 시에는 기존 기능을 새 시스템의 개념에 명확히 매핑하는 문서화 작업이 마이그레이션 성공의 전제 조건이다
정리
- Netflix는 인하우스 배치 잡 시스템의 한계가 누적되면서, 오픈소스 Kueue가 그 수준을 넘어섰다고 판단한 시점에 전환을 결정했다
- 기존 기능을 Kueue의 ClusterQueue, LocalQueue, Cohort 등의 개념에 매핑하는 방식으로 마이그레이션을 진행했다
- 자체 구현 비용이 높았을 고급 스케줄링 기능을 오픈소스 전환으로 추가 비용 없이 확보한 점이 핵심 이점이다