Amazon SageMaker HyperPod를 사용하여 격리와 공정성을 갖춘 상태로 팀 전체에 GPU 클러스터 공유하기

동일한 회사 내 여러 팀이 생성형 AI 작업을 위해 비용이 많이 드는 GPU 클러스터에 대한 공유 액세스를 점점 더 필요로 하면서도, 격리 경계, 리소스 공정성, 운영 독립성을 유지해야 합니다. 대규모 언어 모델을 학습시키는 데이터 사이언스 팀, 추론 워크로드를 실행하는 컴퓨터 비전 그룹, 새로운 모델 아키텍처를 실험하는 연구 팀을 생각해 볼 수 있습니다. 이들 모두 동일한 클러스터에 대한 액세스가 필요할 수 있습니다. 잘 설계된 멀티 테넌트(멀티 팀) 아키텍처가 없다면 조직은 통제되지 않는 리소스 소비, 팀 간 취약한 격리, 발생한 공유 GPU 비용을 해당 팀에 귀속시킬 수 없는 문제, 그리고 혁신의 속도를 늦추는 관리상의 오버헤드에 직면하게 됩니다.

Amazon SageMaker HyperPod는 생성형 AI 워크로드를 위한 대규모 컴퓨팅 클러스터 관리를 간소화하는 목적별 AI 서비스입니다. Amazon Elastic Kubernetes Service(Amazon EKS) 또는 Slurm로 오케스트레이션되는 복원력 있고 최적화된 클러스터를 제공하여, 조직이 분산 학습, 대화형 개발, 모델 추론을 대규모로 실행할 수 있도록 합니다. 동시에 노드 상태 모니터링, 장애 복구, 클러스터 수명 주기 관리를 자동으로 처리합니다.

이 게시물에서는 Amazon SageMaker HyperPod with EKS 위에 멀티 테넌트 환경을 구축하기 위한 참조 아키텍처를 소개합니다. 이 아키텍처는 중앙 집중식 인증을 위해 AWS IAM Identity Center를, 팀에 맞춤화된 사용자 경험을 위해 팀별 SageMaker AI 도메인을, 워크로드 격리를 위해 Kubernetes 네임스페이스를, 공정한 리소스 할당을 위해 HyperPod Task Governance를, 그리고 팀별 지출 가시성 및 차지백(chargeback)을 위해 네임스페이스 수준의 비용 할당을 사용합니다. 이 게시물을 끝까지 읽으면 여러 팀이 단일 HyperPod EKS 클러스터를 효율적으로 공유하기 위한 명확한 청사진을 갖게 될 것입니다.

아키텍처 개요

다음 다이어그램은 멀티 테넌트 HyperPod EKS 배포의 상위 수준 아키텍처를 보여줍니다. 이 예제에서는 두 팀(Team A와 Team B)이 단일 HyperPod EKS 클러스터를 공유하며, 각 팀은 자체적으로 격리된 네임스페이스 내에서 운영됩니다.

그림 1: 하나의 HyperPod EKS 클러스터를 공유하는 두 팀을 위한 상위 수준 멀티 테넌트 아키텍처

이 아키텍처는 왼쪽에서 오른쪽으로 이어지는 계층적 흐름으로 구조화되어 있으며, 사용자 신원을 인가 제어를 통해 연결하고 클러스터의 격리된 워크로드 네임스페이스로 이어집니다.

사용자 및 인증

가장 왼쪽에서는 각 팀의 개별 사용자(A팀의 User 1, B팀의 User 2)가 두 경로를 통해 시스템과 상호작용합니다. 두 경로 모두 왼쪽 아래에 표시된 외부 자격 증명 공급자(예: Microsoft Entra ID)와 연동되는 AWS IAM Identity Center Portal을 통해 인증을 수행합니다.

첫 번째 경로는 CLI 접근을 통한 것입니다. 사용자는 다음으로 인증합니다. aws sso login, 이는 사용자를 Identity Center 포털로 리디렉션하며, 그 후 팀의 권한 세트에서 임시 자격 증명을 받아 다음과 함께 EKS 클러스터에 직접 작업을 제출합니다 kubectl. 다이어그램에서 분홍색 화살표는 CLI 터미널에서 상단을 가로질러 HyperPod EKS 클러스터로 직접 흐릅니다.

두 번째 경로는 Identity Center 포털을 통해 직접 접속하는 것으로, 사용자는 SageMaker Studio 애플리케이션을 선택하여 자신의 팀 전용 SageMaker AI 도메인에 로그인합니다.

각 팀에는 CLI 워크플로에 필요한 AWS Identity and Access Management(IAM) 정책을 담고 있는 해당 권한 세트(TeamA 권한 세트, TeamB 권한 세트)가 있습니다. Identity Center는 각 권한 세트에 대한 IAM 역할을 자동으로 프로비저닝하며, 다이어그램에는 다음과 같이 표시되어 있습니다. TeamA-permissionset-role 그리고 TeamB-permissionset-role (“CLI/Console role”로 표시됨). 이 역할은 사용자가 다음을 통해 인증할 때 IAM 보안 주체로 작동합니다. aws sso login.

SageMaker AI 도메인

Identity Center 포털에서 사용자는 팀 전용 SageMaker AI 도메인으로 라우팅됩니다. 각 도메인(SageMaker AI 도메인 Team A 및 SageMaker AI 도메인 Team B)은 전용 Amazon SageMaker Studio GUI를 제공하며 팀 전용 실행 역할로 구성됩니다(TeamA-role 그리고 TeamB-role 각각에 해당합니다). 이러한 도메인은 기본 작업 공간 인터페이스 역할을 하므로, 사용자는 GUI에서 작업을 제출할 수 있습니다(분홍색 화살표가 EKS 쪽으로 흐르는 것으로 표시됨).

EKS 접근 제어

EKS 경계에서 액세스 엔트리는 IAM 역할을 Kubernetes 권한에 매핑합니다. 다이어그램은 다음에 대한 액세스 엔트리를 보여줍니다 TeamA-role 그리고 TeamB-role SageMaker Studio GUI에서 시작되는 요청을 승인하는 (Studio 실행 역할)입니다. Identity Center에서 프로비저닝된 CLI/Console 역할(TeamA-permissionset-role 및 TeamB-permissionset-role)에 대해서도 액세스 항목을 구성하여 다음을 통해 도착하는 요청을 승인해야 합니다: kubectl. 모든 액세스 항목은 관리형 또는 사용자 지정 역할 기반 액세스 제어(RBAC) 정책(키 아이콘으로 표시됨)과 연결되어 있으며 팀의 지정된 네임스페이스로 범위가 한정됩니다. 그 결과, 액세스가 Studio에서 시작되든 CLI에서 시작되든 사용자는 자신의 네임스페이스에 있는 리소스만 조작할 수 있습니다.

. 모든 액세스 항목은 관리형 또는 사용자 지정 역할 기반 액세스 제어(RBAC) 정책(열쇠 아이콘으로 표시됨)과 연결되며, 팀의 지정된 네임스페이스로 범위가 한정됩니다. 결과적으로 액세스가 Studio에서 시작되든 CLI에서 시작되든, 사용자는 자신의 네임스페이스 내 리소스와만 상호 작용할 수 있습니다.

클러스터 자체는 상단에 두 개의 교차하는 플랫폼 계층으로 표현됩니다: HyperPod Observability(모니터링 및 대시보드용)와 HyperPod Task Governance(컴퓨팅 할당량 관리 및 스케줄링 우선순위용). 이 계층들 아래에는 클러스터가 Namespace A(Team A)와 Namespace B(Team B)로 나뉩니다. 각 네임스페이스 내에서 팀은 자체 HyperPod Spaces(대화형 개발 환경), HyperPod PyTorch 작업(분산 학습 워크로드), HyperPod Inference 엔드포인트(모델 서빙)를 실행할 수 있습니다.

스토리지

클러스터 아래에는 아키텍처에 두 개의 스토리지 계층이 포함됩니다. 첫 번째는 팀별 공유 디렉터리(/fsx/TeamA, /fsx/TeamB)와 사용자별 홈 디렉터리(/home/User1, /home/User2)로 구성된 POSIX 호환 파일 시스템(Amazon FSx for Lustre 또는 Amazon FSx for OpenZFS)입니다. 두 번째는 오브젝트 스토리지를 위한 팀별 또는 공유 Amazon Simple Storage Service(Amazon S3) 버킷으로, 팀의 IAM 실행 역할에 의해 관리됩니다.

이 아키텍처는 인증부터 권한 부여, 워크로드 실행까지 각 팀을 격리하면서도, 값비싼 GPU 인프라를 효율적으로 공유합니다.

인증 및 액세스 제어

모든 멀티 테넌트 시스템의 기반은 강력한 인증입니다. 즉, 사용자가 어떤 리소스와 상호 작용하기 전에 사용자가 누구인지 확인하는 것입니다. 이 아키텍처에서 AWS IAM Identity Center는 중앙 집중식 인증 계층 역할을 하며, 외부 아이덴티티 공급자와 연동하여 사용자 자격 증명과 그룹 멤버십을 관리합니다.

왜 AWS IAM Identity Center인가

AWS IAM Identity Center(AWS Single Sign-On의 후속 서비스)는 AWS 계정 및 애플리케이션 전반에서 인력 자격 증명을 관리할 수 있는 단일한 위치를 제공합니다. 멀티 테넌트 HyperPod 배포를 위해 다음과 같은 몇 가지 핵심 기능을 제공합니다:

• 중앙 집중식 자격 증명 관리 – AWS 서비스별로 별도의 사용자 데이터베이스를 유지하는 대신, Identity Center는 모든 사용자 자격 증명과 그룹 멤버십에 대한 단일 신뢰 원천(source of truth)을 제공합니다.
• 기존 아이덴티티 공급자와의 연동 – 대부분의 기업은 이미 Microsoft Entra ID(구 Azure AD), Okta 또는 Ping Identity와 같은 시스템에서 인력 자격 증명을 관리하고 있습니다. Identity Center는 이러한 공급자와 통합되므로, 조직은 사용자 계정을 중복 생성하지 않고도 기존 자격 증명 인프라를 재사용할 수 있습니다.
• SageMaker AI와의 기본 통합 – SageMaker AI 도메인은 Identity Center 인증을 지원하므로, 사용자는 기업 아이덴티티 공급자를 통해 싱글 사인온(SSO)으로 SageMaker Studio에 로그인할 수 있습니다.
• AWS 계정 액세스 – Identity Center는 특정 권한 세트를 사용하여 기본 AWS 계정에 대한 사용자 액세스 권한을 부여할 수도 있으며, 이는 Studio GUI 환경과 함께 CLI 워크플로우를 지원합니다.
• Amazon Managed Grafana에 필요 – Amazon Managed Grafana는 인력 사용자를 위한 인증 메커니즘으로 Identity Center를 사용하므로, 팀이 워크로드 모니터링을 위한 관측성 대시보드에도 액세스해야 할 때 자연스러운 선택입니다.

자세히 알아보기: IAM Identity Center란 무엇인가

외부 아이덴티티 공급자와 Identity Center 구성

이 참조 아키텍처에서는 Microsoft Entra ID를 외부 아이덴티티 공급자로 사용하지만, 동일한 패턴이 대부분의 표준 SAML(Security Assertion Markup Language) 2.0 공급자에 적용됩니다.

구성은 다음을 포함합니다:

1. 아이덴티티 공급자의 그룹 구조 – Entra ID에서 조직 팀에 해당하는 그룹을 생성합니다. 이 예제에서는 세 개의 그룹을 정의합니다: TeamA, TeamB, 그리고 Admin. 각 그룹에는 해당 팀에 속한 사용자가 포함됩니다(예: user1-teamA@example.com 그룹의 TeamA ).
2. SCIM 프로비저닝 – Entra ID와 AWS IAM Identity Center 간에 SCIM(System for Cross-domain Identity Management) 동기화를 활성화합니다. SCIM은 사용자와 그룹의 자동 프로비저닝 및 프로비저닝 해제를 제공합니다. 새 사용자가 Entra ID의 해당 TeamA 그룹에 추가되면 Identity Center로 자동 동기화되어 수동 개입 없이 적절한 액세스 권한을 얻습니다.
3. SAML 기반 인증 – SAML 2.0 페더레이션을 구성하여 사용자가 인증할 때 Entra ID를 통해 인증하도록 합니다. Identity Center는 서비스 공급자 역할을 하며 Entra ID 테넌트의 어설션을 신뢰합니다.

이 구성을 통해 기존 기업 디렉터리에서 팀 멤버십(모든 후속 권한 부여 결정을 좌우함)을 관리하면 AWS로 자동 전파됩니다.

다음 이미지는 조직 팀이 Microsoft Entra ID에서 표현되는 방식의 예를 보여주며, 다음을 위한 전용 그룹이 포함됩니다 TeamA, TeamB, 그리고 Admin.

그림 2: Microsoft Entra ID에서 그룹으로 표현된 조직 팀

그런 다음 다음 이미지는 AWS IAM Identity Center의 해당 그룹을 보여주며, SCIM 동기화를 통해 Entra ID에서 자동으로 프로비저닝됩니다.

그림 3: SCIM을 통해 프로비저닝된 AWS IAM Identity Center의 해당 그룹

자세히 알아보기: 외부 자격 증명 공급자 연결 · SCIM 프로필 및 SAML 2.0 구현

권한 부여

인증이 설정되면 다음 계층은 권한 부여입니다. 즉, 각 팀이 AWS 서비스와 Kubernetes 클러스터 전반에서 수행할 수 있는 작업을 제어하는 것입니다. 이 아키텍처에서 권한 부여는 두 가지 수준에서 작동합니다. 서비스 수준 액세스를 위한 IAM과 클러스터 수준 액세스를 위한 Kubernetes RBAC입니다.

팀별 IAM 역할

각 팀에는 해당 팀의 AI 및 머신러닝(ML) 워크플로에 필요한 AWS 수준 권한을 담는 전용 IAM 역할이 필요합니다. 이러한 역할은 SageMaker AI 도메인 실행 역할로 사용되며, 팀이 액세스할 수 있는 AWS 서비스를 정의합니다.

일반적인 팀 IAM 역할에는 다음에 대한 액세스 권한을 부여하는 정책이 포함되어야 합니다:

• Amazon SageMaker AI – SageMaker AI API를 통해 HyperPod 클러스터, MLflow 추적 서버 및 기타 SageMaker AI 리소스를 관리하는 경우입니다.
• Amazon S3 – 학습 데이터셋 읽기 및 모델 아티팩트, 체크포인트, 로그 쓰기용입니다. 이 권한은 팀별 버킷 접두사로 범위를 한정하십시오.
• Amazon CloudWatch – 팀의 워크로드와 관련된 로그 및 메트릭을 확인하기 위한 것입니다.
• Amazon EKS – 구체적으로, 이 eks:AccessKubernetesApi 그리고 eks:MutateViaKubernetesApi Kubernetes API 호출을 사용자 대신 수행하기 위해 SageMaker Studio GUI가 필요로 하는 권한입니다(예: Spaces 나열 또는 작업 제출).

각 IAM 역할의 신뢰 정책에는 다음이 포함되어야 합니다. sagemaker.amazonaws.com 신뢰할 수 있는 주체로 지정하여, 사용자가 Studio를 통해 작업할 때 SageMaker AI가 사용자를 대신해 해당 역할을 수임할 수 있도록 합니다. 클러스터 내 워크로드를 위해 동일한 실행 역할을 EKS Pod Identity 연결로 재사용할 계획이라면(뒤의 Amazon S3 스토리지 섹션에서 설명), 신뢰 정책에는 다음도 포함되어야 합니다 pods.eks.amazonaws.com 신뢰할 수 있는 주체(principal)로서입니다. Identity Center를 통한 CLI 액세스는 자체 정책을 갖는 별도의 권한 세트를 사용하므로(“Identity Center를 통한 AWS 계정 액세스” 섹션 참조) CLI 권한을 독립적으로 범위 지정할 수 있습니다.

자세히 보기: SageMaker AI 실행 역할 사용 방법

Identity Center를 통한 AWS 계정 액세스

SageMaker Studio 외에도 팀은 실행과 같은 CLI 작업을 위해 직접적인 AWS 계정 액세스가 필요한 경우가 많습니다 kubectl 명령 실행, 스크립트 워크플로 작성 또는 프로그래밍 방식의 리소스 접근을 수행할 수 있습니다. Identity Center 권한 세트가 이 기능을 제공합니다.

다음을 위한 관리자 그룹에 회사 정책에서 요구하는 대로 관리 권한이 포함된 권한 세트를 할당하여 클러스터 관리 및 관리 작업에 필요한 계정 액세스 권한을 부여하십시오.

위해 A팀 그리고 B팀, CLI 워크플로에 필요한 권한을 직접 부여하는 인라인 또는 관리형 정책이 포함된 권한 세트를 생성하십시오. 일반적인 팀 권한 세트에는 다음에 대한 권한이 포함됩니다 eks:AccessKubernetesApi (AWS Console에서 Kubernetes 리소스를 조회), 팀 데이터에 대한 범위가 지정된 S3 액세스, 모니터링을 위한 CloudWatch 읽기 액세스. 이러한 정책은 Studio 실행 역할과 독립적으로 정의되므로, 관리자는 팀이 명령줄에서 수행하는 특정 작업에 맞게 CLI 권한을 조정할 수 있습니다.

사용자는 AWS Command Line Interface(AWS CLI)를 통해 임시 자격 증명을 다음과 같이 검색합니다. aws sso login, 이를 통해 설정할 수 있습니다 kubectl EKS 클러스터와 직접 상호작용하기 위한 것입니다.

다음 이미지는 AWS IAM Identity Center의 팀별 권한 세트를 보여주며, 실행과 같은 CLI 워크플로를 위해 범위가 지정된 AWS 계정 액세스를 제공합니다. kubectl 그리고 aws sso login EKS 클러스터에 대하여.

그림 4: CLI 워크플로를 위한 AWS IAM Identity Center의 팀별 권한 세트

자세히 알아보기: 권한 세트로 AWS 계정 관리

AWS CLI 구성

팀 멤버는 Identity Center를 통해 인증하도록 다음을 실행하여 AWS CLI를 구성합니다 aws configure sso. 이렇게 하면 ~/.aws/config 에서 Identity Center 세션과 권한 세트를 참조하는 프로필이 생성됩니다. 각 팀 구성원은 명령줄에서 클러스터와 상호 작용할 때 팀 전용 프로필을 사용하여, 액세스가 Studio에서 시작되든 로컬 터미널에서 시작되든 권한 부여 경계를 유지합니다.

결과로 생성되는 구성은 Identity Center 포털을 위한 공유 sso-session 블록과 팀별로 하나의 명명된 프로필을 정의하며, 각 프로필은 해당 팀의 권한 세트를 가리킵니다. 그런 다음 팀 구성원은 aws sso login --profile <team> 를 실행하여 자신의 권한 세트로 범위가 지정된 임시 자격 증명을 얻습니다:

[sso-session my-sso]
sso_start_url = https://d-xxxxxxxxxx.awsapps.com/start
sso_region = us-west-2
sso_registration_scopes = sso:account:access

[default]
sso_session = my-sso
sso_account_id = 123456789012
sso_role_name = OpsAdmin
region = us-west-2

[profile team-a]
sso_session = my-sso
sso_account_id = 123456789012
sso_role_name = TeamA-permission-set
region = us-west-2

[profile team-b]
sso_session = my-sso
sso_account_id = 123456789012
sso_role_name = TeamB-permission-set
region = us-west-2

자세히 알아보기: AWS CLI를 사용한 IAM Identity Center 인증 구성

SageMaker AI 도메인

SageMaker AI 도메인은 각 팀을 위한 워크스페이스 경계를 제공하며, 맞춤형 사용자 경험, 사전 구성된 실행 역할, Identity Center 인증과의 기본 제공 통합을 제공합니다.

SageMaker AI 도메인을 사용하는 이유

팀당 하나의 SageMaker AI 도메인을 사용하는 것은 멀티 팀 환경을 구성하기 위한 잘 확립된 패턴입니다. 이 접근 방식은 다음과 같은 여러 장점을 제공합니다:

• 확립된 멀티 팀 패턴 – AWS는 여러 도메인을 사용하여 사업부 또는 팀을 분리하는 이 접근 방식을 광범위하게 문서화하여, 검증되고 지원되는 구성임을 입증했습니다.
• 기본 제공 Identity Center 인증 – 각 도메인은 Identity Center 인증으로 구성할 수 있으며, 이는 사용자가 기업 자격 증명 공급자를 통해 한 번 로그인하면 팀의 Studio 환경에 바로 접속한다는 의미입니다.
• 기본 제공 팀 구성 – 도메인은 이미 추가적인 사용자 지정 엔터티 없이도 사용자 및 팀에 대한 구성을 지정하는 메커니즘을 제공합니다. 예를 들어, 팀 실행 역할과 같은 설정은 도메인 수준에서 지정할 수 있고, 최대 유연성을 위해 사용자 프로필 수준에서 재정의할 수 있습니다.
• 탐색 사용자 지정 – 도메인 설정을 통해 관리자는 팀의 워크플로와 관련 없는 탐색 항목을 숨겨 HyperPod 사용 사례에 맞춘 집중된 인터페이스를 제공할 수 있습니다.

자세히 알아보기: SageMaker AI 도메인 엔티티 및 상태 · 다중 도메인 개요

팀별 도메인 설정

Identity Center 인증을 사용하여 팀당 하나의 SageMaker AI 도메인을 생성합니다. 이 예제에서는 TeamA-domain 및 TeamB-domain을 생성합니다. 각 도메인은 다음과 같이 구성됩니다:

1. 기본 실행 역할 – 도메인의 기본 실행 역할을 권한 부여 단계에서 생성한 팀 전용 IAM 역할로 설정합니다. 그 결과 Studio를 통해 수행되는 모든 작업은 적절한 권한을 상속받습니다.
2. Identity Center 그룹 할당 – 해당 Identity Center 그룹(예: TeamA 그룹)을 도메인에 추가합니다. 이렇게 하면 해당 그룹의 모든 구성원에 대해 SageMaker Studio 애플리케이션이 활성화되어 Studio 인터페이스에 액세스할 수 있습니다.
3. 애플리케이션 할당 확인 – 그룹 액세스를 구성한 후 Identity Center에서 애플리케이션 할당을 검토하여 올바른 그룹이 올바른 도메인에 매핑되었는지 확인합니다.
4. 탐색 사용자 지정 – 각 도메인의 기본 탐색 설정을 구성하여 관련 기능만 표시합니다. 예를 들어 HyperPod 워크플로와 관련 없는 항목을 숨겨 HyperPod 리소스만 사용해야 하는 팀 구성원의 인지 부담을 줄이는 간소화된 HyperPod 중심의 사용자 경험을 제공할 수 있습니다.

다음 이미지는 팀당 하나의 도메인(TeamA-domain 및 TeamB-domain)이 있는 SageMaker AI 콘솔을 보여주며, 각 도메인은 격리된 작업 공간 경계를 제공합니다.

그림 5: SageMaker 콘솔에서 팀당 하나의 SageMaker 도메인

다음 이미지는 할당된 Identity Center 그룹을 포함하여 TeamA-domain의 세부 정보를 보여줍니다.

그림 6: 할당된 Identity Center 그룹이 있는 TeamA-domain 구성

HyperPod EKS 클러스터 구성

HyperPod EKS 클러스터는 워크로드가 실행되는 곳입니다. 클러스터 수준의 멀티 테넌시는 격리를 위한 Kubernetes 네임스페이스와 권한 부여를 위한 EKS 액세스 항목을 통해 구현됩니다.

네임스페이스 격리

각 팀에 대해 전용 Kubernetes 네임스페이스를 생성합니다(예: hyperpod-ns-team-a 및 hyperpod-ns-team-b. 네임스페이스는 클러스터 내에 논리적 경계를 제공하여 각 팀의 워크로드(Spaces, 학습 작업, 추론 엔드포인트)를 서로 격리합니다.

참고: 네임스페이스는 격리 경계이지 강력한 보안 경계가 아닙니다. 이 아키텍처는 단일 조직 내의 멀티 팀을 대상으로 합니다. 즉, 공통의 관리 도메인과 상호 신뢰라는 기본 수준 아래에서 하나의 클러스터를 공유하는 팀들을 위한 것입니다. 이는 상호 신뢰하지 않는 테넌트 간의 멀티 고객 격리를 위해 설계된 것이 아닙니다.

네임스페이스, RBAC, 쿼터는 우발적인 간섭(팀이 서로의 리소스를 덮어쓰거나 컴퓨팅 할당량을 초과하는 것)을 방지하지만, 악의적인 의도를 가진 테넌트에 대한 방어책은 아닙니다. 네임스페이스에 속한 파드는 동일한 노드와 커널을 공유하며, 클러스터 범위의 리소스(노드, PersistentVolumes, CRD, 일부 연산자 구성 요소)는 어떤 네임스페이스에도 속하지 않습니다.

신뢰할 수 없는 테넌트나 엄격한 규제 격리가 필요한 경우에는 별도의 클러스터나 계정, 전용 노드 풀, 런타임 샌드박싱과 같은 더 강력한 경계를 사용하십시오. 여기서 다루는 멀티 팀 시나리오에서는 네임스페이스 격리와 RBAC, Task Governance 쿼터, 그리고 뒤에서 설명할 POSIX 아이덴티티 제어를 결합하는 것이 분리와 운영 단순성 사이의 적절한 균형을 제공합니다.

네임스페이스는 kubectl create namespace 으로 수동으로 생성하거나 HyperPod Task Governance를 통해 자동으로 프로비저닝할 수 있으며, HyperPod Task Governance는 쿼터 및 스케줄링 구성의 일부로 네임스페이스를 관리합니다.

다음 이미지는 클러스터 네임스페이스(HyperPod Task Governance로 관리됨)를 보여주며, 팀별로 전용 네임스페이스(hyperpod-ns-team-a 및 hyperpod-ns-team-b)가 하나씩 있어 워크로드 격리를 제공합니다.

그림 7: 워크로드 격리를 위한 팀별 전용 Kubernetes 네임스페이스

자세히 알아보기: Kubernetes 네임스페이스

네트워크 격리

네임스페이스는 네트워크 트래픽을 제한하지 않습니다. 기본적으로 Kubernetes 네트워킹은 플랫(flat)합니다. 즉, 모든 파드가 모든 네임스페이스에 걸쳐 다른 모든 파드에 도달할 수 있습니다. 그 결과 hyperpod-ns-team-a 에 있는 파드는 hyperpod-ns-team-b 에 있는 파드에 대한 연결을 열 수 있으며, 이를 방지하려면 제어를 추가해야 합니다. 팀 경계를 따라 파드 간 도달 범위를 제한하려면 Kubernetes NetworkPolicy 리소스를 사용하십시오.

권장 패턴은 네임스페이스별 default-deny 입니다. 먼저 모든 인그레스(및 선택적으로 이그레스)를 거부하는 것으로 시작한 다음, 각 팀에 필요한 트래픽(일반적으로 네임스페이스 내 통신과 DNS, 스토리지 엔드포인트, AWS API와 같은 필수 이그레스)을 명시적으로 허용합니다. 다음 예제는 팀의 네임스페이스에서 모든 인그레스를 거부한 후 동일한 네임스페이스 내의 파드에서 오는 트래픽만 허용합니다:

# 1. Default-deny all ingress in the team's namespace.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: hyperpod-ns-team-a
spec:
  podSelector: {}  # applies to all pods in the namespace
  policyTypes:
  - Ingress
---
# 2. Allow ingress only from pods within the same namespace.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-same-namespace
  namespace: hyperpod-ns-team-a
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector: {}  # any pod in this namespace

NetworkPolicy 정책 적용은 이를 지원하는 CNI(Container Network Interface)에 의존합니다. EKS에서는 Amazon Virtual Private Cloud(Amazon VPC) CNI에서 네트워크 정책 지원을 활성화할 수 있습니다.

네임스페이스와 마찬가지로, NetworkPolicies 은(는) 우발적인 팀 간 도달 가능성을 줄이고 범위를 축소할 수 있지만, 그 자체로 공유 노드에 대한 악의적인 공격 방지용 보안 경계는 되지 못합니다. 더 강력한 분리를 위해서는 앞서 언급했듯이 팀별 전용 노드 풀 또는 별도의 클러스터를 고려하십시오.

자세히 알아보기: Kubernetes 네트워크 정책 · Amazon VPC CNI 네트워크 정책

EKS 액세스 엔트리

EKS 액세스 엔트리는 IAM 보안 주체를 Kubernetes RBAC 권한에 연결합니다. 각 팀에 대해 두 개의 액세스 엔트리를 생성합니다:

• Studio 액세스 엔트리 – IAM 보안 주체는 해당 팀의 SageMaker AI 도메인 실행 역할입니다. 이 엔트리는 SageMaker Studio GUI에서 작업이 시작될 때 사용됩니다.
• CLI 액세스 엔트리 – IAM 보안 주체는 Identity Center가 해당 팀의 권한 세트를 위해 생성한 SSO 프로비저닝 역할입니다(패턴 따름 AWSReservedSSO_<permission-set-name>_<unique-id>). 이 엔트리는 사용자가 다음을 통해 클러스터와 상호 작용할 때 사용됩니다: kubectl.

두 엔트리 모두 관리형 또는 사용자 지정 Kubernetes 정책을 사용하여 해당 팀의 네임스페이스로 범위가 지정됩니다. 예를 들어, Team A의 두 엔트리는 다음 내에서만 권한을 부여합니다 hyperpod-ns-team-a. 두 엔트리는 원하는 경우 서로 다른 RBAC 정책을 가질 수 있습니다. 예를 들어, CLI 엔트리는 특정 리소스 유형에 대한 쓰기 액세스를 제한하는 반면 Studio 엔트리는 전체 액세스를 허용할 수 있습니다.

이러한 범위 지정을 통해 Studio에서 시작되든 CLI에서 시작되든, 사용자는 자신의 네임스페이스 내 리소스와만 상호 작용할 수 있습니다. 다른 팀의 네임스페이스에 있는 리소스를 나열하거나 수정하려고 하면 Kubernetes Forbidden 오류가 발생합니다.

보다 고급 시나리오에서는 액세스 엔트리의 Kubernetes 그룹을 사용하여 표준 관리형 정책을 넘어 세분화된 권한을 제공하는 사용자 지정 ClusterRole 또는 Role에 사용자를 매핑할 수 있습니다.

다음 이미지는 hyperpod-ns-team-b 네임스페이스로 범위가 축소된 Team B의 역할에 대한 EKS 액세스 엔트리를 보여주며, 따라서 그 권한은 Team B의 네임스페이스 내에서만 적용됩니다.

그림 8: Team B의 네임스페이스로 범위가 지정된 EKS 액세스 엔트리

자세히 알아보기: EKS 액세스 엔트리로 IAM 사용자에게 Kubernetes 액세스 권한 부여

HyperPod 작업 거버넌스

클러스터에서 Task Governance가 활성화되면 추가적인 리소스 관리 계층을 제공합니다:

• 컴퓨팅 할당량 – 각 팀이 소비할 수 있는 GPU 및 CPU 용량의 양을 정의합니다. 이를 통해 학습 실행 중에 단일 팀이 공유 하드웨어를 독점하는 것을 방지합니다.
• 우선순위 – 각 팀 또는 워크로드 유형에 스케줄링 우선순위를 할당하여, 리소스가 제한적일 때 중요한 프로덕션 추론 워크로드가 실험적 학습 작업을 선점할 수 있도록 합니다.
• 공정한 스케줄링 – Task Governance를 사용하면 여러 팀이 리소스를 두고 경쟁할 때, 선착순 모델이 아닌 구성된 정책에 따라 할당이 이루어집니다.

각 팀 네임스페이스에 적절한 할당량과 우선순위로 Task Governance를 구성하여, 보장된 최소 할당과 버스티 워크로드를 위한 버스트 용량 사이의 균형을 맞춥니다.

다음 이미지는 두 팀에 대한 Task Governance 컴퓨팅 할당을 보여주며, 각 팀의 네임스페이스에 자체 클러스터 컴퓨팅 용량 할당량이 지정되어 있습니다.

그림 9: 팀 네임스페이스별 Task Governance 컴퓨팅 할당

자세히 알아보기: SageMaker HyperPod 작업 거버넌스

스토리지

스토리지는 여러 팀이 공유하는 인공지능 및 머신러닝(AI/ML) 환경의 핵심 구성 요소입니다. 팀은 학습 데이터, 체크포인트, 모델 아티팩트를 위한 고성능 파일 시스템이 필요하며, 동시에 팀 간 적절한 접근 경계를 유지해야 합니다.

POSIX 호환 파일 시스템

공유되는 고성능 POSIX 파일 시스템이 필요한 워크로드(여러 노드가 동일한 데이터 세트를 읽거나 체크포인트를 쓰는 분산 학습에서 일반적)의 경우 다음 옵션을 고려하십시오:

• Amazon FSx for Lustre – 높은 처리량과 낮은 지연 시간을 제공하는 병렬 파일 시스템 액세스를 제공하며, 대규모 데이터 세트를 고속으로 읽어야 하는 대규모 학습 워크로드에 이상적입니다.
• Amazon FSx for OpenZFS – 강력한 POSIX 의미 체계, 스냅샷 및 압축을 갖춘 범용 파일 시스템을 제공합니다. 고성능과 함께 전통적인 파일 시스템 기능이 필요한 워크로드에 적합합니다.
• Amazon Elastic File System (Amazon EFS) – 완전관리형 탄력적 네트워크 파일 시스템(NFS) 스토리지를 제공합니다. EFS는 액세스 포인트도 지원하며, 이를 통해 서로 다른 마운트 지점을 강제된 UID 및 GID가 적용된 서로 다른 디렉터리에 매핑함으로써 팀별 디렉터리 격리를 간소화할 수 있습니다.

스토리지 레이아웃은 일반적으로 다음 구조를 따릅니다:

• 팀별 공유 디렉터리 – 각 팀에는 팀 구성원 모두가 액세스해야 하는 데이터 세트, 모델, 아티팩트를 위한 공유 디렉터리(예: /fsx/TeamA, /fsx/TeamB)가 있습니다.
• 사용자별 홈 디렉터리 – 각 사용자에게는 개인 작업, 실험, 노트북을 위한 개인 홈 디렉터리(예: /home/User1, /home/User2)가 있습니다.

이러한 파일 시스템의 POSIX 권한 모델은 UID, GID 및 보조 그룹을 사용하여 접근 경계를 적용합니다. 사용자가 HyperPod Space를 시작하거나 학습 작업을 제출할 때 이러한 POSIX 신원이 파드 보안 컨텍스트로 전파되어, 파일 시스템 액세스가 구성된 소유권과 권한을 존중하도록 해야 합니다. 신원 저장소에서 POSIX 신원 정보를 검색하기 위해 Kubernetes mutating admission webhook을 사용하는 것이 좋습니다. 워크로드가 제출되면 웹훅이 런타임에 신원을 조회하고 그에 따라 파드의 보안 컨텍스트를 수정합니다.

# 1. Extract the caller's session identity from the admission request.
# On EKS, requests from IAM-assumed roles (including IAM Identity Center)
# surface the STS session name in userInfo.extra["sessionName"]. Its format
# depends on how the session is created (e.g., an SSO short name, an email,
# or a role-session-name); align your identity mapping with this value.
def extract_username(admission_request):
    extra = admission_request["userInfo"]["extra"]
    ...
    return extra["sessionName"][0]

# 2. Look up the POSIX identity from a mapping table (e.g. DynamoDB).
def lookup_posix_identity(username):
    item = posix_table.get_item(Key={"username": username})["Item"]
    ...
    return {
        "uid": int(item["uid"]),
        "gid": int(item["gid"]),
        "supplementalGroups": [int(g) for g in item["supplementalGroups"]],
    }

# 3. Patch the Pod security context with the resolved POSIX identity.
def build_security_context_patch(pod, posix):
    ...
    return [{
        "op": "add",
        "path": "/spec/securityContext",
        "value": {
            "runAsUser": posix["uid"],
            "runAsGroup": posix["gid"],
            "fsGroup": posix["gid"],
            "supplementalGroups": posix["supplementalGroups"],
        },
    }]

자세히 알아보기: FSx for Lustre · FSx for OpenZFS · Amazon EFS

Amazon S3 스토리지

오브젝트 스토리지의 경우 S3 버킷에 대한 액세스는 팀의 IAM 실행 역할에 의해 관리됩니다. 팀별 버킷을 생성하거나 팀별 접두사가 있는 공유 버킷을 사용하면서 IAM 정책을 통해 격리를 강제할 수 있습니다. 클러스터 내 Pod가 S3에 인증하려면 IAM Roles for Service Accounts(IRSA) 또는 Pod Identity로 구성된 적절한 서비스 계정이 필요합니다. 간단하게 하려면 SageMaker AI 도메인에 구성된 동일한 실행 역할을 팀의 네임스페이스 내 Kubernetes 서비스 계정에 연결하여 Studio와 클러스터 워크로드 양쪽에서 일관된 S3 액세스를 제공할 수 있습니다.

자세히 보기: 서비스 어카운트를 위한 IAM 역할(IRSA) · EKS Pod Identity

HyperPod Spaces

HyperPod Spaces는 클러스터 노드에서 직접 실행되는 대화형 개발 환경(IDE)을 제공합니다. 공유 클러스터에서는 Spaces가 각 팀의 네임스페이스에 적절히 범위가 지정되고 적절한 리소스 템플릿으로 구성되어야 합니다.

우주 템플릿

각 팀별로 네임스페이스 범위의 Space 템플릿을 생성하세요. 이 템플릿들은 팀 구성원이 Space를 생성할 때 사용할 수 있는 리소스 구성(인스턴스 유형, 스토리지 볼륨, 환경 변수)을 정의합니다. 템플릿을 네임스페이스로 범위를 지정하면 각 팀이 지정된 경계 내에서만 Space를 시작할 수 있도록 보장할 수 있습니다.

HyperPod Task Governance가 활성화된 경우, 템플릿에는 거버넌스 시스템에 필요한 기본 레이블(예: 팀 식별자 및 우선순위 레이블)이 포함되어야 합니다. 클러스터 관리자가 이러한 레이블을 미리 구성하므로 팀 구성원이 Spaces를 시작할 때 수동으로 지정할 필요가 없습니다.

다음 예제는 Team A에 범위가 지정된 JupyterLab Space 템플릿을 보여줍니다. 팀별 부분은 다음과 같습니다. metadata.namespace, Task Governance 큐 레이블 아래의 baseLabels, 그리고 defaultVolumes 팀의 공유 파일 시스템과 사용자의 홈 디렉터리를 마운트하는:

apiVersion: workspace.jupyter.org/v1alpha1
kind: WorkspaceTemplate
metadata:
  name: jl-smd-custom
  namespace: hyperpod-ns-team-a  # scopes the template to Team A's namespace
spec:
  displayName: "JupyterLab (team-a)"
  description: "SageMaker Distribution"
  appType: jupyterlab
  baseLabels:
  - key: kueue.x-k8s.io/queue-name  # Task Governance (Kueue) local queue for Team A
    value: hyperpod-ns-team-a-localqueue
  ...
  # container command, default CPU/memory resources, security context, access type, etc.
  ...
  defaultVolumes:
  - name: home-dir  # per-user home directory
    mountPath: /home
    persistentVolumeClaimName: fsx-openzfs-claim
  - name: shared-data  # Team A's shared directory
    mountPath: /fsx
    persistentVolumeClaimName: fsx-lustre-claim
  ...
  # primary (EBS) storage defaults and limits
  ...

퍼시스턴트 볼륨 클레임

각 팀의 네임스페이스에서 공유 파일 시스템을 참조하는 적절한 Persistent Volume Claims(PVC)를 생성합니다. 이러한 PVC는 팀의 공유 디렉터리와 사용자의 홈 디렉터리를 Space에 마운트하여 학습 데이터, 체크포인트 및 개인 작업 공간에 대한 접근을 제공합니다.

소유자 전용 및 공유 스페이스

조직의 Space 공유 관련 요구 사항을 고려하십시오:

• 소유자 전용 스페이스 – 각 Space는 해당 Space를 생성한 사용자만 접근할 수 있습니다. 이것이 기본 구성으로, 팀이 민감하거나 독립적인 프로젝트를 진행할 때 적합합니다.
• 공유 공간 – 여러 팀 구성원이 동일한 Space에 접근할 수 있어, 페어 프로그래밍, 협업 디버깅 또는 공유 개발 환경에 유용합니다. 공유 Space를 활성화할 때는 POSIX 권한과 보조 그룹이 Space 내에서 생성된 파일에 대한 적절한 접근을 허용하도록 구성되어 있는지 확인하십시오.

자세히 알아보기: Amazon SageMaker HyperPod EKS 클러스터에서의 대화형 개발 환경

스튜디오 경험

팀은 다음을 사용하여 CLI에서만으로도 클러스터와 상호 작용할 수 있지만 kubectl, SageMaker Studio는 관리형 GUI 기반 워크플로를 선호하는 사용자를 위해 클러스터에 대한 그래픽 진입점을 제공합니다. 이 아키텍처에서는 각 팀이 자체 SageMaker AI 도메인(앞서 설명한 대로)을 통해 Studio에 액세스하여 동일한 Identity Center 자격 증명으로 로그인하고 팀의 네임스페이스 경계 내에서 작업합니다.

다음 이미지는 사용자가 회사 자격 증명으로 로그인한 후 도달하는 IAM Identity Center 액세스 포털을 보여주며, 할당된 SageMaker Studio 애플리케이션 및 Amazon Managed Grafana 애플리케이션에 대한 싱글 사인온(single sign-on) 액세스를 제공합니다.

Figure 10: 할당된 애플리케이션에 대한 싱글 사인온을 제공하는 IAM Identity Center 액세스 포털

Studio UI에서 팀 멤버는 다음을 수행할 수 있습니다:

• HyperPod Spaces 관리 – 관리자가 구성한 네임스페이스 범위의 Space 템플릿에서 Kubernetes 매니페스트를 작성하거나 Task Governance 레이블을 수동으로 지정하지 않고도 대화형 개발 환경을 시작할 수 있습니다. 팀 멤버는 실행 중인 Space를 시작, 중지 및 연결할 수도 있으며, 관련 IDE(예: JupyterLab)를 브라우저에서 직접 열 수 있습니다.
• Ray 워크로드 관리 – Ray 클러스터를 생성 및 모니터링하고, JupyterLab 또는 Code Editor 워크스페이스를 클러스터에 연결하고, 분산 작업을 제출하고, Ray Dashboard 및 Amazon Managed Grafana 관찰성 대시보드를 열 수 있으며, 이 모든 작업을 Kubernetes 매니페스트를 작성하거나 다음 kubectl 명령을 실행하지 않고 수행할 수 있습니다.

Studio는 팀의 Domain 실행 역할과 해당 EKS 액세스 항목을 통해 작동하기 때문에 모든 작업은 팀의 네임스페이스로 범위가 지정됩니다. Studio에서 Space 또는 Ray 클러스터를 시작하는 사용자는 자신의 팀 경계 내에서만 생성할 수 있으며, 이는 CLI 액세스에 적용되는 격리 모델과 일치합니다.

다음 이미지는 SageMaker Studio UI에서 HyperPod Space를 생성하는 방법을 보여주며, 팀 멤버가 Kubernetes 매니페스트를 작성하거나 Task Governance 레이블을 수동으로 지정하지 않고 네임스페이스 범위의 Space 템플릿을 선택합니다.

Figure 11: SageMaker Studio에서 네임스페이스 범위의 템플릿으로 HyperPod Space 생성

자세히 알아보기: Amazon SageMaker HyperPod EKS 클러스터의 대화형 개발 환경 · SageMaker HyperPod의 새로운 Ray 기능 소개

HyperPod Training Operator

HyperPod Training Operator를 사용하면 팀이 분산 학습 작업을 Kubernetes 커스텀 리소스(예: HyperPodPyTorchJob)로 제출할 수 있습니다. 멀티 테넌트 아키텍처에서 학습 작업은 네임스페이스 범위로 지정되며, 즉 팀의 격리 경계를 자동으로 상속받습니다.

팀은 CLI에서 적절한 작업 매니페스트와 함께 다음을 사용하여 학습 작업을 제출할 수 있습니다 kubectl apply 작업은 팀의 네임스페이스에서 실행되며, 팀의 컴퓨팅 할당량을 사용하고(Task Governance가 활성화된 경우), 팀의 스토리지 볼륨에 접근할 수 있습니다.

Task Governance가 활성화되면 학습 작업은 팀에 할당된 할당량 및 우선순위 설정의 적용을 받습니다. 팀이 보장된 할당량을 소진한 경우, 리소스가 사용 가능해지거나 더 낮은 우선순위의 워크로드가 선점될 때까지 작업이 대기열에 있을 수 있습니다.

작업을 팀에 고정하는 두 가지 요소는 metadata.namespace (팀의 격리 경계로 작업 범위를 지정)와 Task Governance 레이블입니다. Task Governance는 Kueue를 기반으로 구축되었으므로, 작업은 kueue.x-k8s.io/queue-name을 통해 팀의 로컬 큐로 라우팅됩니다. 작업에는 kueue.x-k8s.io/priority-class을 통해 스케줄링 우선순위가 할당되며, 그 값은 클러스터에 정의된 WorkloadPriorityClass 의 이름입니다:

apiVersion: sagemaker.amazonaws.com/v1
kind: HyperPodPyTorchJob
metadata:
  name: team-a-training-job
  namespace: hyperpod-ns-team-a  # scopes the job to Team A's namespace
  labels:
    kueue.x-k8s.io/queue-name: hyperpod-ns-team-a-localqueue  # Task Governance (Kueue) local queue
    kueue.x-k8s.io/priority-class: training-priority  # name of a WorkloadPriorityClass
spec:
  ...
  # replicaSpecs, container image, command, resources, volumes, etc.
  ...

자세히 알아보기: HyperPod 훈련 오퍼레이터 사용

HyperPod Inference Operator

HyperPod Inference Operator를 사용하면 팀이 클러스터에 직접 모델을 추론 엔드포인트로 배포할 수 있습니다. 학습 작업과 마찬가지로 추론 엔드포인트는 네임스페이스 범위로 지정되며 팀의 RBAC 정책 및 Task Governance 할당량의 적용을 받습니다.

팀은 자신의 네임스페이스에서 추론 엔드포인트 커스텀 리소스를 생성하여 CLI로 모델을 배포할 수 있습니다. 엔드포인트는 네임스페이스별로 격리되므로, 팀 A는 팀 B의 추론 엔드포인트에 접근하거나 간섭할 수 없습니다.

높은 가용성이 필요한 프로덕션 추론 워크로드의 경우, 배치 학습 워크로드에 의해 모델 서빙이 중단되지 않도록 추론 엔드포인트에 학습 작업보다 높은 스케줄링 우선순위를 할당하는 것을 고려하십시오.

학습 작업과 마찬가지로 추론 엔드포인트는 팀의 metadata.namespace 에 배치되며 Task Governance 레이블을 포함합니다. 여기서 kueue.x-k8s.io/priority-class 는 더 높은 우선순위의 WorkloadPriorityClass 을 참조하므로, 팀의 리소스가 제한될 때 모델 서빙이 배치 학습을 선점할 수 있습니다:

apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: InferenceEndpointConfig
metadata:
  name: team-a-inference-endpoint
  namespace: hyperpod-ns-team-a  # scopes the endpoint to Team A's namespace
  labels:
    kueue.x-k8s.io/queue-name: hyperpod-ns-team-a-localqueue  # Task Governance (Kueue) local queue
    kueue.x-k8s.io/priority-class: inference-priority  # higher-priority WorkloadPriorityClass
spec:
  ...
  # model source, instance type, replica count, autoscaling, etc.
  ...

자세히 알아보기: Amazon SageMaker HyperPod에 모델 배포

HyperPod Observability

클러스터 상태, 워크로드 성능, 리소스 활용도에 대한 가시성은 모든 팀에게 필수적입니다. HyperPod Observability는 Amazon Managed Grafana를 통해 내장된 모니터링 및 대시보드 기능을 제공합니다.

Grafana에 대한 팀 액세스 구성

팀은 자신의 워크로드를 모니터링하고, 성능 문제를 해결하며, 리소스 소비를 파악하기 위해 관측성 대시보드에 액세스해야 합니다. 그러나 멀티 테넌트 환경에서는 이러한 액세스가 일반적으로 읽기 전용이어야 합니다:

1. Amazon Managed Grafana를 위한 Identity Center 인증 구성 – Amazon Managed Grafana 콘솔에서 Authentication으로 이동하여 AWS IAM Identity Center를 활성화합니다. 그러면 사용자는 SageMaker Studio에서 사용하는 것과 동일한 회사 자격 증명으로 Grafana에 로그인할 수 있습니다.
2. 팀 그룹을 Viewer로 할당 – Identity Center 그룹(TeamA, TeamB)을 Grafana Viewer 역할에 매핑합니다. 이를 통해 팀 구성원은 대시보드나 데이터 소스를 수정할 수 없이 대시보드 및 지표에 대한 읽기 전용 액세스 권한을 갖게 됩니다.
3. 관리자 액세스 - Admin 그룹을 Grafana Admin 또는 Editor 역할에 할당하여 대시보드를 생성 및 수정하고, 경보를 구성하고, 데이터 소스를 관리할 수 있도록 합니다.
4. 팀별 대시보드 – 네임스페이스별로 데이터를 필터링하는 전용 대시보드를 생성하는 것을 고려하세요. 그러면 각 팀은 자신의 워크로드 지표만 볼 수 있습니다. Amazon Managed Grafana는 Grafana Teams(이 아키텍처의 조직 팀과는 구별되는 Grafana 고유의 RBAC 개념)를 지원하며, Identity Center 그룹에서 매핑하여 대시보드 가시성을 제한하고 추가적인 데이터 격리 계층을 제공할 수 있습니다.

다음 이미지는 Amazon Managed Grafana의 Grafana 역할 할당을 보여줍니다. 팀 그룹(TeamA, TeamB)은 대시보드 및 지표에 대한 읽기 전용 액세스를 위해 Viewer 역할이 할당되고, 관리자 그룹은 Admin 역할이 할당되어 대시보드를 생성 및 수정하고, 경보를 구성하고, 데이터 소스를 관리할 수 있습니다.

그림 12: 팀에 읽기 전용 Viewer 액세스를 부여하는 Grafana 역할 할당

자세히 알아보기: Amazon EKS로 오케스트레이션되는 Amazon SageMaker HyperPod 클러스터를 위한 관찰 가능성

비용 할당 및 충당

여러 팀이 비용이 많이 드는 GPU 인프라를 공유하는 멀티 테넌트 환경에서는 누가 무엇을 소비하는지 이해하는 것이 책임 소재 파악, 예산 수립, 비용 청구(chargeback)에 필수적입니다. Kubecost 는 이러한 요구를 충족하기 위해 클러스터 내 지출을 네이티브 Kubernetes 개념(네임스페이스, 레이블, 디플로이먼트, 서비스)별로 세분화하고 이를 팀, 프로젝트 또는 환경과 같은 조직적 개념에 매핑합니다.

이 아키텍처가 이미 각 팀을 전용 네임스페이스로 격리하기 때문에(hyperpod-ns-team-a, hyperpod-ns-team-b) 네임스페이스 수준의 비용 할당은 팀 경계와 직접 일치합니다. 이를 통해 플랫폼 관리자는 추가적인 워크로드 태깅 없이도 팀별 GPU, CPU, 메모리, 스토리지, 네트워크 소비를 명확하게 파악할 수 있습니다. HyperPod 클러스터에 Kubecost를 배포하고 구성하는 단계별 지침은 다음을 참조하세요. Kubecost on SageMaker HyperPod.

팀 가시성 활성화

Kubecost가 데이터를 수집하기 시작하면 Allocations 대시보드에서 비용을 네임스페이스별로 그룹화하여 팀별 지출을 확인할 수 있습니다. 각 팀이 하나의 네임스페이스를 소유하므로 이를 통해 컴퓨팅, 메모리, 스토리지, 네트워크를 포괄하는 팀별 비용 내역이 직접 생성됩니다. 관찰 가능성 대시보드와 마찬가지로 팀은 자체 비용 데이터에 대한 가시성의 이점을 누릴 수 있습니다:

• 각 팀의 네임스페이스로 보기 범위 지정 – Kubecost는 네임스페이스별 필터링과 저장된 리포트를 지원하므로 각 팀은 다른 팀의 데이터를 보지 않고도 자체 소비량과 추세를 검토할 수 있습니다.
• 예산 및 알림 설정 – 네임스페이스별 예산 임계값과 알림을 구성하여 지출이 정의된 한도에 근접하면 팀과 플랫폼 관리자에게 알림이 전송되도록 함으로써 HyperPod Task Governance와 동일한 리소스 공정성 목표를 지원합니다.
• 비용 청구(chargeback) 및 사용 보고(showback) 지원 – 네임스페이스 수준의 할당 리포트는 내부 비용 청구(사용량에 대해 팀에 청구) 또는 사용 보고(청구 없이 사용량 보고) 프로세스에 활용될 수 있으며, 재무 및 플랫폼 팀에 공유 GPU 비용을 공정하게 배분하는 데 필요한 데이터를 제공합니다.

다음 이미지는 네임스페이스별로 그룹화된 Kubecost Allocations 대시보드를 보여주며, 각 팀의 네임스페이스에 대해 최근 7일간의 누적 비용을 표시합니다.

그림 13: 팀별 비용을 위한 네임스페이스별 그룹화된 Kubecost Allocations 대시보드

자세히 알아보기: Kubecost on SageMaker HyperPod · Kubecost

결론

이 게시물에서는 Amazon SageMaker HyperPod with EKS를 기반으로 멀티 테넌트 환경을 구축하기 위한 레퍼런스 아키텍처를 소개했습니다. 인증을 위한 AWS IAM Identity Center, AWS 수준 권한 부여를 위한 팀별 IAM 역할, 맞춤형 작업 공간 경험을 위한 SageMaker AI 도메인, 워크로드 격리를 위한 Kubernetes 네임스페이스, 공정한 리소스 할당을 위한 HyperPod Task Governance, 팀별 지출 가시성을 위한 네임스페이스 수준 비용 할당을 결합함으로써 여러 팀이 단일 HyperPod EKS 클러스터를 효율적으로 공유할 수 있습니다.

이는 여러 구성 요소를 하나의 통합 솔루션으로 결합하는 유연하고 조합 가능한 접근 방식입니다. 이 아키텍처는 다양한 사용 사례와 조직 구조를 수용합니다. 예를 들어, 조직은 이 패턴을 확장하여 EKS와 함께 HyperPod Slurm 클러스터에 팀을 연결함으로써 서로 다른 오케스트레이션 백엔드 전반에 걸쳐 통합된 멀티 테넌트 경험을 제공할 수 있습니다.

이 접근 방식은 여러 구성 요소를 조립하고 구성해야 하지만, 그 결과로 각 조직의 특정 격리, 규정 준수, 운영 요구 사항에 맞게 조정할 수 있는 높은 수준의 제어 및 사용자 지정 기능을 얻을 수 있습니다. 기본 패턴(자격 증명 연동, 네임스페이스 격리, RBAC, 할당량 기반 거버넌스, 비용 할당)은 계속해서 유용하게 적용될 것입니다.

시작하려면 자신의 Amazon SageMaker HyperPod EKS 클러스터에서 이 멀티 테넌트 설정을 구축해 보고, 조직의 격리, 거버넌스 및 비용 할당 요구 사항에 맞게 구성 요소를 조정하세요.

저자 소개