티스토리 뷰

반응형

Motivation

1. Kafka Connector 내용을 공부하면서 DB에 실제로 카프카 커넥터를 붙여서 실행하고 사용해면 좋은 경험이 되고 더 잘 기억에 남을 것 같았음

아쉬웠던 점

👉 자주 사용하는 ORACLE로 연동해보면 더 좋을 것 같다고 생각해서 시도를 했으나 잘 안됐음, 관련 글을 찾아봤는데 ORACLE에 Connector를 연동한 사례가 별로 없었음(MySQL은 비교적 예시도 많았으나, 오라클은 유독 없음. 오라클에 적용할 수 없는 어떤 이유가 있는건가.. 의문..)

👉 m1맥이라 오라클 서버를 실행할 수 없어서 오라클 클라우드에서 제공하는 Autonomous DB를 사용하고 있었는데, 여기에 카프카 커넥터를 적용한 사례가 하나 있긴했으나 Docker를 이용한 방법(나는 카프카 서버를 AWS에 올려두었다)이였고 connection.url 설정에서 계속 문제가 생겨서 우선 미뤄둠 🥲

혹시나 남겨두는 찾아봤던 곳들

2. DB와 Kafka Connector를 연동할 수 있는 방법이 무엇이 있을까?

3. 만일 연동을 한다면 단순하게 연결만 하는 것이 아니라, 효율적으로 데이터 처리를 할 수 있는 방법이 있을까?

 

 

 CDC 오픈소스 Debezium

 


 

CDC(Changed Data Capture)

  • 변경된 데이터를 판별 및 추적하는데 사용되는 소프트웨어 설계 패턴
    👉 쉽게 말해서 변경된 내용을 골라내는 기술(실시간 데이터 변경 이력 관리)
  • DBMS가 CUD 전에 작업내용을 Logging(write-ahead-logging)
  • CDC가 Source DB의 로그를 읽어 변경된 내용을 Target DB에 적용
  • Golden Gate(Oracle), Binlog(MySQL), WAL(PostgreSQL), Debezium 등이 대표적
  • 실시간 처리 가능(새벽마다 통계 및 분석을 위한 대량 배치 작업을 줄일 수 있음)
  • 데이터 변경분만 전송되기에 효율적으로 자원을 사용 가능

 

위키피디아에서의 CDC 정의
In databases, Change Data Capture (CDC) is a set of software design patterns used to determine (and track) the data that has changed so that action can be taken using the changed data.
데이터베이스의 CDC (Change Data Capture)는 변경된 데이터를 사용해 액션(Action)이 취하도록 변경된 데이터를 판별 및 추적하는 데 사용되는 소프트웨어 디자인 패턴이다.

 

 

Debezium(DBs + ium, 디비지움)

출처 : https://access.redhat.com/documentation/ko-kr/red_hat_integration/2022.q2/html/debezium_user_guide/high-level-overview-of-debezium

  • Confluent사(카프카 지원 벤더)에서 개발한 Kafka Connect의 Source Connector 구현체
  • 다양한 데이터베이스의 CDC를 추출하기 위한 오픈 소스 플랫폼
  • DB의 row loevel의 변경 사항을 캡쳐하여 애플리케이션이 변경 내용을 보고 이를 처리할 수 있도록 해주는 분산 서비스
    👉
    모든 row level의 변경을 changed event stream에 기록, 애플리케이션은 이 스트림을 통해 변경 이벤트를 순서대로 읽음
  • Log-Based CDC를 사용하여 DB 변경 사항을 수집
  • DB의 복제로그를 추적해서 스트림으로 제공하는 방식
  • 논리적 복제를 사용해 변경 스트림을 Apache Kafka Topic에 복제
  • Trivago, Wepay, Yotpo, BlaBlaCar에서 사용

 

지원하는 Connector(Debezium이 모니터링할 수 있는 데이터베이스)

  • MongoDB 복제 세트 또는 샤드 클러스터
  • MySQL 데이터베이스 서버
  • PostgreSQL 서버
  • SQL Server 데이터베이스
  • ORACLE 서버
  • Db2
  • Cassandra

 

Query-based CDC vs Log-based CDC

  • Query-based CDC
    • 캡쳐된 테이블의 변경사항(insert or update)을 검색하기 위해 항상 쿼리를 실행해야함
      (With polling-based (or query-based) CDC you repeatedly run queries (e.g. via JDBC) for retrieving any newly inserted or updated rows from the tables to be captured.)
  • Log-based CDC
    • DB의 로그 파일로부터 변경 사항을 보고 반응하여 동작
      (Log-based CDC in contrast works by reacting to any changes to the database’s log files.)
  • Query-Based 커넥터와 Log-based 커넥터를 비교한 글

 

 

Debezium의 용도

  • 데이터베이스의 데이터가 변경될 때마다 애플리케이션이 (거의)즉시 응답할 수 있게 함
  • 애플리케이션은 Create, Update, Delete 이벤트로 무엇이든 할 수 있음
    👉  캐시에서 데이터 제거 시기를 알 수도 있고, 데이터로 검색 색인은 업데이터하거나 푸쉬알림을 보낼 수도 있음

 

 

Debezium의 아키텍처

  • 카프카 커넥터를 통해 배포
  • 데이터를 카프카에 모으는 역할(Source Connector)
  • Debezium 커넥터는 클라이언트 라이브러리를 사용하여 Source 데이터베이스에 커넥션을 맺고 MySQL인 경우 binlog / Postgres의 경우 logical replication stream을 읽음
    👉  Debezium(mysql), NIFI 내부에서 shyiko/mysql-binlog-connectorjava 파서를 사용한다
  • Embedded Engine을 사용하여 Debezium 커넥터를 사용하는 방법도 있음
    👉  대신 이경우에는 카프카 커넥터를 통해 실행되지 않고 자바 애플리케이션의 라이브러리로 사용
    👉  변경 이벤트를 애플리케이션에서 바로 consume하거나 변경 내역을 다른 메시지 브로커로 전달할때 유용
  • 기본적으로 한 테이블의 변경 사항은 하나의 토픽으로 전달됨
  • 변경 이벤트가 있으면 서로 다른 커넥터를 사용하여 Elasticsearch, Data warehous, cache 등에 반영할 수 있음

 

 

Debezium의 특징

  • DML과 DDL이 카프카 토픽에 저장
  • Log Based CDC
  • 모든 데이터의 변경사항을 캡쳐
  • 변경 이벤트를 큰 딜레이 없이 생성
  • data model의 변경이 불필요
  • 데이터의 변경뿐만아니라 데이터의 삭제, 레코드의 과거 상태도 캡쳐 가능

 

Debezium CDC의 추가 기능

  • Snapshosts : 커넥터가 시작될 때 데이터베이스의 현재 상태에 대한 초키 스냅샷을 생성
  • Filters : 특정 테이블이나 컬럼의 변경만 캡쳐
  • Masking : 특정 컬럼 마스킹 처리(민감한 정보일 때)
  • Monitoring : JMX를 사용해서 모니터링 할 수 있음
  • Message Tranformations

 

 

Debezium CDC format

  • 아래와 같은 포맷으로 DB 변경 사항을 수집
{
	"schema" : { // 테이블의 primary key, pk가 없을 경우 unique key에 대한 스키마
    ..
    },
	"payload" : { // 변경 row의 key 데이터로 key schema를 따름
    ..
    },
	"schema" : { // 테이블의 컬럼에 대한 event value 스키마
    ..
    },
	"payload" : { // 변경 row의 모든 컬럼에 대한 데이터로 value schema를 따름
    ..
    },
    
}

// 출처 : 네이버 데뷰 2020
{
    "before" : null,                // 변경 이전 값
    "after" {                       // 변경 이후 값
        "id" : 17,
        "name" : "wine glass",
        "price" : 17000
        },
    "source" : {
    ...
        }
    },
    "op" : "c",                     // operation type(c:create, u:update, d:delete)
    "ts_ms" : 1602982061481,            
    "transaction" : {               // transaction
    	"id" : "506",                // 트랜잭션을 식별한 유니크한 string
        "total_order" : 9,           // 트랜잭션에 의해 생성된 모든 이벤트의 개수(absolute position of the event among all events generated by the transaction)
        "data_collection_order" : 5  // 트랜잭션에 의해 생성된 모든 이벤트의 개수 중 이 트랜잭션의 위치(the per-data collection position of the event among all events that were emitted by the transaction)
    }
}

// 출처 : 네이버 데뷰 2020

 

 

 

MirrorMaker2

  • CDC용 Kafka를 application용 kafka와 격리시킬 목적으로 사용

 

 

Kafka Connector

출처 : https://www.wenyanet.com/opensource/ko/6076d6ed0c0fdf4c2a5604d7.html

  • 빨간색 네모 박스가 Debezium이 적용될 부분
  • 카프카 클러스터를 통해 데이터베이스, 하둡, 검색 같은 외부 시스템 및 파일 시스템에 연결하고 데이터를 가져오고 내보는 프레임워크를 제공
  • Connector : 데이터 베이스, 키-값 저장소, 검색 엔진, 파일 시스템에 대한 연결 인터페이스

 

삼성 소프트웨어 개발자 컨퍼런스 2019의 Debezium 발표 배경 중

 

일반 카프카 커넥트 아키텍쳐

  • Extract - Transform - Load 패턴

출처 : https://www.sosconhistory.net/soscon2019/content/data/session/Day%202_1730_2.pdf

 

 

  • Debezium 카프카 커텍트 아키텍쳐

출처 : https://www.sosconhistory.net/soscon2019/content/data/session/Day%202_1730_2.pdf

 

  • 주문 서비스 적용 예시

출처 : https://www.sosconhistory.net/soscon2019/content/data/session/Day%202_1730_2.pdf

 

 

 

최근 데이터 레이크 아키텍처 트렌드

Lambda 아키텍처
Kappa 아키텍처

Lambda 아키텍처와 비교했을때 Kappa 아키텍처의 특징

  • 배치 레이어를 제거
  • 스피드 레이어가 서비스에서 생성되는 모든 데이터를 처리
개인적인 생각 : 변경된 데이터를 바로 판별할 수 있는 CDC를 지원하는 Debezium이 이러한 Kappa 아키텍처의 특징을 잘 지원할 수 있을 것 같음

 

 

 

Debezium을 사용할 경우 대용량 환경일수록 아키텍처를 잘 잡아야하기 때문에 DBA, 개발자, Devops의 역할이 중요해진다.

 

 


출처 

 

참고한 곳

반응형
Comments