도메인 주도 설계 첫걸음 - 16장 데이터 메시

범위

[Part 4] 다른 방법론 및 패턴과의 관계 - 16장: 데이터 메시(Data Mesh)

개념 정리

• OLTP(Online transaction processing, 온라인 트랜잭션 처리): 트랜잭션 지향 애플리케이션을 손쉽게 관리할 수 있도록 도와주는 정보 시스템의 한 계열로서, 일반적으로 데이터 기입 및 트랜잭션 처리를 위해 존재한다. 이 용어는 모호할 수도 있는데, 컴퓨터 환경에서 트랜잭션을 데이터베이스 트랜잭션으로 해석할 수도 있고 비즈니스 분야에서 금융 거래로 정의할 수도 있기 때문이다. 또, OLTP는 시스템이 사용자 요청에 즉각 반응하는 처리를 가리키는 용어이기도 하다. 은행의 현금 자동 입출금기(ATM)가 상용 트랜잭션 처리를 응용한 하나의 예로 볼 수 있다.[온라인 트랜잭션 처리]
• OLAP(Online Analytical Processing, 온라인 분석 처리): 의사결정 지원 시스템 가운데 대표적인 예로, 사용자가 동일한 데이터를 여러 기준을 이용하는 다양한 방식으로 바라보면서 다차원 데이터 분석을 할 수 있도록 도와준다. 최종 사용자가 다차원 정보에 직접 접근하여 대화식으로 정보를 분석하고 의사결정에 활용하는 과정에서 등장하였다. 사용자는 온라인상에서 직접 데이터에 접근하며, 대화식으로 정보를 분석하므로 사용자가 기업의 전반적인 상황을 이해할 수 있게 하고 의사결정을 지원하는 데 그 목적이 있다고 할 수 있다.
• 데이터 웨어하우스(DWH, Data Warehouse): 기업의 모든 실시간 데이터 처리 시스템에서 데이터를 추출해서 분석 모델로 변환한 후에 적재하는 분석 지향 데이터베이스(analysis-oriented database).
• 서비스 수준 협약서(SLA: Service Level Agreement): 서비스를 제공함에 있어서 공급자와 사용자간에 서비스에 대하여 측정지표와 목표 등에 대한 협약서이다. 일반적으로 여기에 포함될 수 있는 서비스 측정치들은 CPU의 가용시간, CPU 응답시간, 헬프 데스크 응답시간, 서비스 완료시간 등이다.[서비스 수준 협약서]

책에서 기억하고 싶은 내용

분석 데이터 모델과 트랜잭션 데이터 모델의 비교(Analytical Data Model Versus Transactional Data Model)

• 분석(OLAP) 모델과 실시간 처리(OLTP) 데이터 모델은 서로 다른 유형의 사용자를 지원하고, 다른 종류의 유스케이스를 구현하며, 그래서 결국에는 다른 설계 원칙을 따른다.
  • 실시간 데이터 모델
    • 시스템 비즈니스 도메인에 속한 다양한 엔티티를 중심으로 구축되고 이들의 수명주기를 구현하며 상호작용을 조율한다.
    • 실시간 비즈니스 트랜잭션을 지원하도록 최적화돼야 한다.
  • 분석 모델
    • 실시간 데이터 처리 시스템에 대한 다양한 통찰을 제공하도록 고안됐다.
    • 비즈니스 활동의 성과에 대한 통찰을 제공하는 것을 목표로 한다.
    • 더 많은 비즈니스 가치를 얻도록 운영을 최적화하는 방법을 제공하는 것이 목표.
• 자료구조 관점에서 보면 OLAP 모델은 개별 비즈니스 엔티티를 무시하는 대신 팩트 테이블과 디멘전 테이블을 모델링하여 비즈니스 활동에 집중한다.

팩트 테이블(Fact Table)

• 팩트(fact): 이미 발생한 비즈니스 활동을 나타낸다. 과거에 일어난 것에 대해 설명한다는 점에서 도메인 이벤트의 개념과 비슷하다.
• 팩트 레코드는 절대로 삭제되거나 수정되지 않는다.
• 분석 데[이터는 추가만 가능한 데이터다.
• OLAP와 OLTP 모델의 또 다른 큰 차이점은 데이터의 세분화(granularity) 정도다.
  • OLTP 시스템에서는 비즈니스 트랜잭션을 다루기 위해 가장 정밀한 데이터가 필요하다.
  • OLAP 모델의 경우 데이터를 취합하는 것이 다양한 유스케이스에 더 효과적이다.

디멘전 테이블(Dimension Table)

• 팩트가 비즈니스 절차 또는 동작을 표현한도면(동사), 디멘전은 팩트를 묘사한다(형용사).
• 디멘전이 고도로 정규화된 이유는 분석 시스텐에서 유연한 질의를 지원해야 하기 때문이다.
  • 비즈니스 요구사항을 지원하기 위해 실시간 데이터 모델이 어떻게 질의를 받을지는 예상할 수 있다.
  • 분석 모델의 질의 패턴은 예측할 수 없다.
  • 데이터 분석사는 데이터를 들여다보기 위해 유연한 질의가 필요하고, 미래의 어떤 질의가 실행될지 예측하기 어렵다.

분석 모델(Analytical Models)

• 스타 스키마와 스노우플레이크 스키나 모두 데이터 분석가가 비즈니스 성과를 분석하고 무엇을 최적화할지에 대한 통찰을 얻게 하며 BI(Business Intelligence) 리포트를 만들 수 있게 한다.

분석 데이터 관리 플랫폼(Analytical Data Management Platforms)

데이터 웨어하우스(Data Warehouse)

• 데이터 관리 아키텍처는 기본적으로 ETL(Extract-Transform-Load) 스크립트를 기반으로 한다.
• 목표
  • 엔터프라이즈 전방의 모델을 구축
  • 모델은 기업의 모든 시스템에서 생성되는 데이터를 묘사하고, 다양한 데이터의 사용 사례를 다뤄야 한다.
• 데이터 마트(data mart)
  • 데이터 마트는 단일 비즈니스 부서의 분석과 같이, 잘 정의된 분석 요구사항에 관련된 데이터를 저장하는 일종의 데이터베이스
  • 모든 상왕을 아우르는 모델을 구축하는 것의 어려운 점은 데이터 마트(data mart)를 사용하여 부분적으로 해결할 수 있다.
• 데이터 웨어하우스 아키텍처의 다른 어려운 점은 ETL 프로세스가 분석(OLAP) 시스템과 실시간 데이터 처리(OLTP) 시스템 간의 강력한 결합을 만든다는 것이다.
  • 실시간 데이터 처리 스스템 데이터베이스에서는 퍼블릭 인터페이스가 아닌, 내부적으로 구현된 상세 스키마를 사용한다. 그 결과, 스키마가 조금만 바뀌어도 데이터 웨어하우스의 ETL 스크립트가 작동하지 않는다. 실사간 데이터 처리 시스템과 분석 시스템은 다소 멀리 떨어진 조직에서 구현 및 유지보수를 하기 때문에 두 조직간의 커뮤니케이션이 어려우며 많은 마찰이 발생한다.

데이터 레이크(Data Lake)

• 데이터 레이크 기반 시스템은 데이터를 바로 분석 모델로 변환하는 대신 원본 형태, 즉, 원래의 실시간 데이터 모델로 보관한다.
• 데이터 엔지니어와 BI 엔지니어는 데이터 레이크의 데이터를 이해하고 분석 모델을 생성하는 ETL 스크립트를 구현하며, 이를 데이터 웨어하우스에 제공해야 한다.
• 데이터 레이크에서는 실시간 데이터 처리 시스템의 데이터는 원본 형태로 저장되고 나중에 변환되므로 여러 가지 작업 지향 분석 모델을 작동시키는 것이 가능하다.
• 데이터 레이크에 유입되는 데이터는 스키마를 강제하지 않는 무(無)스키마이며, 수신 데이터의 품질을 제어하지 않는다.
  • 데이터 레이크를 사용하면 데이터를 쉽게 수집할 수 있지만 사용하기는 훨씬 더 어렵다.

데이터 웨어하우스와 데이터 레이크 아키텍처의 도전과제(Challenges of Data Warehouse and Data Lake Architectures)

• 데이터 웨어하우스와 데이터 레이크 아키텍처는 둘 다 동일한 가정에 기반한다.
  • 분석을 위한 더 많은 데이터를 유입하면 조직은 더 많은 통찰력을 얻는다.
  • 두 접근 방법 모두 데이터의 ‘방대한 규모’에 대한 무게로 인해 유명무실해지는 경향이 있다.
• 모델링 관점에서 보면 두 아키텍처 모두 실시간 데이터 처리 시스템이 경계를 침범해서 구현 상세에 대한 의존성을 생성한다.
• 데이터 분석가와 데이터 엔지니어는 다른 조직에 소속되므로 실시간 데이터 처리 시스템의 개발 팀이 소유한 비즈니스 도메인에 대한 깊이 있는 지식이 부족하다.
• 구현 모델의 결합은 비즈니스 도메인의 모델을 지속해서 개선하고 발전하는 것을 강조하는 도메인 주도 설계 기반의 프로젝트에서 특히 심하다. 실시간 데이터 모델에 대한 변경은 분석 모델에 예측할 수 없는 결과를 만든다.

데이터 메시(Data Mesh)

• 데이터 메시 아키텍처는 분석 데이터를 위한 도메인 주도 설계라고 볼 수 있다.
• 데이터 메시 아키텍처는 분석 데이터에 대한 모델과 수유 경계를 정의하고 프로젝션한다.
• 데이터 메시 아키텍처는 도메인 기준의 데이터 분리, 제품 관점에서 데이터 다루기(data as a product), 자율성 활성화, 에코시스템 구축의 네 가지 핵심 원칙을 기반으로 한다.

도메인 기준의 데이터 분리(Decompose Data Around Domains)

• 데이터 웨어하우스와 데이터 레이크의 접근 방식은 모두 엔터프라이즈의 모든 데이터를 하나의 큰 모델로 통합하는 것이 목표다.
• 데이터 메시 아키텍처는 모놀리식 분석 모델을 구축하는 대신, 원천 데이터에 분석 모델을 일치시켜서 데이터를 사용하므로 여러 분석 모델을 사용할 수 있다.
• 분석 모델의 소유권 경계를 자연스럽게 바운디드 컨텍스트의 경계와 일치시키게 된다.
• 각 바운디드 컨텍스트는 이제 자신의 실시간 데이터 처리(OLTP) 모델과 분석(OLAP) 모델을 소유한다.
  • 실시간 데이터 모델을 소유한 팀이 그것을 분석 모델로 변환하는 책임을 진다.

제품 관점에서 데이터 다루기(Data as a Product)

• 제품 관점에서 데이터 다루기 원칙에서는 분석 데이터를 제일 중요하게 다뤄야 한다.
• 데이터 메시 기반 시스템에서는 바운디드 컨텍스트가 잘 정의된 출력 포트를 통해 분석 데이터를 제공한다.
• 분석 데이터는 통상적인 퍼블릭 API와 동일하게 취급돼야 한다.
  • 필요한 엔트포인트인 데이터 출력 포트를 쉽게 찾을 수 있어야 한다.
  • 분석 엔드포인트는 제공하는 데이터와 형식을 설명하는 잘 정의된 스키마를 자져야 한다.
  • 분석 데이터는 신뢰할 수 있어야 하고 다른 API와 마찬가지로 서비스 수준 계약(SLA: service-level agreement)을 정의하고 모니터링해야 한다.
  • 문석 모델은 일반적인 API처럼 버전 관리를 하고 그에 따라 모델에서 연동을 방가뜨리는 변경을 관리해야 한다.
• 분석 데이터는 제품 관점에서 제공되므로 사용자의 요구를 반영해야 한다.
  • 데이터 메시는 데이터 웨어하우스 및 데이터 레이크 아키텍처와는 대조적으로 데이터 품질에 대한 책임이 가장 중요한 관심사다.
• 분산 데이터 관리 아키텍처의 목표는 조직의 데이터 분석 요건을 충족할 수 있도록 작은 크기의 분석 모델이 엮일수 있게 하는 것이다.
• 사용자마다 여러 형태의 분석 데이터가 필요할 수도 있다.
  • 데이터 제품은 다양한 사용자의 요구사항을 충족하는 여러 형태의 데이터를 제공하도록 다양한 언어를 제공해야 한다.
• 전통적으로 제품 팀에 실시간 데이터 처리 시스템 관련 전문가만 포함했지만, 데이터를 제품 관점의 원칙에서 구현하려면 데이터 지향 전문가가 필요하다.

자율성 활성화(Enable Autonomy)

• 제품 팀은 자신의 데이터 제품을 만들 수도 있고 다른 바운디드 컨텍스트에서 제공하는 데이터 제품도 사용할 수 있어야 한다.
• 바운디드 컨텍스트에서와 마찬가지로, 데이터 제품은 상호운용이 가능해샤 한다.
• 이 같은 플랫폼을 설계하고 구축하려면 상당한 노력과 전담 데이터 인프라스트럭처 플랫폼 팀이 필요하다.
• 데이터 인프라스트럭처 플랫폼 팀은 데이터 제품의 청사진, 단일화된 접근 패턴, 접근 제어, 그리고 제품 팀이 사용할 다양한 저장소를 정의해야 할 뿐만 아니라 플랫폼을 모니터링해서 SLA와 목적을 만족하는지 보장할 책임이 있다.

에코시스템 구축(Build an Ecosystem)

• 데이터 메시 시스템을 만드는 마지막 단계는 분석 데이터 도메인 관점에서 상호운용과 에코시스템을 가능하게 할 연합 거버넌스 기구를 임명하는 것이다.
  • 바운디드 컨텍스트의 데이터 및 제품 소유자, 그리고 데이터 인프라스트럭처 플랫폼 팀의 대표로 구성되는 그룹이다.
  • 거버넌스 그룹은 상호운용이 가능한 정상적인 에코시스템을 보장하는 규칙을 정의할 책임이 있다.
  • 이 규칙은 모든 데이터 제품과 그 인터페이스에 적용돼야 하고, 거버넌스 그룹은 전사적으로 이 규칙을 따르도록 보장할 책임이 있다.

데이터 메시와 도메인 주도 설계를 엮기(Combining Data Mesh and Domain-Driven Design)

• 일부 도메인 주도 설계 패턴은 데이터 메시 아키텍처를 구현하는 데 상당한 도움을 줄 수 있다.
• 데이터 메시 아키텍처가 기반으로 하는 네 가지 원칙
  • 유비쿼터스 언어와 결과 도메인 지식은 분석 모델 설계를 위한 필수 요소다.
  • 자신의 실시간 데이터 모델과 다른 모델로 바운디드 컨텍스트 데이터를 노출하는 것은 오픈 호스트 패턴이다.
  • CQRS 패턴은 동일한 데이터에 대한 여러 모델을 쉽게 생성하게 해준다.
  • 데이터 메시 아키텍처는 분석 유스케이스를 구현하기 위해 다양한 바운디드 컨텍스트의 모델을 묶기 때문에 실시간 데이터 모델을 위한 바운디드 컨텍스트의 연동 패턴은 분석 모델에도 적용된다.
    • 서로 다른 제품을 담당하는 두 팀은 파트너십 패턴을 적용해서 각자의 분석 모델을 발전시킬 수 있다.

결론(Conclusion)

• 데이터 메시 아키텍처는 전통적인 데이터 관리 아키텍처의 어려움을 해결하는 데 목적이 있다.
• 이 아키텍처의 중심에는 도메인 주도 설계와 동일한 원칙이 적용된다.
  • 분석 모델을 관리 가능한 단위로 분해하고 자체 퍼블릭 인터페이스를 통해 분석 데이터에 안정적으로 접근하고 사용하도록 보장한다.
  • CQRS와 바운디드 컨텍스트 연동 패턴은 데이터 메시 아키텍처의 구현을 지원한다.