Amazon SageMaker HyperPod 머신러닝(ML) 팀이 모델을 학습하고 파인튜닝하기 위한 대규모 가속 컴퓨팅 풀에 접근할 수 있게 해줍니다. 여러 팀이 하나의 클러스터를 공유할 때 기술적인 설정은 대체로 간단합니다. 어려운 부분은 거버넌스입니다. 어떤 팀이 클러스터를 사용할 수 있는지, 각 팀이 어느 정도의 용량을 받는지, 한 팀의 워크로드가 다른 팀과 경쟁할 때 무슨 일이 일어나는지, 그리고 사용이 정책에서 벗어날 때 누가 책임을 지는지를 결정해야 합니다. Amazon SageMaker Unified Studio 또 하나의 고려 사항을 더합니다. SageMaker HyperPod 클러스터를 프로젝트에 연결하여 팀 구성원이 프로젝트 작업 공간에서 워크로드를 시작할 수 있습니다. 이러한 편의성은 가치가 있지만, 여러 팀이 동일한 클러스터에 대한 가시성을 공유하게 되면 누가 무엇을 할 수 있는지를 규율하는 제어가 더욱 중요해집니다. 이 게시물에서는 기본 거버넌스 제어를 유지하면서 SageMaker Unified Studio를 통해 SageMaker HyperPod를 관리하는 방법을 보여줍니다. 우리는 조직, 프로젝트, 클러스터, 워크로드라는 네 가지 제어 계층을 다룹니다. 또한 이들 전반에 걸쳐 아이덴티티, 용량, 관찰 가능성 정책을 설계하는 방법을 설명합니다. 이 글을 마치면 인프라 팀이 클러스터 운영을 계속 담당하면서 승인된 SageMaker HyperPod 컴퓨팅을 ML 팀에 프로젝트 맥락에서 제공하기 위한 반복 가능한 모델을 갖추게 될 것입니다.
Amazon SageMaker HyperPod는 다음의 기능입니다. Amazon SageMaker AI. Amazon SageMaker Unified Studio는 팀이 데이터와 도구를 활용해 개발하는 데이터 및 AI 개발 환경입니다. SageMaker Unified Studio를 사용하면 프로젝트를 기존 SageMaker HyperPod 클러스터에 연결할 수 있습니다. 그러면 멤버는 머신 러닝 워크로드를 시작하고, 클러스터 및 작업 정보를 검토하고, JupyterLab 워크플로를 열 수 있습니다. 클러스터는 계속해서 Amazon SageMaker AI 인터페이스와 API를 통해 관리합니다.
이러한 분리는 인프라 팀에 유용한 운영 모델을 제공합니다. 기존의 클라우드 운영 프로세스를 통해 클러스터 인프라를 관리할 수 있습니다. 동시에 승인된 컴퓨팅을 머신 러닝 팀에 해당 팀의 프로젝트 맥락 안에서 제공할 수 있습니다. 이 게시물에서는 인프라 경계를 설계하고, 액세스를 거버넌스하고, 공유 용량을 할당하고, SageMaker Unified Studio를 통해 SageMaker HyperPod를 일관되게 운영하는 방법을 설명합니다.
행정 구역의 이해
잘 운영되는 환경은 조직 관리, 프로젝트 접근, 클러스터 운영을 분리합니다. 각 계층은 서로 다른 질문에 답하며 서로 다른 제어 방식을 사용합니다. 다음 표는 각 경계, 그 기본 제어 방식, 그리고 관리 목적을 요약합니다.
| 경계 | 기본 컨트롤 | 행정적 목적 |
| 조직 | SageMaker Unified Studio 도메인, 도메인 단위, 연결된 계정, 프로젝트 프로파일 및 권한 부여 정책 | 누가 프로젝트를 생성할 수 있는지, 프로젝트가 어떤 계정과 리전을 사용할 수 있는지, 그리고 어떤 도구를 사용할 수 있는지를 결정합니다 |
| 프로젝트 | 프로젝트 멤버십, 프로젝트 역할 및 SageMaker HyperPod 연결 | 프로젝트 구성원이 액세스할 수 있는 협업 컨텍스트와 AWS 리소스를 정의합니다. |
| 클러스터 | SageMaker HyperPod 클러스터 관리자 역할, Amazon EKS 액세스 항목, 역할 기반 액세스 제어(RBAC), EKS Pod Identity 또는 Slurm 제어 | 클러스터 구성, 스케줄러 접근, 네임스페이스, 태스크 및 인프라 운영을 관리합니다 |
| 워크로드 | 컴퓨팅 할당, 우선순위 클래스, 대여 및 차입 정책, 작업 권한 | 누가 작업을 제출할 수 있는지와 공유 용량이 어떻게 할당되는지를 제어합니다 |
이러한 제어들을 계층으로 취급하십시오. SageMaker HyperPod 연결은 승인된 클러스터를 프로젝트에 추가합니다. 이는 클러스터의 AWS Identity and Access Management (IAM), Amazon Elastic Kubernetes Service (Amazon EKS), 또는 Slurm 제어를 대체하지 않습니다. 프로젝트 역할, 연결 액세스 역할, EKS 액세스 항목 및 RBAC 또는 Slurm 제어, 워크로드 아이덴티티, 데이터와 AWS Key Management Service (AWS KMS) 키 정책, 네트워크 정책, 작업 보기 제한, 그리고 스케줄러 정책을 함께 관리합니다. 이러한 통제가 정렬된 후에야 클러스터를 사용 가능하게 만드십시오.
이러한 통제 항목은 다음 그림과 같이 네 개의 계층을 이룹니다.
그림 1: 네 가지 제어 계층: 조직, 프로젝트, 클러스터, 워크로드. 각 계층은 서로 다른 질문에 답하고 서로 다른 제어를 사용하므로, 각 계층을 해당 경계에서 검토하십시오.
SageMaker Unified Studio 프로젝트는 협업 경계입니다. 이는 강력한 런타임 보안 경계가 아닙니다. SageMaker HyperPod 클러스터, 스케줄러, 그리고 희소한 가속기 용량은 하나의 지정된 용량 계정 아래에 두십시오. 승인된 사용자와 데이터세트는 동일한 계정에 있어도 되고, 별도의 소비자 계정과 데이터 계정에 있어도 됩니다. AWS는 Amazon EKS 클러스터에서 SageMaker HyperPod 작업 거버넌스를 위한 멀티 계정 지원을 문서화하고 있습니다. On-Demand Capacity Reservations는 계정 간에 공유할 수 있지만, SageMaker HyperPod 클러스터 소유권과 용량 관리는 용량 계정에 중앙집중화하십시오. 각 소비자 계정이 독립적인 용량 관리자가 되도록 하는 대신, 승인된 교차 계정 액세스를 사용하십시오.
- Amazon EKS의 경우 테넌트당 네임스페이스를 RBAC, 테넌트별 서비스 계정 및 EKS Pod Identity 역할, default-deny 네트워크 정책, 테넌트별 스토리지 및 AWS KMS 권한과 함께 사용하십시오. Slurm의 경우 계층적 계정 및 연관 관계(association), 서비스 품질(QoS), 우선순위 및 fair-share 정책, 파티션과 함께 Slurm accounting을 사용하십시오. 또한 운영 체제 식별 및 파일 권한, 네트워크 제어, 테넌트별 데이터 경로를 사용하십시오.
- Amazon Simple Storage Service(Amazon S3) 버킷, AWS KMS 키, 시크릿, 컨테이너 레지스트리 및 기타 데이터 서비스에 대한 액세스를 제어할 때는 프로젝트 멤버십만이 아니라 IAM 역할과 리소스 정책을 사용하십시오. 협업 및 위임을 위해서는 프로젝트 및 도메인 단위 정책을 사용하십시오.
- Amazon EKS 클러스터의 경우 SageMaker HyperPod 태스크 거버넌스(할당량, 우선순위 클래스, 대여 및 차입, 선점 포함)를 사용하여 중앙 가속기 풀을 공정하게 공유하십시오. Slurm 클러스터의 경우 네이티브 파티션, 서비스 품질(QoS), 우선순위, fair-share 및 선점 제어를 사용하십시오. Slurm은 동일한 대여-차입 모델을 제공하지 않습니다. 이러한 스케줄링 제어는 승인된 워크로드가 컴퓨팅을 언제 받는지를 결정합니다. 네임스페이스 또는 데이터 액세스 권한을 부여하지는 않습니다.
클러스터 내에서 더 강력한 격리를 위해 적절한 경우 전용 노드 또는 노드 그룹과 어드미션 컨트롤을 사용하십시오. 법적, 규제 또는 보안 요건이 강한 인프라 격리를 요구하는 경우 별도의 클러스터 또는 계정을 사용하십시오. 교차 계정 소비자 액세스는 중앙 SageMaker HyperPod 클러스터를 복제하지 않고도 계정 수준의 소유권을 유지할 수 있습니다. 용량 계정 내에서는 project profiles 및 domain units 를 프로젝트 권한 부여 정책과 함께 사용하여 프로젝트 생성 및 소유권을 위임하십시오.
다음 그림은 테넌트별 워크로드, ID, 데이터, 네트워크 및 가시성 제어와 함께 중앙 집중식 용량을 보여줍니다.
그림 2: 중앙 집중식 SageMaker HyperPod 용량. 클러스터와 스케줄러는 하나의 용량 계정에 유지됩니다. 각 테넌트는 워크로드, ID, 데이터, 네트워크 및 태스크 가시성 제어를 받습니다. 강한 격리 요건이 있는 경우 전용 인프라를 사용합니다.
그림 3은 SageMaker Unified Studio가 승인된 SageMaker HyperPod 컴퓨팅을 프로젝트 멤버에게 노출할 때 이러한 경계가 어떻게 연결되는지 보여줍니다.
그림 3: 권장 SageMaker HyperPod 관리 모델. SageMaker Unified Studio가 협업 컨텍스트를 관리하는 반면, 클러스터 ID, 워크로드 권한 부여, 스케줄러 정책 및 운영 제어는 별도로 유지됩니다.
SageMaker Unified Studio가 적합한 관리 경험인 시점 결정
SageMaker Unified Studio를 사용하면 이미 프로젝트에서 작업 중인 머신 러닝 팀이 승인된 경로를 통해 공유 SageMaker HyperPod 컴퓨팅을 사용할 수 있습니다. 멤버는 연결된 클러스터를 찾고, 상태 및 메타데이터를 검토하고, 지원되는 태스크와 지표를 살펴보고, 별도의 인프라 인벤토리를 사용하지 않고도 JupyterLab으로 이동할 수 있습니다.
이 경험은 클러스터 관리를 대체하지 않습니다. 다음 표는 각 페르소나가 서비스별 인터페이스와 함께 SageMaker Unified Studio를 어떻게 사용해야 하는지 보여줍니다.
| 페르소나 | SageMaker Unified Studio를 사용하는 작업 | 서비스별 도구를 계속 사용하는 작업 |
| 도메인 또는 인프라 관리자 | 도메인 단위, 프로젝트 생성 정책, 프로젝트 프로파일, 멤버십 정책 및 계정 배치 | 조직 수준 제어, 계정 프로비저닝 및 인프라 자동화 |
| SageMaker HyperPod 클러스터 관리자 | 승인된 클러스터 연결 제공 및 클러스터, 태스크, 설정, 메타데이터 보기 검토 | 클러스터 생성, 업데이트, 복원력 구성, 애드온, EKS 또는 Slurm 관리 및 사고 대응 |
| 프로젝트 소유자 | 프로젝트 멤버십 관리 및 승인된 컴퓨팅에 대한 일관된 프로젝트 컨텍스트 제공 | 인프라 변경 요청 및 비즈니스별 액세스 요건 승인 |
| ML 엔지니어 또는 데이터 사이언티스트 | 승인된 컴퓨팅 찾기, 워크로드 상태 검토 및 JupyterLab 워크플로 열기 | SageMaker HyperPod CLI, kubectl또는 적절한 경우 Slurm 도구를 통해 상세 워크로드 제출 및 관리 |
프로젝트 멤버십, 데이터 액세스, 개발 도구 및 컴퓨팅에 공통 컨텍스트가 필요할 때 SageMaker Unified Studio를 사용하세요. 클러스터 변경과 반복 가능한 자동화에는 SageMaker AI API, 인프라 as 코드, 오케스트레이터 도구를 계속 사용하세요. 참조 구현 및 통합에 대해서는 다음을 참조하십시오. SageMaker HyperPod의 AI 사이트.
클러스터를 연결하기 전에 인프라 결정을 내리세요
연결을 승인하기 전에 용량 계정, 소비자 또는 데이터 계정, AWS Region, 네트워크 경로, 신원(identity), 소유자, 워크로드 경계, 격리 요구 사항을 문서화하십시오. 클러스터 생성에 대한 안내가 필요하면 다음을 참조하십시오. Amazon SageMaker HyperPod 문서 혹은 AI on SageMaker HyperPod 사이트.
관리 ID와 워크로드 ID를 분리하십시오. 프로젝트 및 액세스 역할을 생성할 때 SageMaker HyperPod의 클러스터 관리자와 데이터 사이언티스트 사용자 간의 구분을 유지하십시오. 프로젝트용 역할은 해당 사용자가 워크로드를 실행한다는 이유만으로 클러스터 수명 주기 권한을 받아서는 안 됩니다. 지원되는 권한 모델은 SageMaker HyperPod를 위한 AWS Identity and Access Management 를 참조하십시오.
네트워킹을 엔드 투 엔드 컨트롤로 취급하십시오. 승인된 관리 네트워크 경로로만 Amazon EKS Kubernetes API 엔드포인트 액세스를 제한하고, 파드 수신 및 송신을 제어하며, 프로젝트, 연결 역할, 워크로드 역할 및 클러스터 네트워크가 의도된 데이터 경로만 지원하는지 확인하십시오. 오케스트레이터별 구성에 대해서는 Amazon EKS로 SageMaker HyperPod 클러스터 오케스트레이션.
예를 들어, Amazon EKS API 엔드포인트에 대한 프라이빗 액세스를 구성하고 승인된 관리자 또는 워크로드 서브넷에서만 액세스를 허용하십시오. 기본 거부(default-deny) Kubernetes를 적용하십시오. NetworkPolicy 그리고 필요한 서비스 간(service-to-service) 경로와 이그레스(egress) 경로를 명시적으로 허용하십시오. 적절한 경우 Amazon S3, Amazon Elastic Container Registry(Amazon ECR), Amazon CloudWatch와 같은 서비스에 대해 가상 프라이빗 클라우드(VPC) 엔드포인트를 사용하고, 데이터 액세스를 위해 각 테넌트에 전용 워크로드 역할을 부여하십시오.
를 적용하고 필요한 서비스 간 및 송신 경로를 명시적으로 허용하십시오. Amazon S3, Amazon Elastic Container Registry(Amazon ECR), Amazon CloudWatch와 같은 서비스에는 적절한 경우 가상 프라이빗 클라우드(VPC) 엔드포인트를 사용하고, 각 테넌트에게 데이터 액세스를 위한 전용 워크로드 역할을 부여하십시오.
- 연결 계약(connection contract)을 생성하십시오. 연결 계약은 위키 페이지, 티켓, 서비스 카탈로그 레코드 또는 인프라형 코드(Infrastructure-as-Code) 리포지토리에서 추적되는 파일과 같은 고객 관리 거버넌스 레코드입니다. 이는 플랫폼 기능이 아닙니다. 승인된 모든 프로젝트-클러스터 연결에 대해 다음 정보를 기록하십시오:
- 비즈니스 오너, 운영 오너, 비용 오너.
- SageMaker Unified Studio 도메인 유닛 및 프로젝트.
- 클러스터 계정, 리전, 이름 및 오케스트레이터.
- 연결에 사용되는 프로젝트 역할 및 액세스 역할의 Amazon Resource Name(ARN).
- 승인된 워크로드 유형 및 데이터 분류.
- EKS 네임스페이스 또는 Slurm 액세스 범위.
- 스케줄링 정책 및 예외 오너.
모니터링, 지원 및 폐기(decommissioning) 기대 사항.
이 계약은 검토자가 전체 액세스 경로를 평가하고 승인하기 위한 단일 레코드를 제공합니다.
작업과 가시성을 모두 제어하십시오. 작업 이름, 네임스페이스, 리소스 요청, 사용 패턴이 부적절하게 설정되면 다른 팀의 작업에 대한 정보가 노출될 수 있습니다.
작업(actions)과 가시성을 모두 제어하십시오. 작업 이름, 네임스페이스, 리소스 요청 및 사용 패턴이 부적절하게 설정되면 다른 팀의 작업에 대한 정보가 노출될 수 있습니다.
가능한 경우 프로젝트 멤버십과 클러스터 액세스에는 개별 권한 부여 대신 그룹을 사용하십시오. 도메인, 프로젝트, 클러스터 및 워크로드 정책 전반에 걸치는 하나의 광범위한 역할을 만드는 대신, 각 역할을 자체 경계 내에서 검토하십시오.
그림 4: ID 및 작업 가시성 거버넌스. 그룹을 통해 액세스를 할당하고, 각 역할을 해당 경계로 범위를 한정하며, 작업 가시성을 제한하고, 작업을 볼 수 있는 능력과 작업을 수행할 수 있는 능력을 분리하십시오.
그림 4: ID 및 작업 가시성 거버넌스. 그룹을 통해 액세스를 할당하고, 각 역할을 해당 경계로 범위를 한정하며, 작업 가시성을 제한하고, 작업을 볼 수 있는 능력과 작업을 수행할 수 있는 능력을 분리합니다. 사용자를 온보딩하기 전에 기본 작업 가시성을 검토하십시오. SageMaker AI Studio의 SageMaker HyperPod 문서 에 따르면, SageMaker AI Studio 사용자는 기본적으로 모든 Amazon EKS 클러스터 작업을 볼 수 있습니다. Slurm 클러스터의 경우 모든 SageMaker AI Studio 사용자가 사용 가능한 작업을 보고, 관리하고, 상호 작용할 수 있습니다. 여러 팀을 온보딩하기 전에 작업 보기 제한을 구성하십시오. Amazon EKS는 EKS 클러스터에 대한 Studio에서 작업 보기 제한 을, Slurm은 Slurm 클러스터에 대한 Studio에서 작업 보기 제한
Amazon EKS 클러스터의 경우, 각 팀을 승인된 네임스페이스와 RBAC 권한에 매핑하고, 각 워크로드 서비스 계정을 테넌트 전용 IAM 역할에 매핑하십시오. 교차 계정(cross-account) 데이터 액세스의 경우, 서비스 계정을 용량(클러스터) 계정의 EKS Pod Identity 역할과 연결하고 해당 연결에 대상 IAM 역할을 설정하십시오(targetRoleArnAmazon EKS 클러스터의 경우 각 팀을 승인된 네임스페이스 및 RBAC 권한에 매핑하고, 각 워크로드 서비스 계정을 테넌트별 IAM 역할에 매핑하십시오. 교차 계정 데이터 액세스의 경우, 서비스 계정을 용량(클러스터) 계정의 EKS Pod Identity 역할과 연결하고 해당 연결에 대상 IAM 역할을 설정하십시오. 그러면 EKS Pod Identity가 교차 계정 역할 수임(role assumption)을 자동으로 수행하므로, 애플리케이션 코드가 AssumeRole를 호출할 필요가 없습니다. 대상 역할은 소비자 또는 데이터 계정에 위치합니다. 읽기 전용 가시성을 워크로드 생성, 업데이트 또는 삭제 권한과 분리하여 유지하십시오. Slurm 클러스터의 경우 동등한 사용자, 계정, 파티션, 파일 시스템 및 작업 가시성 컨트롤을 정의하십시오.
예를 들어 다음 Kubernetes RBAC Role은 팀에 자체 네임스페이스 내의 작업에 대한 읽기 전용 액세스 권한을 부여합니다. 워크로드를 생성하거나 삭제하려면 별도의 역할이 필요하며, 이를 통해 '확인'과 '실행'이 분리됩니다.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: team-research
name: research-job-viewer
rules:
- apiGroups: ["batch"]
resources: ["jobs"]
verbs: ["get", "list", "watch"]
- apiGroups: ["kubeflow.org"]
resources: ["pytorchjobs"]
verbs: ["get", "list", "watch"]비즈니스 우선순위를 스케줄링 정책으로 전환
Amazon EKS 클러스터의 경우, 아이덴티티 및 워크로드 액세스 제어가 마련된 후에만 작업 거버넌스를 적용하십시오.
다음 그림은 여기에 포함된 두 가지 결정을 구분하여 보여줍니다.
그림 5: 권한 부여와 스케줄링 정책을 분리 상태로 유지합니다. EKS RBAC 또는 Slurm ACL이 사용자가 워크로드를 제출할 수 있는지 여부를 결정합니다. Amazon EKS용 SageMaker HyperPod 작업 거버넌스 또는 기본 Slurm 스케줄링 제어가 워크로드가 언제 컴퓨팅을 할당받는지 결정합니다.
문서화된 보장 용량과 공유 용량, 우선순위 클래스, 그리고 한 팀이 다른 팀의 유휴 할당을 사용할 수 있는지 여부를 다루십시오. 모든 예외에 대해 소유자를 지정하십시오. 작업 거버넌스는 SageMaker HyperPod spaces (클러스터에서 직접 실행되는 자체 완결형 JupyterLab 또는 Code Editor 환경)에도 적용되므로, 이러한 대화형 개발 워크로드를 할당 정책에 포함하십시오.
예를 들어, Amazon EKS 클러스터에서 프로덕션 학습 팀에게 높은 우선순위 클래스와 함께 보장된 60퍼센트 할당을 부여하고, 연구 팀이 더 낮은 우선순위로 유휴 용량을 빌려 쓰도록 하며, 프로덕션 팀이 작업을 제출할 때 해당 빌린 용량을 선점할 수 있도록 할 수 있습니다. 이 정책에 대한 예외를 승인할 소유자를 한 명 지정하여 일회성 요청이 조용히 표준이 되지 않도록 하십시오.
권한 부여와 스케줄링 정책은 분리하여 유지하십시오. EKS RBAC 또는 Slurm ACL은 사용자가 워크로드를 제출할 수 있는지를 결정합니다. Amazon EKS용 SageMaker HyperPod 작업 거버넌스 또는 네이티브 Slurm 스케줄링 제어는 해당 승인된 워크로드가 언제 컴퓨팅을 받는지를 결정합니다. 스케줄러 할당량을 접근 제어로 사용하거나, 권한 부여 제어를 스케줄링 정책으로 사용하면 동작이 불명확해지고 장애 진단이 더 어려워집니다.
게시물 Best practices for Amazon SageMaker HyperPod task governance 에서는 공정 공유 가중치, 할당량, 대여와 빌리기, 우선순위 클래스 및 일반적인 할당 시나리오를 설명합니다. Amazon EKS 클러스터의 경우 할당 정책을 정의할 때 해당 패턴을 사용하십시오. Slurm 클러스터의 경우 앞서 설명한 네이티브 스케줄러 제어를 사용하십시오.
관찰 가능성을 거버넌스 피드백 루프로 활용하십시오
SageMaker Unified Studio에서는 작업, 지표, 설정 및 메타데이터에 대한 SageMaker HyperPod 클러스터 세부 정보를 볼 수 있습니다. Amazon EKS 클러스터의 경우 작업 거버넌스 지표에 하드웨어, 팀 및 작업 보기가 포함됩니다. 이러한 보기는 정책 의도와 실제 소비를 비교하는 데 도움이 됩니다.
다음 그림과 같이 관찰 가능성을 루프로 취급하십시오.
그림 6: 거버넌스 피드백 루프로서의 관찰 가능성. 신호를 모니터링하고, 정책 의도와 비교하고, 대응을 결정하고, 정책과 할당을 조정하며, 모든 신호에 소유자와 대응을 지정합니다.
모니터링하는 모든 신호에 대해 소유자와 대응을 정의하십시오. 다음 예제들은 대시보드 데이터를 관리상의 결정으로 전환합니다.
| 신호 | 관리상의 결정 |
| 클러스터 용량 및 가속기 활용률 | 낮은 활용률이 일시적인 것인지, 정책에 기인한 것인지, 워크로드 제약 때문인지 판단 |
| 팀 할당 및 활용률 | 예약 및 공유 용량이 여전히 비즈니스 수요를 반영하는지 검토 |
| 작업 실행 시간 및 대기 시간 | 우선순위 정책, 워크로드 크기 조정 또는 용량 경합 조사 |
| 대기 중 및 선점된 작업 | 스케줄러 결과가 승인된 우선순위 모델과 일치하는지 확인 |
| 노드 상태 및 복구 이벤트 | 클러스터 장애 프로세스를 실행하고 복구 목표를 검증 |
Amazon EKS 클러스터의 경우 작업 테이블에 Kubeflow 작업(PyTorch, MPI, TensorFlow)이 표시되며, 기본적으로 PyTorch 작업이 표시됩니다. 다른 메커니즘을 통해 제출된 워크로드는 거기에 나타나지 않을 수 있습니다. Slurm 클러스터의 경우 작업 테이블에 현재 스케줄러 큐의 작업이 표시되고, Slurm 계정 기능은 sacct같은 도구를 통해 과거 작업 데이터를 제공합니다. 과거 작업 데이터, 감사 증거 및 장애 세부 정보를 어디서 얻을지 정의하십시오.
문서화된 지표 보기를 위해서는 Amazon CloudWatch Observability EKS 애드온이 필요합니다. 이 애드온에는 자체적인 사전 요구 사항이 있습니다. 버전 2.4.0 이상과 Kubernetes 작업자 노드 역할에 연결된 CloudWatchAgentServerPolicy IAM 정책입니다. 작업 거버넌스 보기를 제공하는 Kueue 지표는 프리 티어 이후 CloudWatch 지표 요금이 발생할 수 있습니다. 최신 설정 및 가격 고려 사항은 SageMaker HyperPod 대시보드 문서 를 참조하십시오.
연결을 전체 수명 주기에 걸쳐 검토하십시오
모든 연결에 대한 검토 일정을 설정하십시오. 또한 프로젝트 소유권, 접근 역할, 계정 또는 Region, 클러스터 용량, 오케스트레이터 버전, 데이터 분류 또는 모니터링 범위의 변경에 대해 이벤트 기반 검토를 정의하십시오. 각 결정을 기록하려면 연결 계약서를 사용하십시오.
다음 그림은 수명 주기 단계를 보여줍니다.
그림 7: 연결 수명 주기. 기록된 연결 계약서로 연결을 승인하고, 운영 및 모니터링하며, 일정에 따라 그리고 정의된 이벤트 발생 시 검토한 후, 갱신하거나 철회합니다.
수동 작업을 줄이는 범위에서 인벤토리 및 증거 수집을 자동화하되, 승인은 책임 있는 관리자에게 유지하십시오. 더 이상 비즈니스 목적이나 책임 있는 소유자가 없는 연결은 철회하십시오.
결론
Amazon SageMaker Unified Studio를 사용하면 머신 러닝 팀은 승인된 SageMaker HyperPod 컴퓨트로 이어지는 프로젝트 중심 경로를 따르면서, 인프라 팀은 중앙화된 클러스터에 대한 통제권을 유지할 수 있습니다. 하나의 비프로덕션(non-production) 클러스터와 테스트 프로젝트로 시작하십시오. 멤버를 추가하기 전에 Amazon EKS용 워크로드 아이덴티티, 네임스페이스 또는 Slurm 범위, 데이터 권한, 네트워크 정책, 태스크 뷰 제한 및 태스크 거버넌스를, Slurm의 경우 네이티브 스케줄링 컨트롤을 구성하십시오. 지표 뷰가 채워지도록 Amazon CloudWatch Observability EKS 애드온을 설치하고, 전체 승인 내용을 연결 계약(connection contract)에 기록하십시오. 승인된 소비자 계정에는 크로스 계정 역할을 사용하고, 강력한 격리가 필요한 경우 전용 인프라를 사용하십시오. 구현 단계는 다음의 SageMaker HyperPod 연결 절차 를 따르십시오.