forked from MinePing/Final
-
Notifications
You must be signed in to change notification settings - Fork 0
library debezium
qbsb147 edited this page Mar 21, 2026
·
1 revision
Debezium은
데이터베이스의 변경사항(CDC, Change Data Capture)을 추적하는 Kafka Connect 기반 Source Connector이다.
- DB의 변경 로그를 읽어 데이터 변경 이벤트 생성
- 변경된 데이터를 Kafka 등 외부 시스템으로 전달
👉 특징
- commit된 데이터만 전파
- 애플리케이션 없이도 DB 변경사항 추적 가능
CDC는
데이터의 변경(INSERT, UPDATE, DELETE)을 식별하고 추적하는 패턴
👉 목적
- 데이터 변경 시 추가 작업 수행
예:
- 캐시 무효화
- 이벤트 발행
- 데이터 동기화
- DB 내부 로직
- 외부 시스템 연동 시 복잡
- DBMS마다 구현 방식 다름
- DB 로그 기반 추적
- DBMS 독립적 구조 제공
- 외부 시스템 연동 용이
👉 결론
Debezium은 DB와 외부 시스템 사이의 middleware 역할
Debezium은 보통 다음 구조로 사용됨
Database → Debezium Connector → Kafka → Consumer
👉 특징
- Kafka 기반 → 확장성, 내구성, 장애 대응
- 메시지 전달 방식 선택 가능
- at-least-once
- exactly-once
- 메시지가 최소 한 번 이상 전달됨
- 중복 발생 가능
👉 특징
- 데이터 유실 없음
- 대신 중복 처리 로직 필요
- 메시지가 정확히 한 번만 전달됨
👉 특징
- 중복 없음
- 구현 복잡도 높음
- Kafka 설정 및 트랜잭션 필요
- 정합성 중요 → exactly-once
- 성능 / 단순성 중요 → at-least-once
- 데이터 변경 시 캐시 무효화 처리
- Debezium이 변경 이벤트를 감지하여 캐시 invalidate 수행
👉 장점
- 캐시 로직을 애플리케이션에서 분리 가능
문제:
- DB 저장 + 캐시 무효화 + Kafka 전송 등
- 여러 외부 시스템 작업을 하나의 트랜잭션으로 묶어야 함 (dual-write)
👉 한계
- 트랜잭션으로 묶기 어려움
- 중간 실패 시 데이터 불일치 발생 가능
👉 해결 (Debezium)
- DB 작업만 트랜잭션 처리
- 변경사항은 Debezium이 CDC로 외부 시스템에 전달
→ 애플리케이션 로직 단순화
→ 데이터 정합성 개선
문제:
- 여러 애플리케이션이 하나의 DB 공유
- 특정 데이터 변경을 다른 서비스가 추적하기 어려움
👉 해결
- Debezium이 변경 이벤트를 발행
- 모든 서비스가 동일 이벤트를 구독 가능
- 데이터가 여러 시스템에 분산 저장되는 경우
- Debezium을 통해 데이터 변경사항을 전파
👉 효과
- 시스템 간 데이터 일관성 유지
- Command(쓰기) 모델과 Query(읽기) 모델 분리
문제:
- 쓰기 데이터 변경 시 읽기 모델도 동기화 필요
👉 해결
- Debezium이 변경 이벤트를 전달
- 읽기 모델 자동 동기화
- 초기 데이터 전체 로드
- 로그가 없는 경우 사용
- schema / table / column 단위 필터링
- 특정 컬럼 데이터 마스킹
- 개인정보 보호에 유용
- JMX 기반 connector 모니터링
- 메시지 가공 및 라우팅 기능
-
Topic Routing
→ 정규식 기반으로 다른 Topic으로 전달 -
Content-based Routing
→ 메시지 내용 기반 라우팅 -
Message Filtering
→ 불필요한 데이터 필터링