넷플릭스는 Kueue로 배치 컴퓨팅을 어떻게 간소화했는가

Netflix는 기존 자체 배치 시스템인 CMB의 큐잉·스케줄링 기능을 Kubernetes 기반 오픈소스인 Kueue로 대체해 배치 컴퓨팅을 단순화했다. Kueue는 Titus의 기존 스케줄러를 유지하면서 멀티테넌트 용량 관리, 우선순위 큐, 선점, 공정 공유 등을 제공해 기능 확장과 Kubernetes 네이티브 전환을 지원했다. Netflix는 사용자 API와 경험을 그대로 유지한 채 수백만 개의 배치 작업을 이전했으며, 현재 Kueue를 프로덕션에서 완전히 운영하고 있다.

CMB와 Titus의 기존 구조

• CMB(Compute Managed Batch)는 완료까지 실행되는 배치 작업을 제출·관리하는 Netflix의 관리형 서비스였다.
• 작업은 테넌트 계층 구조에 따라 관리되며, 우선순위와 큐 순서에 따라 실행됐다.
• Titus는 실제 작업 실행 플랫폼으로, 여러 Kubernetes 클러스터 또는 셀에 걸친 작업 배치와 용량 예약을 담당했다.
• CMB는 단일 Titus 엔드포인트를 통해 클러스터 토폴로지를 직접 알지 않고도 작업과 용량 예약을 관리할 수 있었다.

테넌트 계층과 용량 관리

• Internal Tenant
  • 조직이나 애플리케이션 구조를 표현하기 위한 중간 노드다.
  • 직접 작업을 수용하지 않으며, 하위에 internal tenant나 leaf tenant를 둘 수 있다.
• Leaf Tenant
  • 실제 작업을 제출할 수 있는 최종 테넌트다.
  • 큐를 가지며 하위 테넌트를 둘 수 없다.
• Reserved Capacity
  • 내부 테넌트에서는 하위 트리 전체가 용량을 공정하게 공유한다.
  • 리프 테넌트에서는 특정 용량을 독점적으로 예약해 다른 테넌트가 해당 자원을 예약하지 못하도록 한다.
• Shared Capacity
  • 모든 테넌트가 사용할 수 있는 전역 버스트 용량이다.
  • 기존 CMB에서는 작업이 승인된 뒤에는 선점되지 않았으므로, 이후 수요가 바뀌어도 작업이 끝까지 실행됐다.

Kueue를 선택한 이유

• Kueue는 kube-scheduler를 대체하지 않으므로 Titus의 기존 스케줄링 프로파일과 통합할 수 있다.
  • YuniKorn이나 Volcano처럼 스케줄러 자체를 교체하면 작업 배치가 분산되어 효율이 저하될 수 있었다.
• Kubernetes 생태계에서 빠르게 발전하고 있으며 채택 흐름도 강했다.
• 서로 다른 하드웨어를 사용하는 환경에서 멀티테넌트 쿼터를 관리할 수 있다.
• v1.Pod, batch/v1.Job뿐 아니라 RayJob, RayCluster 같은 고수준 리소스도 지원한다.
• CMB에서 구현하기 어려웠던 기능을 기본 제공한다.
  • 선점(preemption)
  • 전체 작업 단위의 원자적 스케줄링(all-or-nothing scheduling)
  • 토폴로지 인지 스케줄링(topology-aware scheduling)

Netflix Batch로의 마이그레이션

• 마이그레이션 프로젝트의 목표는 다음과 같았다.
  • CMB 사용자가 별도 작업을 하지 않아도 되는 투명한 이전
  • 컨테이너 실행률과 전체 최대 처리량 유지
  • CMB의 큐잉·스케줄링 로직을 Kueue로 대체
• 새로운 구조에서는 Kueue가 활성화된 Titus 셀에서 Kueue가 큐잉과 스케줄링을 담당한다.
• Titus federation은 Netflix가 만든 Kueue router를 통해 작업을 적절한 Kueue 셀로 전달한다.
• 운영자는 UI에서 테넌트의 마이그레이션 버튼을 누르는 것만으로 전환할 수 있으며, 문제가 발생하면 쉽게 롤백할 수 있었다.

CMB 개념을 Kueue 리소스로 변환

• 기존 internal tenant는 Kueue의 Cohort로 변환됐다.
• 기존 leaf tenant는 ClusterQueue와 LocalQueue 조합으로 변환됐다.
• 테넌트의 용량 설정은 Kueue의 다음 개념으로 매핑됐다.
  • Resource Flavor
  • Nominal Quota
• 이 구조를 통해 기존의 테넌트 계층과 용량 정책을 유지하면서 실제 큐 관리는 Kueue에 위임했다.

마이그레이션 과정에서 얻은 교훈

• 기존 API를 유지하고 내부 구현부터 교체하면 고객 경험을 바꾸지 않고 위험을 단계적으로 줄일 수 있다.
• 가장 복잡한 사용 사례를 마지막으로 미루지 않는 것이 중요했다.
  • Netflix는 가장 크고 복잡한 고객을 초기에 이전했다.
  • 이를 통해 다른 고객의 이전 가능성을 검증했고, 실제 프로덕션 마이그레이션은 4주 만에 완료됐다.
• 기본 설정만으로는 Netflix의 처리량을 감당할 수 없었다.
  • Kueue의 QPS, burst, groupKindConcurrency 값을 기본값보다 크게 조정해야 했다.
  • Titus와 유사한 개발 환경에서 부하 테스트를 일찍 수행해 성능 위험을 사전에 확인했다.

현재 운영 상태와 향후 방향

• Kueue는 Netflix 프로덕션에 완전히 배포되어 수백만 개의 배치 작업을 관리하고 있다.
• Netflix는 더 많은 Titus 배치 작업을 Kueue 기반의 관리형 환경으로 편입할 계획이다.
• 예약 용량 활용률을 높이기 위해 공정 공유와 선점 기능도 프로덕션 수준으로 확장했다.
• 이러한 경험은 Kubernetes 네이티브 학습·트레이닝 인프라를 구축하는 다른 내부 팀의 작업 큐와 스케줄링 설정에도 활용되고 있다.

Netflix의 사례는 기존 사용자 인터페이스와 실행 플랫폼을 유지하면서 큐잉 계층만 검증된 Kubernetes 구성 요소로 교체한 점이 핵심이다. 대규모 시스템에서는 한 번에 모든 것을 재작성하기보다 API 호환성, 단계적 전환, 조기 부하 테스트, 손쉬운 롤백을 함께 설계하는 접근이 실용적이다.