운영 환경에서 Postgres CDC를 1년간 사용하며 배운 실전 노하우
운영 환경에서 Postgres 데이터를 ClickHouse로 옮기는 CDC(Change Data Capture)를 1년간 운영하며 겪은 복제 지연 해결책과 아키텍처 설계 노하우를 공유합니다.
김영태
테크리드
안녕하세요, 풀링포레스트의 8년차 개발자 김테크입니다.
백엔드 개발자로서 우리가 가장 신뢰하는 데이터베이스를 하나 꼽으라면 단연 PostgreSQL일 것입니다. 안정적이고, 기능이 풍부하며, 트랜잭션 처리에 탁월하죠. 하지만 서비스가 성장하고 데이터가 쌓이다 보면 필연적으로 마주치는 순간이 있습니다. 바로 복잡한 통계 쿼리나 분석용 SQL을 돌릴 때 DB CPU가 치솟고 서비스 전체가 느려지는 현상입니다.
오늘은 바로 이 시점에 우리가 고려하게 되는 아키텍처, 즉 Postgres의 데이터를 실시간으로 ClickHouse 같은 분석형 DB로 옮기는 CDC(Change Data Capture) 구축 경험과 그 과정에서 얻은 기술적인 교훈을 공유하려 합니다. 최근 ClickHouse 팀에서 PeerDB를 인수하고 통합하여 서비스를 운영한 지난 1년의 회고 내용을 바탕으로, 실무자 입장에서 중요한 포인트들을 정리해 보겠습니다.
왜 굳이 CDC를 도입해야 할까요?
가장 큰 이유는 '적재적소'입니다. 지난 1년여간의 데이터를 살펴보면, 초기에는 Postgres 하나로 트랜잭션과 분석을 모두 처리하려던 팀들이 한계에 부딪히는 시점이 점점 빨라지고 있습니다. 특히 최근 AI 관련 기능이 서비스에 붙으면서 데이터 생성 속도가 기하급수적으로 늘어나고 있습니다. 실제로 일부 AI 네이티브 기업들은 6개월 만에 데이터가 1,000% 이상 증가하기도 했습니다.
이런 상황에서 Postgres에 무거운 집계 쿼리를 날리는 것은 서비스 장애로 가는 지름길입니다. 그래서 트랜잭션(OLTP)은 Postgres에, 분석(OLAP)은 ClickHouse에 맡기는 구조가 각광받고 있습니다. 이를 가능하게 하는 핵심 기술이 바로 CDC입니다.
핵심 트러블슈팅: 복제 연결 재연결 방지 (Reliability)
CDC를 운영하면서 겪게 되는 가장 골치 아픈 기술적 문제는 '복제 지연(Replication Lag)'입니다. 특히 ClickHouse 팀이 지난 1년간 가장 공들여 해결한 문제 중 하나가 바로 '복제 연결의 재연결(Reconnect) 이슈'였습니다. 이 부분은 백엔드 엔지니어로서 매우 흥미로운 지점입니다.
Postgres의 논리적 복제(Logical Replication) 메커니즘을 이해하면 이 문제가 왜 심각한지 알 수 있습니다. CDC 툴이 Postgres와 연결이 끊어졌다가 다시 연결될 때, Postgres는 복제 슬롯(Replication Slot)의 restart_lsn 위치부터 WAL(Write-Ahead Log)을 다시 읽기 시작합니다.
문제는 롱 런 트랜잭션(Long-running transaction)이나 대용량 트랜잭션이 있는 환경입니다. 연결이 끊겼다 재연결될 때, 시스템은 이미 처리했을 수도 있는 아주 먼 과거의 WAL 시점부터 다시 로그를 읽어와야 합니다. 이는 단순히 네트워크가 잠깐 끊긴 것 이상의 비용을 초래합니다.
DB는 디스크에서 오래된 WAL 파일을 다시 읽어야 하므로 I/O 부하가 급증합니다.
CDC 파이프라인은 데이터를 다시 필터링하고 처리하느라 엄청난 지연(Lag)이 발생합니다.
결과적으로 실시간 분석 데이터의 정합성이 깨지는 시간이 길어집니다.
이를 해결하기 위해 운영 환경에서는 '절대로 연결을 포기하지 않는' 구조가 필요합니다. 단순한 재시도 로직을 넘어서, 네트워크 글리치나 일시적 장애 상황에서도 세션을 유지하거나, 재연결 시 불필요한 WAL 스캔을 최소화하는 인프라 레벨의 개선이 필수적입니다. 이 개선이 적용된 후, 대규모 데이터를 다루는 고객사들의 복제 지연 사고가 드라마틱하게 줄어들었다고 합니다.
데이터 웨어하우징으로의 확장
또 하나의 흐름은 CDC가 단순한 서비스 안정화를 넘어, 사내 데이터 웨어하우징의 핵심 파이프라인으로 자리 잡고 있다는 점입니다. 개발팀뿐만 아니라 데이터 분석가, 데이터 과학자들이 내부 BI 도구에서 ClickHouse를 통해 실시간으로 비즈니스 지표를 조회합니다. Postgres 데이터를 ClickHouse로 옮겨두면, 운영 DB에 부하를 주지 않으면서도 수억 건의 데이터에 대한 Group By 쿼리를 밀리초 단위로 수행할 수 있기 때문입니다.
마치며
개발자로서 우리는 늘 "도구의 한계"를 인지해야 합니다. Postgres는 훌륭하지만 만능은 아닙니다. 데이터 규모가 테라바이트 급을 넘어가거나, 복잡한 분석 쿼리가 빈번하다면 Postgres 튜닝만으로 해결하려 하지 말고, 과감하게 아키텍처를 분리하는 것을 고려해 보세요.
특히 CDC를 도입할 때는 단순히 "데이터를 옮긴다"는 개념을 넘어, WAL 처리 방식과 재연결 시나리오 같은 디테일한 장애 상황을 미리 검토해야 합니다. 그래야 새벽에 장애 알람을 받고 깨는 일을 줄일 수 있습니다. 오늘 공유한 내용이 여러분의 데이터 아키텍처 설계에 작은 힌트가 되었기를 바랍니다.
