IT 트렌드 - Data Mesh를 통한 데이터 관리의 탈중앙화

  이번 글에서는 기존 DW, Data Lake 처럼 중앙 집중식으로 데이터 관리하면서 발생되는 문제들을 해결하기 위해 최근 언급되고 있는 새로운 데이터 관리 체계인 Data Mesh 개념에 대해 살표 보겠습니다.


Data Mesh 출현 배경

기업은 내/외부의 데이터를 Data Warehouse 또는 Data Lake를 통해 중앙 집중적으로 수집/통합하여 비지니스 사용자들을 지원해오고 있습니다.

과거의 전통적 On-Premise와 최신 Cloud로 전환되면서 더욱 여러 종류의 Data Source들이 출현하고 있습니다. 이렇다 보니 더 많은 데이터 이동과 복잡한 ETL 작업이 수반되고 데이터의 양은 계속 증가되고 결국 어디서 무엇을 찾을 수 있는지 매우 힘들어지는 상황이 되고 있습니다.

또, DW나 Data Lake를 관리/운영 부서들이 모두 IT 중심의 부서이다 보니 각기 다른 비지니스 사용자들의 비지니스 요구 사항에 능동적으로 대응하기가 매우 어렵다는 것입니다.

그래서 전통적인 중앙 집중식 데이터 관리를 벗어나 해결하려는 고민과 시도들이 나타나게 되었습니다.


Data Mesh 이란 무엇인가?

최근 Cloud 환경에서 어플리케이션을 개발할 때 기존 Monolithic 방식보다 MicroService Architecture(MSA) 방식을 채택 사례가 증가하고 있습니다.

데이터 관리에서도 이런 MSA 방식과 같이 기존 하나의 거대한 Data Repository가 아닌 각자 Domain별로 나누어서 데이터 관리 체계를 구성하는 접근 방식 나타나고 있습니다.

Data Mesh는 최종 사용자가 중요한 데이터를 Data Lake나 Data Warehouse로 통합하지 않고 전문적인 데이터 팀이 개입할 필요 없이 Domain 부서에서 운영 데이터와 분석 데이터를 관리하여 쉽게 액세스할 수 있도록 하는 설계 개념입니다. 

Data Mesh는 데이터 관리의 병목 현상과 사일로를 줄이고 데이터 거버넌스를 희생하지 않으면서 확장성을 가능하게 하여 데이터를 제품으로 독립적이고 안전하게 관리할 수 있는 팀 간에 데이터 소유권을 분산하는 분산화(탈 중앙화)에 중점을 둡니다.

Data Mesh 개념은 Thinkworks North America의 차세대 기술 인큐베이션 이사인 Zhamak Dehghani가 처음 작성했습니다. Dehghani는 2019년 5월 보고서 "How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh"에서 Data Mesh의 원칙과 개념을 제시했으며, 이어 "Data Mesh Principles and Logical Architecture"라는 2020년 12월 보고서를 발표했습니다.


Data Mesh 핵심 요구 사항

Data Mesh를 처음 언급한 Zhamak Dehghani는 Data Mesh의 핵심 요구 사항으로 아래와 같이 4가지를 언급했습니다.

The logical architecture of the data mesh approach (Source: Zhamak Dehghani)

1. Domain-oriented decentralized data ownership and architecture

    - 중앙 집중식 데이터 소유권의 문제는 전문성의 깊이와 폭의 부족

    - 데이터에 가장 가까운 사람이 해당 데이터를 책임 - 데이터를 필요로 하는 소비자에 대한 데이터의 조작(생성 및 변환), 유지 관리 및 배포를 담당

    - 데이터 소유권에 대한 책임을 해당 데이터 영역을 가장 잘 아는 사람들에게 분배

    - 전문가가 서비스를 담당하도록 하면 데이터 요청 파이프라인이 간소화되어 더 빨리 필요한 사람들에게 고품질 데이터를 제공

2. Data as a product

    - 데이터 소비자는 신뢰할 수 있는 데이터 제품에 액세스해야 하며 생성자는 해당 요구 사항을 충족하기 위해 가능한 한 빨리 최고 품질의 데이터를 제공하는 것이 핵심

    - 기업 내에서 우수한 데이터에 대한 수요가 급증하면서 "데이터를 제품으로"라는 개념 등장

    - 제품으로서의 데이터가 데이터 메시 가치의 핵심 원칙

3. Self-serve data infrastructure as a platform

    - 데이터 생성자와 소비자가 Data Mesh를 구성할 수 있는 Self-service 기반의 데이터 플랫폼

    - 데이터 플랫폼을 구성할 수 있는 Infrastructure, Data Repository, Data Catalog 

4. Federated computational governance

    - 각 도메인 데이터에 대한 액세스를 위한 데이터 공유 정책, 규칙, 모니터링, 통제

    - 규정 준수 법률이 점점 더 까다로워지고 데이터 환경이 더 복잡해짐에 따라 데이터 관리와 데이터 거버넌스의 분리 필요성 증가

    - 데이터 거버넌스와 품질 관행이 도메인마다 상이하고 데이터 중복 문제에 대한 해결


Data Mesh를 위한 SAP 솔루션

SAP 솔루션을 통해 Data Mesh 아키텍처를 어떻게 구현할 수 있을까요?

SAP는 Business Technology Platform의 다양한 솔루션의 결합을 통해 Data Mesh를 구현할 수 있습니다.

1. Domain Ownership

    - SAP Master Data Governance의 Master Data Domain

    - SAP Master Data Integration

    - SAP Graph의 One Domain Model

    - SAP Data Warehouse Cloud의 Space

2. Data as a Product

    - SAP Data Intelligence의 Data Catalog

    - SAP HANA Cloud의 Data Security

    - SAP API Management

3. Self-Service Data Infrastructure

    - SAP Data Warehouse Cloud의 Self-Service Modeling

    - SAP Data Intelligence Cloud의 Pipeline & Orchestration

4. Federated Computational Governance

    - SAP HANA Cloud의 Virtualization

    - SAP Master Data Governance의 Master Data Domain

    - SAP Master Data Integration

    - SAP Graph의 One Domain Model


마지막으로 우리가 관과하고 있는 또 한가지는 사람에 대한 것입니다. 기존 데이터 관리는 중앙에서 IT 부서들이 담당하였으나, MicroService Architecture와 같이 개발 부서 즉, 비지니스 도메인 부서에서 데이터를 관리해야 한다는 점입니다. 

Data Mesh 개념을 접하면서 개인적으로 굉장히 신선하면서도, 기존 방식과 완전히 상이하여 기술 아키텍처의 변화 뿐만 아니라 조직(IT부서에서 도메인부서)의 변화도 있어야 한다 점은 매우 큰 어려움으로 다가옵니다.

Data Mesh를 한번에 적용하기 보다는 부분적으로 접근하면서 장/단점을 면밀히 파악해봐야 할 것입니다. Data Mesh가 과연 폭풍속에 찻잔에 그칠 지 아니면 중요 이슈로 지속될 것인지는 좀 더 시간이 필요해 보입니다.


이 블로그의 인기 게시물

DI 구축사례 - 오뚜기 : 데이터 작업 간소화와 예측 분석 업무 활용

DI 구축사례 - Döhler : S/4HANA와 SAP BTP 활용을 통한 지능형 기업으로 전환

Data Intelligence - SAP Data Intelligence 란 무엇인가?