SageMaker HyperPod 거버넌스: 프로젝트별 할당량 접근 방식
GPU 클러스터를 여러 팀이 공유하는 것은 간단해 보이지만, 모두가 새벽 2시에 같은 H100을 원하게 되면 복잡해집니다. AWS 자체의 SageMaker HyperPod 관리 가이드라인은 한 가지에 대해 명확합니다. 클러스터를 Unified Studio 프로젝트에 연결하는 것이 팀에게 작업 공간을 제공할 뿐, 보안 경계를 제공하지는 않는다는 것입니다. 프로젝트 멤버십, 테넌트 권한, 그리고 가속기 할당량 각각은 명시적인 설계가 필요합니다. 벤더 가이드라인이 실제로 말하는 내용은 다음과 같습니다.
1. 누가 인프라에 접근할 수 있는지부터 시작하기
팀들이 컴퓨팅 자원을 어떻게 '공유'할지 결정하기 전에, 누가 그것을 '생성'할 수 있는지 잠가야 합니다. AWS는 CreateCluster 및 UpdateCluster에 대한 세밀한 제어를 위해 세 가지 IAM 조건 키를 문서화합니다:
sagemaker:InstanceTypes — 호출자가 선택할 수 있는 인스턴스 유형을 제한함
sagemaker:VpcSubnets — 클러스터 생성을 승인된 서브넷으로 고정함
sagemaker:VpcSecurityGroupIds — 적용되는 보안 그룹을 제어함
이것은 인프라 API 계층입니다. 테넌트 및 워크로드 제어는 그 아래에 위치합니다. 다른 노브(knobs)가, 다른 계층인 것입니다.
2. 프로젝트는 격리가 아닌 협업의 영역이다
Unified Studio를 사용하면 프로젝트가 연결된 HyperPod 클러스터에서 워크로드를 시작할 수 있지만, AWS는 프로젝트를 '협업 경계'로 명시적으로 설명하며 — 클러스터는 SageMaker AI 인터페이스를 통해 관리됩니다. EKS 클러스터의 경우, 실제 런타임 경계는 고전적인 테넌트 격리 스택입니다: 테넌트당 네임스페이스, RBAC(Role-Based Access Control), 테넌트별 서비스 계정, EKS Pod Identity 역할, 기본 거부 네트워크 정책, 그리고 테넌트별 스토리지와 KMS 키.
가이드라인에서 발견할 수 있는 한 가지 미묘한 함정이 있습니다. AI Studio 사용자는 기본적으로 모든 EKS 클러스터 작업을 볼 수 있으며, Slurm의 경우 모든 사용자가 사용 가능한 작업들을 보고 관리하고 상호 작용할 수 있다는 것입니다. 프로젝트 멤버십 ≠ 작업 개인 정보 보호입니다. 이 동작을 명시적으로 확인해야 합니다.
3. 할당량은 오케스트레이터에 따라 달라지며, 서로 교체 가능하지 않다
EKS와 Slurm은 완전히 다른 용량 메커니즘을 사용하며, AWS는 Slurm이 EKS의 대여 및 차용(lending-and-borrowing) 모델과 동등한 것이 없다고 명시합니다:
| 고려 사항 | EKS | Slurm |
|---|
| 팀 할당 | HyperPod 작업 거버넌스 할당량 (quotas) | 계층적 계정을 사용한 회계 처리 (Accounting w/ hierarchical accounts) |
| ... | | |
On EKS에서는, 작업 거버넌스 애드온이 Kueue (Kubernetes 네이티브 할당량 관리)를 설치합니다. 이는 K8s 1.30 이상 버전, 클러스터 내 기존 HyperPod 노드, 그리고 기존 Kueue가 없어야 한다는 선행 조건(prerequisites)을 가진 실제 종속성입니다. 설치 후에는 SageMaker가 KueueManagerConfig, ClusterQueue, 및 LocalQueue 리소스를 대신 관리합니다. | | |
핵심 요약 (The takeaway)
공유 가속기 풀을 거버넌스하는 것은 계층적 설계 문제입니다: API 레이어의 IAM 조건 키, 런타임 레이어의 네임스페이스 + ID + 네트워크 + 스토리지, 그리고 스케줄링 레이어의 오케스트레이터별 할당량입니다. 어떤 레이어도 건너뛰면 팀이 차단되거나 예상치 못한 GPU 청구서가 발생할 수 있습니다.
더 깊이 알아보기 (Go deeper)
전체 워크스루는 각 제어를 다루며, 기본 AWS 문서 링크를 제공합니다: SageMaker HyperPod 거버넌스: 프로젝트 액세스부터 작업 부하 할당량까지.
원래 Agentic Affairs (https://agentic-affairs.com)에 게시되었습니다.