개발글

CDC - Debezium

yaho-coconut 2022. 11. 6. 01:29

Context

  1. 내가 맡은 서비스에서 데이터 변경 로그의 누락이 없어야함
  2. 변경에 대한 메시지를 발행하자 (이벤트 소싱)
    • FE작업이 필요하여 파일로 로그 출력하는 형태이면 안됨
    • 카프카를 이미 사용하고 있음
    • 로그를 따로 저장 후 어드민 툴에서 볼 수 있어야해서 DB에 저장하는게 용이함
      • 쿼리 필요
    • 다른 서비스에서도 메시지 수신이 필요할 수 있음(가능성이 높다봄)
  3. Webflux 사용 중
    • spring 트랜잭션 5.2.x 문제로 http connection이 끊어져서 cancle signal이 발생할 때 원자성이 보장이 안됨
    • 개발은 빨리해야하는데 5.3 못 기다림

방안

1. Store log on transaction

  • 서비스의 비즈니스 로직의 트랜잭션에서 로그 DB에 직접 저장
    • 간단함
  • spring-transaction 라이브러리 직접 수정
    • 수정 후 검증필요
  • 서비스에 로그 DB와의 커넥션 상태에 대한 의존성 추가 됨
  • 변경에 대한 이벤트 발행에 대한 책임 따로 처리
    • 2번도 같이 할 듯 하다

Data Access

2. Publish message on Transaction

  • 서비스의 비즈니스 로직의 트랜잭션에서 트랜잭션 발행
    • 간단함
  • spring-transaction 라이브러리 직접 수정
    • 수정 후 검증필요
  • 서비스에 로그 카프카 상태에 대한 의존성 추가 됨

3. CDC

  • 관리포인트 증가(Kafka connect)
    • 대신 다른 컨테이너에서 자신이 처리할 수 있는throuput만큼만 가능
  • 서비스의 트랜잭션이 단순해짐
    • 서비스에서 로깅애 대한 책임이 분리 됨
  • 카프카 상태에 문제가 생기더라도 서비스는 동작함
    • fault tolerance 증가

채택 : 3

  • 리퀘스트에 대한 요청이 실패 할 확률이 더 적어짐
  • CDC를 경험해보지 못햇음
  • 내가 할 수있는만큼 하는게 모토임

설정

Connector properties

  • tasks.max
    • shard 의 수 이상으로 설정

kafka Connector

MongoDB

  • 몽고 DB권한을 주자
    • config (read)
    • local (read, for reading oplog)
    • admin(read, be able to invoke listDatabases)
    • Shard마다 따로 줘야한다.
  • Mongos로 연결
  • k8s 환경 또는 회사 클러스터 환경문제일 수도 있는 문제
    • ADVERTISE_HOST_NAME - 카프카 커넥트로 접근 할 수 있는 IP 또는 서비스 주소 (꼭 명시필요)
    • REST_HOST_NAME - REST - 0.0.0.0 (꼭 명시필요)

Debezium Connector for MongoDB

장점

  • CDC 자체만으로 스펙이 끝나는 경우 너무나 간결함

단점

  • CDC처리하는 곳에서 전 상태를 가지고 있어야하는 경우 이벤트 소싱을 통해 스냅샷을 만들어야하는데 존나 귀찮다. → Outbox Pattern 고려