CDC란 Change Data Capture의 약자로 데이터베이스에서 발생하는 변경 사항을 실시간으로 추적하고 기록하는 기술
쿼리기반과 로그기반 두가지 CDC 방식이 있는데 쿼리 기반은 주기적으로 풀스캔 쿼리를 실행하게된다면 DB에 부하가 가해짐, 로그 기반은 트랜잭션 로그 기반으로 변경 사항을 추출하기 때문에 DB에 부하가 일어나지 않음
CDC의 사용 사례
고민사항
여러가지 카카오 데이터들중에 민감 데이터는 마스킹이나 파싱을 통해서 파이프라인에 어떻게 녹여야하는지 많은 고민을 함
초대규모 데이터를 어떻게 빠르게 처리해야할지
정합성 검증을 어떻게 해야할지
효율적인 적재 시스템이란 무엇인지
Debezium
가장 대중적인 트랜잭션 로그 기반 CDC 오픈소스
카프카 커넥트 기반으로 동작
다양한 DBMS 지원
실시간으로 오프셋 기록하며 재 연동시 마지막으로 읽은 오프셋 시점에서 복구 가능
증분 스냅샷 기능 지원→ 스냅샷시 테이블락킹을 회피하기위해서 활용함
일반적인 debezium 파이프라인의 모습. 소스 디비로부터 카프카 커넥터(디비지움)이 카프카 토픽으로 적재한 데이터를 싱크커넥터가 타겟디비로 처리해서 보내줌
파이프라인 구조
1년동안 운영하고 있는 현재 파이프라인 구조 스파크가 정합성에 문제가 없는지 매일매일 확인
현재 약 300개의 테이블, 총 2.3TB, 하루 약 1.4억개 레코드를 처리하고 있음
파이프라인 구조중에 Flink CDC도 결국 디비지움 기반의 CDC 오픈 소스
Flink CDC를 도입함으로 얻은 이점
장애 처리 효율성 향상
카프카 싱크 커넥터
JDBC Sink Connector
SMT
정합성 검사
매일 스파크 배치잡으로 정합성 검사 수행
전체 레코드 비교하는 것도 있고 너무 많으면 일단위 변화분 레코드만 비교해줌
매일 오전 알림을 통해 확인
운영시 발생한 이슈와 해결 과정
이슈1
스키마 변경을 실시간으로 반영하지 않는 이유→ 지표 계산 로직과 호환이 깨질 수 있음, 민감 데이터가 보안존 외부로 나올 수도 있음
그래서 DDL 이벤트가 발생하면 알림을 주고 사람이 직접 확인하고 반영 및 재연동을 진행하게 됨
플링크 실행상태를 유지하면서 DDL 이벤트 이후 이벤트를 타겟에 반영하지 않음
이후 DDL 쿼리를 확인하여 반영 가능한 쿼리인지 확인하고 GTIDs를 활용하여 재연동을 진행
이슈2
테이블당 하나의 토픽생성→ 과도한 카프카 토픽 생성→ 이는 부하의 원인이 됨→ 항상 테이블 특성과 스키마가 동일한 샤딩된 테이블에 한해 하나의 토픽으로 합치는 것을 고민
샤딩된 테이블들은 하나의 카프카 토픽을 공유하고 카프카 커넥트에서 메시지를 보고 타겟 테이블을 선택
메세지의 데이터베이스와 테이블명을 사용하여 토픽 이름을 변경함→ JDBC Sink 커넥터의 기본설정이 테이블명을 설정하지 않으면 토픽명을 테이블 명으로 적재하기 때문에 메세지를 보고 타겟 테이블을 선택하도록 커스텀 SMT 구현
이슈3
null 값이 기본 값으로 바뀌어서 적재됨→ 카프카 커넥트 라이브러리에서 카프카 메세지를 json 객체로 변환시 null값 대신 기본 값을 사용(카프카 3.5버전에서 해결), 카프카 커넥트-jdbc 라이브러리 관련해서 json 객체를 수행될 쿼리로변환시, null 값 대신 기본 값 사용
카프카 커넥트는 라이브러리 버전을 업데이트하였고 JDBC 싱크 커넥터는 커스텀 SMT를 구현해서 대응
Iceberg
오브젝트 스토리지 기반 CRUD가 지원되는 오픈소스 테이블 포맷
아이스버그를 사용함으로써 반복되었던 MySql 테이블 덤프가 제거되고 카프카 의존성이 제거됨
필요한 만큼 자원을 할당할 수 있기 때문에 소싱 시간이 개선됨(스파크 자원할당)
카프카 의존성이 제거되어 기존 디비지움의 change event 포맷을 사용하던 것에서 플링크의 RowData 포맷을 사용할 수 있게됨
compaction
플링크는 항상 Merge-on-Read 방식으로 아이스버그에 데이터를 적재
컴팩션은 데이터 파일과 삭제파일을 합쳐 새로운 데이터 파일을 생성하는 것
컴팩션이 필요한 이유: 플링크는 체크포인트 마다 새로운 데이터 파일과 삭제 파일을 계속 생성하는데 조회시 합쳐야되는 파일 수가 시간이 흐를 수록 증가하기 때문에 주기적으로 컴팩션을 해서 합쳐진 파일들을 만들어야지 조회시 성능이 유지됨
스냅샷 만료 및 고아 파일 제거
스냅샷 만료
고아 파일 제거
민감 데이터는 보안을 위해 주기적으로 과거 상태와 파일들을 삭제하고 있고 일반 데이터는 하둡 블록 사이즈보다 작은 파일들이 계속 생성되면 파일 I/O 성능에 부정적이라 삭제를 진행함
샤딩 테이블을 하나의 테이블로 합침
여러 플링크 잡에서 하나의 아이스버그 테이블에 커밋을 수행하면 동시성 이슈로 간헐적 커밋 실패가 발생함 커밋 재시도 횟수를 늘려서 해결할 수 있으나 실 환경에서는 안정적 운영이 중요하기 때문에 반영하지는 않기로함
소감
생각보다 꽤 재미있는 세션들이 많았다. 지금까지 정리한 것은 데이터 엔지니어 직군만 따로 정리한거고 그냥 시간 날때마다 몇몇개는 따로 공부한다는 느낌보다는 감상한다는 느낌으로 쭉 봐도 괜찮을 것 같다. 예를 들어 DBA is free! MongoDB 자동업그레이드 시스템 개발기를 봤는데, 200개 이상의 클러스터를 업그레이드하는데 기간이 너무 길고 반복되서 비효율적이라는 것을 느낀 카카오 DBA가 자동화를 통해 3분만에 업그레이드를 할수있도록 구현한 구현기를 설명하고 있다. 이외에 MMORPG 실시간 알림 서비스 개발기나 카카오 서비스들은 어떻게 CI/CD를 하는가?라던가 다양한 도메인의 서비스를 하는 만큼 각 서비스를 어떤 방식으로 구현하고 유지보수하는지에 대한 내용들이 나와있어서 보는 눈이 즐겁다.
특히 오늘 정리한 이 CDC파트는 내가 사내에서 가장 크게 맞닿아서 하고있는 부분이기도해서 더욱 재미있게 본 것 같다 특히 증분스냅샷 부분이 몰랐던 부분이라서 흥미로웠다. 우리는 그냥 작은 테이블들은 스냅샷을 사용하고 큰 테이블들은 기존 방식인 스파크 배치와 더불어 위에 이어서 현재시점부터 cdc를 적용하는 식으로 활용하고 있는데 플링크 CDC를 사용하는 방식도 검토해볼만할 것 같다. 부록처럼 아이스버그에 대한 내용도 요새 부쩍 아이스버그에 대한 내용들이 많이 들려와서 아이스버그의 오픈소스 방향성이 이전보다 확실히 더 클라우드 친화적이 되어가고 있다는 생각이 들었다.
