Debezium 3.6: RocksDB 오프힙 스키마 이력·MySQL 폴 경로 최적화·Docling SMT로 CDC 운영 경계를 확장한 방법

왜 지금 봐야 하나

Debezium은 MySQL, PostgreSQL, MongoDB 등 주요 데이터베이스에서 CDC(Change Data Capture) 이벤트를 Kafka로 스트리밍하는 사실상 표준 도구다. 2026년 7월 1일 Debezium 3.6.0.Final이 출시됐다. Kafka Connect 4.3.0을 기반으로 한 이번 릴리스는 두 가지 오랜 운영 문제를 해결했다.

첫 번째 문제: 대규모 스키마 환경에서 JVM 힙 메모리 압박. 수백 개 테이블을 캡처하는 커넥터는 테이블 매핑과 스키마 이력 전체를 JVM 힙에 보관했다. 테이블 수가 늘수록 OOM 위험이 커졌고 GC 부담이 높아졌다. 3.6은 이를 RocksDB 기반 오프힙 스토리지로 교체할 수 있는 플러그인 인터페이스를 도입했다.

두 번째 문제: MySQL 커넥터 폴 경로의 CPU·메모리 오버헤드. doPoll() 메서드가 Java 스트림/컬렉터 파이프라인을 사용해 불필요한 중간 객체를 생성했다. 사전 크기 지정 ArrayList와 직접 루프로 교체하면서 폴 경로의 메모리 할당이 75% 감소하고 CPU 오버헤드가 31~42% 감소했다.

이 두 변화 외에도 AI/RAG 파이프라인 통합을 위한 Docling SMT, Amazon SNS 싱크, MariaDB 신호 기반 binlog 위치 조정 등이 포함됐다.

버전 히스토리

변화 1: RocksDB 오프힙 테이블 이력 스토리지

기존 구조의 문제

Debezium 커넥터는 캡처 중인 테이블의 컬럼 매핑과 스키마 이력을 JVM 힙 내 자료구조로 관리했다. 테이블 50개 수준에서는 문제가 없지만, 수백~수천 개 테이블을 캡처하는 환경에서는 세 가지 문제가 드러난다.

• JVM 힙 사용량이 수 GB에 달해 OOM 위험이 증가한다
• 힙 크기가 커지면 Major GC 일시정지가 길어져 커넥터 처리 지연으로 이어진다
• 커넥터 재시작 시 스키마 이력 재로드에 시간이 걸린다

3.6의 해법: 플러그인 테이블 매핑 스토리지

3.6은 테이블 매핑 스토리지를 인터페이스로 추상화하고 RocksDB 기반 구현체를 제공한다. 기본값은 기존 메모리 구현을 유지한다. RocksDB 구현을 선택하면 스키마 이력과 테이블 매핑이 디스크에 저장되고 JVM 힙 외부에서 관리된다.

# MySQL 커넥터 설정 예시
schema.history.internal=io.debezium.storage.rocksdb.RocksDbSchemaHistory
schema.history.internal.rocksdb.path=/var/debezium/schema-history

table.mapping.storage=io.debezium.relational.history.RocksDbTableMappingStorage
table.mapping.rocksdb.path=/var/debezium/table-mapping

운영 판단: 캡처 테이블이 100개 이하이고 현재 설정이 안정적이라면 굳이 마이그레이션할 필요는 없다. 200개 이상이거나 OOM 이력이 있다면 도입을 고려한다. RocksDB 경로의 I/O 성능이 커넥터 처리량에 직접 영향을 준다 — NVMe SSD를 권장한다. Kubernetes 환경에서는 PersistentVolume 마운트가 필요하다.

변화 2: MySQL 커넥터 폴 경로 최적화

변경 전: 스트림/컬렉터 파이프라인

MySQL 커넥터의 doPoll() 메서드는 binlog 이벤트 배치를 처리할 때 Java 스트림 API와 Collectors.toList()를 사용했다. 스트림 파이프라인은 내부적으로 중간 객체를 생성하고, 최종 컬렉션 크기를 예측하지 못해 ArrayList를 동적으로 확장한다. 폴 경로는 초당 수천 번 호출되는 핫 패스이므로 이 오버헤드가 누적된다.

변경 후: 사전 크기 지정 ArrayList + 직접 루프

// 변경 전
List<SourceRecord> records = events.stream()
    .map(this::toSourceRecord)
    .collect(Collectors.toList());

// 변경 후
List<SourceRecord> records = new ArrayList<>(events.size()); // 사전 크기 지정
for (Event event : events) {
    records.add(toSourceRecord(event));
}

측정 결과:

• 폴 경로 메모리 할당 75% 감소
• CPU 오버헤드 31~42% 감소

높은 처리량 환경(초당 수천 건 이상의 binlog 이벤트)에서 효과가 뚜렷하다. GC 압박 감소로 커넥터 레이턴시 일관성이 개선된다.

이 최적화는 MySQL 커넥터에 적용됐다. PostgreSQL, MongoDB, Oracle 커넥터는 별도로 확인해야 한다.

변화 3: Docling SMT — CDC 이벤트를 AI 파이프라인으로 직접 연결

배경

Docling은 텍스트를 Markdown, JSON 등 구조화된 형식으로 변환하는 문서 처리 라이브러리다. RAG(Retrieval-Augmented Generation) 파이프라인에서 문서를 임베딩 전 전처리할 때 자주 쓰인다.

Docling SMT의 역할

Debezium 3.6의 Docling SMT(Single Message Transformation)는 CDC 이벤트 내 텍스트 필드를 Docling을 통해 구조화된 문서 출력으로 변환한다.

# Kafka Connect 커넥터 설정
transforms=docling
transforms.docling.type=io.debezium.transforms.DoclingTransformation
transforms.docling.field.names=content,description
transforms.docling.output.format=markdown

실용적 활용 예시: 콘텐츠 DB(CMS, 문서 관리 시스템)에서 변경 이벤트가 발생하면 아래 경로로 즉시 흐른다.

텍스트 변경 시 임베딩 재계산이 자동으로 트리거되는 파이프라인을 Kafka Streams나 별도 컨슈머 없이 커넥터 레이어에서 구성할 수 있다.

변화 4: Amazon SNS 싱크

Debezium Server는 기존에 SQS, Kinesis를 AWS 메시지 타깃으로 지원했다. 3.6은 SNS(Simple Notification Service) 싱크를 추가했다.

주요 동작:

• PublishBatch API로 최대 10개 메시지를 배치 전송한다
• 배치 응답의 실패 엔트리만 재시도한다 (전체 배치 재시도 아님)
• Debezium 헤더를 SNS 메시지 속성으로 전달한다
• FIFO 토픽을 지원한다 — 설정 가능한 헤더로 MessageGroupId, MessageDeduplicationId를 제어한다
• 단일 토픽 및 프리픽스 기반 다중 토픽 라우팅을 지원한다

SNS 팬아웃 패턴(SNS → 여러 SQS 큐 구독)을 활용하면 하나의 CDC 스트림을 여러 다운스트림 소비자에게 동시에 전달하는 아키텍처가 단순해진다.

변화 5: MariaDB 신호 기반 binlog 위치 조정

MariaDB 커넥터가 신호(Signal)를 통한 binlog 위치 조정 기능을 지원한다. 신호 테이블에 레코드를 삽입하면 커넥터가 지정된 위치로 이동한다.

-- 특정 binlog 파일/오프셋으로 이동
INSERT INTO debezium_signals VALUES (
  'signal-001', 'reset-offset',
  '{"binlog_file": "mariadb-bin.000042", "binlog_pos": 4096}'
);

-- GTID 기반 위치 지정
INSERT INTO debezium_signals VALUES (
  'signal-002', 'reset-offset',
  '{"gtid": "0-1-12345"}'
);

이 기능이 필요한 상황:

• binlog 파일이 회전되거나 삭제된 후 커넥터를 재시작해야 할 때
• 데이터 마이그레이션 완료 후 CDC를 특정 시점부터 재개할 때
• 파싱 오류가 반복되는 이벤트를 건너뛰어야 할 때

추가 변화 요약

운영 체크리스트

• [ ] RocksDB 오프힙 전환 시 Kubernetes PVC 마운트 경로 확인 및 I/O 성능 테스트
• [ ] RocksDB 경로는 커넥터 재시작 간에 유지되어야 한다 — 임시 스토리지(emptyDir) 사용 금지
• [ ] MySQL 폴 경로 최적화는 MySQL 커넥터에만 해당 — PostgreSQL·MongoDB·Oracle은 별도 확인
• [ ] Docling SMT 사용 전 커넥터 플러그인 의존성에 Docling 라이브러리 버전 호환성 확인
• [ ] Fluss 싱크는 인큐베이팅 상태 — 프로덕션 사용 전 충분한 검증 필요
• [ ] SNS FIFO 토픽 사용 시 MessageDeduplicationId 중복 방지 전략 수립
• [ ] Kafka Connect 4.3 업그레이드 시 Kafka 4.3 릴리스 노트의 클래식 프로토콜 관련 변경 사항 확인
• [ ] 신규 MariaDB binlog 위치 신호 사용 전 신호 테이블이 캡처 범위에 포함됐는지 확인

References

• Debezium 3.6 Release Summary
• Debezium 3.6 Release Notes
• Debezium 3.6 Release Series Overview
• Debezium 3.6.0.Alpha1 Released
• Debezium 3.6.0.Alpha2 Released
• Debezium 3.6.0.CR1 Released