Share GPU clusters across teams with isolation and fairness using Amazon SageMaker HyperPod

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon SageMaker HyperPod의 EKS 기반 참조 아키텍처는 여러 팀이 하나의 GPU 클러스터를 공유하면서 중앙 인증, 팀별 작업 공간, 네임스페이스 권한 제한, 공정한 자원 배분과 비용 귀속을 함께 설계하는 방법을 제시한다.

📌 핵심 요약

• 여러 팀이 고가의 GPU 클러스터를 공유할 때는 통제되지 않는 자원 소비, 취약한 팀 간 격리, 팀별 비용 귀속의 어려움, 관리 부담이 발생할 수 있다. Amazon SageMaker HyperPod는 생성형 AI용 대규모 컴퓨팅 클러스터를 제공하며, Amazon EKS 또는 Slurm 기반으로 분산 학습·대화형 개발·추론을 지원하고 노드 상태 모니터링, 장애 복구, 클러스터 수명주기 관리를 자동 처리한다.
• 본문의 EKS 기반 참조 아키텍처에서는 Team A와 Team B가 하나의 HyperPod EKS 클러스터를 공유한다. AWS IAM Identity Center를 중앙 인증에, 팀별 SageMaker AI 도메인을 작업 공간에, Kubernetes 네임스페이스를 워크로드 격리에, HyperPod Task Governance를 공정한 자원 배분에 사용하며 네임스페이스별 비용 할당으로 팀별 지출 가시성과 비용 귀속을 제공한다.
• 사용자는 AWS IAM Identity Center를 통해 CLI 또는 SageMaker Studio로 접근한다. CLI에서는 aws sso login으로 인증해 팀 권한 세트의 임시 자격 증명을 얻고 kubectl로 작업을 제출하며, Studio에서는 팀별 SageMaker AI 도메인에 로그인해 팀별 실행 역할로 작업을 제출한다. Identity Center는 Microsoft Entra ID 같은 외부 자격 증명 공급자와 연동한다.
• EKS 액세스 항목은 Studio 실행 역할과 Identity Center가 생성한 CLI/Console 역할 모두에 필요하며, 관리형 또는 사용자 정의 RBAC 정책을 팀 네임스페이스로 제한한다. 각 네임스페이스에서는 HyperPod Spaces, HyperPod PyTorch jobs, HyperPod Inference endpoints를 실행할 수 있고, HyperPod Observability와 HyperPod Task Governance가 클러스터 전반의 모니터링, 컴퓨팅 할당량, 스케줄링 우선순위를 담당한다.
• 스토리지는 Amazon FSx for Lustre 또는 Amazon FSx for OpenZFS의 팀별 공유 디렉터리·사용자별 홈 디렉터리와, 팀 실행 역할이 접근을 관리하는 팀별 또는 공유 Amazon S3 버킷으로 구성된다. 외부 자격 증명 공급자 설정 예시는 Microsoft Entra ID의 TeamA, TeamB, Admin 그룹 생성으로 시작하지만, 제공된 본문은 사용자 계정 예시 도중에 잘려 후속 설정 절차를 확인할 수 없다.

🧩 주요 포인트

1. 중앙 인증과 팀별 SageMaker AI 도메인 → 기존 조직 계정을 활용하면서 팀별 작업 경험을 제공하고, Studio와 CLI라는 두 접근 경로를 함께 지원한다.
2. Studio 실행 역할·CLI/Console 역할의 네임스페이스별 RBAC 제한 → 두 접근 경로 모두에서 팀의 작업 범위를 자신의 네임스페이스로 한정하는 것이 격리 설계의 핵심이다.
3. HyperPod Task Governance와 네임스페이스별 비용 할당 → 공유 GPU의 공정한 배분과 팀별 비용 귀속을 설계에 포함하지만, 제공된 본문에는 구체적인 배분 규칙이나 비용 할당 설정이 제시되지 않는다.

🧠 상세 정리

1. 여러 팀의 GPU 공유가 만드는 운영 과제

본문은 같은 회사의 여러 팀이 생성형 AI 작업을 위해 고가의 GPU 클러스터에 공동으로 접근해야 하는 상황에서 출발한다. 대규모 언어 모델을 학습하는 데이터 과학 팀, 추론 워크로드를 실행하는 컴퓨터 비전 그룹, 새로운 모델 아키텍처를 실험하는 연구 팀이 동일한 클러스터를 필요로 할 수 있다는 예시를 든다. 이때 공유 환경에는 팀 간 격리 경계, 자원 배분의 공정성, 각 팀의 운영 독립성이 함께 요구된다. 적절한 멀티테넌트 아키텍처가 없으면 자원 소비를 통제하기 어렵고 팀 간 격리가 약해지며, 공유 GPU 비용을 실제 사용 팀에 귀속하기도 어려워진다고 설명한다. 여기에 관리 부담까지 더해지면 혁신 속도가 느려질 수 있으므로, 글의 문제의식은 GPU 공동 활용과 팀별 통제를 동시에 충족하는 구조에 있다.

2. HyperPod의 역할과 참조 아키텍처의 구성

Amazon SageMaker HyperPod는 생성형 AI 워크로드를 위한 대규모 컴퓨팅 클러스터 관리를 단순화하도록 설계된 AI 서비스로 소개된다. Amazon EKS 또는 Slurm으로 오케스트레이션되는 복원력 있고 최적화된 클러스터를 제공하며, 분산 학습과 대화형 개발, 모델 추론을 대규모로 실행하도록 지원한다. 또한 노드 상태 모니터링과 장애 복구, 클러스터 수명주기 관리를 자동으로 처리한다고 설명한다. 이 글은 그중 EKS 기반 환경에 초점을 맞춰 AWS IAM Identity Center, 팀별 SageMaker AI 도메인, Kubernetes 네임스페이스, HyperPod Task Governance, 네임스페이스별 비용 할당을 결합한 참조 아키텍처를 제시한다. 예시에서는 Team A와 Team B가 하나의 HyperPod EKS 클러스터를 공유하며, 사용자 인증에서 권한 부여를 거쳐 격리된 워크로드 실행 공간으로 이어지는 계층형 흐름을 구성한다.

3. AWS IAM Identity Center를 통한 중앙 인증

본문은 멀티테넌트 시스템의 기반을 사용자가 누구인지 자원 접근 전에 확인하는 견고한 인증으로 설명하고, AWS IAM Identity Center를 중앙 인증 계층으로 둔다. AWS Single Sign-On의 후속 서비스인 Identity Center는 AWS 계정과 애플리케이션 전반의 사용자 및 그룹 구성원을 한곳에서 관리하므로, 서비스마다 별도의 사용자 데이터베이스를 유지하는 부담을 줄이는 구조다. Microsoft Entra ID, Okta, Ping Identity 같은 기존 자격 증명 공급자와 연동해 조직의 기존 계정을 재사용할 수 있다는 점도 제시한다. SageMaker AI 도메인의 Identity Center 인증 지원을 통해 기업 계정으로 Studio에 SSO 로그인할 수 있으며, 권한 세트를 통한 AWS 계정 접근은 CLI 사용도 지원한다. 또한 본문은 Amazon Managed Grafana가 조직 사용자 인증에 Identity Center를 사용한다는 점을 들어, 워크로드 관측용 화면에 접근해야 하는 팀에도 이 인증 계층이 적합하다고 설명한다.

4. CLI 접근과 팀별 권한 세트의 흐름

CLI 경로에서 사용자는 aws sso login으로 인증을 시작하고 AWS IAM Identity Center 포털로 이동한다. 인증 후에는 자신의 팀에 연결된 권한 세트에서 임시 자격 증명을 얻으며, 이를 이용해 kubectl로 EKS 클러스터에 직접 작업을 제출한다. TeamA permission set과 TeamB permission set에는 CLI 작업에 필요한 IAM 정책이 포함되고, Identity Center는 각 권한 세트에 대응하는 IAM 역할을 자동으로 생성한다. 그림에 표시된 TeamA-permissionset-role과 TeamB-permissionset-role은 CLI/Console 역할이며, aws sso login으로 인증한 사용자의 IAM 주체가 된다. 따라서 CLI 경로의 권한 연결을 완성하려면 이 역할들도 EKS 액세스 항목에 등록해야 하며, Studio 실행 역할만 설정하는 것으로는 본문이 제시한 두 접근 경로를 모두 포괄할 수 없다.

5. 팀별 SageMaker AI 도메인과 Studio 작업 공간

두 번째 접근 경로에서는 사용자가 AWS IAM Identity Center 포털에서 SageMaker Studio 애플리케이션을 선택해 자신의 팀에 해당하는 SageMaker AI 도메인으로 로그인한다. 참조 아키텍처는 Team A와 Team B에 각각 별도의 도메인을 배치하며, 각 도메인이 팀 전용 Studio GUI를 제공하도록 구성한다. 도메인에는 각각 TeamA-role과 TeamB-role이라는 팀별 실행 역할이 연결되어 있고, 사용자는 이 작업 공간의 GUI에서 EKS로 작업을 제출할 수 있다. 이 실행 역할은 CLI에서 사용하는 권한 세트 기반 역할과 구분되며, Studio에서 발생한 요청을 EKS 경계에서 승인하는 IAM 역할로 사용된다. 본문에서 팀별 도메인은 팀에 맞춘 사용자 경험과 주 작업 인터페이스를 제공하는 계층이고, 실제 클러스터 자원 접근 범위는 이어지는 EKS 액세스 항목과 네임스페이스 권한 설정을 통해 제한된다.

6. EKS 액세스 항목과 네임스페이스 권한 제한

EKS 경계에서는 액세스 항목이 IAM 역할을 Kubernetes 권한에 연결하며, 이 연결이 인증된 사용자가 실제로 어떤 자원에 접근할 수 있는지를 결정한다. 그림에는 Studio 실행 역할인 TeamA-role과 TeamB-role의 액세스 항목이 표시되어 있지만, 본문은 kubectl 요청을 승인하기 위해 TeamA-permissionset-role과 TeamB-permissionset-role에도 액세스 항목이 필요하다고 명시한다. 모든 액세스 항목에는 관리형 또는 사용자 정의 역할 기반 접근 제어인 RBAC 정책을 연결하고, 적용 범위를 해당 팀의 지정된 네임스페이스로 한정한다. 그 결과 Studio와 CLI 중 어느 경로로 접근하더라도 사용자는 자신의 네임스페이스 안에 있는 자원에만 상호작용할 수 있다는 것이 이 설계의 설명이다. Team A의 Namespace A와 Team B의 Namespace B는 하나의 클러스터 안에서 팀별 실행 공간을 나누며, 인증 경로별 역할을 같은 팀 경계에 맞춰 연결하는 것이 권한 설계의 핵심이다.

7. 공유 플랫폼 계층과 팀별 워크로드

클러스터 상단에는 여러 팀에 걸쳐 적용되는 플랫폼 계층으로 HyperPod Observability와 HyperPod Task Governance가 배치된다. HyperPod Observability는 모니터링과 대시보드를 담당하고, HyperPod Task Governance는 컴퓨팅 할당량 관리와 스케줄링 우선순위를 담당한다고 설명한다. 각 팀의 네임스페이스 안에서는 대화형 개발 환경인 HyperPod Spaces, 분산 학습용 HyperPod PyTorch jobs, 모델 제공용 HyperPod Inference endpoints를 실행할 수 있다. 참조 아키텍처는 이와 함께 네임스페이스별 비용 할당을 포함해 팀별 지출 가시성을 제공하고 공유 GPU 비용을 팀에 귀속하는 방향을 제시한다. 다만 제공된 본문에는 구체적인 할당량 수치, 팀별 우선순위 규칙, 비용 할당의 설정 절차가 나오지 않으므로, 여기서 확인할 수 있는 것은 각 구성 요소의 역할과 전체 설계에서의 위치까지다.

8. 스토리지 구성과 제공된 설정 예시의 범위

클러스터 아래의 스토리지는 POSIX 호환 파일 시스템과 객체 스토리지라는 두 계층으로 구성된다. 첫 번째 계층은 Amazon FSx for Lustre 또는 Amazon FSx for OpenZFS이며, /fsx/TeamA와 /fsx/TeamB 같은 팀별 공유 디렉터리와 /home/User1, /home/User2 같은 사용자별 홈 디렉터리로 정리된다. 두 번째 계층은 팀별 또는 공유 Amazon S3 버킷으로, 접근은 팀의 IAM 실행 역할에 의해 관리된다고 설명한다. 이어지는 외부 자격 증명 공급자 설정 부분에서는 Microsoft Entra ID를 예시로 사용하되, 같은 패턴을 대부분의 표준 SAML 2.0 공급자에도 적용할 수 있다고 밝힌다. 구체적인 그룹 구성은 TeamA, TeamB, Admin이라는 세 그룹을 만들고 각 팀의 사용자를 해당 그룹에 포함하는 방식으로 시작하지만, 제공된 본문은 사용자 계정 예시 도중에 끝나므로 이후 연동 절차나 설정 완료 조건은 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 중앙 인증과 팀별 작업 공간은 서로 다른 역할을 맡는다. AWS IAM Identity Center가 조직 계정을 통합하고, SageMaker AI 도메인이 팀별 사용자 경험을 제공하며, EKS의 네임스페이스 권한이 실제 작업 범위를 제한하는 구조다.
• Studio와 CLI를 함께 지원하는 환경에서는 두 경로의 IAM 역할을 모두 고려해야 한다. 본문이 CLI/Console 역할의 EKS 액세스 항목도 별도로 요구하는 것은 접근 경로 전체에 동일한 팀 경계를 적용하기 위해서다.
• 이 참조 아키텍처는 워크로드 격리뿐 아니라 자원 배분과 비용 귀속까지 공유 클러스터 설계에 포함한다. 다만 제공된 내용만으로 HyperPod Task Governance의 구체적 정책이나 네임스페이스별 비용 할당 구현을 재현하기는 어렵다.

✅ 액션 아이템

• AWS IAM Identity Center와 팀별 SageMaker AI 도메인을 연결해 Studio·CLI의 팀별 접근 구조 구성.
• Studio 실행 역할과 CLI/Console 역할 모두에 팀 네임스페이스로 제한된 EKS 액세스 항목 및 RBAC 정책 적용.
• HyperPod Task Governance의 공정한 자원 배분과 네임스페이스별 비용 할당의 구체적 설정 확인.

❓ 열린 질문

• HyperPod Task Governance에서 팀별 컴퓨팅 할당량과 스케줄링 우선순위는 어떤 규칙으로 설정하는가?
• 네임스페이스별 비용 할당은 공유 GPU 비용을 각 팀에 어떻게 귀속하는가?
• Microsoft Entra ID에서 TeamA, TeamB, Admin 그룹을 생성한 뒤 AWS IAM Identity Center 연동을 완료하려면 어떤 후속 설정이 필요한가?