클러스터에서 가장 비싼 머신이 반드시 가장 중요한 머신인 것은 아닙니다.

GPU 대기열(Queue)이 가득 차기 전까지는 이 말이 당연하게 들릴 것입니다.

하지만 대기열이 차는 순간, 클러스터는 협상의 대상이 됩니다. 어떤 학습 작업(Training job)이 좋은 장치를 가져갈 것인가? 어떤 배치 워크로드(Batch workload)가 대기할 것인가? 어떤 추론 서비스(Inference service)가 지연 시간 예산(Latency budget)을 유지할 것인가? 어떤 팀이 요청한 랙 로컬 배치(Rack-local placement)를 받을 것인가? 절반만 시작된 작업이 희소한 하드웨어를 점유하는 동안, 나머지 절반은 스케줄링되지 못하고 방치되는 상황을 어떻게 허용할 것인가?

이 지점에서 AI 인프라는 단순한 조달(Procurement)의 이야기가 아닌, 스케줄러(Scheduler)의 이야기가 됩니다.

Kubernetes는 한동안 그 방향으로 움직여 왔습니다. 동적 리소스 할당(Dynamic Resource Allocation)은 장치 요청을 단순히 "이 포드(Pod)에 GPU를 할당하라"는 수준보다 더 표현력 있게 만들었습니다. Kubernetes v1.36에서 진행 중인 최신 워크로드 인식 스케줄링(Workload-aware scheduling) 작업은 다음 단계의 문제를 밀어붙입니다. 즉, 많은 고가의 워크로드는 실제로는 포드 형태(Pod-shaped)가 아니라는 점입니다. 이들은 그룹입니다. 이들은 한 번에 충분한 용량이 필요하며, 종종 적절한 토폴로지(Topology) 내에 있어야 하고, 개별 포드 하나하나가 아닌 작업 전체에 의미 있는 장애 동작(Failure behavior)을 가져야 합니다.

이는 처음 보이는 것보다 더 큰 변화입니다.

스케줄러는 더 이상 단순히 빈 슬롯을 찾는 존재가 아닙니다.

이제 스케줄러는 희소한 AI 용량을 하나의 작업 단위(Unit of work)로서 중개(Broker)하기 시작했습니다.

포드 단위(Pod by pod)는 잘못된 사고 모델이다

Kubernetes는 우리 중 많은 이들이 포드 단위로 생각하도록 훈련시켰습니다.

상태가 없는 서비스(Stateless services)의 경우에는 대개 문제가 없습니다. 포드는 CPU, 메모리, 어쩌면 볼륨, 노드 셀렉터(Node selector), 혹은 몇 가지 어피니티 규칙(Affinity rules)이 필요합니다. 스케줄러는 세상을 살펴보고 노드를 찾아내며, 포드는 적절한 어딘가에 안착합니다.

하지만 AI 및 고성능 배치 워크로드(High-performance batch workloads)는 이보다 훨씬 더 까다롭습니다.

분산 학습 작업(Distributed training job)은 여러 개의 워커(Worker)가 동시에 시작되어야 할 수도 있습니다. 만약 파드(Pod)의 절반만 실행되고 나머지 절반이 대기 상태라면, 클러스터는 생산적이지 못한 상태가 됩니다. 이는 값비싼 가속기(Accelerator)를 그저 불안감으로 바꾸고 있을 뿐입니다. 어떤 작업은 빠른 네트워크 경로를 공유하는 장치(Device)를 필요로 할 수도 있습니다. 모든 all-reduce 연산을 느리게 만드는 토폴로지(Topology)로 작업이 분산되는 것을 피해야 할 수도 있습니다. 또한, 개별 파드별로 무관하게 나열된 장치 요청(Claim)들의 집합이 아니라, 그룹을 위한 공유된 장치 요청(Shared device claim)이 필요할 수도 있습니다.

이 시점에서 "이 파드를 스케줄링하라"는 질문은 너무나 규모가 작습니다.

더 나은 질문은 이것입니다: "이 워크로드가 하나의 응집력 있는 개체로서 실행될 수 있는가?"

Kubernetes v1.36의 워크로드 인식 스케줄링(Workload-aware scheduling) 작업은 그 질문을 더욱 명확하게 만듭니다. Workload API는 정적 템플릿(Static template)에 가까워지는 반면, PodGroup은 런타임 스케줄링 객체(Runtime scheduling object)가 됩니다. 이러한 분리는 단순한 API 정리 작업이 아닙니다. 배치되는 대상이 공유된 제약 조건(Shared constraints)을 가진 파드 그룹일 때, 스케줄러가 추론할 수 있는 더 명확한 객체를 제공합니다.

쉽게 말해, 스케줄러가 모든 파드를 독립적인 작은 섬인 것처럼 가장하는 대신, 작업의 '작업(Job)과 같은 형태'를 볼 수 있게 되는 것입니다.

이것이 중요한 이유는 AI 용량(Capacity)이 독립적으로 소비되는 경우가 거의 없기 때문입니다.

갱 스케줄링(Gang scheduling)은 큐의 정직함이다

갱 스케줄링(Gang scheduling)은 틈새적인 배치 컴퓨팅(Batch-computing) 용어처럼 들리지만, 개념은 간단합니다.

만약 워크로드가 함께 실행되기 위해 4개의 파드를 필요로 한다면, 파드 하나를 스케줄링하고 나머지 3개가 결국 자리를 찾기를 바라지 마십시오. 그룹이 최소 요구 사항을 충족할 수 있거나, 아니면 대기해야 합니다.

그것이 바로 큐의 정직함(Queue honesty)입니다.

이것이 없다면 클러스터는 매우 어처구니없는 상태로 빠질 수 있습니다. 부분적인 작업들이 리소스를 점유하고, 차단된 작업들은 계속 재시도하며, 운영자들은 대기 중인(Pending) 파드들을 바라보게 됩니다. 그리고 모두가 클러스터의 자원이 부족한 것인지, 아니면 단순히 잘못된 할당 패턴(Allocation pattern)에 갇힌 것인지에 대해 논쟁하게 됩니다.

v1.36의 PodGroup 스케줄링 사이클은 그룹을 하나의 통합된 작업(unified operation)으로 평가한다는 점에서 흥ered합니다. 스케줄러는 클러스터 상태에 대한 하나의 관점을 취하여 그룹을 위한 유효한 배치(placement)를 찾으려 시도하고, 관련 포드(pod)들에 대해 해당 결정을 원자적(atomically)으로 적용할 수 있습니다. 만약 그룹이 요구 사항을 충족할 수 없다면, 워크로드의 절반이 클러스터에 유출(leaking)되는 대신 그룹 자체가 대기하게 됩니다.

이것은 화려한 기능은 아닙니다.

하지만 이것이야말로 값비싼 인프라를 실제로 사용할 수 있게 만드는, 바로 그 지루한 동작의 전형입니다.

AI 워크로드는 부분적인 성공을 특히 고통스럽게 만듭니다. 레플리카(replica)가 하나 적은 웹 서비스는 성능이 점진적으로 저하(degrade gracefully)될 수 있습니다. 하지만 워커(worker)가 누락된 분산 학습(distributed training) 작업은 장치(device)를 점유하고 있으면서도 아무런 유용한 일을 하지 못할 수 있습니다. 잘못된 토폴로지(topology)에 분산된 배치(batch) 워크로드는 네트워크 오버헤드에 추가 시간을 낭비하면서 기술적으로는 실행될 수도 있습니다.

따라서 스케줄러는 "일부가 실행되고 있는 상태"가 진전(progress)이 아닐 때를 이해해야 합니다.

토폴로지는 용량의 일부이다

"GPU가 충분하다"라는 문구에는 많은 세부 사항이 숨겨져 있습니다.

어디에 충분하다는 것인가요?

어느 노드(node)에 있나요?

어떤 네트워크 뒤에 있나요?

어떤 장치 유형(device types)인가요?

어떤 공유 규칙(sharing rules) 하에 있나요?

밀접하게 결합된(tightly coupled) AI 작업의 경우, 용량(capacity)은 단순히 숫자가 아닙니다. 클러스터의 어색한 네 구석에 흩어져 있는 네 개의 가용 장치는 서로 가까이 있는 네 개의 장치와 동일하지 않을 수 있습니다. 네트워크 경로가 자원의 일부가 됩니다. 랙(rack) 배치가 자원의 일부가 됩니다. 장치 지역성(device locality)이 자원의 일부가 됩니다. 스케줄러는 용량의 양(amount)뿐만 아니라 용량의 형태(shape)에도 신경을 써야 합니다.

이것이 토폴로지 인식 스케줄링(topology-aware scheduling)이 단순한 배치 최적화 이상의 의미를 갖는 이유입니다.

Kubernetes v1.36은 토폴로지 제약 조건(topology constraints)이 PodGroup에 존재할 수 있도록 하여, 스케줄러가 그룹의 포드들을 랙(rack)과 같은 물리적 또는 논리적 도메인 내에 유지하는 배치를 시도할 수 있게 합니다. 구현에는 여전히 한계가 있으며, Kubernetes 포스트는 이에 대해 매우 솔직하게 밝히고 있습니다. 이것은 기초(foundation)이지, 마법 지팡이가 아닙니다.

하지만 방향은 옳습니다.

AI 플랫폼 팀은 단순히 "가속기(accelerators)가 필요하다"는 요구뿐만 아니라, "워크로드(workload)를 실행할 가치가 있도록 이러한 형태의 가속기가 필요하다"는 요구를 표현할 수 있는 방법이 필요할 것입니다. 만약 이것이 스케줄러(scheduler) 외부에 머문다면, 이는 부족 간의 암묵적인 지식(tribal knowledge), 래퍼 스크립트(wrapper scripts), 커스텀 큐(custom queues), 그리고 왜 비싼 작업이 또 느려지는지 묻는 심야의 Slack 메시지로 전락하게 됩니다.

토폴로지(Topology)는 계약의 일부가 되어야 합니다.

구전 설화가 아니라 말입니다.

선점(preemption)은 정치적인 문제가 된다

선점(Preemption)은 스케줄링이 순수하게 기술적인 영역을 벗어나는 지점입니다.

클러스터(cluster)가 중요한 워크로드를 수용할 수 없다면, 다른 무언가가 이동해야 할 수도 있습니다. 일반적인 포드 단위(pod-by-pod) 스케줄링에서도 선점은 이미 섬세한 작업입니다. 워크로드 인식 스케줄링(workload-aware scheduling)에서는 중단되는 단위가 전체 PodGroup이 될 수 있기 때문에 더욱 흥미로워집니다.

Kubernetes v1.36은 PodGroup을 단일 선점 단위(preemptor unit)로 취급하는 워크로드 인식 선점(workload-aware preemption) 기능을 도입합니다. 이는 한 번에 하나의 노드씩 희생자(victim)를 평가하는 대신, 클러스터 전체를 살펴보고 해당 그룹을 위한 충분한 공간을 확보할 수 있습니다. PodGroup의 우선순위(priority)와 중단 모드(disruption mode)는 해당 그룹을 독립적으로 처리할지 아니면 한꺼번에 처리할지를 명시할 수 있는 더 많은 언어를 제공합니다.

이 지점이 바로 스케줄러가 비즈니스 정책(business policy)을 반영하기 시작하는 지점입니다.

어떤 학습 실행(training run)이 어떤 배치 작업(batch job)을 중단시킬 수 있는가? 연구 실험이 낮은 우선순위의 워크로드를 축출(evict)하는 것이 허용되는가? 부분적인 축출이 기다리는 것보다 상황을 악화시킨다면, 그룹을 하나의 단위로 중단시켜야 하는가? 팀들이 예약된 용량(reserved capacity)에 비용을 지불하고 있는가, 아니면 공통 풀(common pool)을 공유하고 있는가? 클러스터는 활용도(utilization), 공정성(fairness), 마감 기한(deadlines), 아니면 우선순위 클래스(priority class)로 위장된 경영진의 긴급성(executive urgency) 중 무엇을 선호하는가?

Kubernetes가 당신을 대신해 이 질문들에 답해주지는 않을 것입니다.

좋습니다.

그래야만 합니다.

하지만 Kubernetes는 플랫폼 팀이 모든 정책을 관습과 커스텀 컨트롤러(custom controllers)의 더미로 인코딩하지 않도록 더 나은 프리미티브(primitives)를 제공할 수 있습니다. 우선순위와 중단 동작(disruption behavior)은 단순한 스케줄러 조절 노브(knobs)가 아닙니다. 그것은 자원 정치(resource politics)가 API 필드로 변모하는 지점입니다.

이것이 불편하게 들린다면, 실제로 그렇기 때문입니다.

또한 이것은 정직한 것입니다.

DRA는 이 파트너를 필요로 했다

Dynamic Resource Allocation (DRA)는 가속기(accelerators)가 모두 동일하지 않기 때문에 중요한 단계였습니다.

하드웨어가 모델, 토폴로지 (topology), 드라이버 (driver), 상태 (health), 파티셔닝 (partitioning), 그리고 공유 동작 (sharing behavior)에 따라 다르기 때문에, 일반적인 확장 리소스 (extended resource)를 요청하는 것은 너무 투박합니다. DRA는 Kubernetes가 특화된 장치를 요청하고 바인딩 (bind)할 수 있는 더 풍부한 방법을 제공합니다. v1.36에서 DRA는 더 나은 폴백 선호도 (fallback preferences), 더 넓은 리소스 지원, 그리고 PodGroup 수준에서의 ResourceClaim 지원을 통해 계속 확장되고 있습니다.

하지만 장치 할당(device allocation)만으로는 작업이 완료되지 않습니다.

필요한 하드웨어를 설명할 수 있게 되더라도, 여전히 그것을 사용할 워크로드 (workload)를 배치해야 합니다. 이것이 바로 DRA와 워크로드 인식 스케줄링 (workload-aware scheduling) 사이의 통합이 흥미로운 장기적 이야기인 이유입니다.

DRA는 다음과 같이 답합니다: 이 작업에는 어떤 종류의 장치가 필요한가?

워크로드 인식 스케줄링은 다음과 같이 답합니다: 이 작업이 적절한 형태(shape)로, 적절한 우선순위 (priority) 및 중단 규칙 (disruption rules) 하에 그룹으로서 실행될 수 있는가?

AI 인프라의 경우, 이 질문들은 하나로 묶여 있습니다.

완벽한 장치 세트를 할당할 수 있지만 작업을 잘못 스케줄링하는 플랫폼은 여전히 돈을 낭비하고 있는 것입니다. 갱 동작 (gang behavior)은 이해하지만 실제 장치에 대해 추론할 수 없는 스케줄러 또한 불완전합니다. 유용한 컨트롤 플레인 (control plane)은 장치 클레임 (device claims), 토폴로지 (topology), 큐잉 (queueing), 선점 (preemption), 상태 (health), 그리고 소유권 (ownership)을 연결하는 것입니다.

이때 비로소 Kubernetes는 포드 (pods)를 실행하는 장소라기보다, 값비싼 용량 (capacity)을 위한 브로커 (broker)처럼 보이기 시작합니다.

플랫폼 팀의 업무는 여전히 남아 있다

이 중 그 어떤 것도 플랫폼 엔지니어링 (platform engineering)을 없애지 않습니다.

그것은 업무의 성격을 바꿀 뿐입니다.

유혹적인 실수는 이러한 기능들을 읽고 스케줄러가 어려운 선택들을 자동으로 수행할 것이라고 가정하는 것입니다. 그렇지 않습니다. 어떤 워크로드가 갱 스케줄링 (gang scheduling) 자격이 있는지, 어떤 토폴로지 레이블 (topology labels)이 의미가 있는지, 어떤 큐 (queues)가 존재하는지, 우선순위 클래스 (priority classes)가 실제 약속에 어떻게 매핑되는지, 선점 (preemption)을 인간에게 어떻게 설명할지, 그리고 팀이 배치될 수 없는 워크로드를 어떻게 디버깅할지를 누군가는 여전히 결정해야 합니다.

운영 단계 (day-two work)가 진정한 시험대가 될 수도 있습니다.

사용자가 PodGroup이 왜 대기 중인지 이해할 수 있을까요? 운영자가 어떤 토폴로지 제약 조건(topology constraint) 때문에 배치가 불가능해졌는지 확인할 수 있을까요? 재무 담당자가 왜 용량(capacity)이 유휴 상태임에도 특정 작업에 할당되지 않는지 이해할 수 있을까요? 엔지니어가 차단 원인이 장치 상태(device health), 할당량(quota), 우선순위(priority), 토폴로지(topology), 또는 잘못된 요청(bad request)인지 구분할 수 있을까요? 플랫폼이 "대기 중(pending)" 상태가 더 이상 미스터리한 상태가 되지 않도록 충분한 정보를 노출할 수 있을까요?

이 지점이 바로 AI 인프라가 제품(product)이 되는 단계입니다.

단순한 GPU 노드의 더미나 YAML 박물관이 아닙니다. 큐(queues), 설명(explanations), 기본값(defaults), 에러 메시지(error messages), 예산(budgets), 그리고 탈출구(escape hatches)를 갖춘 제품입니다.

스케줄러 기본 요소(scheduler primitives)는 필수적이지만, 그 주변의 사용자 경험(user experience)에 따라 팀들이 플랫폼을 신뢰할지, 아니면 플랫폼을 우회할지가 결정될 것입니다.

핵심 요약 (the punchline)

AI 용량(capacity)은 단순히 클러스터 크기의 문제가 아닙니다.

그것은 YAML 재킷을 입고 있는 공정성(fairness), 토폴로지(topology), 선점(preemption), 그리고 관측 가능성(observability)의 문제입니다.

Kubernetes의 워크로드 인식 스케줄링(workload-aware scheduling)이 흥미로운 이유는 플랫폼을 실제 작업의 형태에 더 가깝게 이동시키기 때문입니다. PodGroup은 스케줄러가 모든 Pod가 독립적으로 존재한다고 가정하는 대신 그룹 단위로 추론할 수 있게 해줍니다. 갱 스케줄링(Gang scheduling)은 부분적인 작업이 값비싼 리소스를 점유(squatting)하는 것을 방지합니다. 토폴로지 인식 배치(Topology-aware placement)는 용량이 어디에 위치하는지가 중요하다는 점을 인정합니다. 워크로드 인식 선점(Workload-aware preemption)은 우선순위와 중단(disruption)을 명시적인 정책으로 전환합니다.

DRA와 결합하여, 이는 AI 인프라를 위한 더 성숙한 모델을 가리킵니다.

"GPU를 샀으니, 행운을 빕니다"가 아닙니다.

그보다는 다음과 같습니다: 클러스터는 희소한 장치(scarce devices)를 이해하고, 스케줄러는 워크로드의 형태를 이해하며, 플랫폼 팀은 모두가 동시에 동일한 고가의 하드웨어를 원할 때 용량이 어떻게 공유되어야 하는지를 표현할 수 있습니다.

이는 벤치마크 차트보다 덜 흥미로울 수 있습니다.

하지만 대부분의 팀이 실제로 직면하게 될 문제에 훨씬 더 가깝습니다.

AI 플랫폼의 미래 병목 현상은 Kubernetes가 워크로드를 실행할 수 있는지 여부가 아닐 수도 있습니다.

오히려 이 질문이 핵심일 수 있습니다. 즉, 이러한 장치(devices)를 가진 이 워크로드가, 이 토폴로지(topology)에서, 이 우선순위(priority)로, 왜 다른 워크로드가 아닌 지금 실행되어야 하는지를 Kubernetes가 설명할 수 있는지 여부입니다.

이것이 바로 스케줄러가 용량 브로커(capacity broker)가 되어가고 있다는 의미입니다.

그리고 일단 청구서가 도착하고 나면, 모두가 갑자기 브로커(brokers)에 관심을 갖게 됩니다.

references

• Kubernetes: Kubernetes v1.36: Advancing Workload-Aware Scheduling
• Kubernetes: Spotlight on WG Device Management
• Kubernetes: Kubernetes v1.36: More Drivers, New Features, and the Next Era of DRA

제 프로젝트를 테스트하기 위해 저는 Railway를 사용합니다. 시작할 때 20달러(USD)를 받고 싶다면, 이 링크를 사용하세요.