데이터 메시는 데이터를 제품으로서(이 문서에서는 '데이터 제품'이라고 부름) 테스트하는 아키텍처 및 조직 프레임워크입니다. 이 프레임워크에서 데이터 제품은 데이터를 가장 잘 이해하고 조직 전체의 데이터 거버넌스 표준 집합을 따르는 팀에서 개발됩니다. 데이터 제품을 데이터 메시에 배포한 후에는 한 조직의 여러 팀이 자신의 요구와 관련된 데이터를 보다 빠르고 효율적으로 탐색 및 액세스할 수 있습니다. 이렇게 잘 작동하는 데이터 메시를 달성하기 위해서는 먼저 이 문서에서 설명하는 상위 수준의 아키텍처 구성요소 및 조직 역할을 설정해야 합니다.
이 문서는 Google Cloud에서 데이터 메시를 구현하는 방법을 설명하는 시리즈의 일부입니다. 여기에서는 사용자가 Google Cloud를 사용하여 최신 분산 데이터 메시 빌드에 설명된 개념을 읽고 이에 대해 잘 알고 있다고 가정합니다.
이 시리즈에 포함된 내용은 다음과 같습니다.
- 데이터 메시의 아키텍처 및 기능(이 문서)
- 데이터 메시에 대한 셀프 서비스 데이터 플랫폼 디자인
- 데이터 메시에서 데이터 제품 빌드
- 데이터 메시에서 데이터 제품 탐색 및 사용
이 시리즈에서 설명하는 데이터 메시는 조직 내부에 있습니다. 데이터 제품을 타사에 제공하도록 데이터 메시 아키텍처를 확장하는 것이 가능하지만 이러한 확장된 접근 방법은 이 문서의 범위를 벗어납니다. 데이터 메시 확장에는 조직 내 사용을 벗어난 추가적인 고려사항이 포함됩니다.
아키텍처
다음 주요 용어는 이 시리즈에 설명된 아키텍처 구성요소를 정의하기 위해 사용됩니다.
- 데이터 제품: 데이터 제품은 하나 이상의 관련된 데이터 리소스가 논리적으로 포함된 컨테이너 또는 그룹입니다.
- 데이터 리소스: 데이터 리소스는 구조화된 데이터를 포함하거나 구조화된 데이터를 생성하는 쿼리가 저장된 스토리지 시스템의 물리적 애셋입니다.
- 데이터 속성: 데이터 속성은 데이터 리소스의 필드 또는 요소입니다.
다음 다이어그램은 Google Cloud에 구현된 데이터 메시에 있는 주요 아키텍처 구성요소에 대한 개요를 보여줍니다.
앞의 다이어그램은 다음을 보여줍니다.
- 중앙 서비스는 데이터 메시 참여자, 액세스 제어(Identity and Access Management 그룹 사용), 인프라 관련 아티팩트에 영향을 주는 조직 정책을 포함하여 데이터 제품의 생성 및 관리를 가능하게 해줍니다. 이러한 약정 및 예약의 예시와 데이터 메시 기능을 활용하는 인프라에 대한 설명은 플랫폼 구성 요소 및 솔루션 만들기를 참조하세요.
- 중앙 서비스는 주로 데이터 메시의 모든 데이터 제품에 대한 Data Catalog 및 이러한 제품의 잠재적 고객에 대한 탐색 메커니즘을 제공합니다. 데이터 카탈로그에서 데이터 제품을 등록하는 방법은 데이터 메시에서 데이터 제품 및 리소스 설명 및 구성을 참조하세요.
- 데이터 도메인은 잘 정의된 데이터 소비 인터페이스를 통해 데이터 하위 집합을 데이터 제품으로 노출합니다. 이러한 데이터 제품은 테이블, 뷰, 구조화된 파일, 주제, 스트림일 수 있습니다. BigQuery에서는 데이터 세트이고 Cloud Storage에서는 폴더 또는 버킷입니다. 데이터 제품으로 노출될 수 있는 인터페이스는 여러 유형이 있습니다. 인터페이스 예시에는 BigQuery 테이블을 통한 BigQuery 뷰가 있습니다. 분석 목적으로 가장 일반적으로 사용되는 인터페이스 유형에 대해서는 데이터 메시에서 데이터 제품 빌드를 참조하세요.
데이터 메시 참조 구현
이 아키텍처의 참조 구현은 data-mesh-demo 저장소에서 찾을 수 있습니다.
참조 구현에 사용되는 Terraform 스크립트는 데이터 메시 개념을 보여주며 프로덕션 용도가 아닙니다. 이러한 스크립트를 실행하여 다음 작업을 수행하는 방법을 알아봅니다.
- 제품 정의를 기본 데이터에서 분리합니다.
- 제품 인터페이스를 설명하는 Data Catalog 템플릿을 만듭니다.
- 이 템플릿을 사용하여 제품 인터페이스에 태그를 지정합니다.
- 제품 소비자에게 권한을 부여합니다.
제품 인터페이스의 경우 참조 구현은 다음과 같은 인터페이스 유형을 만들고 사용합니다.
- BigQuery 테이블에 대한 승인된 뷰입니다.
- Pub/Sub 주제를 기반으로 하는 데이터 스트림
자세한 내용은 저장소의 README 파일을 참조하세요.
데이터 메시의 함수
데이터 메시가 올바르게 작동하기 위해서는 데이터 메시 내에서 태스크를 수행하는 사람에 대해 명확한 역할을 정의해야 합니다. 소유권은 팀 아키타입 또는 기능에 할당됩니다. 이러한 기능에는 데이터 메시에서 작업하는 사람들에 대한 핵심 사용자 여정이 포함됩니다. 사용자 여정을 명확하게 기술하기 위해 사용자 역할에 할당되어 있습니다. 이러한 사용자 역할은 각 기업의 상황에 따라 분할 및 조합할 수 있습니다. 조직 내 직원 또는 팀에 역할을 직접 매핑할 필요가 없습니다.
데이터 도메인은 비즈니스 단위(BU) 또는 기업 내 부서에 맞게 조정됩니다. 비즈니스 도메인에 대한 일반적인 예시로는 은행의 담보대출 부서, 기업의 고객, 배급, 금융, HR 부서를 들 수 있습니다. 개념적으로 데이터 메시에는 데이터 생성자팀과 데이터 소비자팀의 두 가지 도메인 관련 기능이 있습니다. 단일 데이터 도메인은 두 기능을 동시에 수행할 가능성이 있다는 것을 이해하는 것이 중요합니다. 데이터 도메인팀은 자신이 소유한 데이터로부터 데이터 제품을 생성합니다. 또한 이 팀은 비즈니스 통계를 위해 데이터 제품을 소비하고 다른 도메인의 사용을 위해 파생된 데이터 제품을 생성합니다.
도메인 기반 기능 외에도 데이터 메시에는 조직 내 중앙화된 팀에서 수행되는 기능 집합이 포함됩니다. 이러한 중앙 팀은 도메인 간 감독, 서비스, 거버넌스를 제공하여 데이터 메시 작동을 가능하게 합니다. 이들은 데이터 제품의 생성 및 소비 시 데이터 도메인의 운영 부담을 줄여주고 데이터 메시 작동을 위해 필요한 도메인 간 관계를 용이하게 합니다.
이 문서에서는 데이터 메시 관련 역할이 포함된 기능에 대해서만 설명합니다. 플랫폼에 사용되는 아키텍처에 관계없이 기업에는 몇 가지 다른 역할이 필요합니다. 그러나 이러한 다른 역할은 이 문서의 범위를 벗어납니다.
데이터 메시의 네 가지 기본 기능은 다음과 같습니다.
- 데이터 도메인 기반 생산자팀: 수명주기에 따라 데이터 제품을 만들고 유지합니다. 이러한 팀을 종종 데이터 생산자라고 부릅니다.
- 데이터 도메인 기반 소비자팀: 데이터 제품을 탐색하고 여러 분석 애플리케이션에서 이를 사용합니다. 이러한 팀은 데이터 제품을 소비하여 새 데이터 제품을 생성할 수 있습니다. 이러한 팀을 종종 데이터 소비자라고 부릅니다.
- 중앙 데이터 거버넌스팀: 데이터 생산자 간의 데이터 거버넌스 정책을 정의하고 적용하여 소비자를 위한 높은 데이터 품질 및 데이터 신뢰성을 보장합니다. 이 팀을 종종 데이터 거버넌스팀이라고 부릅니다.
- 중앙 셀프 서비스 데이터 인프라 플랫폼팀: 데이터 생산자를 위해 셀프 서비스 데이터 플랫폼을 제공합니다. 이 팀은 또한 데이터 소비자 및 데이터 생산자가 모두 사용하는 중앙 데이터 검색 및 데이터 제품 관측 가능성을 위한 도구를 제공합니다. 이 팀을 종종 데이터 플랫폼 팀이라고 부릅니다.
고려해야 할 선택적인 추가 기능은 데이터 메시에 대한 Center of Excellence(COE)입니다. COE의 목적은 데이터 메시에 대한 관리를 제공하는 것입니다. COE는 또한 다른 기능에서 발생하는 충돌을 해결하도록 지정된 중재팀입니다. 이 기능은 다른 4개의 기능 연결을 돕는 데 유용합니다.
데이터 도메인 기반 생산자 팀
일반적으로 데이터 제품은 데이터의 물리적 저장소 위에 빌드됩니다(단일 또는 다중 데이터 웨어하우스, 레이크, 스트림). 조직은 이러한 물리적 저장소를 만들고 유지하기 위해 전통적인 데이터 플랫폼 역할이 필요합니다. 그러나 이러한 전통적인 데이터 플랫폼 역할은 일반적으로 데이터 제품을 생성하는 사람들이 아닙니다.
이러한 물리적 저장소에서 데이터 제품을 만들기 위해서는 조직에 데이터 엔지니어 및 데이터 설계자와 같은 다양한 데이터 실무자가 필요합니다. 다음 표에서는 데이터 생산자팀에 필요한 모든 도메인 관련 사용자 역할을 보여줍니다.
역할 |
책임 |
필요한 기술 |
원하는 결과 |
|---|---|---|---|
데이터 제품 소유자 |
|
데이터 분석 데이터 아키텍처 제품 관리 |
|
데이터 제품 기술 리드 |
|
데이터 엔지니어링 데이터 아키텍처 소프트웨어 엔지니어링 |
|
데이터 제품 지원 |
|
소프트웨어 엔지니어링 사이트 안정성 엔지니어링(SRE) |
|
데이터 도메인의 주제 전문가(SME) |
|
데이터 분석 데이터 아키텍처 |
|
데이터 소유자 |
|
|
|
데이터 도메인 기반 소비자팀
데이터 메시에서 데이터 제품을 사용하는 사람들은 일반적으로 데이터 제품 도메인 외부에 있는 데이터 사용자입니다. 이러한 데이터 소비자는 중앙 데이터 카탈로그를 사용하여 자신의 요구와 관련이 있는 데이터 제품을 찾습니다. 요구를 충족하는 데이터 제품이 여러 개 있을 수 있기 때문에 결국 데이터 소비자가 여러 데이터 제품을 구독하게 될 수 있습니다.
데이터 소비자가 자신의 사용 사례에 필요한 데이터 제품을 찾을 수 없으면 데이터 메시 COE와 직접 상의해야 합니다. 상담 중에는 데이터 소비자가 자신의 데이터 요구를 제기하고 하나 이상의 도메인으로 이러한 요구를 충족시킬 수 있는 방법에 대한 조언을 구할 수 있습니다.
데이터 제품을 찾을 때 데이터 소비자는 영구적인 분석 대시보드 및 보고서, 개별 성능 보고서, 기타 비즈니스 성능 메트릭과 같이 여러 사용 사례를 달성하는 데 도움이 되는 데이터를 찾습니다. 또한 데이터 소비자가 인공지능(AI) 및 머신러닝(ML) 사용 사례에 사용될 수 있는 데이터 제품을 찾을 수 있습니다. 이러한 다양한 사용 사례를 달성하기 위해 데이터 소비자에게는 다음과 같은 혼합된 데이터 실무자 구성이 필요합니다.
역할 |
책임 |
필요한 기술 |
원하는 결과 |
|---|---|---|---|
데이터 분석가 |
비즈니스 인텔리전스 프레임워크 운영 기초를 만들기 위해 단일 도메인 또는 교차 도메인 제품을 검색, 식별, 평가, 구독합니다. |
분석 엔지니어링 비즈니스 분석 |
|
애플리케이션 개발자 |
도메인 내부 또는 외부를 포함하여 하나 이상의 데이터 제품에서 데이터 소비를 위한 애플리케이션 프레임워크를 개발합니다. |
애플리케이션 개발 데이터 엔지니어링 |
|
데이터 시각화 전문가 |
|
요구사항 분석 데이터 시각화 |
|
데이터 과학자 |
|
ML 엔지니어링 분석 엔지니어링 |
|
중앙 데이터 거버넌스팀
데이터 거버넌스팀은 조직에 규정 준수 위험을 초래하지 않고도 데이터 생산자 및 소비자가 셀프 서비스 방식으로 데이터를 안전하게 공유, 집계, 계산할 수 있게 해줍니다.
조직의 규정 준수 요구사항을 충족하기 위해 데이터 거버넌스 팀은 다음과 같은 혼합된 데이터 실무자들로 구성됩니다.
역할 |
책임 |
필요한 기술 |
원하는 결과 |
|---|---|---|---|
데이터 거버넌스 전문가 |
|
법무 SME 보안 SME 데이터 개인 정보 보호 SME |
|
데이터 관리자(각 도메인 내에 포함) |
|
데이터 아키텍처 데이터 관리 |
|
데이터 거버넌스 엔지니어 |
|
소프트웨어 엔지니어링 |
|
중앙 셀프 서비스 데이터 인프라 플랫폼팀
셀프 서비스 데이터 인프라 플랫폼팀 또는 단순히 데이터 플랫폼팀은 데이터 인프라 구성요소 집합을 만듭니다. 분산 데이터 도메인팀은 이러한 구성요소를 사용하여 자신의 데이터 제품을 빌드하고 배포합니다. 데이터 플랫폼팀은 또한 권장사항을 촉진하고 새 기술을 도입할 때 분산팀의 인지 부하를 줄이는 데 도움이 되는 도구 및 방법론을 도입합니다.
플랫폼 인프라는 글로벌 관측 가능성, 계측 및 규정 준수 자동화를 위해 운영 도구와 쉽게 통합되어야 합니다. 또는 성공적으로 분산팀을 설정할 수 있도록 인프라에서 이러한 통합을 촉진해야 합니다.
데이터 플랫폼팀에는 분산된 도메인팀 및 기본 인프라팀과 함께 사용하는 공유 책임 모델이 있습니다. 이 모델은 플랫폼 소비자에게 기대되는 책임과 데이터 플랫폼팀이 지원하는 플랫폼 구성요소를 보여줍니다.
데이터 플랫폼 자체가 내부 제품이므로 이 플랫폼은 모든 사용 사례를 지원하지 않습니다. 대신 데이터 플랫폼팀은 우선순위별 로드맵에 따라 새로운 서비스 및 기능을 지속적으로 출시합니다.
데이터 플랫폼팀에는 표준 구성요소 집합이 배치되고 개발 중일 수 있습니다. 그러나 데이터 도메인팀은 팀의 요구가 데이터 플랫폼에서 제공되는 것과 일치하지 않을 경우 다른 고유한 구성요소 집합을 사용하도록 선택할 수 있습니다. 데이터 도메인팀이 다른 접근방법을 선택할 경우에는 빌드 및 유지보수하는 플랫폼 인프라가 보안 및 데이터 거버넌스를 위한 조직 전체 정책 및 가드레일을 준수하는지 확인해야 합니다. 중앙 데이터 플랫폼팀 외부에서 개발된 데이터 플랫폼 인프라의 경우 데이터 플랫폼팀이 공동 투자하거나 자체 엔지니어를 도메인팀에 포함하도록 선택할 수 있습니다. 데이터 플랫폼팀이 공동 투자 또는 엔지니어 포함을 선택할지 여부는 조직에 대한 데이터 도메인 플랫폼 인프라의 전략적 중요성에 따라 달라질 수 있습니다. 데이터 도메인팀의 인프라 개발에 계속 참여함으로써 조직은 향후 재사용을 위해 개발 중인 새로운 플랫폼 인프라 구성요소를 다시 패키징하는 데 필요한 조정 및 기술적 전문 지식을 제공할 수 있습니다.
데이터 메시를 확장하기 위해 이해관계자로부터 승인을 얻는 것이 초기 목표인 경우 데이터 메시의 초기 구축 단계에서 자율성을 제한해야 할 수 있습니다. 그러나 자율성을 제한하면 중앙 데이터 플랫폼 팀에서 병목 현상이 발생할 위험이 있습니다. 이러한 병목 현상은 데이터 메시 확장을 방해할 수 있습니다. 따라서 모든 중앙 집중화 결정은 신중하게 이뤄져야 합니다. 데이터 생산자의 경우 사용 가능한 제한적인 옵션 집합 중에서 기술적 선택을 하는 것이 그 자체로 무제한적인 옵션 목록을 평가하고 이중에서 선택하는 것보다 나을 수 있습니다. 데이터 생산자의 자율성을 촉진하는 것은 통제되지 않는 기술 환경을 조성하는 것과 같지 않습니다. 대신 선택의 자유와 표준화 사이의 적절한 균형을 유지함으로써 규정 준수와 플랫폼 채택을 촉진하는 것이 목표입니다.
마지막으로 우수한 데이터 플랫폼팀은 회사의 나머지 부분에 대한 교육 및 권장사항을 제공하는 중심 원천입니다. 중앙 데이터 플랫폼팀에서 수행하도록 권장되는 가장 영향력 있는 활동은 다음과 같습니다.
- 새로운 기능 프로젝트에 대한 정기적인 아키텍처 설계 검토를 촉진하고 개발팀 전반에 공통적인 개발 방법을 제안합니다.
- 지식과 경험을 공유하고 권장사항 및 아키텍처 가이드라인을 종합적으로 정의합니다.
- 엔지니어가 코드, 버그, 성능 저하와 같이 일반적인 문제를 검증하고 확인할 수 있는 올바른 도구가 갖춰졌는지 확인합니다.
- 개발팀이 내부 도구 요구사항을 표면화할 수 있도록 내부 해커톤을 구성합니다.
중앙 데이터 플랫폼팀의 역할 및 책임 예시는 다음과 같습니다.
| 역할 | 책임 | 필요한 기술 |
원하는 결과 |
|---|---|---|---|
데이터 플랫폼 제품 소유자 |
|
데이터 전략 및 운영 제품 개발 이해관계자 관리 |
|
데이터 플랫폼 엔지니어 |
|
데이터 엔지니어링 소프트웨어 엔지니어링 |
|
플랫폼 및 보안 엔지니어(네트워킹 및 보안 등 데이터 플랫폼팀에 포함된 중앙 IT팀의 대표) |
|
인프라 엔지니어링 소프트웨어 엔지니어링 |
|
엔터프라이즈 설계자 |
|
데이터 아키텍처 솔루션 반복 및 문제 해결 합의 구축 |
|
데이터 메시 추가 고려 사항
분석 데이터 플랫폼에는 여러 가지 아키텍처 옵션이 있으며, 각 옵션마다 서로 다른 기본 요건이 있습니다. 각 데이터 메시 아키텍처를 사용 설정하기 위해서는 이 섹션에 설명된 권장사항을 따르는 것이 좋습니다.
플랫폼 자금 확보
'금융으로 시작을 전환하고 싶다면' 블로그 게시물에 설명된 대로 플랫폼은 결코 완성되지 않습니다. 플랫폼은 항상 우선 순위 로드맵에 따라 운영됩니다. 따라서 플랫폼은 엔드포인트가 고정된 프로젝트가 아닌 하나의 제품으로서 자금을 조달해야 합니다.
데이터 메시의 첫 번째 채택자가 비용을 부담합니다. 일반적으로는 데이터 메시를 시작하는 첫 번째 데이터 도메인을 형성하는 비즈니스와 일반적으로 중앙 데이터 플랫폼팀을 수용하는 중앙 기술팀이 서로 비용을 공유합니다.
재무팀이 중앙 플랫폼에 대한 자금 지원을 승인하도록 설득하려면 시간 경과에 따라 중앙화된 플랫폼의 가치를 나타내는 비즈니스 사례를 만드는 것이 좋습니다. 이러한 가치는 개별 제공팀에서 동일한 구성요소를 다시 구현함으로써 얻을 수 있습니다.
데이터 메시에 대한 최소 실행 가능한 플랫폼 정의
데이터 메시를 위한 최소 실행 가능한 플랫폼을 정의하기 위해서는 하나 이상의 비즈니스 사례를 파일럿으로 테스트하고 반복하는 것이 좋습니다. 파일럿을 위해서는 필요성이 있고 결과 데이터 제품을 채택할 준비가 된 소비자가 있는 사용 사례를 찾아보세요. 사용 사례에는 이미 데이터 제품 개발을 위한 자금이 있어야 하지만 기술팀의 입력 요구가 있어야 합니다.
파일럿을 구현하는 팀이 데이터 메시 운영 모델을 다음과 같이 이해해야 합니다.
- 비즈니스(즉, 데이터 생산자팀)가 백로그, 지원 및 유지보수를 소유합니다.
- 중앙 팀이 셀프 서비스 패턴을 정의하고 비즈니스가 데이터 제품을 빌드하도록 지원하지만 데이터 제품이 완료될 때 실행하고 소유하도록 비즈니스에 데이터 제품을 전달합니다.
- 기본 목표는 비즈니스 운영 모델(도메인 생산, 도메인 소비)을 입증하는 것입니다. 보조 목표는 기술적인 운영 모델(중앙 팀에서 개발된 셀프 서비스 패턴)을 입증하는 것입니다.
- 플랫폼팀 리소스가 제한적이기 때문에 트렁크 및 브랜치팀 모델을 사용하여 지식을 풀링하지만 전문 플랫폼 서비스 및 제품 개발을 허용합니다.
또한 다음을 수행하는 것이 좋습니다.
- 서비스 및 기능이 유기적으로 발전하도록 내버려두지 말고 로드맵을 계획합니다.
- 수집, 스토리지, 처리, 분석, ML에 이르는 실행 가능한 최소 플랫폼 기능을 정의합니다.
- 별도의 작업 스트림이 아닌 모든 단계에 데이터 거버넌스를 포함합니다.
- 거버넌스, 플랫폼, 가치 스트림, 변경 관리 전반에 걸쳐 최소한의 기능을 구현합니다. 최소 기능은 비즈니스 사례의 80%를 충족하는 기능입니다.
기존 데이터 플랫폼과 함께 데이터 메시의 공존을 계획합니다.
데이터 메시를 구현하려는 많은 조직은 데이터 레이크, 데이터 웨어하우스 또는 이 둘을 조합한 기존 데이터 플랫폼을 이미 보유하고 있을 가능성이 높습니다. 데이터 메시를 구현하려면 먼저 이러한 조직이 데이터 메시 확장에 따른 기존 데이터 플랫폼의 진화 방법을 계획해야 합니다.
이러한 조직은 다음과 같은 요소를 고려해야 합니다.
- 데이터 메시에서 가장 효과적인 데이터 리소스
- 기존 데이터 플랫폼 내에 있어야 하는 애셋
- 애셋을 이동해야 하는지 여부 또는 기존 플랫폼에서 유지보수할 수 있고 데이터 메시에 참여할 수 있는지 여부
다음 단계
- Google Cloud 아키텍처 프레임워크를 확인하여 클라우드 토폴로지 설계 및 운영에 대해 자세히 알아봅니다.
- 그 밖의 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 알아보려면 클라우드 아키텍처 센터를 확인하세요.