승밈

지난 글에서 우리가 CDC 파이프라인을 JDBC source connector로 구축한 얘기를 했다. 동기화하면서 비정규화 변환까지 함께 처리할 수 있어서 우리 요구사항에 잘 맞는 도구였다.근데 솔직히 그 글에서 못 한 얘기가 있다. 이 도구의 가장 큰 약점은 스키마 변경에 약하다는 거다. 운영하면서 이거 때문에 진짜 자주 깨졌다. 오늘은 그 얘기를 좀 해보려고 한다.평일 오후 3시, 슬랙에 빨간 알림상황은 대충 이렇다. 평화롭게 동기화 잘 되던 평일 오후, 슬랙에 알림이 뜬다.🚨 connector user_activity_mart FAILED. config 백업 후 재시작 시도.뭐 알아서 재시작되겠지 싶다. 10분 주기로 FAILED 감지하면 자동 재시작하는 로직을 돌리고 있으니까.10분 뒤. 다시 ..

서비스가 어느 정도 자리 잡고 나면 한 번씩 겪는 순간이 있다. 누가 분석 쿼리 하나 던지면 운영 DB가 픽픽 쓰러지기 시작하는 순간.우리도 그랬다. 비개발 직군에서 "이번 달 액티브 유저 수가 얼마야?", "이 콘텐츠 통계 좀 뽑아줘" 같은 요청이 늘어나면서 운영 DB CPU가 점점 천장을 찍기 시작했다. 처음엔 슬로우 쿼리만 잡으면 됐는데 어느 순간부터는 그것만으론 부족했다. 분석용 데이터를 따로 떼어내야 할 시점이 온 거다.그래서 CDC(Change Data Capture) 파이프라인을 구축하게 됐다. 보통 CDC 하면 Debezium을 떠올리는데, 우리는 Kafka Connect의 JDBC source connector로 갔다. 오늘은 왜 그렇게 골랐는지에 대한 얘기다.우리가 풀어야 했던 진짜 문..