복제(ReplicatedMergeTree)와 ClickHouse Keeper — 메타데이터 조율과 데이터 페치
ClickHouse 복제(ReplicatedMergeTree/Keeper) 및 TTL 공식 문서·기술 블로그 종합 (웹 리서치, 2026) — ClickHouse 공식 문서(engines/table-engines/mergetree-family/replication, concepts/features/operations/delete/ttl) ClickHouse 공식 문서 Replicated table engines
이 모듈을 다 읽으면
- 조율 서비스(Keeper/ZooKeeper)가 실제 데이터가 아니라 메타데이터만 저장한다는 것을 설명할 수 있다
- 새 파트가 다른 레플리카로 전파되는 과정(로그 알림 → 페치)을 설명할 수 있다
- ClickHouse Keeper가 ZooKeeper 대비 갖는 실무적 이점을 판단할 수 있다
clickhouse-learn-06의 Distributed 테이블(샤딩)과는 별개 축인 복제(replication)를 다룬다 — 같은 데이터의 복제본을 여러 노드에 유지해 장애에 대비하는 ReplicatedMergeTree와, 그 동기화를 조율하는 Keeper/ZooKeeper의 역할을 정리한다.
조율 서비스는 실제 데이터를 저장하지 않는다
ReplicatedMergeTree 테이블은 각 레플리카가 INSERT/MERGE/mutation 같은 데이터 변경 작업을 수행할 때마다, 그 작업 내역을 조율 서비스(ClickHouse Keeper 또는 ZooKeeper)의 해당 테이블 경로 아래에 로그 엔트리로 기록한다. 여기서 핵심은 조율 서비스에 저장되는 것은 '어떤 작업이 있었다'는 메타데이터(로그)일 뿐, 실제 컬럼 데이터 자체는 저장되지 않는다는 점이다 — 이는 clickhouse-learn-06에서 다룬 Distributed 테이블이 '라우팅만 하고 데이터는 안 갖는다'는 것과 유사한 역할 분리 원칙이다.
핵심 포인트
- 조율 서비스(Keeper/ZooKeeper)에는 데이터 변경 작업의 로그(메타데이터)만 기록되고, 실제 컬럼 데이터는 저장되지 않는다
- Distributed 테이블이 라우팅만 하고 데이터를 안 갖는 것과 유사한 역할 분리
새 파트는 어떻게 다른 레플리카로 퍼지는가 — 알림 후 페치
한 레플리카가 INSERT를 받아 로컬 디스크에 새 파트를 만들면, 그 사실이 복제 로그를 통해 다른 레플리카들에게 '새 파트가 생겼다'고 알려진다. 그러면 각 레플리카는 독립적으로 원본 레플리카에 접속해 그 파트를 자기 로컬 파일시스템으로 내려받는다(fetch). 즉 조율 서비스가 데이터를 중계하는 게 아니라, 조율 서비스는 '알림판' 역할만 하고 실제 데이터 전송은 레플리카끼리 직접 주고받는다 — 이 구조 덕분에 조율 서비스 자체의 부하가 데이터 크기와 무관하게 낮게 유지된다.
핵심 포인트
- 새 파트 생성 → 복제 로그로 다른 레플리카에 알림 → 각 레플리카가 원본에서 직접 파트를 fetch
- 조율 서비스는 '알림판' 역할만, 실제 데이터 전송은 레플리카 간 직접 통신 — 조율 서비스 부하가 데이터 크기와 무관하게 낮음
ClickHouse Keeper — ZooKeeper를 대체하는 내장 구현체
ReplicatedMergeTree는 조율 서비스로 ZooKeeper(3.4.5 이상) 또는 ClickHouse Keeper를 쓸 수 있다. ClickHouse Keeper는 ZooKeeper와 같은 와이어 프로토콜을 구사하는 C++ 구현체로, ClickHouse에 내장돼 별도 JVM 기반 ZooKeeper 클러스터를 따로 운영할 필요가 없다는 게 큰 이점이다(Raft 합의 알고리즘 사용). ZooKeeper와 프로토콜이 호환되므로 '드롭인 교체'가 가능하며, 신규 배포에서는 ClickHouse Keeper가 권장된다 — Kafka가 KRaft로 ZooKeeper 의존성을 없앤 것과 같은 방향의 발전이다.
핵심 포인트
- ClickHouse Keeper = ZooKeeper와 같은 와이어 프로토콜을 쓰는 C++ 내장 구현체(Raft 기반), 별도 ZooKeeper 클러스터 불필요
- 프로토콜 호환으로 드롭인 교체 가능, 신규 배포는 Keeper 권장 — Kafka의 KRaft 전환과 같은 방향성