MLflow와 Amazon SageMaker AI 모델 레지스트리 동기화를 통한 교차 계정 모델 거버넌스 확장

Amazon SageMaker AI는 관리형 MLflow와의 통합을 통해 교차 계정 환경에서 모델 거버넌스를 지원하는 새로운 토폴로지를 제시한다. 이는 이전에 소개된 단일 계정 모델 등록 및 거버넌스 기능을 다중 계정 설정으로 확장하는 것으로, 자동 모델 등록 기능을 활용하여 등록된 모델을 SageMaker AI 모델 레지스트리로 동기화한다.

대규모 조직에서는 개발 환경과 프로덕션 환경을 계정 수준에서 분리하는 것이 일반적이다. 이는 워크로드 격리를 제공하고, 특히 규제 환경에서는 개발 워크로드가 프로덕션 등급 계정에 직접 쓰기 작업을 수행할 수 없다는 엄격한 요구사항이 존재한다. 이러한 요구사항을 충족하기 위해 중앙 집중식 거버넌스 또는 개발 계정의 완전한 격리를 지원하는 아키텍처가 필요하며, SageMaker AI는 이러한 시나리오를 위한 두 가지 교차 계정 거버넌스 토폴로지를 제공한다.

첫 번째 토폴로지는 허브-스포크 중앙 거버넌스 패턴이다. 이 방식은 중앙 허브 계정에 MLflow 앱과 중앙 모델 레지스트리를 호스팅하고, AWS Resource Access Manager (AWS RAM)를 사용하여 이 MLflow 앱을 여러 개발(스포크) 계정과 공유한다. 스포크 계정의 데이터 과학자는 공유된 MLflow 앱에 모델을 등록하며, 자동 등록 기능을 통해 Model Package Group 및 버전이 허브 계정에 동기적으로 생성된다. 관리자는 허브에서 MLflow 앱 및 Model Package Group에 대한 AWS RAM 리소스 공유를 설정하고, 스포크 계정의 실행 역할에 허브 아티팩트 S3 버킷에 대한 s3:GetObject, s3:PutObject, s3:ListBucket, s3:GetBucketLocation 권한을 부여한다. 거버넌스 담당자는 허브에서 동기화된 지표와 계보를 검토한 후 모델을 승인한다. 승인된 모델은 CI/CD 파이프라인을 통해 스포크 계정의 SageMaker 엔드포인트에 배포된다.

두 번째 토폴로지는 허브-스포크 하이브리드 거버넌스 패턴으로, 규제 환경에 적합하다. 이 패턴에서는 각 개발 계정이 자체 MLflow 앱과 모델 레지스트리를 유지하며 허브 계정으로부터 완전히 격리된다. 데이터 과학자는 개발 계정 내에서 모델을 등록하고, 이는 해당 계정의 모델 레지스트리에 동기화된다. 개발 계정의 모델 소유자가 모델을 로컬에서 승인하면, 이 승인 이벤트가 복사 워크플로를 트리거한다. 이 워크플로는 승인된 모델 아티팩트를 허브 계정 소유의 S3 버킷으로 복제하고, 추론 사양을 허브 복사본을 가리키도록 재작성하며, 허브의 공유 대상 그룹에 모델 패키지를 등록한다. 허브의 거버넌스 담당자는 복사된 모델을 재검증하고 독립적으로 승인한다. 이 방식은 허브 패키지가 자체 포함되도록 하여 배포 시 교차 계정 아티팩트 접근이 필요 없도록 한다.

이러한 토폴로지는 각 페르소나의 워크플로에 영향을 미친다. 데이터 과학자는 MLflow를 통해 모델을 등록하며, 중앙 토폴로지에서는 허브 앱의 Amazon Resource Name (ARN)을 사용하고 하이브리드 토폴로지에서는 자체 계정 앱을 사용한다. 거버넌스 담당자는 허브 계정의 SageMaker Studio 모델 UI에서 모든 스포크 계정의 후보 모델을 중앙에서 검토하고 승인한다. 하이브리드 토폴로지에서는 개발 계정의 모델 소유자가 로컬 승인을 먼저 수행하여 허브로의 프로모션을 트리거한다. 관리자는 AWS RAM 공유, S3 버킷 정책, 대상 그룹 설정 등 초기 교차 계정 설정을 담당한다.

두 토폴로지 모두에서 모델 레지스트리에서의 승인이 배포의 게이트 역할을 한다. 모델 승인 상태 변경은 Amazon EventBridge로 이벤트를 발행하며, 이 이벤트는 CI/CD 배포 파이프라인을 트리거하여 승인된 Model Package로부터 엔드포인트를 생성하거나 업데이트한다. 파이프라인 실행 위치와 엔드포인트 배포 위치는 조직의 선택에 따라 달라질 수 있으며, 샘플은 개발(스포크) 계정 내에서 실행 및 배포하는 방식을 보여준다. 배포를 수행하는 계정은 모델 아티팩트에 대한 읽기 권한이 필요하며, 중앙 토폴로지에서는 허브 아티팩트 버킷에, 하이브리드 토폴로지에서는 자체 포함된 허브 복사본에 접근한다.

토폴로지 선택은 계정 격리와 운영 복잡성 사이의 균형을 고려해야 한다. 중앙 토폴로지는 스포크가 공유 MLflow 앱을 통해 허브에 쓰기 작업을 허용하는 대신 중앙 집중식 거버넌스를 제공하며 운영 비용은 중간 수준이다. 하이브리드 토폴로지는 개발 계정의 완전한 격리를 유지하며, 승인된 자체 포함된 복사본만 허브로 이동하고 가장 높은 운영 비용이 발생한다. 모델 계보는 동기화가 기록된 계정에 유지되므로, 배포 계정으로 모델을 따라가지 않는다. 따라서 거버넌스 검토는 허브 또는 개발 레지스트리를 중심으로 계획해야 한다.

단일 계정, 허브-스포크 중앙, 허브-스포크 하이브리드 토폴로지는 계정 수, 허브에 대한 쓰기 권한 주체, 거버넌스 경계, 최적의 사용 사례, 운영 비용 측면에서 차이를 보인다. 단일 계정은 가장 낮은 운영 비용으로 소규모 팀에 적합하며, 허브-스포크 중앙은 공유 툴링을 통한 중앙 거버넌스에 적합하다. 허브-스포크 하이브리드는 허브 격리가 필요한 규제 환경에 최적이다. 모든 토폴로지에서 자동 등록, 수명 주기 스테이징 구성, IAM 조건 키 및 리소스 태그를 통한 승인 게이트는 동일한 빌딩 블록으로 작용하며, 계정 경계의 위치와 모델이 이를 통과하는 방식이 달라진다.