Debezium

Debezium 은 데이터베이스에서 바뀐 행을 한 건씩 읽어 내 Kafka 로 흘려보냅니다. 애플리케이션 코드는 손대지 않습니다. 데이터베이스가 이미 남기는 변경 기록을 옆에서 따라 읽습니다. 검색 색인이나 캐시처럼 원본을 따라가야 하는 저장소가 그 흐름을 받아 씁니다.

상세

Debezium 은 변경 데이터 캡처를 하는 오픈소스 프로그램입니다. 변경 데이터 캡처(Change Data Capture, CDC)는 데이터베이스에 생긴 변경을 한 건씩 뽑아 다른 시스템으로 넘기는 일입니다. 주문 표의 행 하나가 바뀌면 그 변경 한 건이 넘어갑니다.

아래에서는 주문 표 하나의 변경이 Kafka 를 거쳐 검색 색인까지 가는 장면을 따라갑니다. 변경을 어디서 읽는지, 한 건이 어떤 모양인지, 멈췄다 다시 뜰 때 무엇을 하는지를 차례로 봅니다.

이중 쓰기와 주기적 조회

주문이 바뀔 때마다 검색 색인도 같이 바뀌어야 한다고 해 봅시다. 가장 쉬운 방법은 애플리케이션이 데이터베이스에 쓴 뒤 검색 색인에도 한 번 더 쓰는 것입니다. 이것을 이중 쓰기라고 부릅니다.

이중 쓰기는 둘 중 한쪽만 성공할 때 문제가 됩니다. 데이터베이스 쓰기가 끝난 뒤 검색 색인 쓰기가 실패할 수 있습니다. 그러면 둘이 어긋난 채로 남습니다. 어긋났다고 알려 주는 쪽도 없습니다.

다른 방법은 주기마다 표를 조회해 바뀐 행을 찾는 것입니다. 마지막으로 고친 시각을 적는 열을 하나 둡니다. 주기마다 그 시각이 지난 행만 고릅니다. 이 방법은 지워진 행을 못 찾습니다. 지워진 행은 조회 결과에 나오지 않기 때문입니다.

데이터베이스가 이미 적어 두는 변경 기록

데이터베이스는 자기가 한 변경을 순서대로 파일에 적어 둡니다. 장애가 나면 이 파일을 되짚어 되살립니다. 복제본에 같은 변경을 보낼 때도 이 파일을 씁니다. 이 문서에서는 이 파일을 변경 기록이라고 부릅니다.

Debezium 은 이 변경 기록을 읽습니다. MySQL 이나 PostgreSQL 이 보기에 Debezium 은 복제본이 하나 더 붙은 것과 같습니다. 복제본이 원본의 변경을 받아 가는 통로로 Debezium 도 변경을 받아 갑니다.

그래서 애플리케이션은 데이터베이스에만 씁니다. 삭제도 순서도 데이터베이스가 적은 대로 나옵니다. 사람이 콘솔에서 직접 고친 행도 똑같이 잡힙니다.

Kafka Connect 위에서 도는 커넥터

Debezium 은 혼자 뜨는 서버가 아닙니다. Kafka Connect 라는 실행 틀 위에 얹혀 돕니다. Kafka Connect 는 Kafka 와 바깥 시스템 사이로 데이터를 옮기는 일을 맡는 프로그램입니다.

Kafka Connect 에 끼워 쓰는 플러그인이 커넥터입니다. 바깥 시스템마다 커넥터가 따로 있습니다. Debezium 은 데이터베이스마다 하나씩 만든 커넥터의 묶음입니다.

커넥터가 데이터베이스마다 따로인 까닭은 변경 기록의 형식이 제품마다 다르기 때문입니다. 읽는 방법도, 미리 켜 두어야 할 설정도 다릅니다.

MySQL 의 binlog 는 바이너리 로그(binary log)를 줄인 이름입니다. 문장을 적는 방식과 바뀐 행을 적는 방식이 있습니다. Debezium 은 바뀐 값을 읽어야 해서 행을 적는 방식으로 설정해 둡니다.

PostgreSQL 은 WAL 을 날것으로 내주지 않습니다. 논리 디코딩이라는 기능이 WAL 을 「어느 표의 어느 행이 어떻게 바뀌었나」로 풀어서 내줍니다.

복제 슬롯은 PostgreSQL 이 읽는 쪽 하나마다 「여기까지 가져갔다」를 기억해 두는 표시입니다. 아직 안 가져간 WAL 은 지우지 않고 남겨 둡니다. 그래야 Debezium 이 잠시 멈췄다 와도 빠진 변경이 없습니다.

MongoDB 는 행 대신 문서라는 단위로 데이터를 담습니다. 변경 스트림이라는 창구로 바뀐 문서를 내줍니다. 이 창구는 서버 여러 대를 복제 세트로 묶었을 때만 열립니다. 이 밖에 Oracle 같은 다른 데이터베이스용 커넥터도 있습니다.

변경 한 건의 모양

Debezium 이 만든 변경 한 건은 Kafka Connect 를 거쳐 Kafka 에 메시지 하나로 올라갑니다. 이 메시지는 데이터베이스가 남기는 변경 기록과는 다른 것입니다. Kafka 는 메시지를 주제별로 나눈 토픽에 담습니다. 토픽은 표마다 하나씩 생기고, 주문 표의 변경은 주문 토픽으로 갑니다.

Kafka 메시지는 키와 값 두 덩이로 이루어집니다. 키에는 그 행의 기본 키가 들어갑니다. 값에는 무엇이 어떻게 바뀌었는지가 들어갑니다.

주문 8871번의 상태가 결제 대기에서 결제됨으로 바뀌었다고 해 봅시다. 그 값을 JSON(JavaScript Object Notation)으로 적으면 핵심 칸은 이렇습니다.

{
  "op": "u",                 // 고쳤다
  "before": {
    "status": "pending"      // 바뀌기 전
  },
  "after": {
    "status": "paid"         // 바뀐 뒤
  },
  "source": {
    "table": "orders",       // 어느 표
    "lsn": 24023128          // WAL 위치
  }
}

before 와 after 는 그 행의 바뀌기 전 값과 바뀐 뒤 값입니다. 받는 쪽은 after 만 보고 자기 저장소의 행을 덮어쓰면 됩니다. before 는 무엇이 달라졌는지 가릴 때 씁니다.

PostgreSQL 에서는 before 가 저절로 차지 않습니다. 바뀌기 전 행 전체를 WAL 에 남기도록 표를 설정해 두어야 합니다. 설정하지 않으면 이 칸이 비거나 키 열만 담겨 옵니다.

source 는 이 변경이 어디서 왔는지 적습니다. lsn 은 LSN(Log Sequence Number)입니다. PostgreSQL 의 WAL 안에서 이 변경이 적힌 위치를 가리킵니다. MySQL 이라면 binlog 파일 이름과 그 파일 안의 위치가 이 칸에 들어갑니다.

op 는 무슨 일이 있었는지를 한 글자로 적습니다.

앞의 셋은 변경 기록에서 나옵니다. 마지막 r 은 Debezium 이 처음 뜰 때 표를 전부 읽어 내보냅니다.

지우기는 Kafka 에 메시지 두 개를 남깁니다. 하나는 op 가 d 인 메시지입니다. 다른 하나는 키만 있고 값이 비어 있는 메시지입니다. 값이 빈 이 메시지를 툼스톤이라고 부릅니다.

툼스톤은 Kafka 의 정리 기능을 위한 것입니다. Kafka 는 같은 키를 가진 메시지 가운데 마지막 하나만 남기도록 토픽을 정리할 수 있습니다. 이런 정리가 로그 컴팩션입니다. 마지막 메시지가 툼스톤이면 그 키의 메시지는 결국 모두 사라집니다.

처음 한 번의 스냅샷

변경 기록은 지나간 변경을 모두 갖고 있지 않습니다. 파일이 끝없이 커질 수 없어서 오래된 부분부터 지웁니다. 오늘 Debezium 을 붙이면 작년에 들어온 주문은 변경 기록에서 찾을 수 없습니다.

그래서 Debezium 은 처음 뜰 때 스냅샷부터 뜹니다. 스냅샷은 어느 한 시점의 표를 전부 읽어 두는 일입니다. 읽은 행마다 op 가 r 인 메시지를 하나씩 내보냅니다.

스냅샷과 그 뒤의 읽기 사이에 틈이 있으면 안 됩니다. 스냅샷을 뜨는 동안에도 주문은 계속 바뀌기 때문입니다. Debezium 은 스냅샷을 시작하는 순간의 변경 기록 안 위치를 먼저 적어 둡니다. 스냅샷이 끝나면 그 위치부터 변경 기록을 이어 읽습니다.

표가 크면 스냅샷이 오래 걸립니다. 처음 스냅샷을 뜨는 동안에는 새 변경이 흘러가지 않습니다.

이 멈춤을 줄이는 방식이 증분 스냅샷입니다. 표를 기본 키 순서로 잘게 나눠 조금씩 읽습니다. 한 조각을 읽는 사이사이에 새 변경을 흘려보내므로 흐름이 오래 멈추지 않습니다. 이미 돌고 있는 커넥터에 나중에 표를 더할 때도 이 방식을 씁니다.

읽은 위치와 되풀이 전달

Debezium 은 변경 기록을 어디까지 읽었는지를 주기적으로 적어 둡니다. 적는 값은 앞에서 본 lsn 같은 변경 기록 안의 위치입니다. Kafka Connect 에서는 이 값을 오프셋이라고 부릅니다.

커넥터가 멈췄다 다시 뜨면 마지막으로 적은 오프셋부터 읽습니다. 멈춰 있던 동안의 변경은 그때 따라잡습니다.

오프셋은 변경을 내보낼 때마다 적지 않고 일정한 간격으로 몰아서 적습니다. 커넥터가 갑자기 죽으면 마지막으로 적은 오프셋 뒤에 이미 내보낸 변경이 남습니다. 다시 뜬 커넥터는 그 변경을 한 번 더 내보냅니다.

받는 쪽은 같은 변경을 두 번 받아도 결과가 같게 만들어 둡니다. after 의 값으로 행 전체를 덮어쓰면 두 번 덮어써도 결과가 같습니다. 이 성질을 멱등성이라고 부릅니다. 빠뜨리지는 않되 두 번 갈 수는 있는 이 전달 방식이 최소 한 번 전달입니다.

오래 멈춘 커넥터가 남기는 문제

Debezium 이 오래 멈춰 있으면 문제는 데이터베이스 쪽에서 생깁니다. 어떤 문제인지는 데이터베이스가 변경 기록을 언제 지우느냐에 따라 갈립니다.

PostgreSQL 은 복제 슬롯이 아직 안 가져간 WAL 을 지우지 않습니다. Debezium 이 멈춰 있는 동안 WAL 이 계속 쌓입니다. 며칠이 지나면 데이터베이스 서버의 디스크가 찰 수 있습니다. 디스크가 차면 원본 데이터베이스가 쓰기를 못 합니다.

MySQL 은 반대입니다. binlog 는 보관 기간이 지나면 읽는 쪽과 상관없이 지워집니다. Debezium 이 적어 둔 위치가 지워진 구간에 들어가면 이어 읽을 곳이 없어집니다. 그때는 스냅샷부터 다시 떠야 합니다.

stateDiagram-v2
    state "스냅샷" as SNAP
    state "변경 기록 읽기" as READ
    state "멈춤" as STOP
    [*] --> SNAP
    SNAP --> READ: 적어 둔 위치부터
    READ --> STOP
    STOP --> READ: 적어 둔 위치가 남아 있다
    STOP --> SNAP: 적어 둔 위치가 지워졌다

멈춘 커넥터가 어디로 돌아가느냐는 적어 둔 위치가 변경 기록에 아직 남아 있느냐로 정해집니다. PostgreSQL 은 디스크를 내주는 대신 위치를 지킵니다. MySQL 은 디스크를 지키는 대신 위치를 잃을 수 있습니다.

커넥터 하나가 읽는 한 줄

변경 기록은 한 줄로 이어진 파일입니다. 순서를 지키려면 앞에서부터 차례로 읽어야 합니다.

Kafka Connect 는 커넥터의 일을 태스크라는 단위로 나눠 여러 서버에 흩을 수 있습니다. 그런데 MySQL 과 PostgreSQL 커넥터는 태스크 하나로만 돕니다. Kafka Connect 서버를 늘려도 데이터베이스 하나를 읽는 속도는 늘지 않습니다.

표 구조 변경

원본 표에 열이 하나 늘면 그 뒤 메시지의 after 에도 칸이 하나 늡니다. 받는 쪽이 옛 모양만 알면 거기서 멈추거나 새 칸을 버립니다. 메시지의 모양을 따로 등록해 두어 양쪽이 맞춰 가게 하는 스키마 레지스트리가 이 문제를 줄입니다.

MySQL 커넥터는 표 구조를 바꾼 명령을 따로 모아 두는 토픽을 하나 더 씁니다. binlog 는 기본 설정에서 행의 값만 차례로 적고 열 이름은 적지 않습니다. 그래서 변경 기록 속의 옛 행을 풀려면 그 시점의 표 구조를 알아야 합니다. 이 토픽을 잃으면 커넥터가 옛 행을 해석하지 못합니다.

흘러 나가는 민감한 열

Debezium 은 표에 있는 열을 가리지 않고 내보냅니다. 비밀번호 해시나 개인 정보가 담긴 열도 따라 나갑니다. 커넥터 설정에서 뺄 열이나 가릴 열을 정해 둘 수 있습니다.

쓰는 곳과 안 쓰는 곳

Debezium 을 붙이는 까닭은 대개 한 데이터베이스의 변경을 여러 저장소가 따라가야 해서입니다. 받는 쪽마다 무엇을 하는지만 다릅니다.

마지막 줄은 아웃박스 패턴입니다. 애플리케이션이 주문 행과 「주문이 들어왔다」 행을 한 트랜잭션으로 씁니다. 뒤의 행은 아웃박스 표라는 별도의 표에 들어갑니다. Debezium 이 아웃박스 표를 읽어 그 행을 이벤트로 내보냅니다.

이렇게 하면 주문 저장과 이벤트 발행이 함께 성공하거나 함께 실패합니다. 데이터베이스와 Kafka 에 따로 쓰는 이중 쓰기를 피하는 방법입니다. Debezium 은 아웃박스 표의 행을 이벤트 종류별 토픽으로 나눠 보내는 기능을 함께 내놓습니다.

안 맞는 곳도 있습니다. 받는 쪽은 원본보다 늘 조금 늦습니다. 주문을 저장하자마자 검색에서 찾아야 하는 화면에는 맞지 않습니다. 시간이 지나면 같아지는 이 상태를 최종 일관성이라고 부릅니다.

변경 기록을 읽을 권한이나 설정을 받을 수 없는 데이터베이스에는 붙일 수 없습니다. 하루에 한 번 표를 통째로 옮겨도 되는 일이라면 Kafka 와 Kafka Connect 를 굴리는 부담이 더 큽니다.

맞물림

Debezium 이 하는 일은 변경 기록을 읽어 Kafka 메시지로 만드는 데까지입니다. Debezium 을 띄우는 일, 위치를 적어 두는 일, 메시지를 쌓아 두는 일, 대상 저장소에 쓰는 일은 둘레의 다른 물건이 맡습니다.

이 절은 Kafka Connect · Kafka 토픽 · 싱크 커넥터 · 스키마 레지스트리가 Debezium 과 어느 방향으로 붙는지를 봅니다. Kafka 없이 Debezium 을 띄우는 두 방식도 끝에서 봅니다.

그림에 나오는 싱크 커넥터는 Kafka 토픽을 읽어 바깥 저장소에 쓰는 커넥터입니다. Debezium 처럼 바깥에서 읽어 Kafka 에 넣는 커넥터는 소스 커넥터라고 합니다.

flowchart TD
    DB["원본 데이터베이스"] -->|변경 기록을 읽는다| DBZ
    subgraph KC["Kafka Connect"]
        DBZ["Debezium 커넥터"]
        SINK["싱크 커넥터"]
    end
    KC -->|표마다 토픽에 쓴다| K["Kafka"]
    KC -.->|메시지 모양을 등록한다| SR["스키마 레지스트리"]
    K -->|토픽을 읽는다| SINK
    SINK -->|덮어쓴다| ES["검색 색인"]

원본에서 검색 색인까지 한 줄로 이어집니다. 애플리케이션은 그림에 없습니다. 애플리케이션은 원본 데이터베이스에만 씁니다. 그 뒤에 무엇이 붙어 있는지는 모릅니다.

Debezium 을 띄우는 Kafka Connect

Kafka Connect 가 Debezium 커넥터를 띄워서 부릅니다. Debezium 은 변경 기록에서 읽은 것을 Kafka 메시지로 만들어 돌려줄 뿐입니다. Kafka 에 쓰는 일은 Kafka Connect 가 합니다.

오프셋도 Kafka Connect 가 적어 둡니다. Kafka Connect 를 여러 대로 묶어 띄우면 오프셋을 Kafka 안의 전용 토픽에 적습니다. 한 대가 죽으면 다른 대가 그 커넥터를 넘겨받아 적힌 오프셋부터 이어 갑니다.

커넥터를 붙일 때는 Kafka Connect 에 설정을 JSON 한 덩이로 등록합니다. 어느 데이터베이스에 붙을지, 어느 표를 읽을지가 그 안에 들어갑니다. 대가는 Kafka Connect 라는 서버 묶음을 하나 더 굴려야 한다는 것입니다.

표마다 하나씩 생기는 Kafka 토픽

토픽 이름은 커넥터에 붙인 접두어와 데이터베이스나 스키마 이름, 표 이름을 점으로 이어 짓습니다. 주문 표 하나가 토픽 하나에 대응하므로 받는 쪽은 필요한 표의 토픽만 골라 읽습니다.

Kafka 는 토픽을 여러 조각으로 나눠 담습니다. 그 조각이 파티션입니다. Kafka 는 한 파티션 안에서만 순서를 지킵니다.

Debezium 이 메시지의 키로 기본 키를 쓰므로 같은 행의 변경은 늘 같은 파티션으로 갑니다. 그래서 한 행에 대한 변경은 일어난 순서대로 읽힙니다.

대가는 표와 표 사이의 순서입니다. 주문 표와 결제 표의 변경은 다른 토픽으로 갑니다. 두 표를 한 트랜잭션에서 고쳤어도 받는 쪽에는 따로따로 닿습니다.

Debezium 의 토픽을 읽는 싱크 커넥터

싱크 커넥터는 Debezium 의 반대쪽 끝에 붙습니다. 소스 커넥터인 Debezium 이 채운 토픽을 싱크 커넥터가 읽어 바깥 저장소에 씁니다.

검색 색인을 맞출 때는 Elasticsearch 싱크 커넥터가 주문 토픽을 읽어 색인에 씁니다. 같은 Kafka Connect 위에서 소스와 싱크가 함께 돌 수 있습니다.

Debezium 의 메시지는 바뀐 행을 before·after·source 같은 설명 칸으로 감싼 모양입니다. 이 모양을 봉투(envelope)라고 부릅니다. 싱크 커넥터는 대개 행 하나를 기대하므로 봉투를 그대로 받으면 안 맞습니다.

그래서 Kafka Connect 의 변환을 하나 끼웁니다. 변환은 메시지가 커넥터를 드나들 때 한 건씩 모양을 바꾸는 작은 단계입니다. 봉투에서 after 만 꺼내 넘기는 변환을 Debezium 이 함께 내놓습니다. 대가로 before 와 source 는 싱크 쪽에서 볼 수 없게 됩니다.

컨버터와 스키마 레지스트리

Kafka Connect 는 메시지를 Kafka 에 쓰기 전에 컨버터로 바이트로 바꿉니다. 바이트로 바꾸는 이 일이 직렬화입니다. 컨버터를 무엇으로 고르느냐에 따라 토픽에 실리는 모양이 달라집니다.

JSON 컨버터는 메시지마다 칸 이름과 모양 설명을 함께 싣도록 설정할 수 있습니다. 모양 설명을 매번 실으면 받는 쪽이 따로 묻지 않고 읽을 수 있습니다. 대신 메시지 하나하나가 커집니다.

Avro 는 칸 이름 없이 값만 차례로 바이트에 적는 직렬화 형식입니다. 칸 이름이 빠지므로 JSON 보다 작습니다. 그 대신 읽는 쪽은 모양 설명이 있어야 값을 풀 수 있습니다.

Avro 컨버터를 쓰면 그 모양 설명을 스키마 레지스트리에 한 번만 등록합니다. 스키마 레지스트리는 메시지의 모양에 번호를 붙여 모아 두는 서버입니다. 메시지에는 그 번호만 실립니다.

스키마 레지스트리는 새 모양이 옛 모양과 어긋나면 등록을 거절하도록 설정할 수 있습니다. 표 구조 변경이 받는 쪽을 깨뜨리기 전에 거기서 멈춥니다. 대가는 서버를 하나 더 굴려야 한다는 것입니다. 받는 쪽도 메시지를 읽을 때 스키마 레지스트리를 부릅니다.

Kafka 없이 붙이는 Debezium Server 와 임베디드 엔진

Kafka 를 두지 않는 곳도 있습니다. 이때는 Kafka Connect 대신 다른 것이 Debezium 을 띄웁니다.

Debezium Server 는 Debezium 커넥터를 혼자 띄우는 프로그램입니다. 읽은 변경을 Kafka 대신 다른 메시지 브로커로 보냅니다. 메시지 브로커는 Kafka 처럼 메시지를 받아 두었다가 읽는 쪽에 나눠 주는 서버입니다. Amazon Kinesis · Apache Pulsar · Redis 같은 곳입니다. 이때는 Debezium Server 가 브로커를 부릅니다.

임베디드 엔진은 Java 라이브러리입니다. 애플리케이션이 이 엔진을 자기 안에서 띄웁니다. 변경이 들어올 때마다 엔진이 애플리케이션이 넘겨 둔 함수를 부릅니다.

두 방식 모두 Kafka Connect 가 해 주던 일을 떠안습니다. 오프셋을 어디에 적을지 스스로 정해야 합니다. 한 대가 죽었을 때 다른 대가 넘겨받는 일도 저절로 되지 않습니다.

관련 항목

Debezium 이 변경을 읽어 내는 데이터베이스

MySQL · PostgreSQL · MongoDB · Oracle Database · SQL Server · Db2 · Cassandra

Debezium 이 따라 읽는 데이터베이스 변경 기록

WAL · binlog · LSN · oplog · 트랜잭션 로그

Debezium 이 변경을 읽을 때 기대는 데이터베이스 기능

복제 · 복제 슬롯 · 논리 디코딩 · 변경 스트림 · 스냅샷 · 증분 스냅샷

Debezium 을 띄우고 부르는 Kafka Connect 부품

Kafka Connect · 커넥터 · 소스 커넥터 · 싱크 커넥터 · 컨버터 · 스키마 레지스트리 · Avro

Debezium 이 변경을 쌓는 Kafka 의 구성 요소

Apache Kafka · 토픽 · 파티션 · 오프셋 · 로그 컴팩션 · 툼스톤

Debezium 을 Kafka 없이 띄우는 실행 방식

Debezium Server · Debezium 임베디드 엔진 · Amazon Kinesis · Apache Pulsar · Redis

Debezium 이 구현하는 데이터 흐름 설계

변경 데이터 캡처 · 아웃박스 패턴 · 이벤트 스트림 · 스트림 처리 · 이벤트 주도

Debezium 이 대신하는 동기화 방식

이중 쓰기 · 폴링 · 트리거 · ETL · 전량 적재

Debezium 과 같은 일을 두고 겨루는 도구

Maxwell · AWS DMS · Oracle GoldenGate · Flink CDC · Airbyte · Fivetran

Debezium 을 붙이면 따라오는 전달 성질

최소 한 번 전달 · 정확히 한 번 전달 · 멱등성 · 최종 일관성 · 순서 보장 · 복제 지연

Debezium 의 변경을 받아 쓰는 저장소

Elasticsearch · 검색 색인 · 캐시 · 데이터 웨어하우스 · 데이터 레이크 · 읽기 모델

Debezium 이 속하는 상위 분류

데이터 엔지니어링 · 데이터 통합 · 데이터 파이프라인 · 오픈소스