데이터 규모와 아키텍처

학습 목표

volume·velocity·variety로 OLTP 한계와 분석·ML 경로 분리 필요를 판단할 수 있다.

scale-up과 scale-out을 RDB·Kafka·Spark·object storage 관점에서 비교할 수 있다.

ingest · process · store · serve 역할 분리로 파이프라인을 설계할 수 있다.

중앙 데이터 플랫폼과 data mesh의 트레이드오프를 개요 수준에서 설명할 수 있다.

문제 상황

• 일일 2억 행 클릭 로그를 PostgreSQL에 INSERT — WAL·디스크 포화, OLTP 지연 폭증
• 야간 SELECT 리포트가 주문 API와 같은 DB — 피크에 lock·I/O 경합
• “서버 스펙만 올리자” — 64 vCPU까지 갔는데 쓰기 TPS 천장, 비용만 증가
• Kafka·Spark 도입했지만 한 팀이 전 도메인 파이프라인 담당 — 병목·SLA 미스
• 데이터 레이크에 파일만 쌓음 — 누가 주문 데이터를 소유하는지·계약이 없음
• Architecture에서 scale-out은 봤지만 — 데이터 워크로드마다 선택이 다른 이유를 모름

오리엔테이션에서 source → infer 흐름을 봤다. 이번 편은 왜 그 경로를 분리하고 어떻게 늘리는지 — 규모·역할·조직 축이다. batch vs stream 선택은 다음 편.

1. 규모를 나누는 축

데이터 시스템은 한 번에 커지지 않는다. 세 축이 겹칠 때 OLTP·단일 cron만으로는 부족해진다.

축	질문	흔한 신호
Volume	얼마나 많은 데이터?	TB·PB, 파티션·보관 연수
Velocity	얼마나 빠르게 들어오나?	초당 이벤트·CDC lag
Variety	형태가 얼마나 다양한가?	JSON·로그·이미지·스키마 drift

Volume   — 500GB/일 이벤트, 3년 보관 → ~500TB raw
Velocity — 피크 80k events/s, end-to-end < 5 min (스트림 집계)
Variety  — 앱 이벤트 + RDB CDC + S3 export, 필드 추가 매주

• Volume만 크면 — 배치·압축·tiered storage로 버티는 경우도 있음
• Velocity가 크면 — 버퍼·스트림 (Kafka) 없이는 소스 DB가 먼저 죽음
• Variety가 크면 — 스키마·품질·계보 (이후 편) 없이 downstream 깨짐
• ELK는 로그 검색 축 — 본 시리즈는 분석·학습용 테이블·피처 경로

2. Scale-up vs Scale-out (데이터 관점)

Architecture 분산 기초에서 vertical vs horizontal을 봤다. 데이터 계층에서는 워크로드마다 기본 전략이 다르다.

	Scale-up	Scale-out
방법	더 큰 CPU·RAM·디스크	더 많은 노드·파티션
적합	강한 일관성 단일 writer	분산 읽기·쓰기·처리
한계	hardware·비용 천장	조율·shuffle·일관성 비용

계층별 흔한 선택

계층	1차	다음 단계	비고
OLTP RDB	scale-up	read replica → CDC offload	분석 쿼리는 빼기
Kafka	—	partition·broker out	ordering은 partition key
Spark	driver 메모리 up	executor·partition out	shuffle이 병목
Object storage	—	bucket·prefix out	저렴한 무한에 가까운 용량
Warehouse	warehouse size up	cluster out (제품별)	compute·storage 분리 추세

• 앱만 scale-out하고 DB가 100% — 효과 없음 (병목 측정 후 스케일)
• RDB shard는 마지막 수단에 가깝 — 이벤트·레이크로 읽기·분석을 빼는 편이 흔함
• Elasticity — 배치 피크에 executor 늘리기, 스트림은 상시 partition 설계

# code/scale-signals.yaml (발췌)
signals:
  - id: oltp-saturated
    when: "CPU > 80% AND p99 write latency rising"
    first: "scale-up primary OR read replica for read-only"
    then: "move analytics off OLTP via CDC to Kafka / lake"
  - id: batch-window-slip
    when: "nightly ETL misses SLA"
    first: "bigger batch worker"
    then: "Spark scale-out + partition by date"

3. 데이터 플레인 역할 분리

한 DB에 다 넣기 vs 경로 분리. 프로덕션 ML·리포트는 보통 플레인을 나눈다.

레이어	역할	대표 기술
Source	진실·이벤트 발생	앱, 파일, CDC 이벤트
Ingest	버퍼·순서·내구	Kafka, Kinesis
Process	변환·집계·조인	Spark, Flink, dbt
Store	분석용 저장	lake, warehouse, feature table
Serve	소비	BI, API, batch scoring

OLTP (orders DB)          Analytics path
     │                           │
     ├── API (transaction)       │
     └── CDC / events ──────────► Ingest ─► Process ─► Store ─► Serve
                                       (품질·계보·멱등 — 파이프라인 전 구간)

• OLTP — 짧은 트랜잭션·강한 일관성 (Database 시리즈). 다이어그램에서 별도 박스 — API 트랜잭션 경로
• Source — 분석 경로 진입점 (앱 이벤트·파일·CDC). OLTP 복제본이 아니라 이벤트 스트림으로 합류
• 분석 경로 — 처리량·재처리·스키마 진화 우선
• 같은 데이터라도 물리적으로 분리 — replica·CDC·이벤트로 동기화
• 오리엔테이션 파이프라인 다이어그램의 Ingest~Infer가 이 레이어의 구체화

분리하지 않을 때 비용

증상	원인
리포트가 주문 느리게	OLTP와 analytics 경합
스키마 변경이 전사 장애	한 warehouse에 모든 도메인 무계획 적재
재처리 불가	소스만 있고 immutable raw layer 없음

4. 중앙 플랫폼 vs Data Mesh

누가 파이프라인을 만들고 누가 데이터를 소유하느냐 — 규모가 커지면 조직 문제가 된다.

왼쪽 중앙 플랫폼 — 한 팀·공유 lake/warehouse. 오른쪽 data mesh — 도메인 data product + self-serve 플랫폼.

중앙 데이터 플랫폼 (흔한 1단계)

	내용
구조	한 data platform 팀이 lake·warehouse·공통 파이프라인 운영
장점	표준·도구 일원화, 초기 속도
한계	도메인 증가 시 대기열·컨텍스트 부족

Data Mesh (개요)

원칙	의미
Domain ownership	도메인 팀이 자기 data product 책임
Data as a product	SLA·스키마·문서·품질이 있는 소비 가능 단위
Self-serve platform	도메인이 직접 쓸 플랫폼 (Kafka·Spark·catalog)
Federated governance	전사 표준은 있되 중앙만 게이트키핑하지 않음

• Mesh ≠ “플랫폼 없음” — self-serve 플랫폼이 더 중요
• 작은 조직 — 중앙 플랫폼으로 시작하고, 도메인 성숙 후 product 단위 이양
• Team Topology의 data-platform 팀 — complicated-subsystem으로 파이프라인 제공 (Architecture)
• 본 시리즈 Part 2 — ETL·lakehouse·품질이 플랫폼·product를 어떻게 채우는지

상황	쪽
스타트업·단일 제품	중앙 lake + 소수 파이프라인
도메인 10+·팀 자율	data product + federated governance 검토
규제·PII	중앙 정책 + 도메인 마스킹 책임 분리

5. 설계 체크리스트

#	질문
1	OLTP에 analytics가 남아 있지 않은가
2	volume·velocity 중 어느 쪽이 먼저 한계인가
3	scale-out 대상이 stateless 처리인가, 데이터 재배치인가
4	ingest·process·store 경계가 코드·팀으로 보이는가
5	raw immutable layer가 있어 재처리 가능한가
6	도메인 소유권·data product 계약이 있는가

정리

• 3V가 겹치면 OLTP와 분석 경로 분리를 먼저 검토
• RDB는 scale-up·replica, Kafka·Spark·S3는 scale-out이 기본
• 역할 분리 — source / ingest / process / store / serve
• 조직 — 중앙 플랫폼에서 시작, 성장 시 data mesh 원칙으로 도메인 ownership 확장

다음에 다룰 것

• Batch vs Stream
• bounded vs unbounded, latency·throughput, use case

---

해당 내용은 Kleppmann — Designing Data-Intensive Applications, Dehghani — Data Mesh principles 를 기반으로 합니다.