데이터 메시는 데이터 아키텍처 디자인 및 개발에 대한 흥미로운 새로운 접근 방식입니다. 기존 데이터 아키텍처와 달리 데이터 메시는 데이터 제품을 만드는 데 중점을 둔 기능 데이터 도메인과 기술 기능에 중점을 둔 플랫폼 팀 간에 책임을 구분합니다. 이러한 책임 분리는 플랫폼에 반영되어야 합니다. 도메인에 구애받지 않은 기능을 제공하고 도메인 팀이 조직 전체에 데이터를 모델링, 처리 및 배포할 수 있도록 하는 것 사이의 균형을 유지해야 합니다.
플랫폼을 사용하여 분리하기 위한 적절한 수준의 도메인 세분성 및 규칙을 선택하는 것은 쉽지 않습니다. 이 문서에는 자세한 지침을 제공하는 몇 가지 시나리오가 포함되어 있습니다.
클라우드 수준의 분석
Azure를 사용하여 데이터 메시를 빌드하려는 경우 클라우드 규모 분석을 채택하는 것이 좋습니다. 이 프레임워크는 배포 가능한 참조 아키텍처이며 오픈 소스 템플릿 및 모범 사례와 함께 제공됩니다. 클라우드 규모 분석 아키텍처에는 모든 배포 선택에 기본적인 두 가지 주요 구성 요소가 있습니다.
- 데이터 관리 랜딩 존: 데이터 아키텍처의 기초입니다. 여기에는 데이터 카탈로그, 데이터 계보, API 카탈로그, 마스터 데이터 관리 등과 같은 데이터 관리를 위한 모든 중요한 기능이 포함되어 있습니다.
- 데이터 랜딩 존: 분석 및 AI 솔루션을 호스트하는 구독. 여기에는 분석 플랫폼을 호스팅하기 위한 주요 기능이 포함됩니다.
다음 다이어그램에서는 데이터 관리 랜딩 존과 단일 데이터 랜딩 존이 있는 클라우드 규모 분석 플랫폼의 개요를 제공합니다. 모든 Azure 서비스가 다이어그램에 표시되는 것은 아닙니다. 이 아키텍처 내의 핵심 개념 리소스 조직을 강조하기 위해 간소화되었습니다.
클라우드 기반 분석 프레임워크는 프로비전해야 하는 데이터 아키텍처의 정확한 형식에 대해 명시적이지 않습니다. (엔터프라이즈) 데이터 웨어하우스, 데이터 레이크, 데이터 레이크 하우스 및 데이터 메시를 비롯한 많은 일반적인 클라우드 규모 분석 솔루션에 사용할 수 있습니다. 이 문서의 모든 예제 솔루션은 데이터 메시 아키텍처를 사용합니다.
모든 아키텍처는 도메인 소유권, 제품으로서의 데이터, 셀프 서비스 데이터 플랫폼 및 페더레이션된 계산 거버넌스와 같은 데이터 메시 원칙을 준수한다는 것을 이해합니다. 서로 다른 여러 경로가 모두 데이터 메시로 이어질 수 있습니다. 단 하나의 옳은 대답이나 잘못된 대답은 없습니다. 조직의 필요에 맞게 적절한 균형을 찾아야 합니다.
단일 데이터 랜딩 존
데이터 메시 아키텍처를 빌드하기 위한 가장 간단한 배포 패턴에는 하나의 데이터 관리 랜딩 존과 하나의 데이터 랜딩 존이 포함됩니다. 이러한 시나리오의 데이터 아키텍처는 다음과 같습니다.
이 모델에서는 모든 기능 데이터 도메인이 동일한 데이터 랜딩 존에 상주합니다. 단일 구독에는 표준 서비스 집합이 포함되어 있습니다. 리소스 그룹은 서로 다른 데이터 도메인 및 데이터 제품을 분리합니다. Azure Data Lake Store 및 Azure Logic Apps와 같은 표준 데이터 서비스는 모든 도메인에 적용됩니다.
모든 데이터 도메인은 데이터 메시 원칙을 따릅니다. 데이터는 도메인 소유권을 따르고 데이터는 제품처럼 처리됩니다. 플랫폼은 완전히 셀프 서비스이지만 서비스의 변형은 제한적입니다. 모든 도메인은 동일한 데이터 관리 원칙을 강력하게 준수하고 준수해야 합니다.
이 배포 옵션은 데이터 메시를 수용하지만 지나치게 복잡하지는 않으려는 소규모 회사 또는 그린필드 프로젝트에 유용할 수 있습니다. 이 배포는 더 복잡한 항목을 빌드하려는 조직의 시작점이 될 수도 있습니다. 이 경우 나중에 여러 랜딩 존으로 확장할 계획입니다.
원본 시스템 정렬 및 소비자 맞춤 랜딩 존
이전 모델에서는 다른 구독 또는 온-프레미스 애플리케이션을 고려하지 않았습니다. 들어오는 모든 데이터를 관리하기 위해 원본 시스템 정렬 랜딩 존을 추가하여 이전 모델을 약간 변경할 수 있습니다. 데이터 온보딩은 어려운 프로세스이므로 두 개의 데이터 랜딩 존을 사용하는 것이 유용합니다. 온보딩은 데이터를 사용하는 데 가장 어려운 부분 중 하나입니다. 또한 온보딩에는 통합과는 다른 문제가 있기 때문에 통합을 해결하기 위한 추가 도구가 필요한 경우가 많습니다. 데이터 제공과 데이터 소비를 구분하는 데 도움이 됩니다.
이 다이어그램 왼쪽의 아키텍처에서 서비스는 CDC, API 끌어 오는 서비스 또는 데이터 세트를 동적으로 빌드하기 위한 데이터 레이크 서비스와 같은 모든 데이터 온보딩을 용이하게 합니다. 이 플랫폼의 서비스는 온-프레미스, 클라우드 환경 또는 SaaS 공급업체에서 데이터를 가져올 수 있습니다. 이러한 유형의 플랫폼은 기본 운영 애플리케이션과 더 많은 결합이 있기 때문에 일반적으로 오버헤드가 더 깁니다. 이를 데이터 사용량과 다르게 처리할 수 있습니다.
다이어그램 오른쪽의 아키텍처에서 조직은 소비를 최적화하고 데이터를 가치로 전환하는 데 중점을 두는 서비스를 제공합니다. 이러한 서비스에는 기계 학습, 보고 등이 포함될 수 있습니다.
이러한 아키텍처 도메인은 데이터 메시의 모든 원칙을 따릅니다. 도메인은 데이터의 소유권을 가지며 데이터를 다른 도메인에 직접 배포할 수 있습니다.
허브, 제네릭 및 특수 데이터 랜딩 존
다음 배포 옵션은 이전 디자인의 또 다른 반복입니다. 이 배포는 관리되는 메시 토폴로지 다음에 따릅니다. 데이터는 중앙 허브를 통해 배포되며, 데이터는 도메인별로 분할되고 논리적으로 격리되며 통합되지 않습니다. 이 모델의 허브는 자체(도메인에 구애받지 않는) 데이터 랜딩 존을 사용하며, 다른 도메인에 배포되는 데이터를 감독하는 중앙 데이터 거버넌스 팀이 소유할 수 있습니다. 또한 허브는 데이터 온보딩을 용이하게 하는 서비스를 제공합니다.
새 데이터를 사용, 사용, 분석 및 만들기 위해 표준 서비스가 필요한 도메인의 경우 일반 데이터 랜딩 존을 사용합니다. 이 단일 구독은 표준 서비스 집합을 보유합니다. 또한 대부분의 데이터 제품이 허브에 이미 유지되고 더 많은 데이터 중복이 필요하지 않으므로 데이터 가상화를 적용합니다.
이 배포를 통해 도메인을 논리적으로 그룹화할 수 없는 경우 프로비전할 수 있는 추가 랜딩 존인 '특수'를 사용할 수 있습니다. 지역 또는 법적 경계가 적용되거나 도메인에 고유하고 대조적인 요구 사항이 있는 경우 필요할 수 있습니다. 또한 해외 활동을 제외하고 강력한 글로벌 자회사 거버넌스가 적용되는 상황에서 필요할 수도 있습니다.
조직에서 어떤 데이터가 어떤 도메인에서 배포되고 사용되는지 제어해야 하는 경우 허브 배포가 좋은 옵션입니다. 또한 대규모 데이터 소비자에 대한 시간 변형 및 비휘발성 문제를 해결하는 경우에도 옵션입니다. 데이터 제품 디자인을 강력하게 표준화하여 도메인이 시간 여행을 가능하게 하고 재전송을 수행할 수 있습니다. 이 모델은 금융 업계에서 특히 일반적입니다.
기능 및 지역적으로 정렬된 데이터 랜딩 존
여러 데이터 랜딩 존을 프로비전하면 작업 및 공유 데이터에 대한 응집력 및 효율성에 따라 기능 도메인을 그룹화할 수 있습니다. 모든 데이터 랜딩 존은 동일한 감사 및 제어를 준수하지만 다른 데이터 랜딩 존 간에 유연성과 디자인 변경이 있을 수 있습니다.
공유 데이터 랜딩 존에 대해 논리적으로 그룹화하려는 기능 데이터 도메인을 결정합니다. 예를 들어 지역 경계가 있는 경우 동일한 템플릿을 구현할 수 있습니다. 소유권, 보안 또는 법적 경계는 도메인을 강제로 분리할 수 있습니다. 유연성, 변화의 속도, 기능의 분리 또는 판매도 고려해야 할 중요한 요소입니다.
추가 지침 및 모범 사례는 데이터 도메인에서 찾을 수 있습니다.
각각의 랜딩 존은 독립적으로 존재하지 않습니다. 다른 영역에서 호스트되는 데이터 레이크에 연결할 수 있습니다. 이렇게 하면 도메인이 기업 전체에서 공동 작업할 수 있습니다. 여러 데이터 저장소 기술을 혼합하기 위해 다각형 지속성을 적용할 수도 있습니다. Polyglot 지속성을 사용하면 도메인에서 데이터를 복제하지 않고도 다른 도메인에서 직접 데이터를 읽을 수 있습니다.
여러 데이터 랜딩 존을 배포할 때 각 데이터 랜딩 존에 연결된 관리 오버헤드가 있음을 알 수 있습니다. 모든 데이터 랜딩 존 간에 VNet 피어링을 적용해야 하며, 추가 프라이빗 엔드포인트를 관리해야 합니다.
데이터 아키텍처가 큰 경우 여러 데이터 랜딩 존을 배포하는 것이 좋습니다. 아키텍처에 랜딩 존을 더 추가하여 다양한 도메인의 일반적인 요구 사항을 해결할 수 있습니다. 이러한 추가 랜딩 존은 가상 네트워크 피어링을 사용하여 데이터 관리 랜딩 존과 다른 모든 랜딩 존 모두에 연결합니다. 피어링을 사용하면 랜딩 존에서 데이터 세트와 리소스를 공유할 수 있습니다. 별도의 영역에 데이터를 분할하면 Azure 구독 및 리소스에 워크로드를 분산할 수 있습니다. 이 방법은 데이터 메시를 유기적으로 구현하는 데 도움이 됩니다.
다양한 데이터 관리 영역이 필요한 대규모 엔터프라이즈
글로벌 규모로 운영되는 대기업은 조직의 여러 부분 간에 데이터 관리 요구 사항을 대조할 수 있습니다. 이 문제를 해결하기 위해 여러 데이터 관리 및 데이터 랜딩 존을 함께 배포할 수 있습니다. 다음 다이어그램에서는 이러한 유형의 아키텍처에 대한 예를 보여 있습니다.
여러 데이터 관리 랜딩 존은 오버헤드 및 통합 복잡성을 정당화해야 합니다. 예를 들어 다른 데이터 관리 랜딩 존은 조직 외부의 누구도 조직의(메타) 데이터를 볼 수 없는 상황에 적합할 수 있습니다.
결론
데이터 메시로의 전환은 뉘앙스, 장단 관계 및 고려 사항을 포함하는 문화적 변화입니다. 클라우드 규모 분석을 사용하여 모범 사례 및 실행 가능한 리소스를 얻을 수 있습니다. 이 문서의 참조 아키텍처는 구현을 시작하기 위한 시작 지점을 제공합니다.