셀프 서비스 데이터 플랫폼에 대한 디자인 고려 사항

데이터 메시는 데이터 아키텍처의 디자인과 개발에 대한 새롭고 흥미로운 접근 방식입니다. 기존 데이터 아키텍처와 달리 데이터 메시는 데이터 제품을 만드는 데 중점을 둔 기능 데이터 도메인과 기술 기능에 중점을 둔 플랫폼 팀 간의 책임을 분리합니다. 이러한 책임의 분리는 플랫폼에 반영되어야 합니다. 도메인에 구애받지 않는 기능을 제공하는 일과 도메인 팀이 조직 전반에 걸쳐 데이터를 모델링, 처리하고 배포할 수 있도록 하는 일 간의 균형을 유지해야 합니다.

플랫폼을 사용해 분리하는 데 적절한 수준의 도메인 세분성과 규칙을 선택하기란 쉽지 않습니다. 이 문서에는 참고 자료를 제공하는 시나리오가 몇 가지 포함되어 있습니다.

클라우드 규모 분석

Azure를 사용하여 데이터 메시를 빌드하려는 경우 클라우드 규모 분석을 채택하는 것이 좋습니다. 이 프레임워크는 배포 가능한 참조 아키텍처로, 오픈 소스 템플릿 및 모범 사례와 함께 제공됩니다. 클라우드 규모 분석 아키텍처에는 모든 배포를 선택하는 데 반드시 필요한 두 가지 주요 구성 요소가 있습니다.

• 데이터 관리 랜딩 존: 데이터 아키텍처의 기반. 여기에는 데이터 카탈로그, 데이터 계보, API 카탈로그, 마스터 데이터 관리 등과 같이 데이터 관리에 중요한 기능이 모두 포함되어 있습니다.
• 데이터 랜딩 존: 분석 및 AI 솔루션을 호스트하는 구독. 여기에는 분석 플랫폼을 호스팅하기 위한 주요 기능이 포함되어 있습니다.

다음 다이어그램에는 데이터 관리 랜딩 존과 단일 랜딩 존이 포함된 클라우드 규모 분석 플랫폼의 개요가 나와 있습니다. 모든 Azure 서비스가 다이어그램에 표시되는 것은 아닙니다. 다이어그램은 이 아키텍처 내 핵심 개념의 리소스 구성을 강조 표시하기 위해 간소화했습니다.

클라우드 기반 분석 프레임워크는 프로비전해야 하는 데이터 아키텍처의 정확한 형식을 명시하지 않습니다. (엔터프라이즈) 데이터 웨어하우스, 데이터 레이크, 데이터 레이크 하우스, 데이터 메시를 비롯한 일반적인 여러 클라우드 규모 분석 솔루션에 사용할 수 있습니다. 이 문서의 모든 예제 솔루션에서는 데이터 메시 아키텍처를 사용합니다.

모든 아키텍처는 도메인 소유권, 제품으로서의 데이터, 셀프 서비스 데이터 플랫폼 및 페더레이션된 계산 거버넌스와 같은 데이터 메시 원칙을 준수함을 이해합니다. 다른 경로는 모두 데이터 메시로 이어질 수 있습니다. 옳고 그른 답은 하나도 없습니다. 조직의 요구 사항에 적절한 절충안을 만들어야 합니다.

단일 데이터 랜딩 존

데이터 메시 아키텍처를 빌드하기 위한 가장 간단한 배포 패턴에는 데이터 관리 랜딩 존과 데이터 랜딩 존이 하나씩 포함되어 있습니다. 이러한 시나리오의 데이터 아키텍처는 다음과 같습니다.

이 모델에서는 모든 기능 데이터 도메인이 동일한 데이터 랜딩 존에 상주합니다. 단일 구독에는 표준 서비스 집합이 포함됩니다. 리소스 그룹은 서로 다른 데이터 도메인과 데이터 제품을 분리합니다. Azure Data Lake Store, Azure Logic Apps, Azure Synapse Analytics 같은 표준 데이터 서비스는 모든 도메인에 적용됩니다.

모든 데이터 도메인은 데이터 메시 원칙을 따릅니다. 데이터는 도메인 소유권을 따르며, 데이터는 제품처럼 처리됩니다. 플랫폼은 전체 셀프 서비스이지만, 서비스의 변형은 제한적입니다. 모든 도메인은 동일한 데이터 관리 원칙을 강력하게 준수해야 합니다.

이 배포 옵션은 데이터 메시를 수용하지만 지나치게 복잡하지 않은 소규모 회사나 그린필드 프로젝트에 유용할 수 있습니다. 이 배포는 좀 더 복잡한 항목을 빌드하려는 조직의 시작점이 될 수도 있습니다. 이 경우 나중에 여러 랜딩 존으로 확장할 계획을 세웁니다.

원본 시스템 맞춤/소비자 맞춤 랜딩 존

이전 모델에서는 다른 구독 또는 온-프레미스 애플리케이션을 고려하지 않았습니다. 들어오는 모든 데이터를 관리하기 위해 원본 시스템 맞춤 랜딩 존을 추가하여 이전 모델을 약간 변경할 수 있습니다. 데이터 온보딩은 까다로운 프로세스이므로, 데이터 랜딩 존이 두 개 있으면 유용합니다. 온보딩은 대규모 데이터 사용 시 가장 어려운 부분 중 하나입니다. 또한 온보딩에는 통합과 관련된 문제가 다르기 때문에 통합을 다루기 위해서는 추가 도구가 필요한 경우가 많습니다. 이는 데이터 제공과 데이터 소비를 구분하는 데 도움이 됩니다.

이 다이어그램 왼쪽에 있는 아키텍처의 서비스는 CDC, API 끌어오기 서비스 또는 데이터 세트를 동적으로 빌드하기 위한 데이터 레이크 서비스 같은 모든 데이터의 온보딩을 용이하게 합니다. 이 플랫폼의 서비스는 온-프레미스, 클라우드 환경 또는 SaaS 공급업체에서 데이터를 끌어올 수 있습니다. 이 유형의 플랫폼은 기본 운영 애플리케이션과 더 많이 결합되어 있기 때문에 일반적으로 오버헤드가 더 많습니다. 이를 데이터 사용량과 다르게 처리하고자 할 수 있습니다.

다이어그램 오른쪽에 있는 아키텍처의 조직에서는 소비를 최적화하고 데이터를 가치로 전환하는 데 초점을 맞춘 서비스를 제공합니다. 이러한 서비스에는 기계 학습, 보고 등이 포함될 수 있습니다.

이러한 아키텍처 도메인은 모든 데이터 메시 원칙을 따릅니다. 도메인은 데이터의 소유권을 보유하며, 데이터를 다른 도메인에 직접 배포할 수 있습니다.

허브, 제네릭, 특수 데이터 랜딩 존

다음 배포 옵션은 이전 디자인의 또 다른 반복입니다. 이 배포는 관리되는 메시 토폴로지를 따릅니다. 데이터는 중앙 허브를 통해 분산되는데, 여기에서 데이터가 도메인별로 분할되고 논리적으로 격리되며 통합되지 않습니다. 이 모델의 허브는 자체(도메인에 구애받지 않음) 데이터 랜딩 존을 사용하며, 다른 도메인에 배포되는 데이터를 감독하는 중앙 데이터 거버넌스 팀이 소유할 수 있습니다. 또한 허브는 데이터 온보딩을 용이하게 해 주는 서비스를 제공합니다.

새 데이터를 소비, 사용하고 분석하며 만들기 위해 표준 서비스가 필요한 도메인의 경우 제네릭 데이터 랜딩 존을 사용합니다. 이 단일 구독에는 표준 서비스 집합이 포함됩니다. 또한 대부분의 데이터 제품이 허브에 이미 잔존하고 더 많은 데이터 중복이 필요하지 않으므로, 데이터 가상화를 적용합니다.

이 배포는 '특수', 즉 도메인을 논리적으로 그룹화할 수 없는 경우 프로비전할 수 있는 추가 랜딩 존을 허용합니다. 지역 또는 법적 경계가 적용되거나 도메인에 고유하면서도 대조적인 요구 사항이 있는 경우 필요할 수 있습니다. 해외 활동에 대한 예외를 제외하고, 강력한 글로벌 자회사 거버넌스가 적용되는 상황에서도 필요할 수 있습니다.

조직이 어떤 데이터가 어떤 도메인에서 배포되고 사용되는지를 제어해야 하는 경우, 허브 배포가 좋은 옵션입니다. 또한 대규모 데이터 소비자에 대한 시간의 변화, 비휘발성 문제를 해결하는 경우에도 적합한 옵션입니다. 데이터 제품 디자인을 강력하게 표준화하여 도메인이 시간을 이동하고 다시 배달하도록 할 수 있습니다. 이 모델은 금융 업계에서 특히 일반적입니다.

기능/지역적 맞춤 데이터 랜딩 존

여러 데이터 랜딩 존을 프로비전하면 작업/공유 데이터의 응집력과 효율성에 따라 기능 도메인을 그룹화할 수 있습니다. 모든 데이터 랜딩 존은 동일한 감사/제어 기준을 준수하지만, 다른 데이터 랜딩 존 간에 디자인 변경 사항과 유연성이 여전히 있을 수 있습니다.

공유 데이터 랜딩 존에 대해 논리적으로 그룹화하려는 기능 데이터 기본 결정합니다. 예를 들어 지역 경계가 있는 경우 동일한 템플릿을 구현할 수 있습니다. 소유권, 보안 또는 법적 경계로 인해 도메인을 강제로 분리해야 할 수 있습니다. 유연성, 변화의 속도, 기능의 분리 또는 판매도 고려해야 할 중요한 요소입니다.

추가 참고 자료와 모범 사례는 데이터 도메인에서 찾을 수 있습니다.

다른 랜딩 존은 독립적으로 실행되지 않습니다. 다른 영역에서 호스트된 데이터 레이크에 연결할 수 있습니다. 이렇게 하면 도메인이 엔터프라이즈 전체에서 협업할 수 있습니다. 또한 다중저장소 지속성을 적용하여 여러 데이터 저장소 기술을 혼합할 수 있습니다. 다중저장소 지속성을 사용하면 도메인에서 데이터를 복제하지 않고도 다른 도메인에서 직접 데이터를 읽을 수 있습니다.

여러 데이터 랜딩 존을 배포하는 경우 각 데이터 랜딩 존에 연결된 관리 오버헤드가 존재한다는 사실을 알고 있습니다. 모든 데이터 랜딩 존 간에 VNet 피어링을 적용해야 하며, 추가 프라이빗 엔드포인트 등을 관리해야 합니다.

데이터 아키텍처가 크면 여러 데이터 랜딩 존을 배포하는 것이 좋습니다. 아키텍처에 랜딩 존을 추가하여 다양한 도메인의 일반적인 요구 사항을 해결할 수 있습니다. 이러한 추가 랜딩 존은 가상 네트워크 피어링을 사용해 데이터 관리 랜딩 존과 다른 모든 랜딩 존에 모두 연결합니다. 피어링을 통해 랜딩 존에서 데이터 세트와 리소스를 공유할 수 있습니다. 별도의 영역에 데이터를 분할하면 Azure 구독과 리소스 전반에 걸쳐 워크로드를 분산할 수 있습니다. 이 접근 방식은 데이터 메시를 유기적으로 구현하는 데 도움이 됩니다.

다양한 데이터 관리 영역이 필요한 대규모 엔터프라이즈

글로벌 규모로 운영되는 대기업은 조직의 여러 부분 간에 대조적인 데이터 관리 요구 사항이 있을 수 있습니다. 이 문제를 해결하기 위해 여러 데이터 관리 및 데이터 랜딩 존을 함께 배포할 수 있습니다. 다음 다이어그램에는 이 유형의 아키텍처 예제가 나와 있습니다.

데이터 관리 랜딩 존이 여러 개인 경우 오버헤드 및 통합의 복잡성을 정당화해야 합니다. 예를 들어 다른 데이터 관리 랜딩 존이 조직 외부의 누구도 조직의 (메타)데이터를 봐서는 안 되는 상황에 적합할 수 있습니다.

결론

데이터 메시로의 전환은 뉘앙스, 절충점 및 고려 사항과 관련된 문화적 변화입니다. 클라우드 규모 분석을 사용하여 모범 사례와 실행 가능한 리소스를 얻을 수 있습니다. 이 문서의 참조 아키텍처에서는 구현을 시작하기 위한 시작점을 제공합니다.

다음 단계

• 데이터 마켓플레이스