무슨 일이냐면요
스트리밍 서비스 뒤에는 사용자 눈에 안 보이는 거대한 작업들이 쉴 새 없이 돌아가요. 영상을 화질별로 인코딩하고, 추천 모델을 학습시키고, 매일 쌓이는 로그를 가공하죠. 이런 걸 “배치 작업”이라고 불러요. 실시간 요청이 아니라 한 묶음씩 백그라운드에서 처리하는 일이거든요. 문제는 이런 작업이 수천, 수만 개씩 동시에 몰린다는 거예요. GPU나 CPU 자원은 한정돼 있는데, 여러 팀이 서로 “내 작업 먼저 돌려줘” 하면서 경쟁하니까 누가 얼마나 쓸지 정리해주는 “교통정리” 시스템이 꼭 필요해요. 넷플릭스는 그 교통정리를 Kueue라는 오픈소스로 바꿨는데, 그 이야기를 풀어볼게요.
Kueue가 뭐냐면요
쿠버네티스(Kubernetes)는 컨테이너를 자동으로 굴려주는 시스템인데, 원래는 “계속 떠 있는 서버(웹 서비스 같은)”를 다루는 데 강해요. 반대로 “시작했다가 끝나는 작업(배치 잡)”을 똑똑하게 줄 세우는 기능은 약했거든요. 기본 스케줄러는 “지금 빈 자리 있으면 바로 넣어”라는 식이라, 자리가 없으면 작업들이 우르르 대기만 하면서 자원을 어정쩡하게 잡아먹는 문제가 생겨요.
Kueue는 여기서 “대기열 관리자” 역할을 해요. 핵심 개념 몇 개만 알면 돼요. ClusterQueue는 “이 묶음이 쓸 수 있는 자원 총량(쿼터)”을 정하는 통이에요. LocalQueue는 각 팀이나 네임스페이스가 작업을 던져 넣는 입구고요. ResourceFlavor는 “어떤 종류의 하드웨어(예: A100 GPU냐, 일반 CPU냐)”를 구분해줘요. 작업이 들어오면 Kueue가 “지금 쿼터 안에서 돌릴 수 있나?” 확인하고, 가능할 때만 실제로 쿠버네티스에 내려보내요(이걸 admission, 입장 허가라고 해요). 자리가 없으면 파드를 띄우지 않고 대기열에 얌전히 세워두니까 클러스터가 어수선해지지 않아요.
특히 멋진 건 코호트(cohort)와 빌려쓰기(borrowing)예요. A팀이 자기 쿼터를 다 안 쓰고 놀고 있으면, B팀이 그 남는 자원을 잠깐 빌려서 쓸 수 있어요. 그러다 A팀이 다시 자기 작업을 돌려야 하면 선점(preemption)으로 빌려준 자원을 되찾아오죠. 덕분에 전체 클러스터 사용률은 높이면서도 각 팀의 최소 보장량은 지켜줘요.
다른 선택지와 비교하면
배치 스케줄링 분야엔 경쟁자가 꽤 있어요. Volcano는 AI 학습용 갱 스케줄링(분산 학습처럼 여러 파드를 전부 동시에 띄워야 하는 경우)에 강하고, Apache YuniKorn은 빅데이터(Spark 등) 쪽에서 많이 쓰여요. 이들에 비해 Kueue의 장점은 “쿠버네티스 표준에 가깝다”는 거예요. 기본 Job 리소스를 그대로 쓰면서 그 위에 얇게 얹히는 구조라 러닝커브가 낮고 생태계 호환이 좋거든요. 넷플릭스가 자체 시스템을 버리고 Kueue로 간 것도, 직접 만들어 유지보수하는 부담보다 잘 큰 오픈소스 표준에 올라타는 게 낫다고 판단한 거죠.
한국 개발자에게
요즘 한국에서도 ML 학습이나 데이터 파이프라인을 쿠버네티스 위에서 돌리는 곳이 빠르게 늘고 있어요. GPU가 워낙 비싸다 보니 “여러 팀이 한정된 GPU를 어떻게 공정하게 나눠 쓰지?”가 진짜 현실적인 고민이거든요. 이럴 때 Kueue를 알아두면 좋아요. 자체 대기열 로직을 짜느라 고생하는 대신, 쿼터·공정 분배·선점을 선언적으로(YAML 설정만으로) 해결할 수 있으니까요. 사내 GPU 클러스터를 운영하거나 MLOps를 맡고 있다면 한 번쯤 PoC로 올려볼 가치가 충분해요.
마무리
한 줄로 정리하면, Kueue는 “쿠버네티스에 제대로 된 배치 대기열을 달아주는 표준 도구”예요. 넷플릭스 같은 큰 회사가 자체 솔루션을 접고 갈아탔다는 건 그만큼 성숙했다는 신호고요. 여러분 회사는 한정된 GPU 자원을 어떻게 나눠 쓰고 있나요? 자체 스케줄러를 쓰나요, 아니면 Kueue 같은 표준을 써볼 의향이 있나요?
🔗 출처: Hacker News