Kubernetes DRA는 AI 하드웨어를 API 계약으로 만들고 있습니다

Kubernetes는 지난 10년 동안 인프라를 API 객체로 천천히 전환해 왔습니다.

Pods, Services, Ingress, volumes, identities, policies, autoscalers, gateways. 이제 이 패턴은 익숙합니다. 어떤 것이 처음에는 복잡한 운영상의 문제로 시작되지만, Kubernetes가 이를 충분히 흡수하면 팀들은 Slack을 통해 암묵적인 지식(tribal knowledge)을 전달하는 것을 멈추고 리소스(resource)를 통해 의도(intent)를 표현하기 시작합니다.

Dynamic Resource Allocation (DRA)은 그것이 해결하는 문제에 직면하기 전까지는 매우 매력적이지 않게 들리는 변화 중 하나입니다.

그리고 AI 인프라는 그 문제를 매우 값비싸게 만들고 있습니다.

요약하자면: Kubernetes DRA는 워크로드(workload)가 기존의 "N개의 장치를 주고 운에 맡겨라" 방식 대신, 더 풍부하고 스케줄러를 인식하는 클레임(claims)을 통해 특화된 리소스를 요청할 수 있게 해줍니다. Kubernetes v1.36에서 DRA는 점점 더 본격화되고 있습니다. AWS 또한 Trainium과 Elastic Fabric Adapter를 위한 DRA 드라이버를 발표했는데, 이는 이것이 단순한 업스트림 아키텍처 천문학(upstream architecture astronomy)이 아니라는 매우 좋은 신호입니다.

이것은 플랫폼이 "내 Pod를 스케줄링해줘"에서 "희소한 하드웨어를 올바르게 중개해줘"로 이동하는 것입니다.

이것은 큰 변화입니다.

가속기(accelerators)는 단순히 더 큰 CPU가 아닙니다

오랫동안 Kubernetes 스케줄링은 주로 CPU와 메모리에 관한 것이었습니다. 네, 스토리지(storage)도 중요했습니다. 네, 네트워킹(networking)도 중요했습니다. 네, GPU도 존재했습니다. 하지만 워크로드 요청의 기본적인 형태는 일반적인 사람들이 이해할 수 있는 수준이었습니다: 이 Pod는 약간의 CPU, 약간의 메모리, 아마도 장치 개수, 그리고 몇 가지 배치 제약 조건(placement constraints)이 필요하다는 식이었죠.

AI 워크로드는 훨씬 덜 정중합니다.

그들은 가속기 유형(accelerator type), 토폴로지(topology), NUMA 경계(NUMA boundaries), 고성능 네트워킹(high-performance networking), 장치 지역성(device locality), 공유 동작(sharing behavior), 드라이버 설정(driver configuration), 그리고 ML 팀에게는 완벽하게 말이 되는 워크로드별 특이 설정들에 신경을 씁니다.

기존의 디바이스 플러그인 (device plugin) 모델은 Kubernetes가 특수 하드웨어를 인식하도록 도와주었지만, 이러한 작업들을 수행하기에는 여전히 너무 투박합니다. "가속기 4개"라는 것은 "적절한 네트워크 인터페이스와 가까운 곳에, 올바른 토폴로지 (topology)를 갖추어 배치된 가속기 4개"와 같은 의미가 아닙니다.

과거에는 이러한 차이점이 커스텀 스케줄러 (custom schedulers), 초기화 컨테이너 (init containers), 런칭 템플릿 (launch templates), 어드미션 훅 (admission hooks), 내부 런북 (internal runbooks), 그리고 어떤 인스턴스 유형을 절대 섞어서는 안 되는지 어떻게든 알고 있는 사람들의 머릿속에 숨겨져 있었습니다.

리소스 클레임 (resource claim)이 핵심적인 객체입니다

DRA에서 중요한 아이디어는 하드웨어 요구 사항이 스케줄러가 이해할 수 있는 클레임 (claims)이 된다는 것입니다.

특수 하드웨어를 단순히 평면적인 개수 (flat count)로 취급하는 대신, 플랫폼은 더 풍부한 속성 (attributes)을 노출할 수 있습니다. 워크로드는 특정 리소스 클래스 (class of resource)를 요청할 수 있습니다. 스케줄러는 배치를 논리적으로 추론할 수 있습니다. kubelet과 드라이버는 워크로드가 시작되기 전에 할당을 조정할 수 있습니다.

이것은 배관 작업 (plumbing)처럼 들리는데, 실제로 배관 작업이기 때문입니다.

하지만 좋은 배관 작업은 제품을 변화시킵니다.

희소한 하드웨어가 API 계약 (API contract)으로 표현되면, 플랫폼 팀은 이를 중심으로 골든 패스 (golden paths)를 구축할 수 있습니다. 모든 ML 엔지니어가 노드의 물리적 토폴로지 (physical topology)를 학습하게 만들지 않고도, 학습 (training), 추론 (inference), 실험 (experimentation), 그리고 비용이 많이 드는 프로덕션 작업 (production jobs)을 위한 승인된 리소스 클래스를 정의할 수 있습니다.

이것이 바로 승리입니다. ML 팀과 인프라 팀 사이의 복잡한 합의가 티켓과 관례에서 Kubernetes 객체 (objects)로 이동할 수 있습니다.

그렇게 되면 스케줄러는 조직적 계약 (organizational contract)의 일부가 됩니다.

토폴로지는 비용이 누수되는 지점입니다

AWS Trainium과 Elastic Fabric Adapter의 예시는 문제를 구체화해주기 때문에 유용합니다. 분산 AI 워크로드는 단순히 연산 (compute)만을 요구하는 것이 아닙니다. 이들은 연산과 더불어 빠른 통신 (fast communication)을 요구합니다. 만약 가속기와 네트워크 경로가 제대로 정렬되지 않는다면, 워크로드가 여전히 실행될 수는 있지만 더 느려질 것입니다. 느려진다는 것은 더 많은 비용이 든다는 것을 의미하며, 결국 팀들은 플랫폼을 우회하는 방법들을 고안하기 시작합니다.

이것이 인프라가 기이해지는 방식입니다.

누군가 특정 배치(placement)가 더 효과적이라는 사실을 발견합니다. 그러면 스크립트가 나타납니다. 그다음에는 그 스크립트를 사용하라는 위키(wiki) 페이지가 생깁니다. 3개월 후에는 플랫폼이 해당 패턴을 지원하는지, 아니면 그 패턴이 그저 영웅적인 예외 사항(heroic exceptions)들의 집합일 뿐인지 아무도 알지 못하게 됩니다.

DRA는 Kubernetes가 그러한 의도(intent)를 전달할 수 있는 네이티브한 장소를 제공한다는 점에서 흥미롭습니다. AWS는 EFA 및 Neuron DRA 드라이버를 고성능 네트워킹 및 가속기(accelerators)를 위해 Kubernetes에 토폴로지 인식 배치(topology-aware placement)를 제공하는 방법이라고 설명합니다. 핵심은 플랫폼이 중요한 제약 조건(constraints)을 유지하면서도, 선언적 요청(declarative request) 뒤로 물리적인 혼란을 더 많이 숨길 수 있다는 점입니다.

이것이 바로 훌륭한 플랫폼 추상화(platform abstractions)가 하는 일입니다.

물리학이 사라진 척하는 것이 아닙니다.

물리학에 더 나은 API를 제공하는 것입니다.

이것은 플랫폼 팀의 업무를 변화시킵니다

플랫폼 팀은 과거에 클러스터(clusters)를 제공했습니다. 그다음에는 배포 경로(deployment paths)를 제공했습니다. 그다음에는 보안 제어(security controls), 관측성(observability), 비밀(secrets), 서비스 템플릿(service templates), 내부 개발자 포털(internal developer portals), 그리고 프로덕션 시스템 주변에 서서히 쌓이는 그 외 모든 것들을 제공했습니다.

AI 하드웨어는 플랫폼 팀을 또 다른 역할인 리소스 브로커(resource broker)로 밀어넣습니다.

단순히 "포드(pod)를 실행할 수 있는가?"가 아니라 다음과 같은 질문을 던지게 됩니다:

어떤 팀이 이 가속기 클래스(accelerator class)를 사용할 권한이 있는가?
이 요청이 실험용인가, 아니면 프로덕션용인가?
이 워크로드(workload)가 네트워크 인터페이스를 안전하게 공유할 수 있는가?
이 작업에 토폴로지 보장(topology guarantees)이 필요한가?
이 워크로드가 더 저렴한 무언가를 선점(preempt)해야 하는가?
스케줄러(scheduler)가 왜 그곳에 배치했는지 어떻게 설명할 것인가?
이 요청이 한 시간 동안 대기 상태(pending)로 머물 경우 발생하는 비용은 얼마인가?

이 질문들은 YAML에 관한 사소한 지식이 아닙니다. 이것은 인프라의 옷을 입고 있는 비즈니스 질문들입니다.

이것이 제가 DRA가 중요하다고 생각하는 이유입니다. DRA는 플랫폼 팀이 이러한 결정들을 정책(policy)과 제품(product)으로 전환할 수 있는 더 나은 기본 요소(primitive)를 제공합니다. 대안은 커스텀 스케줄러(custom schedulers), 팀별 관례, 그리고 "대규모 작업을 실행하기 전에 인프라 채널에 문의하세요"라는 식의 늪에 빠지는 것입니다.

모든 팀을 하드웨어 팀으로 만들지 마십시오

여기에 함정이 있습니다.

AI 인프라는 비용이 많이 들고 전문화되어 있기 때문에, 조직은 애플리케이션 및 ML 팀에 너무 많은 세부 정보를 떠넘기고 싶은 유혹을 느낄 것입니다. "여기 가속기 유형, 네트워크 토폴로지 (topology), 드라이버 주의사항, 할당량 (quota) 모델, 그리고 스프레드시트가 있습니다. 알아서 잘 처리해 주세요."라고 말이죠.

그것은 플랫폼이 아닙니다. 그것은 kubectl을 사용하는 조달 프로세스일 뿐입니다.

더 나은 버전은 의견이 반영된 리소스 클래스 (opinionated resource classes)입니다.

팀들에게 작은 메뉴를 제공하십시오:

소규모 추론 (small inference)
배치 추론 (batch inference)
대화형 실험 (interactive experiment)
분산 학습 (distributed training)
대규모 예약 학습 (large reserved training)

이러한 클래스 뒤에서 플랫폼은 장치 할당, 토폴로지 (topology), 네트워크 지역성 (network locality), 공유 규칙, 할당량 (quota), 비용 라벨, 그리고 승인 정책 (admission policy)을 인코딩할 수 있습니다. 사용자는 여전히 비용과 트레이드오프 (tradeoffs)를 이해해야 하지만, 유용한 작업을 수행하기 전에 모든 물리적 제약 조건을 알 필요는 없어야 합니다.

모든 훌륭한 내부 플랫폼이 주는 교훈과 같습니다: 숨길 수 있는 것은 숨기고, 선택해야 하는 것은 노출하며, 위험한 경로는 명시적으로 만드십시오.

스케줄링 (scheduling)은 거버넌스 (governance)가 됩니다

사람들은 종종 AI 인프라를 용량 문제로 이야기합니다. 더 많은 GPU가 필요합니다. 더 많은 가속기. 더 많은 리전 (regions). 더 많은 할당량 (quota). 물론입니다. 때로는 정답이 말 그대로 "하드웨어를 더 구매하는 것"일 수도 있습니다. 하지만 구매한 후에도 여전히 그것을 할당해야 합니다.

그 할당 계층은 매우 빠르게 거버넌스 (governance)가 됩니다. 누가 우선순위를 갖는가? 어떤 작업이 가장 비싼 리소스 클래스를 사용할 수 있는가? 어떤 워크로드 (workloads)가 공유를 허용받는가? 어떤 요청이 승인을 필요로 하는가? 어떤 팀이 작업의 토폴로지 (topology)가 부적절함에도 불구하고 기술적으로는 정상이라서 돈을 낭비하고 있는가?

이 지점이 바로 Kubernetes가 Kubernetes다운 일을 계속하는 곳입니다. 컨트롤 플레인 (control plane)이 더 많은 모호성을 흡수합니다. 과거에 인간의 조정 문제였던 것이 API 형태, 스케줄러 (scheduler) 동작, 정책, 그리고 관찰 가능성 (observability)이 됩니다.

이것은 마법이 아닙니다. 여전히 어렵습니다. 하지만 모든 팀이 임시 스크립트를 통해 수동으로 하드웨어 액세스를 협상하는 것보다는 더 나은 종류의 어려움입니다.

내가 가장 먼저 할 일

만약 제가 오늘날 Kubernetes 기반의 AI 플랫폼을 구축한다면, 모든 DRA 기능을 모든 사용자에게 노출하는 것부터 시작하지는 않을 것입니다.

저는 이미 고통을 겪고 있는 하나의 값비싼 워크플로우(workflow)부터 시작할 것입니다.

팀들이 인프라의 도움을 정기적으로 필요로 하는 학습(training) 또는 추론(inference) 경로를 하나 선택하십시오. 한두 개의 리소스 클래스(resource class)를 정의하십시오. 비용 라벨(cost labels)을 추가하십시오. 명확한 할당량(quota)을 추가하십시오. 대기 중인 클레임(pending claims)을 가시화하십시오. 사람들이 "클러스터가 가득 찼다"와 "당신의 요청은 이 토폴로지(topology)로 충족될 수 없다"를 구분할 수 있을 만큼 배치 결정(placement decisions)을 충분히 설명 가능하게 만드십시오.

그런 다음 지루한 지표들을 측정하십시오:

작업(jobs)이 대기 상태로 머무는 빈도
팀들이 잘못된 클래스를 요청하는 빈도
가속기 용량(accelerator capacity)이 얼마나 고립(stranded)되어 있는지
수동 개입(manual intervention)이 필요한 빈도
토폴로지가 올바르게 처리될 때 성능이 얼마나 변하는지

그러한 피드백 루프(feedback loop)는 거창한 AI 플랫폼을 발표하는 것보다 더 중요합니다.

첫 번째 버전은 고통스러운 한 종류의 조정(coordination) 과정을 제거해야 합니다. 그다음 또 다른 것을, 그리고 또 다른 것을 제거해 나가는 것입니다.

핵심 요약 (the punchline)

Kubernetes DRA는 단순한 디바이스 할당(device allocation) 기능이 아닙니다. 이는 AI 워크로드(workloads)가 하드웨어를 플랫폼 API의 일부가 되도록 강제하고 있다는 신호입니다.

이는 좋은 현상입니다.

기존 모델은 팀들에게 너무 많은 물리적 세부 사항을 이해하도록 요구하거나, 너무 많은 숨겨진 플랫폼의 마법(platform magic)에 의존하게 만듭니다. 더 나은 모델은 희소하고 토폴로지에 민감한 리소스를 명시적인 클레임(claims), 정책(policies), 그리고 스케줄러 결정(scheduler decisions)으로 전환합니다.

미래의 AI 플랫폼은 단순히 Kubernetes에 연결된 가속기(accelerators)의 더미가 아닙니다. 그것은 모든 사용자를 하드웨어 전문가로 만들지 않고도 해당 가속기들을 중개할 수 있는 컨트롤 플레인(control plane)입니다.

컨테이너(Containers)는 컴퓨팅을 휴대 가능하게 만들었습니다. Kubernetes는 운영(operations)을 프로그래밍 가능하게 만들었습니다. 이제 AI 하드웨어는 다음 단계의 불편한 변화를 밀어붙이고 있습니다. 즉, 머신의 값비싼 부품들 또한 계약(contracts)이 필요하다는 것입니다.

그리고 무언가가 계약이 되는 순간, 누군가는 그 조건을 소유해야 합니다.

그것이 바로 플랫폼 엔지니어링(platform engineering)입니다.