클릭하우스(ClickHouse)가 포스트그레스(Postgres)의 데이터를 클릭하우스로 복제하는 오픈소스 엔진 'WalShadow'를 공개했다. 핵심은 복제 방식의 근본적인 전환에 있다. 기존의 변경 데이터 캡처(CDC) 도구가 대부분 의존해 온 논리적 복제(logical replication) 대신, 포스트그레스가 물리 복제와 복구를 위해 이미 생성하는 물리 WAL(Write-Ahead Log) 스트림을 그대로 소비한다. 클릭하우스는 벤치마크에서 커밋된 트랜잭션이 약 200밀리초 만에 클릭하우스에서 조회 가능해졌고, 초당 28만 9,000행을 지속적으로 처리했다고 밝혔다.
논리적 복제 대신 물리 WAL을 읽는다는 것
이 둘의 차이를 이해하려면 부하가 어디에 걸리는지를 봐야 한다. 논리적 복제는 원본 데이터베이스가 WAL을 논리적 이벤트로 디코딩하고, 복제 슬롯을 유지하며, 출력 플러그인을 통해 변경 사항을 내보내는 과정을 거친다. 이 디코딩과 직렬화 작업 자체가 원본 포스트그레스 인스턴스의 자원을 소모하고 운영 부담을 만든다. 반면 WalShadow는 원본에 '변경을 해석해 달라'고 요청하지 않는다. 물리 스탠바이(standby)가 받는 것과 동일한 WAL 스트림을 밖으로 받아 와, 원본 데이터베이스 외부에서 네 단계를 거쳐 디코딩한 뒤 클릭하우스 네이티브 블록으로 직접 기록한다.
그 결과 논리적 복제 슬롯이 필요 없고, 카프카(Kafka) 같은 중간 메시징 계층이나 JSON 직렬화, 별도의 정규화 단계도 사라진다. 원본은 물리 WAL을 전송하기만 하면 되므로, 부하 프로파일이 물리 스탠바이를 하나 더 붙인 것과 유사한 수준에 그친다. 분석 부하를 위해 원본 트랜잭션 데이터베이스에 가하는 압박을 최소화한다는 점은, OLTP와 OLAP를 분리해 운영하는 실무자에게 실질적인 의미가 있다.
병렬 처리와 순서 보장의 균형
성능을 끌어올리기 위해 WalShadow는 블록을 병렬로 처리하는데, 이 때문에 데이터가 클릭하우스에 순서가 뒤바뀐 채 도착할 수 있다. WalShadow는 모든 행에 원본 WAL 위치를 나타내는 _lsn 값을 붙여 이 문제를 푼다. 클릭하우스는 이 값을 기준으로 각 키에 대해 가장 최신 버전만 유지하므로, 도착 순서가 어긋나도 최종 상태의 정합성이 보장된다. 반대로 스키마 변경이나 테이블 트렁케이트(truncate)처럼 엄격한 순서가 필요한 작업은 배리어(barrier)를 두어, 앞선 모든 데이터가 내구성 있게 반영될 때까지 기다린 후 적용한다. 또한 초기 적재, 연속 복제, 재시작 복구, 계획된 소스 전환(switchover)에 더해 ADD COLUMN·RENAME COLUMN·DROP COLUMN·CREATE TABLE 같은 스키마 변경까지 복제 생애주기 전반을 다룬다는 점을 강조했다.
벤치마크와 그 한계
비교 대상은 클릭하우스 자사의 CDC 도구인 PeerDB다. PeerDB는 논리적 복제 기반으로 ClickPipes를 구동하며, 원래 클릭하우스가 인수해 확보한 기술이다. 동일 리전에 배치한 8 vCPU c8i.2xlarge 인스턴스에서 단일 테이블의 연속 변경을 복제한 조건에서, 네이티브 물리 복제본이 약 50밀리초의 기준선을 보였고 WalShadow는 약 200밀리초를 기록했다. PeerDB는 약 10초 수준으로, 이 벤치마크상 WalShadow가 약 50배 낮은 지연을 보였다. 처리량에서도 원본이 초당 약 29만 행을 넣는 동안 WalShadow는 28만 9,000행을 소화해 사실상 원본 속도를 따라잡았고, PeerDB는 약 12만 행으로 원본의 40% 수준에 머물렀다.
다만 이 수치는 단일 테이블에 대한 연속 삽입이라는 통제된 조건의 결과라는 점을 함께 읽어야 한다. 클릭하우스 스스로도 성능은 워크로드에 따라 달라진다고 밝혔다. 다수 테이블, 복잡한 트랜잭션, 대량의 갱신·삭제가 섞인 실제 운영 환경에서 동일한 지연과 처리량이 재현될지는 별개의 문제다. 벤치마크는 아키텍처가 만들어내는 격차의 방향성을 보여 주는 지표로 보는 편이 안전하다.
가용성의 전제 조건
실무 도입에서 가장 큰 제약은 물리 WAL 접근성이다. WalShadow는 물리 WAL을 직접 소비하는 것이 아키텍처의 핵심인데, 대부분의 매니지드 포스트그레스 서비스는 고객에게 물리 WAL을 노출하지 않는다. 즉 아마존 RDS를 비롯한 상당수 관리형 환경에서는 이 도구를 그대로 적용하기 어렵다는 뜻이다. 클릭하우스는 이 한계를 겨냥해, 스택 양쪽을 자사가 관리하는 ClickHouse Managed Postgres에 WalShadow를 통합하고 이를 프라이빗 프리뷰로 제공한다. 스스로 포스트그레스를 운영해 물리 WAL을 확보할 수 있는 조직이라면 깃허브에 공개된 오픈소스를 바로 쓸 수 있지만, 관리형 서비스를 쓰는 조직에는 선택지가 제한된다.
결국 WalShadow는 PeerDB 인수, ClickPipes의 포스트그레스 CDC, ClickHouse Managed Postgres로 이어져 온 '트랜잭션은 포스트그레스, 분석은 클릭하우스'라는 통합 스택 전략의 연장선에 있다. 클릭하우스는 앞으로 몇 달간 초기 디자인 파트너들과 실제 워크로드에서 안정성을 다듬어 나가겠다고 밝혔다. 지연을 낮추면서 처리량을 희생하지 않는다는 접근은 분명 매력적이지만, 물리 WAL 확보라는 전제와 아직 초기 단계라는 성숙도를 함께 저울질해 검토하는 것이 합리적이다.