8장. Shards & Replicas — 분산 아키텍처

한 대로 감당이 안 되면 나누고(Shard), 장애가 두려우면 복사한다(Replica). 그리고 그 전체를 하나의 테이블처럼 보이게 하는 Distributed 테이블 — ClickHouse 클러스터의 구조와 솔직한 한계까지 살펴봅니다.

8.1 Shard — 데이터를 나누는 단위

샤딩이 필요한 경우는 두 가지입니다: 데이터가 단일 서버의 스토리지를 초과하거나, 단일 서버의 처리 성능이 부족할 때. 샤딩은 테이블의 데이터를 여러 서버로 수평 분할합니다. 각 shard는 데이터의 부분 집합을 담은 평범한 ClickHouse 테이블이며, 독립적으로 쿼리할 수도 있습니다.

[전체 데이터]
   ├── Shard 1 (Server A): 행 1 ~ 1000만
   ├── Shard 2 (Server B): 행 1000만+1 ~ 2000만
   └── Shard 3 (Server C): 행 2000만+1 ~ 3000만

그런데 개별 shard에 직접 쿼리하면 부분 데이터만 보입니다. 전체를 하나의 테이블처럼 보여주는 것이 Distributed 테이블 — 데이터를 전혀 저장하지 않는 라우팅 레이어입니다.

CREATE TABLE uk.uk_price_paid_simple_dist ON CLUSTER test_cluster
(
    date   Date,
    town   LowCardinality(String),
    street LowCardinality(String),
    price  UInt32
)
ENGINE = Distributed('test_cluster', 'uk', 'uk_price_paid_simple', rand())
--                     클러스터         DB      로컬 테이블            sharding key

• SELECT: 모든 shard에 쿼리를 전달하고, 결과를 수집·병합합니다.
• INSERT: 각 행마다 sharding key를 평가해 적절한 shard로 라우팅합니다.

8.2 분산 SELECT — 쿼리는 어떻게 흩어지고 다시 모이는가

"Global Query Plan이 없다" — 가장 중요한 구조적 제약

공식 architecture 문서는 이렇게 솔직하게 말합니다: "분산 쿼리 실행을 위한 global query plan은 없다. 각 노드는 자기 몫에 대한 로컬 플랜만 가진다. 우리는 단순한 1-pass 분산 실행만 지원한다 — 원격 노드에 쿼리를 보내고 결과를 머지할 뿐." 노드 간 데이터 재분배(reshuffle)가 필요한 실행은 지원하지 않습니다.

이 제약이 문제 되는 쿼리 유형:

8.3 분산 INSERT — sharding key가 행의 목적지를 정한다

-- shard별 데이터 분포 확인 (쏠림 감지)
SELECT
    hostName() AS host,
    count() AS rows,
    formatReadableSize(sum(bytes_on_disk)) AS size
FROM clusterAllReplicas('test_cluster', system.parts)
WHERE database = 'uk' AND `table` = 'uk_price_paid_simple' AND active
GROUP BY host;

8.4 Replica — 비동기 멀티마스터 복제

복제의 목적은 세 가지입니다: 데이터 무결성(하드웨어 장애 시 손실 방지), 페일오버(장애 시 다른 레플리카로 서비스 지속), 쿼리 처리량(여러 레플리카에 읽기 분산). 각 shard 안의 모든 레플리카는 동일한 데이터를 보유하며, 복제는 ReplicatedMergeTree 엔진으로 구현됩니다.

CREATE TABLE uk.uk_price_paid_simple ON CLUSTER test_cluster
(
    date   Date,
    town   LowCardinality(String),
    street LowCardinality(String),
    price  UInt32
)
ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/uk_price_paid', '{replica}')
ORDER BY (town, street);
-- 같은 Keeper 경로를 가진 테이블들이 서로의 레플리카가 된다

ClickHouse 복제의 세 가지 핵심 특성:

• 비동기(Asynchronous): 어느 레플리카에 INSERT되면 다른 레플리카로 비동기 복제됩니다. INSERT가 모든 레플리카의 확인을 기다리지 않습니다.
• 멀티마스터(Multi-master): Keeper 세션이 있는 어떤 레플리카에든 INSERT 가능. 단일 마스터 병목이 없습니다.
• Conflict-free: ClickHouse는 제자리 UPDATE가 없으므로(INSERT only + 머지 기반 변환) 복제 충돌 자체가 발생하지 않습니다.

8.5 클러스터의 구조적 한계 — "Not Elastic"

공식 문서가 스스로 인정하는 한계를 아는 것이 중요합니다.

ClickHouse Cloud는 이 한계를 다른 아키텍처로 우회합니다: 오브젝트 스토리지 기반 SharedMergeTree가 레플리카를 대체해 고가용성을 확보하고, Parallel Replicas가 전통적 shard처럼 동작합니다.

ClickHouse Keeper 운영 요점

• Keeper는 ZooKeeper의 ClickHouse 네이티브 대체품으로, ReplicatedMergeTree·ON CLUSTER DDL·분산 INSERT ... SELECT에 필수입니다.
• 과반수 합의를 위해 홀수 노드(3, 5, 7)로 구성하세요.
• Keeper 장애 시 INSERT와 머지는 중단되지만, SELECT는 정상 동작합니다 (읽기는 Keeper에 의존하지 않음).

-- 복제 지연(replication lag) 모니터링
SELECT
    database, `table`, replica_name, is_leader,
    absolute_delay,      -- 최신 레플리카 대비 지연(초)
    queue_size,
    inserts_in_queue,    -- 높으면: 네트워크/파트 다운로드 병목
    merges_in_queue      -- 높으면: 머지 스레드 부족
FROM system.replicas
WHERE absolute_delay > 0
ORDER BY absolute_delay DESC;

✍️ 이해도 체크