분산형 데이터 분석 아키텍처-데이터 매쉬

Data mesh

조대협 (http://bcho.tistory.com)

Data mesh는 빅데이터 분석 시스템의 아키텍쳐 스타일로, 마이크로 서비스 아키텍처 (이하 MSA)컨셉과 유사하게 데이터 분석 시스템을 각각의 분산된 서비스 형태로 개발 관리하는 아키텍쳐 모델이다. 

이번 글에서는 차세대 데이터 분석 시스템 아키텍처인 Data mesh에 대해서 알아본다. 

데이터 분석 시스템의 역사

Data mesh에 대해서 이해하려면 기존의 데이터 분석 시스템의 아키텍처와 그 역사에 대해서 이해하라 필요가 있다.데이터 분석 시스템은, DataWare house를 거쳐 현재는 Data Lake 형태가 주류를 이루고 있으며, 차세대로는 Data Mesh가 각광 받고 있다. 각각 아키텍처 스타일을 보면 다음과 같다.

Data warehouse

Data Warehouse는 전통적인 RDBMS 형태에서 데이터를 모아서 분석하는 아키텍처로 파일이나 데이터 베이스 (OLTP)시스템에 저장된 데이터를 일반적으로 ETL이나 CDC 방식으로 Data Warehouse 로 수집한 후에, Data Warehouse에서 데이터를 저장하고 분석하는 방식이다. 

각 비즈니스 부서에 따라서 데이터 분석에 대한 요구 사항이 많을 경우에 Data warehouse 에서 그 부서에만 필요한 데이터를 Data Mart라는 형태의 별도의 분석용 데이터 베이스에 저장하고 비즈니스 부서는 그 Data Mart 만 사용하는 구조를 사용하는 경우도 있다.

<그림. Data Warehouse의 일반적인 아키텍처>

이 구조는 전통적인 RDBMS 를 활용하는 아키텍처이기 때문에, 테이블처럼 구조화된 데이터 (structure data)를 처리하는데 유리하다. 통상적으로 상용 벤더에서 제공되는 솔루션을 기반으로 구축이 되는데, 

이러한 Data Warehouse는 RDBMS의 특성으로 인하여 빅데이터에 대해서 횡적인 스케일에 한계가 있고, 상용 소프트웨어와 이를 지원하기 위한 인증된 하드웨어를 사용해야하기 때문에 인프라 비용이 높다는 단점을 가지고 있다. 

Data lake

데이터의 볼륨이 늘어나고 다양화되어감에 따라 빅데이터 분석의 요구 사항이 발생하였고, 이러한 문제를 해결하기 위한 아키텍처 구조가 Data Lake 이다. 기존의 Data Warehouse가 테이블 형태의 정형 데이터 (structured data)를 지원했다면, Data Lake는 데이터 형식에 제한이 없이 텍스트나, 이미지등의 비정형 데이터 (unstructured data)에 대한 저장과 분석을 지원하며, JSON과 같은 반정형 데이터 (semi-structured data)까지 지원하는 특성을 가지고 있다.

데이터 처리 측면에서는 Data Warehouse가 기존의 RDBMS등의 소스로 부터 배치로 데이터를 주기적으로 적재하여 처리 및 분석 했다면, Data Lake 기반의 분석 시스템의 특징은 로그 스트림이나 모바일 앱 이벤트로그와 같은 실시간 스트리밍성 데이터에 대한 실시간 처리가 가능하다는 강점을 가지고 있다. 

이렇게 처리된 데이터는 결과 데이터 저장소에 저장이 되서 직접 분석이 되거나 (원본 데이터를 전처리 과정을 끝난 후에, 데이터 분석가들이 Hive 등의 쿼리를 이용해서 분석하는 시나리오를 예를 들 수 있다.) 또는 정형 데이터의 경우에는 기존의 Data Warehouse나 Data Mart로 복사되어 비즈니스 사용자가 좀 더 편리하게 분석할 수 있도록 서비스를 제공한다.

<그림. 일반적인 Data Lake 시스템 아키텍처 예시>

이러한 Data Lake 시스템은 일반적으로 Hadoop/Spark 기반으로 구축되며, Data Lake의 저장소로는 HDFS (Hadoop File System)을 사용하고, 분석 엔진으로는 Hadoop 이나 Spark 을 사용하며, 실시간 스트리밍 처리는 Kafka 와 같은 대용량 큐를 사용하고, 뒷단에 처리 시스템으로 Spark Streaming 등을 사용하는 것이 일반적인 아키텍처 구조이다. 

기존 아키텍처의 문제점

Data Lake나, Data Warehouse 아키텍처 시스템은 하나의 중앙 집중화된 시스템에 데이터를 모으고 분석하는 형태이고, 데이터를 분석하는 주체가 중앙 집중화된 데이터 분석 팀이라는 특징을 가지고 있다. 

한군데 데이터를 모두 모아서 한 조직이 분석한다는 개념은 이론적으로 봤을때는 완벽한 개념으로 보이지만 실무적으로 봤을때 문제가 있는 아키텍처 구조이다.

도메인 지식의 부족

데이터를 중앙에 모아놓고, 데이터 분석팀이 데이터 분석을 진행할때, 이 데이터 분석가들은 데이터 분석 업무 자체에는 전문성을 가질 수 있으나, 데이터의 특성을 이해하기 위한 도메인 지식이 부족하다. 예를 들어 영업/마케팅/회계등. 도메인 지식이 부족한 상태에서는 데이터에 대한 인사이트를 뽑아내기 어렵다. 그래서 현업팀 (각 도메인별)과 커뮤니케이션을 하면서 요구사항 기반으로 도메인의 지식을 습득하여 데이터를 분석하는데, 이로 인해서 하나의 분석팀이 여러 현업팀을 상대해야 하기 때문에, 커뮤니케이션의 지속성이 떨어지고 이로 인해서 도메인에 대한 이해도가 떨어지기 때문에, 결과적으로 신속하고 깊은 수준이 데이터 분석이 어려워 진다.

<그림. 하나의 데이터 분석팀이 여러 현업 부서와 커뮤니케이션 하는 모델>

여기에 더해서 현업팀과 데이터 분석팀은 별도의 부서이기 때문에, 부서간의 커뮤니케이션이 필요한 만큼 서로간의 업무를 이해하기 어려워지게 된다. 특히나 다른 부서는 다른 골을 가지고 있기 때문에, 새로운 데이터 분석 시스템을 올린다고 했을때 쉽게 성공하지 못하는 이유이다. 예를 들어 회사에서 차세대 데이터 분석 시스템을 만들겠다고 데이터 분석팀이 과제를 시작한다고 했을 때, 이 시스템들은 각 현업 부서로 부터 데이터도 수집해와야 하고, 요구 사항을 수집도 해야 하지만, 협업 부서 (예를 들어 영업팀)는 해당 부서의 골(매출 향상)에 가장 최우선 목적을 두는 만큼 기대했던것 만큼 충분한 성과를 이루어내기가 어렵다. 

단일화된 기술 체계

중앙 집중화된 단일 데이타 분석 시스템의 경우에는 단일 시스템이기 때문에 단일화된 분석 기술 솔루션을 사용한다. 그러나 데이터나 도메인의 특성에 따라서 유용한 솔루션이 다른 경우가 많다. 예를 들어 디지털 마케팅의 경우 Adobe 등과 같이 디지털 마케팅에 최적화된 플랫폼등이 있을 수 있는데, 중앙 집중화된 데이터 분석 플랫폼은 이런 다양한 기술 체계를 수용하기가 어렵다. 

예산 및 인력 부족 

데이터 분석팀은 전통적으로 이윤을 남기는 영업 조직이나 마케팅 조직이 아닌 연구성 조직에 가깝기 때문에, 이윤 조직(profit center) 보다는 비용만 쓰는 비용 조직 (cost center)으로 인식 되는 경우가 많다. 데이터 분석으로 인한 수익에 대한 기여 부분을 수치화 하기가 어렵기 때문인데, 독립적으로 수익을 내지 못하기 때문에, 회사내의 투자된 비용에 따라 조직을 운영하는 경우가 많다. 특정 도메인(부서)를 위한 데이터 분석 시스템을 만들기 위해서, 그 부서로 부터 자금을 투자 받아 시스템등을 운영하는 케이스가 있는데, 이도 결과적으로 외부 투자와 지원에 의존적인 구조이다.

이렇다 보니, 일반적으로 데이터 분석 조직은 필요한 인력과 장비에 대한 투자를 충분히 하기가 어렵고 이로 인해서 인력 부족으로 원하는 만큼 데이터 분석을 하기 어려운 경우가 많다. 

실제 필드 상황

이미 실제 필드에서는 이러한 상황을 잘 이해하고 있기 때문에, 중앙 집중화된 데이터 분석 플랫폼이 있음에도 불구하고 각 부서에서 데이터 분석 플랫폼을 따로 만드는 경우가 있다. 예산이 충분하고 데이터에 대한 인사이트가 있는 부서의 경우, 자신의 부서를 위한 데이터 분석 플랫폼을 올리는 경우인데, 

예를 들어 마케팅 팀에서 마케팅 데이터 분석 플랫폼을 새로 만들고, 웹 사이트를 위한 웹 분석 플랫폼, 고객 지원 서비스에 대한 데이터 분석 플랫폼들이 따로 생기는 경우이다. 

Data Mesh

이러한 문제를 해결 하기 위한 데이터 분석 시스템 아키텍처가 Data Mesh 이다. 

기존 데이터 분석 플랫폼이 아래와 같이 모든 도메인에 대해서 단일 시스템과 단일 분석팀을 사용하였다. 이를 Monolithic (모노리틱) 구조라고 한다. 

<그림. Monolithic data analytics platform architecture > 

아래와 같이 도메인(업무) 별로 시스템과 팀을 분리하는 구조를 Data Mesh 아키텍처라고 한다. 데이터 분석팀과 분석 시스템이 각 업무 별로 할당되어 있는 Distributed 구조가 된다. 

<그림. Distributed data analytics platform architecture>

핵심은 부서별로 독립된 시스템과 팀을 보유하고, 데이터 생성자와 소비자 (현업) 역시 한 팀에 묶어서 요구 사항에 대한 반영을 빠르게 하고, 독립된 예산과 팀으로 움직여서 비즈니스 여건에 맞는 시스템을 빠르게 개발할 수 있다는 장점이 있으며, 해당 도메인에 적합한 기술을 사용함으로써, 기술적인 최적화가 가능하다는 장점을 가지고 있다. 

이 아키텍처 구조는 애플리케이션 아키텍처인 마이크로 서비스 아키텍처와 같은 철학과 특징을 가지고 있다. 마이크로 서비스 아키텍처로 업무 단위로 서비스를 나누고 각 팀안에서 기획에서 부터 개발/운영을 모두 담당하게 함으로써 속도를 높이는 아키텍처 라고 하면, Data Mesh도 데이터 도메인별로 팀과 시스템을 나누는 방식으로 해서 해당 데이터에 대한 이해도와 속도를 높이는 장점을 제공하는 것이다. 

Data Mesh는 기동성을 높인다는 의미에서는 장점이 있으나 반대로 단점도 있다.  다음은 몇몇 단점과 함께 Data Mesh 시스템이 가지고 있어야 하는 기능에 대해서 설명한다. 

타부서간의 데이터 조회 지원

특히 다른 부서간에 데이터를 억세스 하고자 할때 이런 단점이 있다. 예를 들어 아래 그림과 같이 마케팅 팀이 세일즈 팀의 데이터를 접근하고자 할때, 전혀 다른 시스템이기 때문에 추가적인 계정 생성과 접근 권한을 받아야 하는 문제가 필요하고, 특히 마케팅 데이터 분석 시스템과 영업 데이터 분석 시스템의 분석 도구나 UI 등이 달라서 타 부서 데이터를 접근하는 것이 어려울 수 있다.  

 

<그림. 타 부서의 데이터를 조회 해야하는 요구 사항>

이런 문제를 해결하기 위해서는 데이터 분석 도구를 통일하는 방법이 있는데, 아래 그림과 같이 분석 시스템 앞단에 분석용 UI (시각화나 쿼리 인터페이스)를 통합하여, 같은 인터페이스로 여러 데이터를 쿼리 하도록 하고, 데이터에 대한 접근 통제도 분석용 UI단에서 하는 방식이다. 

<그림. 여러 부서의 데이터를 통합된 분석용 UI로 조회하는 구조>

이런 UI는 멀티 백앤드를 지원하는 타블루, Looker 등을 사용하여 이기종 데이터 분석단에도 통합된 경험을 제공할 수 있다. 유사한 오픈소스로는 Hue 등이 있다.

타부서 데이터에 대한 통합 데이터 분석

이렇게 다른 부서의 데이터를 조회하게 하도록 지원하더라도, 다른 부서 데이터를 참고해서 (JOIN)해서 데이터를 분석하고자 하는 요건이 있을 수 있다. 예를 들어 마케팅 캠페인을 한 사용자 목록과 세일즈 데이터를 JOIN 해서, 마케팅이 실제 판매에 어떤 영향을 주었는지등을 분석하는 시나리오이다. 

 

<그림. 타 부서의 데이터를 JOIN하여 분석하는 페더레이션 시나리오>

이 시나리오는 각각 독립적인 두개의 이기종 데이터 분석 시스템간의 Federation을 요구로 한다. 기존에는 이런 시나리오를 ETL등을 이용해서, 특정 테이블만 상대쪽에 복사해놓고 하는 방법을 사용하였다. 지금도 유효한 방법이지만, 플랫폼이 지원해준다면, 별도로 데이터를 복사하지 않고 문제를 풀어나갈 수 있다. 

예를 들어 구글의 BigQuery의 경우 특정 데이터셋(테이블의 집합)을 타 부서의 프로젝트로 공유를 해줄 수 있다.  이 경우 별도의 ETL 작업이 불필요 하며, 이 기종 분석 시스템에 대해서도 구글의 MySQL/PostgreSQL 매니지드 서비스인 CloudSQL에 저장되어 있는 데이터나 구글의 NoSQL인 BigTable에 있는 데이터를 쿼리할 수 있다. (이를 Federation 이라고 한다. )

이 보다 핵심 기능은 GCS (Google Cloud Storage)에 있는 파일을 직접 쿼리할 수 있는데, Parquet 과 같은 파일 포맷을 지원한다. Parquet은 Hive 등에서 데이터 저장 파일포맷으로 사용되는데, 정리해서 이야기 하면 별도의 연동 ETL이 없이 Hadoop eco 시스템으로 구축되어 있는 데이터를 조회하여 통합 (JOIN)분석을 할 수 있다는 이야기가 된다. 

이렇게 서로 다른 시스템간의 데이터를 서로 상호 조회할 수 있는 기능을 Federation이라고 하고, Data Mesh에서 매우 중요한 항목으로 취급된다. 

데이터 카탈로그 서비스 

이렇게 조직간의 데이터를 서로 크로스로 조회하고, 연관 분석을 할 수 있게 되면 다음 문제는 여러 부서간의 방대한 데이터에 대해서 어디에 어떤 데이터가 있는지를 찾을 수 있어야 한다. 데이터 거버넌스 측면에서 데이터 검색 및 메타 데이터 관리 기능에 대한 컴포넌트가 반드시 필요하다. 

필요한 데이터를 사용자가 찾고 쉽게 액세스할 수 있어야 하며, 여기에 더불어 사용자에 따라서 데이터 접근 권한을 관리할 수 있는 기능이 필요하다. 

또한 보안 관점에서 데이터에 대한 액세스 히스토리를 통해서 누가 언제 어떤 데이터를 조회하였는지 확인할 수 있어야 한다. 

이러한 메터데이터에 대한 관리를 할 수 있는 소프트웨어로는 오픈소스에 Apache Atlas와 상용 솔루션으로는  Colibra 등이 있고, 구글 클라우드에서는 Data Catalog라는 서비스로 구글 클라우드에 저장되는 데이터 (빅쿼리, GCS, Pub/Sub 메시징 큐)에 대한 메타 데이터 저장 검색 및 정책에 따른 접근 관리 기능을 제공한다. 

실시간 스트리밍 데이터

현대 빅데이터 시스템의 특징 중의 하나는, 정형,비정형의 데이터를 실시간 형태로 처리하는 스트리밍 데이터 처리가 추가된다는데 있다. 예를 들어 웹 접속 로그를 실시간으로 수집하여 분석하거나, 매장의 제품 판매 내용을 실시간으로 수집해서 분석하는 것과 같은 유스 케이스인데, 이러한 실시간 데이터 처리는 대용량 메시지 큐를 사용한다. 

<그림. 실시간 스트리밍 데이터 처리 아키텍처>

이 메세지 큐의 특징은 1:1 메시지 딜리버리뿐만 아니라 1:N 메시지 딜리버리를 지원해야 한다는 것인데, 

실시간 메시지 큐는 데이터를 저장하는 데이터 베이스 성격이 아니지만, 데이터를 다룬다는 점에서 데이터 엣셋으로 분류되어서 데이터 카달로그에 등록되어서 관리되어야 한다. 

Devops

Data Mesh 시스템도 마이크로 서비스와 유사하게 Devops의 개념을 도입하는 것이 좋은데, 이유는 속도 중심의 아키텍처 스타일로 각 도메인에 대한 데이터 분석을 각 팀이 수행하기 때문인데, 여기에 빠른 속도를 더하기 위해서는 운영과 개발을 함께 하는 구조가 되는 것이 좋다. 

단순하게 개발과 운영을 그팀에서 한다는 개념으로 소화를 하면 안되고, 제대로된 Devops를 하기 위해서는 데이터 분석 시스템이 플랫폼화가 되어 있어야 한다.

예를 들어서 마케팅 데이터 분석 시스템을 개발/운영 하는 팀이 있다고 할때, 이 시스템을 Hadoop으로 개발한다고 하자. 마케팅 데이터 분석 팀은 필요한 하드웨어 구매에서 부터, Hadoop 설치, 데이터 카탈로그, 분석 로직 개발, 시각화든 인프라에서 부터 툴 셋업 및 그위에 분석 업무까지 모두 개발해야 하는데, 이는 시간이 많이 걸리는 작업이고, 타 부서의 분석팀도 동일한 작업을 계속해야 한다. 

그래서 플랫폼의 필요성이 대두되는데, 분석가들은 분석 업무와 비즈니스 로직을 구현하는데만 집중하고, 하부에 인프라와 솔루션은 플랫폼 형태로 제공되서 Self Service 형태로 분석가들이 인프라를 구성하고 사용할 수 있는 구조가 되어야 한다.

이 개념 아키텍처를 도식화 한것이 아래 그림이다. 

< 그림. 데이터 플랫폼 아키텍처와 Devops 팀의 역할 관계 개념도 >

특히 이 공통 플랫폼을 개발하고 운영 하는 팀이 Devops 팀이고, 이 팀의 역할은 플랫폼을 개발해서 이를 각 데이터 분석팀이 사용할 수 있는 구조로 해주고 플랫폼을 운영 유지보수 하는 역할을 한다. 

참고 자료

• Data Monolithic to mesh