동블

그래프 뷰

22. Data Pipeline 지도 - Event, Outbox, CDC, Kafka, Batch

9 min read

이 지도를 통해 아래 질문들에 답할 수 있게 됩니다.

  • 서비스 DB의 데이터는 어떻게 이벤트와 배치를 통해 다른 시스템으로 이동하는가?
  • Outbox와 CDC는 Dual Write 문제를 어디에서 줄이는가?
  • Kafka, Consumer, DLQ, Batch, Backfill은 각각 어떤 실패와 운영 문제를 다루는가?
  • Data Warehouse와 Data Quality는 서비스 데이터 흐름의 어느 위치에 놓이는가?
flowchart LR

subgraph SERVICE_SIDE["Service Transaction"]
direction TB
API["[ServiceAPI]<br/>사용자 요청 처리<br/>예: order create"]
DB[("[ServiceDB]<br/>OLTP 원장 데이터<br/>예: order, payment")]
EVENT["[DomainEvent]<br/>업무 사건 표현<br/>예: OrderCreated"]
OUTBOX[("[Outbox]<br/>트랜잭션 안 이벤트 기록<br/>예: event table")]
end

subgraph STREAM_SIDE["Stream Pipeline"]
direction TB
CDC[["[CDC]<br/>DB 변경 로그 캡처<br/>예: Debezium"]]
KAFKA[["[KafkaTopic]<br/>이벤트 스트림 보관<br/>예: order.events"]]
CONSUMER["[Consumer]<br/>이벤트 처리 작업자<br/>예: notify, index"]
DLQ[["[DLQ]<br/>실패 이벤트 격리<br/>예: poison message"]]
end

subgraph BATCH_SIDE["Batch / Backfill"]
direction TB
SCHED[["[Scheduler]<br/>시간 기반 실행<br/>예: daily"]]
BATCH["[BatchJob]<br/>대량 추출·변환<br/>예: settlement"]
BACKFILL["[Backfill]<br/>과거 데이터 재처리<br/>예: replay"]
end

subgraph ANALYTICS["Analytics / Quality"]
direction TB
DWH[("[DataWarehouse]<br/>분석용 저장소<br/>예: fact, dimension")]
QUALITY{"[DataQuality]<br/>정확성·완전성·최신성 검증<br/>예: count, freshness"}
REPORT["[ReportingSearchAI]<br/>리포트·검색·추천<br/>예: dashboard, vector"]
end

API ==>|write transaction| DB
API ==>|record event in tx| OUTBOX
DB -.->|change log| CDC
OUTBOX -.->|poll or capture| CDC
CDC -.->|publish event| KAFKA
KAFKA -.->|consume event| CONSUMER
CONSUMER ==>|update projection| REPORT
CONSUMER -->|failed after retry| DLQ
SCHED -.->|trigger| BATCH
BATCH ==>|bulk read| DB
BATCH ==>|load data| DWH
BACKFILL ==>|reprocess range| DWH
KAFKA -.->|replay events| BACKFILL
DWH -->|serve analytics| REPORT
DWH -->|validate data| QUALITY
QUALITY -->|alert quality issue| DLQ

classDef server fill:#E8F5E9,stroke:#2E7D32,color:#1B5E20;
classDef data fill:#FFF3E0,stroke:#EF6C00,color:#E65100;
classDef event fill:#F3E5F5,stroke:#6A1B9A,color:#4A148C;
classDef ops fill:#ECEFF1,stroke:#455A64,color:#263238;
classDef alert fill:#FFEBEE,stroke:#C62828,color:#B71C1C;

class API,CONSUMER,BATCH,BACKFILL,REPORT server;
class DB,OUTBOX,DWH data;
class EVENT,CDC,KAFKA,SCHED event;
class QUALITY,DLQ alert;

linkStyle 0,1,6,9,10,11 stroke:#EF6C00,stroke-width:3px;
linkStyle 2,3,4,5,8,12 stroke:#6A1B9A,stroke-width:2px,stroke-dasharray:5 5;
linkStyle 7,15 stroke:#C62828,stroke-width:2px;
linkStyle 13,14 stroke:#2E7D32,stroke-width:2px;

이 지도는 서비스 DB의 데이터가 이벤트와 배치를 통해 알림, 검색, 분석, 추천 같은 다른 시스템으로 이동하는 흐름을 설명한다. 서비스 API는 사용자 요청을 처리하며 ServiceDB에 트랜잭션을 기록한다. 동시에 이벤트를 발행해야 한다면 DB 쓰기와 메시지 발행이 따로 성공하는 Dual Write 문제가 생길 수 있다.

Outbox는 이 문제를 줄이기 위해 서비스 트랜잭션 안에 이벤트 기록을 함께 남기는 패턴이다. 이후 CDC나 polling이 Outbox 또는 DB 변경 로그를 읽어 Kafka 같은 스트림으로 발행한다. Consumer는 이벤트를 읽어 알림, 검색 인덱스, 분석 저장소 같은 후속 시스템을 갱신한다.

Batch와 Backfill은 스트림만으로 해결하기 어려운 대량 처리와 과거 데이터 재처리를 담당한다. Data Warehouse는 분석용 저장소이고, Data Quality는 데이터가 최신이고 완전하며 정확한지 검증한다.

장애가 났을 때 먼저 확인할 것

  • 서비스 DB 트랜잭션은 성공했는지, Outbox 기록은 남았는지 확인한다.
  • CDC가 변경 로그를 읽고 있는지, lag가 증가하는지 확인한다.
  • Kafka topic의 consumer lag, retry, DLQ를 확인한다.
  • Batch 마지막 성공 시각과 처리 건수, checkpoint를 확인한다.
  • Data Warehouse 적재 지연과 Data Quality rule 실패를 확인한다.

설계할 때 선택 기준

  • 서비스 트랜잭션과 이벤트 발행을 함께 보장해야 하면 Outbox를 검토한다.
  • DB 변경을 지속적으로 스트림화해야 하면 CDC를 검토한다.
  • 이벤트 재처리와 여러 consumer가 필요하면 Kafka 같은 event stream을 검토한다.
  • 정해진 시간의 대량 집계나 정산은 Batch로 분리한다.
  • 과거 데이터 수정이나 로직 변경이 잦으면 Backfill과 idempotent consumer를 함께 설계한다.

운영 중 볼 지표

  • outbox pending count, outbox age, CDC lag
  • Kafka consumer lag, offset commit failure, retry count, DLQ count
  • batch duration, last success time, checkpoint age, backfill throughput
  • warehouse freshness, row count diff, completeness failure count
  • duplicate event count, schema compatibility failure count

흔한 오해

  • DB에 저장한 뒤 메시지를 보내면 항상 둘 다 성공한다고 생각하면 위험하다.
  • Kafka를 쓰면 정확히 한 번 처리된다고 기대하기보다 중복 처리에 대비해야 한다.
  • Batch는 낡은 방식이 아니라 대량 처리와 재처리에 여전히 중요하다.
  • Data Warehouse의 숫자가 서비스 DB와 다르면 원인은 ETL, CDC, 지연, 중복 어디든 있을 수 있다.
  • Data Quality는 분석팀만의 문제가 아니라 서비스 변경이 만든 데이터 영향까지 포함한다.

실전 체크리스트

  • 서비스 트랜잭션과 이벤트 발행 사이의 Dual Write 위험을 줄였는가?
  • 이벤트 schema와 versioning 기준이 있는가?
  • Consumer가 중복 이벤트를 안전하게 처리하는가?
  • DLQ와 Backfill 재처리 절차가 있는가?
  • Data Warehouse freshness와 품질 rule을 관측하는가?

질문에 대한 답변

  1. 서비스 DB의 데이터는 어떻게 이벤트와 배치를 통해 다른 시스템으로 이동하는가?

    서비스 API가 DB에 데이터를 기록하고, Outbox나 CDC가 변경을 이벤트로 추출한다. Kafka topic을 거쳐 Consumer가 알림, 검색, 분석 저장소를 갱신한다. 대량 집계나 재처리는 Batch와 Backfill이 담당한다.

  2. Outbox와 CDC는 Dual Write 문제를 어디에서 줄이는가?

    Outbox는 서비스 트랜잭션 안에 이벤트 기록을 함께 남겨 DB 쓰기와 이벤트 기록을 같은 경계에 둔다. CDC는 DB 변경 로그를 읽어 그 기록을 스트림으로 발행한다.

  3. Kafka, Consumer, DLQ, Batch, Backfill은 각각 어떤 실패와 운영 문제를 다루는가?

    Kafka는 이벤트를 보관하고 재생할 수 있게 한다. Consumer는 이벤트를 처리한다. DLQ는 반복 실패 이벤트를 격리한다. Batch는 대량 작업을 수행하고, Backfill은 과거 데이터를 다시 처리한다.

  4. Data Warehouse와 Data Quality는 서비스 데이터 흐름의 어느 위치에 놓이는가?

    Data Warehouse는 운영 DB와 분리된 분석용 저장소다. Data Quality는 적재된 데이터가 최신성, 완전성, 정확성을 만족하는지 검증하는 운영 경계다.

관련 상세 문서

참고한 자료

관련 문서

백링크