데이터 관리 패턴: CDC, 이벤트 소싱, CQRS, 최종 일관성

왜 패턴이 필요한가

서비스가 하나의 DB를 쓸 때는 트랜잭션 하나로 정합성을 지킨다. 서비스가 나뉘고 캐시·검색 엔진·데이터 웨어하우스가 붙으면 같은 사실이 여러 저장소에 복사된다. 이때 문제는 둘이다.

1. 한 곳의 변경을 다른 곳에 어떻게 빠짐없이 전달하나
2. 전달되는 동안 저장소끼리 어긋나는 것을 어떻게 다루나

CDC: 변경 데이터 캡처

CDC(Change Data Capture) 는 DB에서 일어난 삽입·수정·삭제를 잡아 다른 시스템으로 실시간 전달하는 기법이다. 애플리케이션은 평소처럼 DB에 쓰기만 하고, 나머지는 CDC가 맡는다.

flowchart TB
  app["앱"] -->|"INSERT/UPDATE/DELETE"| db["원본 DB"]
  db -->|"트랜잭션 로그 (MySQL binlog, PostgreSQL WAL)"| src["소스 커넥터 (Debezium)"]
  src -->|"변경 이벤트 (before / after / op)"| k["Kafka 토픽"]
  k --> s1["싱크: 검색 인덱스"]
  k --> s2["싱크: 캐시(Redis)"]
  k --> s3["싱크: 데이터 웨어하우스"]

대표 도구 Debezium은 MySQL, PostgreSQL, Oracle, SQL Server, MongoDB 등의 커넥터를 제공하고, 보통 Kafka Connect 위에서 돌린다. Kafka 없이 쓰는 Debezium Server도 있다. 샤드 클러스터로 데이터를 옮길 때 CDC를 쓰는 흐름은 데이터베이스 샤딩에 있다.

이중 쓰기 대신 아웃박스

「DB에 쓰고, 이어서 메시지 큐에도 발행」하는 이중 쓰기(dual write) 는 둘 중 하나만 성공하면 어긋난다. DB와 브로커는 한 트랜잭션으로 묶이지 않기 때문이다.

트랜잭셔널 아웃박스(transactional outbox) 는 업무 데이터와 함께 같은 트랜잭션으로 outbox 테이블에 이벤트를 쓰고, 별도 릴레이(message relay)가 그 테이블을 읽어 브로커로 보낸다. DB 트랜잭션 하나로 「상태 변경」과 「발행할 이벤트」가 함께 확정되고, 발행은 그 뒤에 언제든 다시 시도할 수 있다.

BEGIN
  UPDATE orders SET status = 'PAID' WHERE id = 7;
  INSERT INTO outbox (id, aggregate_type, aggregate_id, type, payload, created_at)
       VALUES ('evt-91', 'order', 7, 'OrderPaid', '{...}', now());
COMMIT
                 ↓ 릴레이 (폴링 또는 CDC)
           Kafka 토픽 order (키 = aggregate_id)

• 릴레이는 보낸 뒤 표시하기 전에 죽으면 같은 이벤트를 다시 보낸다. 즉 아웃박스는 최소 한 번 발행이므로, 이벤트 ID를 넣어 소비자가 중복을 거른다.
• 순서는 집합체(aggregate) ID를 메시지 키로 써서 집합체 단위로 지킨다.
• 발행이 끝난 행은 지우거나 보존 기간 뒤 정리해 테이블이 무한히 커지지 않게 한다.
• 브로커가 죽어도 이벤트는 DB에 남아 있다가 복구 뒤 나간다. 아웃박스는 브로커 장애를 업무 장애와 떼어 놓는 장치이기도 하다.

이벤트 소싱

일반적인 CRUD 설계는 현재 상태를 저장하고 덮어쓴다. 이벤트 소싱(event sourcing) 은 상태를 바꾼 이벤트를 추가 전용으로 저장하고, 현재 상태는 이벤트를 처음부터 차례로 적용해 계산한다.

CRUD: orders 테이블

flowchart TB
  subgraph row1[" "]
    direction LR
    h1["id"] ~~~ h2["status"]
  end
  subgraph row2[" "]
    direction LR
    v1["7"] ~~~ v2["PAID<br/>← 덮어씀"]
  end
  row1 ~~~ row2

이벤트 소싱: order_events (추가만 한다)

flowchart LR
  E1["1. OrderPlaced<br>{id: 7, amount: 30000}"] --> E2["2. PaymentDone<br>{id: 7}"] --> E3["3. OrderShipped<br>{id: 7}"] --> F["현재 상태 = fold(이벤트들)"] --> S["SHIPPED"]

이벤트 소싱은 결정성(determinism) 을 전제로 한다. 같은 이벤트를 같은 순서로 적용하면 언제나 같은 상태가 나와야 한다. 그래서 이벤트 적용 로직 안에서 현재 시각·난수·외부 호출을 쓰지 않고, 필요한 값은 이벤트에 담는다.

현재 상태와 스냅숏

현재 상태는 집합체(aggregate) 하나의 이벤트를 순서대로 읽어 적용(fold)해 계산한다. 이벤트 저장소는 집합체 ID와 버전(순번)으로 이벤트를 찾으므로, 전체 로그가 아니라 그 집합체의 이벤트만 읽는다. 버전은 쓰기 때의 낙관적 동시성 제어에도 쓴다. 「버전 5를 읽고 결정했으니 6번으로 추가」가 다른 쓰기와 겹치면 거절된다.

스냅숏(snapshot) 은 특정 버전까지 적용한 상태를 저장해 둔 것이다. 상태를 만들 때 가장 최근 스냅숏을 읽고 그 뒤 이벤트만 적용한다.

이벤트:  1 2 3 … 200 [스냅숏 v200] 201 202 203
현재 상태 = 스냅숏(v200) + 이벤트 201~203 적용

• 스냅숏은 캐시다. 진실의 원천은 여전히 이벤트이므로, 스냅숏은 지우고 다시 만들 수 있어야 한다.
• 상태 구조나 적용 로직이 바뀌면 옛 스냅숏을 버리고 이벤트에서 다시 만든다. 그래서 스냅숏에 스키마 버전을 붙인다.
• 대부분의 집합체는 이벤트가 적어 스냅숏이 필요 없다. 재생이 실제로 느린 집합체에만 둔다.

CQRS

CQRS(Command Query Responsibility Segregation) 는 데이터를 바꾸는 명령(command) 모델과 읽는 조회(query) 모델을 분리한다. 쓰기 쪽은 정규화와 불변식 검증에, 읽기 쪽은 화면에 맞춘 비정규화 뷰에 최적화한다.

CQS에서 CQRS로

CQS는 코드 수준 규칙이라 어디에나 적용해도 해가 없지만, CQRS는 구조를 나누는 결정이라 쓸 곳을 고른다.

flowchart TB
  cmd["명령"] --> w["쓰기 모델 (정규화 DB / 이벤트 저장소)"]
  w -->|"변경 이벤트 (CDC 또는 이벤트 발행)"| p["투영기(projector)"]
  p --> r["읽기 모델 (비정규화 테이블, 검색 인덱스, 캐시)"]
  r --> q["조회"]

쓰는 이유와 비용

동기화와 지연

투영기는 같은 이벤트를 두 번 받아도 결과가 같게(이벤트 ID·버전 기록) 만들고, 읽기 모델에 「어느 버전까지 반영했나」를 남긴다.

동기화 지연(lag) 때문에 생기는 「방금 쓴 게 안 보인다」는 다음으로 다룬다.

일관성 모델의 종류(자기 쓰기 읽기, 단조 읽기)는 분산 시스템의 시간과 장애에 있다.

조회 모델의 저장소

조회마다 저장소를 다르게 둘 수 있다는 것이 CQRS의 이점이지만, 저장소가 늘면 운영 부담도 는다. 하나로 시작해 필요한 조회만 떼어 낸다.

맞는 곳과 맞지 않는 곳

CQRS와 이벤트 소싱

CQRS는 이벤트 소싱이 아니다. 둘은 독립된 패턴이다.

함께 쓰면 역할이 맞물린다. 이벤트 소싱은 「무엇이 일어났나」를 잃지 않는 쓰기 모델을 주고, CQRS는 그 이벤트로 조회에 맞는 뷰를 여러 개 만든다. 이벤트 소싱의 약점인 조회를 CQRS가 메우고, CQRS의 「읽기 모델을 어떻게 동기화·재구축하나」를 이벤트 재생이 푼다. 새 화면이 필요하면 새 투영기를 만들어 처음부터 이벤트를 재생하면 과거 데이터까지 담긴 읽기 모델이 생긴다. ETL·스트림 처리와 함께 본 데이터 흐름 패턴 지도는 분산 시스템의 통신·데이터 흐름 패턴에 있다.

최종 일관성을 만드는 네 가지 방법

최종 일관성(eventual consistency) 은 새 쓰기가 없으면 모든 복제본이 결국 같은 값에 수렴한다는 약속이다. 그 사이에는 저장소마다 다른 값이 보일 수 있다. 비동기 복제가 대표적인 예다.

2PC와 사가의 비교, 보상 트랜잭션 설계, 중간 상태 대응, 오케스트레이션·코레오그래피 구현은 분산 트랜잭션: 2PC와 사가에 있다.

이벤트를 전달받는 쪽은 같은 이벤트를 두 번 받을 수 있다고 가정한다. 메시지 시스템의 전달 보장 수준과 유실 대책은 메시지 큐와 Kafka에 있다.

데이터 이전과 스키마 진화: Avro

데이터를 다른 저장소로 옮기거나 이벤트를 오래 보관하면, 그 사이에 스키마가 바뀐다. 옛 데이터와 새 데이터를 함께 읽을 수 있어야 한다.

Apache Avro 는 데이터 직렬화와 RPC를 위한 형식으로, Hadoop 생태계에서 시작했다. 스키마를 JSON으로 정의하고 데이터는 압축된 바이너리로 쓴다.

Protobuf·Thrift는 필드 번호를 붙인 스키마로 코드를 미리 생성하는 쪽이라 RPC에 강하고, Avro는 스키마를 데이터와 함께 다니게 해 대량 이전과 파이프라인에 강하다. Kafka에서는 스키마를 스키마 레지스트리(schema registry) 에 등록하고 메시지에는 스키마 ID만 실어, 호환성 규칙(backward, forward, full)을 어기는 스키마 변경을 등록 단계에서 막는다. Protobuf 쪽은 gRPC: Protocol Buffers로 정의하는 RPC에 있다.

호환성 규칙

이벤트와 메시지는 생산자와 소비자가 따로 배포되고, 저장된 옛 데이터는 새 코드가 다시 읽는다. 그래서 스키마 변경은 누가 먼저 배포되느냐에 맞춰 호환성을 정한다.

Confluent Schema Registry의 기본값은 직전 버전과의 하위 호환(BACKWARD)이다. 안전한 변경 습관은 다음과 같다.

• 필드는 기본값과 함께 추가하고, 소비자는 모르는 필드를 무시한다(tolerant reader).
• 필드 이름·타입·의미를 바꾸지 않는다. 바꿔야 하면 새 필드를 추가하고 옛 필드를 한동안 함께 채운 뒤 걷어 낸다.
• 필수 필드를 없애거나 의미를 뒤집는 변경은 호환되지 않는다. 새 이벤트 타입이나 새 버전 토픽(OrderPlaced.v2)을 만들고, 한동안 두 버전을 함께 발행한다.
• 이벤트 소싱처럼 옛 이벤트를 영원히 읽어야 하면 읽을 때 새 형식으로 바꾸는 업캐스터(upcaster)를 둔다.

정리

• 저장소가 여럿이면 「변경을 빠짐없이 전달」과 「전달 중 어긋남」을 함께 설계한다.
• 변경 전달은 로그 기반 CDC가 표준이고, 이중 쓰기 대신 아웃박스로 상태 변경과 이벤트 발행을 한 트랜잭션에 묶는다.
• 이벤트 소싱은 상태 대신 사건을 저장해 재현과 감사를 얻고, 그 대가로 투영·스냅숏·스키마 버전을 관리한다.
• CQRS와 이벤트·사가 기반 연동은 최종 일관성을 받아들이는 대신 확장성과 결합도를 얻는다.
• 오래 사는 데이터는 스키마 진화 규칙(Avro, 스키마 레지스트리, 하위·상위·완전 호환)을 처음부터 정해 둔다.
• 2PC 대신 사가로 서비스 사이 트랜잭션을 풀고, CQRS는 이벤트 소싱 없이도 쓸 수 있는 독립된 패턴이다.

관련 노트: 분산 트랜잭션: 2PC와 사가, 메시지 큐와 Kafka, 데이터베이스 샤딩, 데이터베이스 확장과 성능 최적화, 웹 확장성의 구성 요소: 한 장으로 보는 웹 아키텍처, 트랜잭션과 회복, 분산 시스템의 통신·데이터 흐름 패턴, 캐시 전략: 계층, 읽기·쓰기 패턴, 교체 정책, 장애 패턴, 이벤트 기반 아키텍처 설계