통합적인 관점에 기반한 온프레미스 데이터 플랫폼 구조 비교분석

이 글의 원문은 11번가 데이터 플랫폼 팀에서 데이터 엔지니어로 근무(20190923 ~ 20201115)하며 사내 블로그에 작성한 '통합적인 관점에 기반한 11번가 온프레미스 데이터 플랫폼 구조 비교분석'입니다. 온프레미스 데이터 플랫폼을 운영하시는 분들에게 도움이 되기 위해 11번가와 연관된 정보를 제외하고 게시하였습니다.

---

들어가기 전에

'온프레미스' 데이터 플랫폼은 다양한 인하우스 애플리케이션과 분사 등 독특한 역사를 가지고 있습니다. 클라우드 데이터 플랫폼 사용 시에는 많은 공유 세션과 다수의 클라우드 데이터 플랫폼 디자인 패턴 등을 통해 비교적 쉽게 통합적인 관점을 구상해 낼 수 있는 반면, 현시점에서 그러한 역사가 반영된 데이터 플랫폼에 대한 통합적이고 일관된 관점이 부재합니다.

이러한 '통합적이고 일관된 관점'에 대한 부재로 팀원은 각자 운영하고 있는 서비스 중심으로 이해한 데이터 플랫폼에 대한 관점을 가지고 다른 팀원과 커뮤니케이션하기에 생각을 일치시키는 데에 많은 비용이 소모되고 있습니다. 또한, 외부의 다양한 데이터 플랫폼 구조를 일관된 관점으로 데이터 플랫폼과 비교분석하여 인사이트를 얻어내는 데에 어려움을 겪거나 국소적인 컴포넌트 비교에만 머물고 있습니다.

이 글에서는 온프레미스 데이터 플랫폼'에 대해 6-Layered 클라우드 데이터 플랫폼 아키텍쳐를 변형하여 일관된 관점을 제공하고, 분산 데이터 메쉬(Distributed Data Mesh)에서 나온 Data Platform(원본 - Infra) Team의 역할 (또는 다른 좋은글 참고)을 적용하여 비교분석을 진행함과 동시에 비교분석의 기준을 제시하려고 합니다.

온프레미스 데이터 플랫폼에 대한 통합적인 관점

비교분석 시, 처음 발생하는 질문은 "무엇과 비교를 해야 하는가?"입니다. 이 부분을 결정하기 위해서는 분석 대상이 어디에 속하며 어떤 것과 유사하여 비교해볼 수 있는지를 알아야 합니다. 다음으로 발생하는 질문은 "어떤 기준을 통하여 비교를 해야 하는가?"입니다. 어떠한 기준을 통해서 유사한 대상들을 비교할 수 있어야, 어떤 부분이 개선 가능하고 어떤 부분이 충분히 고도화되어 있는지를 알 수 있습니다.

이번 장에서는 온프레미스 환경에 맞게 변형한 6-Layered 데이터 플랫폼 아키텍쳐를 통해 무엇과 비교해야 되는지에 대한 아키텍쳐 뷰를 설명하고, 분산 데이터 메쉬 환경에서의 데이터 플랫폼 팀의 역할을 통해 어떠한 기준을 통해 유사한 대상들을 비교할 수 있는지 알아봅니다.

 

6-Layered 데이터 플랫폼 구조

먼저, 6-Layered 데이터 플랫폼 구조는 아래의 이미지와 같이 6개의 레이어(Ingestion, Storage, Processing, Metadata, Governance, Serving)으로 구성됩니다. 다른 많은 데이터 구조와 구분되는 특성은(뒤에서도 언급되겠지만), 앞의 5레이어 모두가 마지막의 Serving 레이어에서 데이터 플랫폼 사용자(데이터 오너, 데이터 사용자)에게 최대한의 self-service가 가능해야 한다는 사실입니다. 이어서 각 레이어의 특성을 살펴보고, 각 레이어에 해당되는 특정 기능을 가진 컴포넌트를 알아보겠습니다.

 

| Self-Service 관점에서의 데이터 플랫폼 구조에서는 Data Lake와 같이 Domain-Specific한 개념은 제외됩니다.

• Ingestion 레이어는 데이터를 Source에서 그대로(또는 기본적인 Encryption만 적용하여) 가져오는 부분을 일컬읍니다. 크게 Batch와 Streaming으로 구분되어 전형적인(아직..) Lambda 아키텍쳐에 기반하고 있습니다. 또한, push와 pull로 ingest의 실행이 어느 부분에서 시작되는지 표시하였습니다.
• Storage 레이어는 데이터를 영속적으로(persistent) 저장하는 부분을 담당합니다. Ingestion 레이어는 데이터를 영속적이지 않게 보관하므로(Cache 등), 추후 넓은 범위의 데이터 사용을 위해 이러한 레이어가 필요합니다. Persistent Storage는 Computing과 완전히 분리를 지향합니다.
• Processing 레이어는 데이터를 변형(Transform)하여 저장하거나, 바로 사용(Ad-hoc)하기 위해 제공되는 부분입니다. 
• Metadata 레이어는 '데이터에 관한 데이터'의 역할을 하며 데이터에 대한 정보를 일정하게 형식화하여 사용 및 관리 시 일관된 추상화를 제공합니다.
• Governance 레이어는 데이터 관리와 그것을 통해 최종적으로 데이터 라이프사이클 전체 과정에서 높은 데이터 품질을 보장하기 위한 활동을 담당합니다. 그것은 GDPR과 같은 정보보호규정을 준수하거나 데이터 플랫폼 사용자에게 높은 품질의 데이터 플랫폼 서비스를 제공하기 위해서 입니다.
• Serving 레이어는 앞의 5가지 레이어를 self-service 형태(또는 데이터 플랫폼 운영자의 최소한의 처리만으로)로 접근할 수 있는 서비스를 제공하는 부분입니다. 각 레이어와의 관계와 예시는 대략적으로 아래와 같습니다:
  • to Ingestion: 데이터 입수(Ingestion) 정보는 데이터 사용자의 요구사항에 따라 CRUD 될 수 있어야 합니다. 하나의 데이터 입수에 대한 정보는 데이터가 어디서, 어디로, 무엇을, 어떻게, 어떤 형태로, 어떤 주기로 입수되는지에 관한 정보를 가지며, 입수는 이 정보를 바탕으로 실행됩니다.
  • to Storage: 데이터 저장을 제공하는 데이터 저장소(Storage)는 적용된 권한에 맞게 접근가능하여야 합니다. 최종적으로 서빙 레이어의 서비스에서 직접 접근만이 아니라, 입수 및 프로세싱 등의 레이어를 통해서도 권한에 맞는 접근이 가능해야 합니다. 또한, 데이터 라이프 사이클 관리와 같은 추가 기능을 제공합니다.
  • to Processing: 다양한 실행 주기, 엔진 등의 데이터 처리가 제공되며 데이터 처리를 관리하기 위한 스케쥴러와 같은 서비스도 제공합니다.
  • to Metadata: 다양한 데이터에 관한 데이터가 제공, 검색될 수 있어야 합니다. 데이터에 관한 데이터는 단순한 구조, 파일타입, 명칭 등에서부터 데이터 리니지, 프로파일, 검증결과 등까지 넓은 범위를 가집니다. 또한, 메타데이터 라이프사이클 등의 추가 관리 기능을 제공합니다. 
  • to Governance: 다양한 거버넌스 서비스에 적용된 권한에 맞게 접근할 수 있어야 합니다. 그러한 거버넌스 서비스로는 각 레이어를 구성하는 서비스에 대한 모니터링, 개인정보 규정 준수 여부 모니터링, 데이터 품질 검증 서비스 등이 있습니다.

 

728x90

분산 데이터 메쉬 환경에서의 데이터 플랫폼 팀의 역할로 본 비교기준

데이터는 어디에나 존재하고 분산되어 있습니다(Embrace the reality of ever present, ubiquitous and distributed nature of data). 그렇기에 서비스의 규모가 점점 커지고, Monolith에서 Microservice로 변화해갈 수록 하나의 전문화된 Monolith 데이터 팀이 여러 기능 도메인(Cross-Functional Domain)의 데이터 제공자(source team)과 데이터 사용자의 요구사항과 데이터를 직접 처리하게된다면 병목이 발생하거나 다른 팀과 긴밀히 협업하지 못하는(Siloed) 상황을 만들게 됩니다(아래 이미지).  

그렇기에 데이터의 소유와 처리는 데이터 오너(기존의 데이터 제공자)와 데이터 사용자에게 분산되어 주어져야 합니다(아래 이미지).

 

이러한 환경에서 데이터 파이프라인을 구축하는 데에 드는 중복의 노력과 기술은 플랫폼으로 인프라를 구축하면서 해결할 수 있습니다. 이러한 플랫폼을 구축하는 관점에서 데이터 플랫폼의 역할은 아래의 2가지 주요 역할을 가지며 그것을 통해 얻을 수 있는 기준은 다음과 같습니다:

• domain 독립성 - 특정 domain에 종속되지 않는 Platform을 제공 to not include any domain specific concepts or business logic, keeping it domain agnostic
• Self-Service화 정도: 데이터 인프라 컴포넌트의 복잡성을 감추면서 Self-Service가 가능한 형태로 제공 make sure the platform hides all the underlying complexity and provides the data infrastructure components in a self-service manner

 

 

Domain 독립성 - 특정 domain에 종속되지 않는 Infra를 제공

제공되는 데이터 플랫폼은 음악 플레이 기능, 상품추천, 주문 등 해당 기업에 존재하며 데이터 플랫폼과 연계된 특정 Domain에 종속되지 않아야 합니다. 데이터 플랫폼이 특정 Domain에 종속된다면, 그것은 데이터 플랫폼이 플랫폼의 역할을 벗어나 다시 하나의 Monolith 데이터 팀으로 회귀하여 다른 Domain과의 Silo를 키워가고 있음을 의미합니다. 그렇기에 'Domain 독립성'이라는 기준을 통해 평가하고 검토해볼 수 있습니다. Domain 독립성은 주로 대상 플랫폼 사용자를 선정하고, 플랫폼 사용자의 요구사항을 반영하는 부분에 해당된다는 점에서 (기능적인 요소가 많은) Self-Service화 정도와 다릅니다. 관련한 질문은 다음과 같습니다:

• 플랫폼 사용자(데이터 오너 또는 데이터 사용자)에 대한 정의가 모든 부서와 Domain을 포괄하는가?
• 플랫폼 사용자의 요구사항이 특정 부서나 특정 Domain에서만 국한되어 발생하지는 않는가?
• 플랫폼 사용자 요구사항의 반영이 특정 부서나 특정 Domain에 치우쳐져 있지는 않는가?

위와 같은 질문을 통해 플랫폼이 특정 부서나 특정 Domain에 매몰되는 것을 벗어나, 독립적이고 전사적으로 범용가능한 데이터 플랫폼으로 발전하기 위한 판단의 기준을 확보할 수 있습니다.

 

Self-Service화 정도: 데이터 인프라 컴포넌트의 복잡성을 감추면서 Self-Service가 가능한 형태로 제공

'Self-Service화 정도'라고 한다면 보통 온디맨드로 온프레미스보다 월등히 '높은' Self-Service화를 제공하는 클라우드 환경에서 제공되는 서비스들을 기준으로 생각하기가 쉬울 듯 합니다. 하지만, 무조건적인 Self-Service화라는 부분 이전에 '컴포넌트의 복잡성을 감추는'이라는 점을 명심해야 합니다. 컴포넌트의 복잡성을 높이는 Self-Service는 굳이 필요하지 않은 오버엔지니어링일 수 있기 때문입니다(이점에서 복잡성을 감추는 것이 Self-Service화를 높이는 것보다 중요합니다). 그렇기에 Self-Service화 정도의 평가는 Context에 기반한 적절한 Self-Service화 정도의 산정 이후에 Self-Service화 정도 평가로 아래와 같이 이뤄집니다:

적절한 Self-Service화 정도의 산정		Ingestion 레이어에서 데이터 사용자는 송신되고 있는 ClickStream 데이터, 운영 DB, 서버 로그를 제한된 컴퓨팅 리소스에 작업을 추가하여 Stream 또는 Batch 주기로 공용 HDFS Storage에 입수할 수 있어야 하고 입수 구성의 모든 제반사항은 Self-Service가 가능하며  데이터 운영자 측에서의 최종 확인만으로 입수가 실행될 수 있어야 함
현재의 Self-Service화 정도의 평가		항목별 평가 입수 레이어: 데이터 운영자 측의 교육 및 공유 또는 기능의 구현(필요하다면)을 통해, 더욱 Self-Service화된 데이터 입수를 제공할 수 있음

 

 

 

통합적인 관점에 기반한 현재의 데이터 플랫폼 분석 및 사외 서비스 비교검토

위에서 기술한 'Domain 독립성'과 'Self-Service화 정도'라는 2가지 기준을 통해 현재의데이터 플랫폼을 레이어별로 각 레이어에 속하는 컴포넌트들의 기능과 해당 기능을 담당하는 서비스를 분석합니다.

또한, 산정된 Self-Service화 정도가 유사하고 각 레이어의 컴포넌트 기능이 비슷한 사외 서비스를 선정하고 비교검토 합니다(각 환경에 맞게 빈 칸을 채워넣어야 합니다).

그 내용을 요약하면 아래 표와 같습니다:

 

Layer	Domain 독립성	적절한 Self-Service화 정도의 산정	현재의 Self-Service화 정도의 평가	컴포넌트의 기능	사내 서비스	유사한 사외 서비스
Ingestion				Clickstream Tracking		Mixpanel Segment IO Google Analytic.js AWS Kinesis SDK
				Log Collecting		Apache Flume FluentBit Fluentd Chukwa Google Dapper
				Batch Data Movement		Apache Sqoop Apache Gobblin Embulk Spark, Presto 등을 사용 Google Transfer Service AWS DB to S3
				Stream Data Movement		Apache Flink Apache Storm Apache Samza Spark Streaming AWS Kinesis Firehose Google Millwheel
Storage				Buffer Storage		Apache Kafka Apache Pulsar AWS Kinesis Google Pub/Sub Facebook Scribe
				Persistent Storage		Google File System HDFS GlusterFS Ceph IBM GPFS AWS S3 Google Cloud Storage Microsoft Azure Storage
				In-Memory		Apache Ignite
				OLAP(HTAP) DBMS		Apache Druid Apache Kudu Redis Hbase AWS Redshift Google Bigtable Huawei FusionInsight LibrA
				Feature Store		Hopsworks Feature Store 다양한 Feature Store들
Processing				Stream		Ingestion 레이어의 Stream Data Movement와 동일함
				Batch & Interactive		Mapreduce Apache Tez Apache Spark Prestodb Apache Pinot Apache Drill Dremio Google Dremel
Metadata				Catalog & Transaction Management		Apache Hive AWS Glue Catalog Databricks Delta Lake Apache Hudi
				ML Management		Databricks MLFlow Kubeflow Apache Submarine
Governance				Data Security		Apache Ranger Apache Sentry LDAP
				Profile & Quality Check		AWS Deequ Apache Griffin Profiler
				Object Lifecycle Management		AWS S3 Object Lifecycle
Serving				Ingestion Management		Uber Marmaray
				Data Pipeline Orchestration		Apache Oozie Apache Airflow Apache Nifi Streamsets Prefect
				Monitoring		Apache Ambari Sematext Datadog
				Alerting		사내 메시저에 종속적임
				Web-Based Interactive Data Analytic		Jupyter Apache Zeppelin RStudio Apache Superset Google Looker Uber Kepler
				Metadata Management		Lyft Amundsen Apache Atlas
				Knowledge Share		Airbnb Knowledge Repo
				A/B Testing		Google Optimize Cucumber

| 컴포넌트의 기능은 책 The Self-Service Data Roadmap의 내용을 중심으로 기술하였습니다.

 

이후 진행해야할 활동

이후 진행해야할 활동은 위의 비교검토에 작성한 내용을 토대로 각 레이어별로 도출해낼 수 있습니다. 아래 주요 3가지 경우에 따라 나누어집니다:

• 도메인 종속성이 높은 경우: 해당 컴포넌트가 가지는 추상화된 핵심 기능을 뽑아내어 모든 도메인을 대상으로 적용될 수 있도록 일반화합니다.
• 평가된 Self-Service화 정도가 산정된 것보다 낮을 때: 합의를 통해 산정한 결과를 토대로 유사한 사외 서비스에서 차용할 부분을 없는지 검토하고 기능과 업무 프로세스를 재정립합니다.
• 평가된 Self-Service화 정도가 산정된 것보다 높을 때: 제공된 기능보다 한 단계 추상화된 기능을 제공하여 온디맨드 형태로 각 요구사항에 맞게 제공될 수 없는지 검토하고 기능과 업무 프로세스를 재정립합니다.
  • 예) Superset, Jupyter, Metabase 등 다양한 웹 기반 분석 툴을 직접 제공하는 것에서 원하는 이미지로 Kubernetes 컨테이너를 생성하고 다른 레이어에 일정한 API로 연결할 수 있는 가이드를 만드는 것으로 업무의 목표를 재정의합니다.

 

Reference

• Technical Facts
  • Architecting Modern Data Platforms
• ML Ops 
  • Machine Learning Design Patterns
  • Google MLOps
• Log Collecting
  • I Hearts Log
  • The Mystery Machine: End-to-end Performance Analysis of Large-scale Internet Services
• Data Quality
  • Competing with High Quality Data: Concepts, Tools, and Techniques for Building a Successful Approach to Data Quality
• A/B Testing
  • The Anatomy of a Large-Scale Online Experimentation Platform  
  • Overlapping Experiment Infrastructure: More, Better, Faster Experimentation