Kubernetes GPU 학습 스케줄링 최적화, Datadog으로 TAS와 gang scheduling 모니터링하는 법

AS-IS: 기본 스케줄러가 놓치는 두 가지

분산 학습 job의 pod들은 서로 의존적입니다. 매 학습 스텝마다 워커들이 AllReduce나 gather, reduce, all-to-all 같은 collective communication 연산으로 데이터를 주고받는데, 이 통신은 지연에 민감해서 워커들이 클러스터 어디에 배치되느냐가 성능을 좌우해요. 같은 노드 안(NVLink/NVSwitch 또는 PCIe), 같은 랙 내 다른 노드, 다른 랙 이렇게 topology domain에 따라 대역폭과 지연이 달라지는데, 기본 Kubernetes 스케줄러는 이런 물리적 위치 관계를 전혀 고려하지 않고 pod를 아무 노드에나 배치합니다. 또한 학습 job은 지정된 수의 pod가 모두 running 상태가 돼야 작업을 시작할 수 있는데, 기본 스케줄러는 이 상호의존성을 인식하지 못해서 일부 워커만 배치된 채로 나머지를 기다리는 상황이 생겨요. 이 사이 GPU는 이미 할당돼서 비용은 발생하는데 실제로는 아무 작업도 못 하는 상태가 됩니다.

이번 내용: Kueue와 Coscheduling의 역할 분담

Kueue는 topology-aware scheduling을 담당하는 오픈소스 Kubernetes 네이티브 job 큐잉 시스템으로, kube-scheduler보다 위에서 어떤 job을 언제 스케줄러에 넘길지 통제해요. 노드에 미리 부여된 topology 라벨(예: topology.kubernetes.io/rack)을 기준으로 block, rack, host 단위 domain을 구성하고, job의 pod들이 대역폭 요구사항을 만족하는 하나의 domain 안에 들어가도록 admission 시점에 배치를 강제합니다. 다만 Kueue가 클러스터 topology를 스스로 발견하지는 못하고, 관리자나 클라우드 provider의 topology labeler가 라벨을 먼저 붙여줘야 해요. Coscheduling 플러그인은 scheduling framework를 통해 kube-scheduler를 확장해서 gang scheduling을 구현합니다. Kueue가 pod를 노드에 할당하면 그 pod는 Coscheduling의 Permit phase에서 대기하다가, 최소 요구 워커 수를 충족할 만큼 다른 pod들도 할당되면 그제야 모든 pod가 동시에 binding됩니다. gang이 조립되지 못하면 Coscheduling이 대기 중인 pod를 거부하고 스케줄러 예약을 해제해서, 부분적으로만 시작된 학습 job이 도는 상황을 막아줘요.

실무 적용 포인트

Datadog은 kueue_pending_workloads, kueue_admission_wait_time_seconds, kueue_evicted_workloads_total 같은 지표로 admission queue 상태와 배치 효과성, gang 조립 상태, 학습 처리량을 모니터링할 수 있다고 소개합니다. 클라우드 지출에서 GPU 비중이 커지는 조직이라면 다음을 체크해보면 좋아요.

• 클러스터 노드에 topology 라벨(rack, host 등)이 실제로 붙어 있는지 확인한다
• Kueue Workload 객체의 admission 상태와 대기 시간을 추적한다
• gang이 부분 조립 상태로 대기하다 evict되는 빈도를 살펴본다
• 인프라 지표(GPU 할당률)와 별도로 실제 학습 처리량 지표를 함께 본다

인프라 지표는 활동량을 보여줄 뿐 생산성을 보여주지 않기 때문에, GPU가 할당돼 있다고 해서 실제로 일하고 있다는 뜻은 아니에요.

자주 묻는 질문

TAS(topology-aware scheduling)란 무엇인가요

GPU 간 통신 대역폭을 고려해서 pod들을 물리적으로 가까운 위치에 배치하는 스케줄링 방식이에요. Kueue가 노드의 topology 라벨을 기준으로 block, rack, host 단위 domain 안에 job의 pod를 배치하는 방식으로 구현합니다.

gang scheduling은 왜 필요한가요

분산 학습 job은 지정된 모든 pod가 동시에 running 상태여야 작업을 시작할 수 있어요. 기본 스케줄러는 이걸 인식하지 못해서 일부 워커만 배치되고 나머지를 기다리는 동안 GPU가 할당된 채로 놀게 되는데, gang scheduling은 모든 pod가 동시에 binding되도록 강제해서 이런 낭비를 막아줍니다.

Kueue와 Coscheduling은 어떻게 다른가요

Kueue는 admission 단계에서 job을 언제 스케줄러에 넘길지 통제하고 topology 배치 제약을 설정하는 역할이고, Coscheduling은 kube-scheduler 자체를 확장해서 모든 pod가 동시에 binding되도록 gang 단위로 조율하는 역할이에요. 두 컴포넌트가 함께 동작해서 배치 정밀도와 동시성 조율을 모두 제공합니다.

Datadog으로 어떤 지표를 봐야 하나요

kueue_pending_workloads, kueue_admission_wait_time_seconds, kueue_evicted_workloads_total 같은 지표로 admission queue 상태와 gang 조립 여부, 학습 처리량을 확인할 수 있습니다. 인프라 지표만으로는 GPU가 실제로 유용한 작업을 하는지 알 수 없기 때문에 이런 별도 지표가 필요해요.