DCM Projects를 위한 아키텍처 권장 사항
DCM Projects를 위한 아키텍처 권장 사항
이 주제는 DCM Projects 정의를 프로젝트 폴더와 배포 대상으로 구성하기 위한 아키텍처 권장 사항을 제공해요. 또한 여러 환경으로 작업하고 프로젝트에서 함께 협업하는 방법을 설명해요.
본문
프로젝트 폴더와 배포 대상
프로젝트 폴더는 manifest.yml 파일과 sources/definitions/ 아래의 정의 집합을 포함해요. 매니페스트는 각 대상을 Snowflake 계정의 DCM 프로젝트 객체에 매핑해요. 각 대상은 그 객체의 소유자 역할을 지정하고 템플릿 구성을 선택할 수 있어요.
옵션 A: 대상이 하나인 프로젝트 폴더
한 대상이 정의 집합을 한 번 배포하거나, 파라미터화된 템플릿을 루프로 렌더링할 수 있어요. 각 전체 PLAN 또는 DEPLOY 연산은 모든 루프 반복과 함께 정의를 평가하므로 DCM Projects가 그 배포 안에서 종속성을 해석할 수 있어요. PLAN DELTA는 변경한 정의만 평가할 수 있게 해줘요.
옵션 B: 대상이 여러 개인 프로젝트 폴더
한 프로젝트 폴더가 여러 공존하는 프로덕션 대상을 정의할 수도 있어요. 대상은 개발, 스테이징, 또는 프로덕션 환경 외에도 테넌트나 리전 팀을 나타낼 수 있어요. 예를 들어 100개 이상의 테넌트를 서비스하는 플랫폼 팀은 하나의 표준 정의 집합을 유지 관리하고, 템플릿으로 각 테넌트의 구성을 렌더링할 수 있어요.
옵션 C: 각자 자신의 대상을 가진 별도의 프로젝트 폴더
별도의 프로젝트 폴더를 사용하면 각 팀이 자신의 매니페스트와 대상을 가진 서로 다른 정의 집합을 유지 관리할 수 있어요. 이는 마케팅·파이낸스 팀처럼 그들 사이의 종속성이 제한된 객체 그룹에 적합해요.
아키텍처 옵션에 걸친 고려 사항
나머지 지침은 모든 아키텍처 옵션에 적용돼요.
- 관심사 분리와 배포 종속성 — 주로 옵션 C를 위한 고려 사항이에요.
- 환경 격리와 객체 명명 — 세 옵션 모두에 적용돼요.
- 독립적인 개발 — 옵션 A에 적용돼요.
관심사 분리와 배포 종속성:
한 정의 집합이 인프라와 거버넌스 정의를 모두 다룰 수 있으며, DCM Projects가 이들의 종속성을 해석하고 PLAN·DEPLOY의 실행 순서를 결정해요. 비즈니스나 조직 요구 사항이 별도의 소유권이나 책임을 요구한다면 옵션 C처럼 별도의 프로젝트를 만들어요.
환경 격리와 객체 명명:
다음은 DCM 프로젝트를 여러 환경에 배포하는 일반적인 워크플로예요. 각 환경을 별도의 Snowflake 계정으로 설정하는 것이 일반적으로 권장돼요. 이는 실험적인 개발로부터 프로덕션 인프라를 완전히 분리하고, 개발자가 프로덕션 데이터에 대한 접근 제한을 보장해요. 그러나 단일 계정 설정에서는 각 환경에 대해 구별되는 객체 이름이 요구 사항이에요(예: EMEA_DB와 EMEA_ADMIN을 EMEA_DB_DEV와 EMEA_ADMIN_DEV와 분리). Snowflake는 다중 계정 설정에서도 이 관행을 권장해요. 템플릿화된 이름으로 여러 환경 배포를 가능하게 해요.
공유 환경에서의 독립적인 개발:
여러 개발자가 같은 개발 계정을 공유해 데이터 제품을 병렬로 구축·반복하는 것이 일반적이에요. 그러나 여러 사용자가 같은 프로젝트에서 병렬로 작업하면, 템플릿을 사용해 변경을 격리하지 않으면 PLAN과 DEPLOY 연산이 충돌을 일으킬 수 있어요.