ClickHouse HA

ClickHouse는 기본적으로 OLAP(분석) 용도 DB로 설계되었으며, 멀티 노드 구성을 통해 **고가용성(HA)**을 실현할 수 있습니다.
그 핵심은 ReplicatedMergeTree 엔진(또는 변형: ReplicatedReplacingMergeTree, ReplicatedCollapsingMergeTree 등)을 사용해 서로 다른 노드에 테이블을 복제(Replication) 하고, **클라이언트(또는 Distributed 테이블)**에서 읽기 쿼리를 요청할 때 건강한(접근 가능한) 노드 중 하나에 연결하는 구조입니다.

아래에서는 ClickHouse HA 아키텍처의 주요 요소와 구현 방법을 단계별로 정리해 봅니다.

---

1. ReplicatedMergeTree로 테이블 복제

1. ReplicatedMergeTree 엔진
   • ClickHouse에서 고가용성을 구현하는 핵심은 테이블을 ReplicatedMergeTree 계열로 생성하는 것입니다.
   • 예:
     sql

     복사

     CREATE TABLE my_table ( event_time DateTime, user_id UInt64, ... ) ENGINE = ReplicatedMergeTree( '/clickhouse/tables/{shard}/my_table', -- ZooKeeper 경로 '{replica}' -- ZooKeeper에서의 replica 식별자 ) PARTITION BY toYYYYMM(event_time) ORDER BY (event_time, user_id);
   • 여기서 ZooKeeper(또는 최근에는 ClickHouse Keeper)가 테이블 메타데이터와 복제 상태를 관리합니다.
   • 한 샤드(Shard) 내 여러 노드가 동일한 테이블을 비동기로 복제하여, 어느 한 노드가 다운되더라도 다른 노드에서 데이터를 제공할 수 있게 됩니다.
2. 복제 구조 동작
   • 노드 A에서 새로 들어온 데이터 파트가 생성되면, ZooKeeper를 통해 “이 파트가 생겼다”는 사실을 다른 노드들이 인지하고, Pull 방식으로 해당 파트를 가져와 로컬에 저장합니다.
   • 이는 Eventually Consistent 모델입니다(완전한 동기화가 아닌 비동기 복제).
3. 샤드(Shard) & 복제(Replica)
   • 대규모 데이터를 처리하기 위해, 보통 여러 샤드를 구성하고, 각 샤드별로 2개 이상의 Replica를 둬서 HA를 확보합니다.
   • 즉 “샤딩(데이터 분산) + 복제(노드 장애 대비)”라는 이중 구조로 확장성과 가용성을 동시에 얻습니다.

---

2. 읽기/쓰기 시 HA 구성

1. 쓰기(INSERT)
   • 클라이언트가 특정 노드에 INSERT를 보내면, 해당 노드가 먼저 로컬 파트를 만든 뒤, ZooKeeper에 기록해 “새 파트”가 생겼음을 알립니다.
   • 다른 Replica 노드는 이를 감지하고, 파트를 다운로드 받아 로컬에 반영합니다.
   • 완전한 동기식(Strong Consistency)은 아니므로, 네트워크 지연이나 노드 상황에 따라 타 Replica 반영이 조금 늦어질 수 있습니다(비동기).
2. 읽기(SELECT)
   • 클라이언트가 복제본 중 하나로 쿼리를 보내면, 그 노드가 로컬에 있는 데이터를 활용해 SELECT를 수행합니다.
   • 만약 어떤 Replica 노드가 다운되면, 로드 밸런서나 클라이언트 드라이버(또는 Distributed 테이블)가 다른 Replica로 요청을 시도하여 서비스 중단을 막습니다.
3. Distributed 테이블
   • 각 샤드/Replica 위에 Distributed 엔진 테이블을 만들어 두면, 클라이언트 입장에서 하나의 테이블에 쿼리를 보내는 것처럼 보이지만, 내부적으로 각 Replica에게 쿼리를 분산·집계합니다.
   • 샤드나 Replica 중 일부가 비정상이면 자동으로 요청을 재시도(retry)하거나, 나머지 노드에서 데이터를 가져와 고가용성을 어느 정도 확보합니다.

---

3. ZooKeeper (또는 ClickHouse Keeper)의 역할

1. 메타데이터 및 파트(Part) 동기화
   • ReplicatedMergeTree 테이블은 ZooKeeper 상의 경로(ex: /clickhouse/tables/cluster_db/my_table/replicas/replica1)를 사용해, 어떤 파트들이 있는지, 복제 진행 상태가 어떤지, 장애가 발생했는지 등을 관리합니다.
   • 모든 Replica 노드는 이 경로를 공유하여, “나는 아직 이 파트를 못 받았다” 등을 확인하며 데이터를 동기화합니다.
2. HA를 위한 ZooKeeper 클러스터
   • ZooKeeper 자체도 3노드 이상의 쿼럼 구성을 통해 고가용성을 가져야 합니다.
   • ClickHouse 21.9 버전 이후에는 ClickHouse Keeper라는 ZooKeeper 호환 내장 기능이 제공되므로, ZooKeeper 없이도 HA 메타스토어를 구축할 수 있습니다(규모가 크지 않은 경우).
3. 주의사항
   • ZooKeeper(또는 CH Keeper)가 완전히 다운되면, 새 파트 생성(INSERT)이나 복제 동작이 제대로 이루어지지 않습니다(기존에 받은 파트로 SELECT는 가능).
   • 즉, 메타스토어가 단일 장애점(SPOF)이 되지 않도록 ZooKeeper 클러스터도 중복 구성해야 합니다.

---

4. 실제 HA 구성 방법

1. 기본 개념
   • 노드 2~3개(혹은 그 이상)를 한 샤드로 묶고, ReplicatedMergeTree 테이블을 구성.
   • 그리고 필요에 따라 여러 샤드가 있을 경우, 샤드마다 2개 이상의 Replica.
   • ZooKeeper/CH Keeper는 3개 이상의 노드로 쿼럼 클러스터를 구성.
2. 샤드/Replica 예시
   • 2샤드 x 2Replica: 총 4대 ClickHouse 노드 (혹은 4+@로 ZooKeeper 별도 구성)
   • 각 샤드: 노드 A(Replica 1), 노드 B(Replica 2)
   • 두 번째 샤드: 노드 C(Replica 1), 노드 D(Replica 2)
   • 상단에 Distributed 테이블이 있어서, “SELECT * FROM distributed_table” 쿼리 시 A/B/C/D가 모두 참여.
3. 로드밸런싱/리다이렉션
   • 클라이언트가 노드 A로 쿼리 요청 → 노드 A 장애 시, 자동으로 노드 B로 fallback.
   • 이를 위해 DNS 라운드 로빈, HAProxy, Keepalived + VIP, ClickHouse 자체 distributed_replica_selection_mode 옵션 등 다양한 방법을 활용합니다.
4. Auto-Failover
   • 마스터-슬레이브 구도가 아니라 멀티 마스터(Active-Active) 구조이므로, 노드 A가 장애 시 B가 자동으로 INSERT/SELECT를 받을 수 있습니다(동시에 모수가 커진 만큼 B에 부하가 집중될 수 있음을 주의).

---

5. 장애 대응 시나리오

1. Replica 노드 다운
   • 다운된 Replica가 복구 후 다시 올라오면, 해당 노드가 ZooKeeper를 통해 missing 파트를 인지하고, 자동으로 다른 Replica에게 필요한 파트를 복사해 최신 상태가 됩니다.
   • 장애 시간 동안 INSERT된 데이터도 그대로 복제되므로, 일관성 유지에 크게 문제없습니다.
2. ZooKeeper(또는 CH Keeper) 장애
   • ZooKeeper 클러스터가 2/3 노드 이상 동작 중이면 쿼럼 유지, INSERT/SELECT에 문제 없음.
   • ZooKeeper가 완전히 불능이면 새 파트 생성(INSERT)은 차단되고, SELECT는 이미 로컬에 있는 데이터로만 가능합니다.
   • ZooKeeper 복구 후 다시 정상 동작.
3. 분산 테이블에서 일부 Replica 오프라인
   • 분산 테이블 쿼리 시, 해당 Replica가 반응 없으면 다른 Replica로부터 데이터를 가져오거나, 일부 파티션만 응답해 에러 대신 가능한 부분만 반환(설정에 따라 다름)할 수 있습니다.

---

6. 요약

1. ReplicatedMergeTree 엔진 + ZooKeeper(또는 CH Keeper):
   • HA 구성의 핵심. 각 노드는 비동기로 파트를 복제하며, 어느 노드가 다운되어도 나머지 노드에서 데이터 조회/쓰기가 가능.
2. 멀티 노드(Replica), 멀티 샤드:
   • 확장성 + 가용성을 동시에 달성.
   • 샤드는 데이터를 수평 분산(Scale-out)하고, Replica는 노드 장애 시에도 데이터를 잃지 않도록 함.
3. Distributed 테이블 + 로드밸런서
   • 하나의 논리적 테이블처럼 쿼리를 보내면, 백엔드에서 Replica 노드를 찾아가 집계.
   • 노드 장애 시 자동 Failover(혹은 재시도)로 서비스 중단 최소화.
4. Eventually Consistent
   • 완벽한 동기화가 아닌 비동기 복제이므로, OLTP처럼 “즉각적인 트랜잭션 일관성”을 보장하진 않음.
   • 하지만 OLAP 시나리오에서는 충분히 높은 가용성을 제공.

ClickHouse의 HA는 기본적으로 “Active-Active 비동기 복제” 모델로 구현되며, ZooKeeper/CH Keeper가 중앙 메타스토어 역할을 담당합니다.
노드가 장애 났을 때 나머지 Replica로 요청을 보내면 되고, 장애 복구 후에는 자동으로 파트 동기화를 진행한다는 점이 핵심입니다.