Data Infrastructure Patterns
대규모 데이터 시스템의 반복되는 아키텍처 패턴과 트레이드오프
개요
데이터 인프라는 반복되는 아키텍처 패턴의 조합이다. 각 패턴은 특정 문제를 해결하지만 고유한 트레이드오프를 수반한다.
데이터 이동과 변환
| 패턴 | 핵심 문제 | 대표 사례 |
|---|---|---|
| Change Data Capture | 풀 테이블 복사의 비효율성 | Debezium + Postgres WAL |
| Transactional Outbox Pattern | DB 트랜잭션과 메시지 발행의 원자성 | Zapier SQLite 샤딩 |
| Medallion Architecture | 원시→정제→비즈니스 데이터의 계층화 | Bronze/Silver/Gold |
| Semantic Layer | 데이터와 비즈니스 의미의 연결 | Context Store, ECL 프레임워크, Context Architect |
쿼리 실행과 최적화
| 패턴 | 핵심 문제 | 대표 사례 |
|---|---|---|
| Query Optimization | 쿼리 비용 절감과 라우팅 | PostgreSQL Portable Stats, Trino Gateway |
| Query Proxy | 서비스·에이전트의 분석 백엔드 통합 접근 | gRPC + Parquet, Hot/Warm 페더레이션 |
| DuckDB | 개발 환경 웨어하우스 비용 절감, FTS, MySQL HTAP | SQL 트랜스파일링, DuckLake, AliSQL DuckDB 엔진 |
| Spark at Scale | 대규모 분산 처리 운영 | Informatica Spark++, S3 Shuffle |
실시간 처리
| 패턴 | 핵심 문제 | 대표 사례 |
|---|---|---|
| Real-Time Stream Processing | 저지연 이벤트 처리 | Spark Real-Time, Volga, Flink Materialized Tables |
| Feature Store | ML 피처의 일관된 계산과 서빙 | Volga Request Mode, Pinterest Feature Trimmer |
| Data Sketches | 대규모 근사 집계 | HyperLogLog, Theta, KLL 스케치 |
| Stream vs OLAP 경계 | 계산 경계 분리 | Flink(push) vs ClickHouse/Pinot(pull) |
데이터 통합과 거버넌스
| 패턴 | 핵심 문제 | 대표 사례 |
|---|---|---|
| 통합 인테그레이션 | 이기종 파트너 시스템 간 데이터 동기화 | LinkedIn BuildIn/BuildOut + Temporal |
| 통합 인제스천 플랫폼 | 다중 플랫폼 온보딩 파편화 | Grab Hugo (Flink CDC, 4→2 컴포넌트, 며칠→수 분) |
| LLM 기반 거버넌스 | 스키마 진화에 대응하는 PII 자동 분류 | Databricks LogSentinel |
| Knowledge Representation | 데이터에 구조적 의미 부여 | 온톨로지, 컨텍스트 그래프 |
| Knowledge Graph Infrastructure | 대규모 그래프 저장·다중 hop 순회 | Airbnb JanusGraph+DynamoDB, Uber graph-aware transformer |
스토리지 진화
| 패턴 | 핵심 문제 | 대표 사례 |
|---|---|---|
| Object Storage Evolution | 멀티모달 데이터 접근 | S3 Tables, S3 Vectors, S3 Files |
| Catalog-Managed Tables | 파일시스템 경로 의존성 | Delta Lake 4.1 + Unity Catalog, Catalog Commits GA |
메시지 큐 및 스트리밍
| 패턴 | 핵심 문제 | 대표 사례 |
|---|---|---|
| Real-Time Stream Processing | S3 기반 Kafka 대체 | AutoMQ (무상태 브로커, 공유 스토리지) |
| Kafka 컨슈머 관리 | 파티션 관리 복잡성 | Uber uForwarder (gRPC Push 프록시) |
| Kafka 리밸런스 | 글로벌 동기화 장벽 | KIP-848 (서버 사이드 점진적 할당) |
| Kafka 성능 벤치마킹 | 재현·공유 가능한 차원 테스트 | Dimster (Run/Explore/Drain/Correctness, K8s 런타임) |
| 실시간 Upsert | append-only 스토리지 버전 누적 | Apache Pinot SegmentRefreshTask |
| Interval-Aware 캐싱 | 롤링 윈도우 반복 쿼리 | Netflix Druid 프록시 (82% 캐시 히트) |
데이터 품질
| 패턴 | 핵심 문제 | 대표 사례 |
|---|---|---|
| Data Quality and Validation | 다계층 데이터 검증 | Netflix Data Canary, Halodoc 4계층 |
| Data Contracts | 생산자-소비자 품질 합의 | 50개 프로덕션 구현 분석 |
실행 엔진과 동시성
| 패턴 | 핵심 문제 | 대표 사례 |
|---|---|---|
| Columnar Execution Engine | JVM 오버헤드 우회 | Velox + Gluten, Microsoft Fabric |
| Database Concurrency Control | 고동시성 인덱스 운영 | PostgreSQL Blink-tree |
| Distributed Systems Reliability | 조용한 장애 방지 | ClickHouse 분산 큐, Pinterest 쿼터 |
| Spot Instance Management | 비용-신뢰성 균형 | Karpenter, Spark on Spot |
파이프라인 기초 패턴
| 패턴 | 핵심 문제 | 대표 사례 |
|---|---|---|
| Data Pipeline Fundamentals | 파이프라인 유형·로딩 전략·백필 | SeattleDataGuy 시리즈 |
| Full Refresh vs Incremental | 비용-구현 난이도 트레이드오프 | WAP 패턴, dbt materialization |
| 소스 표준화 | 이기종 데이터 통합 | SFTP/API 멀티소스 매핑 |
| 데이터 스택 복잡성 | 레이어·도구 스프롤 | 37+ 도구 스택, 프랙탈 시스템 |
공통 교훈
- 단순한 것부터: 복잡한 아키텍처보다 경계와 운영 규율이 중요
- 비용 인지: S3 API 비용, 웨어하우스 컴퓨트 비용 등 숨겨진 비용 관리
- 통합 엔진 추세: 스트리밍/배치/서빙을 단일 엔진으로 통합하려는 움직임
- CDC 기반 인제스천: 풀 테이블 복사에서 변경분만 캡처하는 통합 프레임워크로 전환
- 레이어 추가 전 검증: 문제 정의, 미추가 시 영향, 6개월 후 소유권의 3가지 질문
분산 데이터 소유권
| 패턴 | 핵심 문제 | 대표 사례 |
|---|---|---|
| Data Mesh and Federation | 모놀리식 DWH의 확장성 한계 | Uber Hive Federation, Monzo dbt Interfaces, Grab Signals Marketplace, Airbnb Viaduct |
| Large-Scale Data Migration | 대규모 시스템 전환의 안전한 실행 | Meta Shadow/Reverse-Shadow, Netflix Like-for-Like + Decider 패턴 |
| Self-Healing Pipelines | 파이프라인 자동 복구 | Halodoc 6-레이어 아키텍처 |
| ML Metadata and Discovery | ML 자산 통합 발견 | Netflix Model Lifecycle Graph |
| Airflow DAG Bundles | 팀별 DAG 배포의 Helm 의존성 | S3 번들 + 사이드카 (30초 핫 리로드) |
| YuniKorn 스케줄링 | K8s 기본 스케줄러의 Spark 조정 부재 | Halodoc gang scheduling + 계층 큐 + bin packing |
dew_277~286 — 조율·복구·경계 번역
조율 단위를 저장 단위에서 떼어내기
이번 묶음의 가장 반복적인 패턴이다 — 물리 레이아웃을 건드리지 않고 메타데이터 레이어에서 해결한다.
| 패턴 | 문제 | 조작 대상 |
|---|---|---|
| Compaction Conflict Resolution | compaction이 논리적 noop인데 동시 트랜잭션을 무효화 | position delete vector를 remap |
| Control Plane Cardinality | 세그먼트 100만+에서 Helix/ZK가 병목 | 조율 단위만 100배 확대 |
| Object-Storage-Native WAL | 로그 durability를 위해 디스크 fleet 운영 | conditional write로 조율을 스토리지에 위임 |
| DuckLake (CDC 타깃) | 작은 커밋마다 레이크 메타데이터 폭증 | 카탈로그 위치(오브젝트 스토어 파일 → DB) |
경계에서 번역하기 (translate at the boundary)
Lyft의 Flink operator 이관이 이 패턴의 교과서적 사례다. 전체 시스템이 레거시 FlinkApplication CRD 중심으로 지어져 있어 모든 라이브러리와 앱 오버레이를 다시 쓰는 것은 거대하고 위험했다.
→ deploy API 안에서 FlinkApplication → FlinkDeployment로 번역해 팀들이 늘 하던 대로 애플리케이션을 계속 정의하게 했다. 동적 설정으로 앱 단위 점진 이관과 즉시 롤백. “개발자에게 변화는 대체로 보이지 않았다.”
⚠️ 다만 번역 레이어가 끝이 아니다. “번역 레이어가 Apache operator 위에 올려놨지만 마이그레이션은 아직 끝나지 않았다” — 진짜 이득(오토스케일링·오토튜닝)을 얻는 후속 작업이 그 뒤에 있었다.
자동화가 인접 시스템을 깨뜨린다
Lyft 사례에서 가장 일반화 가능한 교훈:
- 오토튜닝이 Beam의 Python harness 메모리 hack을 회수해 fleet 전반을 OOM-kill했다 (JVM overhead에 몇 년간 숨겨둔 예약분). → harness를 sidecar로 분리
- 오토튜닝과 in-place 오토스케일링이 상충한다(튜닝은 재시작을 요구). → 2-tier 정책 — 비즈니스 크리티컬은 in-place 오토스케일링만, 나머지는 둘 다
- 오토튜닝이 정적 노드 풀의 CPU:메모리 비율 가정을 깨뜨렸다 → Karpenter로 on-demand 프로비저닝
하나의 자동화가 그 아래 계층의 암묵적 가정을 드러낸다는 것이 공통 구조다.
인시던트를 워크플로로
Data Incident Operations — Grab의 DPI. Self-Healing Pipelines가 복구 메커니즘이라면 DPI는 인시던트 운영 모델 (triage → RCA → 오너 라우팅 → auto-heal → 검증 → 자동 종료). workflow-per-job으로 blast radius를 격리하는 Stream Autoscaling의 Temporal 설계와 같은 본능이다.
스택 진화 지도
Open Source Data Stack, Declarative Data Engineering, Consensus Engineering — 명령형 → 선언형, 그리고 분석 생산 비용이 0이 되면서 희소 자원이 consensus로 이동한다는 관점.
관련 토픽
- Cost and Efficiency — 재플랫폼과 비용 곡선
- Storage and Compute Architecture — 스토리지·실행 엔진 층 상세
- Semantic and Ontology Stack — 의미 아티팩트 층
- Data Reliability and Trust — 신뢰성·인시던트 운영
- Evaluation and Measurement — 인프라 선택을 벤치마크로 검증하기
관련 이슈: DEW #256, #257, #258, #261, #262, #263, #264, #265, #267, #268, #269, #270, #271, #277, #283, #284, #285, #286 | SeattleDataGuy 시리즈 | ByteByteGo