Manage Amazon SageMaker HyperPod Spaces directly from SageMaker Studio

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon SageMaker Studio에서 HyperPod EKS 클러스터의 Spaces를 직접 생성·관리하고 JupyterLab, Code Editor 또는 로컬 VS Code로 개발할 수 있게 됐으며, 관리자의 접근 설정과 선택적 사전 워밍으로 개발 환경 접근성과 시작 시간을 개선할 수 있다.

📌 핵심 요약

• Amazon SageMaker HyperPod는 대규모 파운데이션 모델 학습·추론용 인프라를 제공하며, 이번 SageMaker Studio 통합으로 HyperPod CLI나 kubectl 없이 브라우저에서 Spaces를 생성·설정·시작·중지·열 수 있다.
• 관리자는 Spaces 애드온과 EKS 접근 항목을 설정해야 한다. 웹 브라우저 접근에는 Custom install이 필요하며, 통합 출시 이전에 생성한 Studio 도메인은 사용자별 신원 전파를 활성화해야 사용자 작업 기록과 Space 소유권을 연결할 수 있다.
• 사용자는 JupyterLab이나 Code Editor를 브라우저에서 열거나 SSH-over-SSM으로 로컬 VS Code에 연결할 수 있다. JupyterLab 작업은 연결된 Amazon EBS 볼륨에 유지되며, 로컬 연결에는 SSH 키 관리나 포트 22 노출이 필요하지 않다.
• Space templates, Task Governance, Karpenter autoscaling, 영구 볼륨, Custom images, Idle shutdown, NVIDIA MIG 등은 필요에 따라 조합하는 선택 기능이다. Task Governance는 네임스페이스별 연산 할당량과 우선순위 기반 자원 진입을 지원하고, NVIDIA MIG는 A100/H100에서 분할 GPU 할당을 지원한다.
• Karpenter over-provisioning은 사전 워밍과 이미지 캐시로 Space 시작 시간을 콜드 스타트의 5–7분에서 약 30–40초로 줄일 수 있지만, 실행 중인 EC2 노드 유지 비용이 추가된다. 제시된 측정값은 CPU 환경 기준이며 GPU에는 별도 준비가 필요하다. Spaces 애드온 설정 자체에는 추가 요금이 없으나 원문의 Pricing 설명은 중간에 끊겨 있다.

🧩 주요 포인트

1. SageMaker Studio의 시각적 Space 관리 → 데이터 과학자의 일상 작업에서 명령줄 의존도를 낮추고, 같은 HyperPod 인프라에서 대화형 개발·학습·배포 자원을 활용하는 범위를 넓힌다.
2. EKS 접근 항목·사용자별 신원 전파·Task Governance → 사용자 작업과 Space 소유권을 추적하고, 다중 사용자 환경의 접근 및 연산 할당량을 관리하는 기반이 된다.
3. Karpenter over-provisioning의 약 30–40초 시작 시간과 EC2 유지 비용 → 개발 대기 시간 감소와 추가 비용 사이의 선택이 필요하며, CPU 측정값을 GPU 환경에 그대로 적용할 수 없다.

🧠 상세 정리

1. HyperPod의 역할과 Studio 통합의 배경

Amazon SageMaker HyperPod는 파운데이션 모델의 대규모 학습과 추론을 위한 전용 인프라를 제공하며, Amazon EKS 오케스트레이션으로 수백 개의 가속기에 걸친 분산 학습과 내장 복원력·자동 장애 복구를 지원한다. 학습뿐 아니라 수십억 매개변수 규모 모델의 저지연·확장 가능한 추론에도 같은 EKS 기반 인프라를 활용한다. 앞서 출시된 Amazon SageMaker Spaces for HyperPod 애드온은 이 클러스터에 대화형 개발 환경을 만들고, 분할 GPU 할당을 통해 학습 작업과 모델 배포 alongside 대화형 워크로드를 함께 실행할 수 있게 했다. 기존 생성·관리 방식은 주로 HyperPod CLI나 kubectl에 의존해 인프라 관리자에게 세밀한 제어를 제공했다. 이번 Studio 통합은 시각적 인터페이스를 선호하는 데이터 과학자와 ML 엔지니어가 브라우저에서 몇 번의 선택으로 JupyterLab과 Code Editor 환경을 열고 모델 개발에 착수하도록 돕는다.

2. IDE and Notebooks에서 제공하는 Space 관리

SageMaker Studio의 HyperPod 클러스터 상세 페이지에 추가된 IDE and Notebooks 탭은 Space 생성·설정·시작·중지·열기를 위한 사용자 인터페이스를 제공한다. 생성 양식에서는 연산 자원, 네임스페이스, 스토리지, 연산 할당량 관리를 위한 HyperPod Task Governance 및 이미지 설정을 구성할 수 있다. 검색 가능한 목록에는 Space 이름, 애플리케이션 유형, 상태, 접근 유형, 스토리지, GPU와 vCPU 할당량이 표시돼 환경과 자원 배분을 함께 확인할 수 있다. 사용하지 않는 Space는 한 번의 선택으로 중지해 연산 자원을 반환하고, 필요할 때 다시 시작할 수 있다. 실행 중인 환경은 브라우저의 JupyterLab 또는 Code Editor로 열거나 VS Code 같은 원격 IDE로 연결할 수 있어 일상적인 Space 운영에 CLI 도구가 필요하지 않다.

3. 관리자의 애드온·접근 권한·사용자 신원 설정

초기 설정은 관리자가 클러스터를 준비하고 데이터 과학자가 Space를 생성·여는 두 역할로 나뉘며, 관리자는 Amazon SageMaker AI 콘솔의 IDE and Notebooks 탭에서 최적화된 기본값을 쓰는 Quick install 또는 Custom install로 Spaces 애드온을 설치한다. 웹 브라우저 접근을 활성화하려면 Custom install이 필요하고, 설치 이후에는 네임스페이스와 Space templates를 구성하며 EKS 접근 항목으로 접근을 관리할 수 있다. 데이터 과학자의 IAM 역할에는 AmazonSagemakerHyperpodSpacePolicy, AmazonSagemakerHyperpodUserClusterPolicy, AmazonSagemakerHyperpodSpaceTemplatePolicy의 세 관리형 정책을 연결한다. Studio와 HyperPod Spaces 통합 출시 이전에 생성한 도메인은 도메인마다 한 번 사용자별 신원 전파를 활성화해 Space 생성·중지·삭제 작업을 EKS 접근 항목과 AWS CloudTrail에서 해당 사용자 프로필에 귀속시켜야 한다. 이 매핑은 생성자를 추적하고 Space가 비공개인지 Studio 도메인에서 공유되는지도 판단하는 엄격한 소유권 적용의 기반이며, update-domain으로 ExecutionRoleSessionNameMode를 USER_IDENTITY로 설정한 뒤 describe-domain으로 같은 값이 반환되는지 확인한다. 기존 실행 중인 앱은 영향을 받지 않고 사용자는 다음 로그인부터 새 설정을 적용받으며, 추가 기능은 필요에 따라 선택적으로 활성화할 수 있다.

4. 데이터 과학자의 접근과 JupyterLab 작업 환경

애드온 설치와 접근 설정이 끝나면 데이터 과학자는 SageMaker Studio의 Compute → HyperPod에서 클러스터를 선택하고 IDE and Notebooks 탭으로 Space 관리 화면에 접근한다. Space 상태가 Running이 되면 Open으로 브라우저의 JupyterLab 또는 Code Editor를 열거나 Open in VS Code로 로컬 편집기에 연결할 수 있으며, 콜드 클러스터에서는 보통 몇 분, over-provisioning을 적용하면 약 30–40초가 걸린다고 설명한다. JupyterLab Space에는 ipykernel을 사용하는 Python 3 노트북, Glue PySpark와 Glue Spark 콘솔, SparkMagic PySpark와 Spark 커널이 제공된다. 명령 실행용 터미널, 영구 스토리지를 탐색하는 파일 브라우저, 내장 채팅과 문맥 기반 도움말도 사용할 수 있다. 작업 내용은 연결된 Amazon EBS 볼륨에 유지되므로 Space를 중지했다가 다시 시작해도 작업 진행 상황을 잃지 않는다.

5. Code Editor와 로컬 VS Code 연결

Code Editor Space는 브라우저에서 VS Code와 유사한 경험을 제공하는 가벼운 웹 IDE로, 구문 강조와 IntelliSense를 지원하는 파일 편집 기능을 갖춘다. 통합 터미널에서는 셸 명령 실행, 학습 작업 제출, 클러스터 자원 조작이 가능하고, 언어 서버·린터·포매터용 확장과 Git 통합도 지원한다. 클러스터 파일 시스템 및 마운트된 Amazon FSx 볼륨에 직접 접근할 수 있어 학습 스크립트 작성·디버깅, 실험 설정 관리, 코드 저장소 작업에 적합하다고 설명한다. Spaces 목록에서 Open in VS Code를 선택하면 SSH-over-SSM 터널링으로 로컬 Visual Studio Code를 연결하므로 SSH 키를 관리하거나 포트 22를 노출할 필요가 없다. 이때 확장·테마·키 바인딩 등 로컬 VS Code 환경을 사용하면서 코드는 HyperPod 클러스터의 연산 자원에서 실행한다. AWS Toolkit for Visual Studio Code에서도 SageMaker AI > HyperPod 아래의 Spaces를 조회하고 패널에서 직접 시작·중지·연결할 수 있다.

6. 필요에 따라 조합하는 선택 기능

원문은 모든 추가 기능이 선택 사항이며 팀의 필요에 맞게 조합할 수 있다고 명시하고, 웹 브라우저 접근에는 AWS Application Load Balancer와 Amazon Route 53의 사용자 지정 DNS를 사용하지만 VS Code over SSM 원격 접근에는 이것이 필요하지 않다고 설명한다. Space templates는 연산 자원·이미지·스토리지·수명 주기 스크립트를 관리자가 미리 설정해 팀 간 일관된 구성을 제공하고, Task Governance는 Kueue를 통해 네임스페이스 수준의 연산 할당량·대기열·우선순위 기반 자원 진입을 지원한다. Karpenter autoscaling은 Space 수요에 따라 노드를 늘리거나 줄이며, Karpenter over-provisioning은 이미지를 미리 내려받은 준비된 노드로 시작 시간을 줄인다. EFS / FSx 영구 볼륨은 여러 Spaces에 걸쳐 유지되는 공유 사용자 디렉터리와 팀 데이터셋을 제공하고, Amazon ECR의 Custom images에는 팀별 런타임과 라이브러리를 담을 수 있다. Idle shutdown은 비활성 Spaces를 자동 종료해 연산 비용의 과도한 증가를 방지하며, NVIDIA MIG는 A100/H100 하드웨어의 GPU를 분할 할당해 대화형 워크로드의 비용 효율을 높이는 기능이다.

7. Over-provisioning으로 콜드 스타트를 줄이는 방식

Karpenter autoscaling으로 노드가 0개까지 축소된 HyperPod EKS 클러스터에서는 첫 Space 생성 시 기본적으로 5–7분의 콜드 스타트 지연이 발생하며, 주요 원인은 Amazon EC2 인스턴스 시작, Kubernetes 노드 등록, SageMaker Distribution 이미지 다운로드다. 지연에 민감한 JupyterLab과 Code Editor 작업에는 표준 Kubernetes over-provisioning 패턴으로 사전 워밍과 이미지 캐시가 완료된 노드 풀을 유지해 시작 시간을 약 30–40초로 줄일 수 있다. 우선순위가 -1000인 자리 확보용 Deployment는 준비된 각 노드에 실제 Space와 같은 CPU·메모리를 요청하는 파드 하나를 유지하고, initContainer는 Karpenter가 노드를 준비할 때 SageMaker Distribution 이미지를 미리 내려받는다. 사용자가 기본 우선순위 0의 Space를 생성하면 Kubernetes 스케줄러가 우선순위 -1000의 파드를 선점해 이미 준비된 노드에 Space를 배치하므로 노드 시작과 이미지 다운로드를 기다리지 않는다. 이후 Karpenter는 밀려난 자리 확보용 파드를 위한 대체 노드를 백그라운드에서 준비하며, 이 방식은 미리 유지한 자원으로 사용자 대기 시간을 줄이는 구조다.

8. 측정된 시작 시간, GPU 제약과 요금 정보의 한계

검증된 시작 시간은 할당 가능한 24 vCPU의 ml.m5.12xlarge에서 자리 확보용 파드에 2 vCPU와 8 GiB 메모리를 지정하고, 약 3.5 GB인 sagemaker-distribution:latest-cpu 이미지를 사용한 조건에서 제시됐다. Space가 자리 확보용 파드와 함께 들어갈 수 있으면 약 14초, 해당 파드를 선점하면 약 35초, 준비된 노드 풀이 없으면 5–7분이 걸렸다. 원문은 이 수치가 CPU 전용임을 명시하며, GPU Spaces에는 nvidia.com/gpu를 요청하는 별도 자리 확보용 Deployment와 GPU 이미지 사전 다운로드가 필요하다고 설명한다. 이를 준비하지 않으면 GPU 노드는 콜드 상태로 남고, 약 10 GB인 GPU 이미지는 3.5 GB CPU 이미지보다 다운로드 부담이 훨씬 크다. 준비된 각 노드는 EC2 인스턴스 하나를 Running 상태로 유지하므로 온디맨드 노드에서는 그 유지에 추가 비용이 발생한다. Pricing 부분은 Spaces 애드온 설정 자체에 추가 요금이 없다고 밝힌 뒤 기반 자원에 대한 지불 설명 도중 끊겨 있어, 제공된 자료만으로 구체적인 과금 대상과 전체 요금 조건을 확정할 수 없다.

🧾 핵심 주장 / 시사점

• SageMaker Studio 통합은 HyperPod의 대화형 개발 환경을 시각적으로 관리하게 해 데이터 과학자의 접근 부담을 낮추지만, 애드온 설치와 EKS 접근 설정이라는 관리자의 사전 준비는 여전히 필요하다.
• 사용자별 신원 전파와 Task Governance는 각각 작업·소유권 추적과 연산 자원 배분을 다루므로, 여러 사용자가 같은 HyperPod 인프라를 쓰는 환경에서 서로 다른 관리 요구를 지원한다.
• Over-provisioning의 시작 시간 개선은 준비된 노드와 이미지 캐시를 유지하는 데서 나오므로, 추가 EC2 비용과 CPU·GPU별 준비 조건을 함께 고려해야 측정 결과를 적절히 해석할 수 있다.

✅ 액션 아이템

• SageMaker Studio에서 HyperPod Spaces를 사용하기 위한 Spaces 애드온·EKS 접근 항목을 확인하고, 웹 브라우저 접근의 Custom install 및 기존 도메인의 사용자별 신원 전파 조건을 점검한다.
• 개발 방식에 맞춰 JupyterLab, Code Editor, 로컬 VS Code를 선택하고, JupyterLab의 Amazon EBS 작업 유지와 로컬 VS Code의 SSH-over-SSM 연결 특성을 활용한다.
• Karpenter over-provisioning의 약 30–40초 시작 시간과 EC2 유지 비용을 비교해 적용 여부를 검토하고, GPU 환경에는 CPU 측정값을 그대로 적용하지 않는다.

❓ 열린 질문

• 사용할 SageMaker Studio 도메인은 사용자별 신원 전파 활성화가 필요한 기존 도메인이며, 웹 브라우저 접근을 위한 Custom install이 설정돼 있는가?
• 현재 개발 작업에는 브라우저의 JupyterLab·Code Editor와 SSH-over-SSM으로 연결하는 로컬 VS Code 중 어느 환경이 적합한가?
• Karpenter over-provisioning으로 시작 시간을 5–7분에서 약 30–40초로 줄이는 이점이 EC2 유지 비용을 감수할 만큼 크며, GPU 환경의 별도 준비도 가능한가?