CDC 아키텍쳐를 이루는 debezium, kafka connect

INTRO

해당 게시글은 Udemy의 Change Data Capture(CDC) using Debezium for MySQL 섹션 1을 보고 정리한 내용입니다.
내용상 오류가 있을수 있습니다. 댓글로 남겨주시면 확인 후 수정하겠습니다. 감사합니다!
 
 

Debezium이 생기게 된 배경

기존 RDB&NOsql(MySQL, MongoDB, Cassandra…) → (Capture) ⇒ Big data System (e.g. HDFS…)
 

Debezium의 특징 

1. 이벤트 기반 으로 작동한다
2. 다양한 데이터기반 환경을 하나로 합칠수 있다
3. DB의 상태 혹은 진행사항을 지속적으로 모니터링하는것을 보장한다
4. Apache Kafka기반으로 만들어진거라 빠르다
 

Kafka Connect 컨셉

데이터 스트리밍을 위한 Apache Kafka의 프레임워크
중앙집중형(중앙화된) 데이터 허브에 가까움
 

Kafka Connect 특징

1. 대규모 데이터를 이동시키는 Connector를 정의할수 있음
2. Kafka 브로커 이외에 별개로 동작함
3. 데이터 추상화를 사용해서 Kafka로 가져옴 → 유연성과 확장성을 확보
4. 독립형&분산모드 에서 스트리밍&배치형으로 둘다 가능함
 

커넥터 유형

소스커넥터: DB&Application 데이터를 Kafka 로 보냄
싱크커넥터: Kafka에서 DB&Application 에 데이터를 보냄
 

Debizium의 역할

DB에서 데이터를 가져와 Kafka topic에 넣는 소스커넥터

일반적인 전체 아키텍쳐

• 다른DB로 넣는거는 다른 싱크커넥터들이 역할을 진행함

 

Data capture의 정의

DB에서 데이터에 대한 변경사항을 확인하고 캡쳐하는 프로세스
변경사항을 실시간으로 Downstream프로세스나 시스템에 전달함
 

CDC를 사용하지 않는 기존방식의 문제점

기존방식은 정기적인 간격으로 데이터를 대량으로 lift and shift 함(이동)
일반적으로 스냅샷을 찍는것이고, batch 형식으로 진행되는게 대부분임
기존방식으로 진행하면 실시간으로 데이터의 변화를 확인할 수 없음
 

CDC의 특징

DB에서 변경사항이 발생하면 즉시 캡쳐하기때문에, 최신 데이터를 실시간으로 얻을수 있음
추가로, 실시간 분석이 가능해진다는것을 의미함
 

Debezium 커넥터를 활용한 파이프라인 구성

Schema Registry의 역할

메타데이터에 대한 서빙레이어 역할
RESTful 인터페이스 를 제공함
모든 스키마 변경에 대한 버전관리
 

Schema Registry의 특징

Kafka 브로커 외부에 독립적으로 존재함
Producer & Consumer는 여전히 Kafka Topic에 접근할수 있고, Schema Registry와 통신하는 일종의API
 

Schema Registry의 장점

Kafka Producer는 Topic에 대해서 데이터를 쓰고, Kafka Consumer는 Topic에 대해서 데이터를 읽음
Producer입장에서 봤을때 Consumer가 가져갈수 있는 스키마로 데이터를 넣는다는 암묵적인 규정이 존재하는 게 일반적이고, 이는 스키마가 발전되는동안에도 마찬가지임.
따라서 Producer와 Consumer는 데이터가 변화해도, 스키마를 호환시켜줄 필요성을 갖고있음
이는 배치애플리케이션이 아니라, 스트리밍 애플리케이션의 경우에도 동일하게 적용함.
 

스키마레지스트리가 작용하는 구조

Supported MySQL Topology

지원되는 토폴로지모드

• Standalone: 단일 MySQL를 사용하는경우, 서버 인스턴스를 모니터링함
• Primary and Replica: MySQL커넥터가 Primary서버를따라감. Replica서버에는 따라가지않음. 즉, 수집기가 Primary에만 존재함
• HA clusters: 대부분의 HA MySQL클러스터는 Replica서버가 Primary를 따라갈수 있도록 GTID ID를 따라가는데, 이를 이용해서 CDC를 진행함
• Multi-primary
• Hosted