Amazon SageMaker Unified Studio에서 Cross-Account Amazon Redshift Data Sharing 거버넌스 패턴 검증

1. 도입 배경 및 요구사항

• 자회사별로 분리된 Redshift 및 ML 워크로드를 SageMaker Unified Studio(SMUS)로 통합하며, 소스 컴퓨트 격리와 데이터 공유 거버넌스 동시 충족이 필요했습니다.
• 주요 요구사항은 다음과 같습니다:
  • 소스 데이터 컴퓨트 외부 노출 금지
  • 다른 계정 분석 팀의 안전한 데이터 조회
  • 데이터 카탈로그를 통한 자산 검색, 게시, 구독 워크플로우
  • 구독한 데이터는 Amazon Redshift 엔진으로 직접 쿼리

2. 권장 아키텍처 (TL;DR)

• 소스 계정(Source Account): 운영 Redshift 클러스터 보유, 컴퓨트 외부 노출 금지.
• 도메인 계정(Domain Account): SMUS 도메인 및 Consumer 프로젝트 위치.
• 권장 패턴: Publisher 프로젝트를 소스 계정에 배치하고, Consumer 프로젝트는 도메인 계정에 둡니다. Account-agnostic Project Profile과 Account Pool을 함께 사용하여 다계정 환경을 운영합니다.
• 두 메커니즘:
  1. 거버넌스 경로 (SMUS Catalog): Publisher-Consumer 간 publish/subscribe 워크플로우는 SMUS 내에서 완결됩니다. Publisher가 소스 계정에 있어 datashare grant 권한을 자체 행사합니다.
  2. 데이터 경로 (Redshift Data Sharing): Datashare로 grant된 view는 Consumer의 자체 워크그룹에서 실행되며, 소스 클러스터에는 storage read만 발생하여 컴퓨트 격리가 유지됩니다.

3. 실패 사례 분석

• 구성 1 (수동 Cross-Account Datashare + Add Compute): 소스 Redshift → 도메인 Redshift로 수동 datashare 생성 후 Add Compute로 연결 시, SMUS Data Source가 datashare 기반 DB 객체를 자산으로 import하지 못해 publish가 불가합니다.
• 구성 2 (Federated Catalog - Data → Connection): SMUS Account Association으로 소스 계정 연결 후 Data → Connection으로 등록 시, 쿼리 자체는 가능하나 publish 진입점이 분리되어 있고 JDBC pass-through 방식으로 소스 컴퓨트에서 실행되어 격리가 깨집니다.
• 구성 3 (Publisher를 도메인 계정에 배치): Publisher 프로젝트를 도메인 계정에 두고 cross-account access role로 소스 클러스터 연결 시, Data Source Run은 성공하나 마지막 권한 부여 단계에서 Publisher 계정 내 클러스터만 찾으려 하여 실패합니다.

4. SMUS 설계 원칙 및 권장 패턴 상세

• 핵심 설계 원칙: SMUS publish/subscribe 거버넌스는 Publisher와 소스 데이터가 같은 계정에 있어야 하며, cross-account는 subscribe 방향에서만 지원됩니다.
• 권장 패턴 구현: Publisher 프로젝트를 소스 계정에 생성하고, Account-agnostic Project Profile과 Account Pool을 사용하여 도메인 계정에서 소스 계정을 관리합니다.
• 리소스 배치: Publisher는 소스 계정, Consumer 및 SMUS 도메인은 도메인 계정에 배치합니다.
• 구현 단계:
  1. 도메인 계정에서 거버넌스 base 구축 (RAM association, Account Pool/Profile 생성)
  2. 소스 계정에 Publisher 환경 배포 (프로젝트 생성, 태그 부착, VPC peering, Add Compute, Data Source Run)
  3. 도메인 계정 Consumer 측에서 구독 및 쿼리 (워크그룹 생성, 자산 publish/subscribe, 쿼리 실행)
• 운영 고려사항:
  • 쿼리 엔진(Redshift)과 메커니즘(SMUS Catalog, Datashare) 분리 이해.
  • SMUS Catalog는 Redshift 자산(datashare view)에만 적용되며 Glue Data Catalog와 다름.
  • VPC CIDR 충돌 주의, Account Pool/Profile 확장성 고려.
  • Athena 호환과 컴퓨트 격리 간 트레이드오프 인지.

5. 결론

SMUS publish/subscribe 거버넌스의 핵심 원칙은 Publisher와 소스 데이터가 같은 계정에 있어야 한다는 것입니다. 이 원칙을 따라 Publisher 프로젝트를 소스 계정에 배치하고, Account-agnostic Project Profile을 활용하여 다계정 환경에서 표준화된 거버넌스를 구축할 수 있습니다. 이를 통해 컴퓨트 격리, 카탈로그 거버넌스, Redshift 엔진 쿼리 요건을 모두 만족시킬 수 있습니다.