올리브영의 실시간 캠페인 타겟팅을 위한 CDC 전환기를 읽고나서

아주 예전에는 쇼핑몰에서 며칠 있다가 쿠폰 알림이 와도 그런가 보다 했는데, 이 블로그 글을 읽고 나니까 이제는 실시간으로 맞춤 알림이 오지 않으면 뭔가 이상하다고 느끼게 된 이유를 알겠다. 요즘 사용자들은 서비스에 더 민감하고 빠른 반응을 기대하는 것 같다. 그래서 이 글에서 강조하고 있는 ODI의 한계와 CDC로 마이그레이션하는 과정이 재미졌다. 나도 2년 전에 Kafka CDC 기반으로 데이터베이스 싱크를 맞춘 경험이 있는데, 그 때 삽질(?)했던게 새록새록 떠올랐다.

CDC와 OGG, Kafka 조합의 의미

나도 데이터 동기화 프로젝트를 했던 적이 있었는데 역시 배치는 데이터 일관성 맞추기가 참 힘들었고 사용자의 행동이 서비스에 바로바로 반영이 안 돼서 불편한 부분이 존재한다. 그런데 여기선 OGG로 CDC 기반 파이프라인을 구현했다는 점이 재미졌다. Kafka가 중간에서 메시지를 분산 처리해주고 OGG는 트랜잭션 로그에서 실시간으로 변경사항을 잡아주는 구조인데 나처럼 DB 리플리케이션에 신경 많이 썼던 사람에게는 매력적으로 느껴질 수 있을 것 같다. 앞으로 실시간 고객에 대해서 타겟팅 또는 맞춤화 시스템에는 이런 구조가 점점 기본이 될 것으로 생각한다. (물론 필수는 아님..)

나는 MySQL → AWS RDS 싱크를 Kafka CDC로 구성한 경험이 있다. Debezium MySQL Connector로 소스 MySQL의 binlog를 캡처하고 Kafka Connect JDBC Sink로 타깃 RDS에 upsert하는 흐름이었다.

하이브리드 구조

개인적으로 제일 인상 깊었던 부분은 OGG 커넥터가 모든 비즈니스 요구를 직접 처리하지 않아서 하이브리드 구조를 썼다는 점이다. 소스와 타겟의 1:1 매핑이 아닌 다중 조인이나 복잡한 데이터 가공이 필요한 경우는 별도의 Campaign-Worker에서 처리하게 했다는 점을 보고 속으로 "대박!"을 외쳤다. 기술적으로 완전 크고 무거운 엔터프라이즈 솔루션이라도 "우린 복잡해서 이거 한 방에 못 간다."라는 현실적 한계를 인정하는 게 나이스한 자세하고 생각한다.

메시지 순서 이슈와 Retry, DLT, 복구 배치

카프카를 쓰면 단일 파티션에서는 메시지 순서가 유지되지만 서로 다른 토픽 혹은 파티션에서는 순서 보장이 안 돼서 나도 비슷한 고민을 했었다. 실제로 서로 join이 필요한 데이터의 메시지가 비동기로 오면 정합성이 깨지는다는 내용을 기술블로그에서 볼 수 있다. 여기서 Retry-DeadLetter-DLT 복구 배치까지 3중 안전장치를 둔 게 확실히 실무에서 필요한 꼼꼼함 같다. 이 정도는 되어야 "실시간인데도 데이터 누락 거의 없다."고 자신 있게 말할 수 있겠구나...싶었다.

실시간 모니터링

Datadog 같은 도구로 실제 운영 현황을 모니터링하면서 Kafka lag이나 DLQ/DLT 처리 현황을 실시간으로 본다는 건 단순 개발자가 아니라 진짜 서비스 운영자를 위한 배려라고 느꼈다. 회사마다 다르겠지만 보통 개발자가 모니터링 툴을 통해서 운영 현황을 모니터링하긴 한다. 단지 파이프라인을 구현하는 것만으로 끝나는 게 아니라 유실이나 지연이 나면 바로바로 조치할 수 있는 체계를 준비하는 게 현업에서는 진짜 중요하다고 생각한다는 거....ㅎㅎ

참고 문헌

• 올리브영의 실시간 캠페인 타겟팅을 위한 CDC 전환기