ClickHouse Multi-Datacenter Replication

데이터 인프라의 고가용성(HA)과 재해복구(DR)는 현대 엔터프라이즈 환경에서 필수 요건입니다. 특히 글로벌 서비스를 운영하거나 규제 준수가 필요한 기업에서는 Multi-Datacenter Replication이 중요한 아키텍처 패턴으로 자리잡고 있습니다. 이 글에서는 ClickHouse OSS 환경에서 멀티 데이터센터 복제를 구현하는 방법을 상세히 살펴보겠습니다.

• 왜 Multi-Datacenter Replication이 필요한가?
• ClickHouse OSS의 복제 아키텍처 이해
• 핵심 개념: Shard와 Replica
• Multi-Datacenter 구성 패턴
• 패턴 1: Active-Active 양방향 복제
• 패턴 2: Active-Passive (DR) 구성
• ClickHouse Keeper의 Multi-DC 배포
• 3-DC Keeper 구성 (권장)
• 2-DC 환경의 Keeper 구성
• 장애 시나리오별 대응
• 시나리오 흐름도
• 모니터링 쿼리
• 네트워크 고려사항
• 대역폭 및 지연시간
• 성능 튜닝
• 운영 체크리스트
• 패턴 3: Dual Ingestion (논리적 복제)
• 이론적 장점
• 실질적인 문제점: 왜 권장하지 않는가
• 1. Offset 동기화의 어려움
• 2. 장애 복구 시나리오의 복잡성
• 3. 데이터 정합성 검증 불가
• 비교: 물리적 복제 vs 논리적 복제 (Dual Ingestion)
• 결론: Dual Ingestion은 권장하지 않습니다
• ClickHouse Cloud의 자동화된 고가용성
• ClickHouse Cloud 특징
• 결론

왜 Multi-Datacenter Replication이 필요한가?

단일 데이터센터 구성은 여러 위험 요소를 내포합니다. 자연재해, 네트워크 장애, 전력 문제 등으로 인해 전체 서비스가 중단될 수 있습니다. Multi-Datacenter Replication은 이러한 위험을 분산시키고, 지리적으로 분산된 사용자에게 낮은 지연시간을 제공하며, 규제 요건(데이터 주권, 백업 정책 등)을 충족하는 데 핵심적인 역할을 합니다.

ClickHouse OSS의 복제 아키텍처 이해

ClickHouse는 ReplicatedMergeTree 테이블 엔진을 통해 데이터 복제를 구현합니다. 이 엔진은 ClickHouse Keeper(또는 ZooKeeper)를 coordination layer로 사용하여 복제본 간의 일관성을 유지합니다.

핵심 개념: Shard와 Replica

ClickHouse 클러스터는 Shard와 Replica라는 두 가지 축으로 구성됩니다.

• Shard: 데이터의 수평 분할 단위로, 전체 데이터셋을 여러 노드에 분산 저장
• Replica: 동일한 Shard 내에서 데이터의 복제본, 고가용성 제공

Multi-Datacenter 환경에서는 각 Shard의 Replica를 서로 다른 데이터센터에 배치하여 DC 레벨의 장애에 대응합니다.

Multi-Datacenter 구성 패턴

패턴 1: Active-Active 양방향 복제

가장 일반적인 패턴은 두 개 이상의 데이터센터에서 동시에 읽기/쓰기를 처리하는 Active-Active 구성입니다.

클러스터 설정 예시:

패턴 2: Active-Passive (DR) 구성

재해복구 목적으로 Primary DC에서만 쓰기를 처리하고, Secondary DC는 읽기 전용 복제본을 유지하는 패턴입니다.

테이블 생성 예시:

-- Primary DC에서 테이블 생성
CREATE TABLE events ON CLUSTER 'multi_dc_cluster'
(
    event_id UUID,
    event_time DateTime,
    user_id UInt64,
    event_type String,
    payload String
)
ENGINE = ReplicatedMergeTree(
    '/clickhouse/tables/{shard}/events',
    '{replica}'
)
PARTITION BY toYYYYMM(event_time)
ORDER BY (event_time, event_id);

ClickHouse Keeper의 Multi-DC 배포

복제의 핵심인 ClickHouse Keeper는 반드시 홀수 개의 노드로 구성해야 하며, 데이터센터 장애 시에도 quorum을 유지할 수 있도록 배치해야 합니다.

3-DC Keeper 구성 (권장)

Keeper 설정 예시:

2-DC 환경의 Keeper 구성

두 개의 데이터센터만 있는 경우, 세 번째 Keeper를 "witness" 역할로 클라우드나 별도 위치에 배치하는 것을 권장합니다.

장애 시나리오별 대응

시나리오 흐름도

모니터링 쿼리

-- 복제 지연 모니터링
SELECT
    database,
    table,
    replica_name,
    queue_size,
    inserts_in_queue,
    merges_in_queue,
    absolute_delay
FROM system.replicas
WHERE absolute_delay > 0;

-- Read-only 상태 확인
SELECT
    database,
    table,
    is_readonly,
    is_session_expired
FROM system.replicas
WHERE is_readonly = 1;

네트워크 고려사항

대역폭 및 지연시간

성능 튜닝

운영 체크리스트

패턴 3: Dual Ingestion (논리적 복제)

물리적 복제 외에도, 각 데이터센터에서 독립적으로 동일한 데이터를 수집하는 Dual Ingestion 방식을 고려할 수 있습니다. 이 방식은 Kafka, Kinesis 등 메시지 큐에서 양쪽 DC가 각각 데이터를 consume하는 구조입니다.

이론적 장점

이 방식은 표면적으로 몇 가지 장점이 있어 보입니다:

실질적인 문제점: 왜 권장하지 않는가

그러나 실제 운영 환경에서는 심각한 문제가 발생합니다:

1. Offset 동기화의 어려움

각 DC의 Consumer Group은 독립적으로 offset을 관리합니다. 네트워크 지연, Consumer 처리 속도 차이, 일시적 장애 등으로 인해 양쪽 DC의 offset은 항상 다를 수 있습니다.

DC1 Consumer: partition-0 offset 12847, partition-1 offset 8932
DC2 Consumer: partition-0 offset 12845, partition-1 offset 8930

→ 언제 어떤 메시지가 누락되었는지 파악 불가

2. 장애 복구 시나리오의 복잡성

DC1에서 Kafka Consumer가 1시간 동안 장애가 발생했다고 가정해봅시다:

문제 상황:
- DC1: 1시간 동안 데이터 수집 중단
- DC2: 정상 수집 진행

복구 시 선택지:
1. DC1 offset을 1시간 전으로 되돌림 → 중복 데이터 발생
2. DC1 현재 offset부터 재개 → 1시간 데이터 유실
3. DC2에서 DC1으로 데이터 복사 → 어떤 데이터가 누락인지 파악 어려움

→ 어느 방법도 완벽하지 않음

3. 데이터 정합성 검증 불가

-- DC1에서 실행
SELECT count(*) FROM events WHERE event_date = today();
-- 결과: 1,847,293

-- DC2에서 실행 (동일 쿼리)
SELECT count(*) FROM events WHERE event_date = today();
-- 결과: 1,847,156

-- 137건 차이 → 어느 쪽이 정확한가?

양쪽 DC의 데이터가 다를 때, 어느 쪽이 올바른 데이터인지 판단할 수 없습니다. 물리적 복제에서는 단일 source of truth가 있지만, Dual Ingestion에서는 두 개의 독립적인 truth가 존재합니다.

비교: 물리적 복제 vs 논리적 복제 (Dual Ingestion)

결론: Dual Ingestion은 권장하지 않습니다

Dual Ingestion은 이론적으로는 간단해 보이지만, 실제 운영에서는 데이터 정합성과 장애 복구 측면에서 심각한 문제를 야기합니다. 특히 Kafka offset 불일치 시 양쪽 DC의 데이터를 맞추는 것이 사실상 불가능합니다.

Multi-DC 환경에서는 반드시 **물리적 복제(ReplicatedMergeTree)**를 사용하여 단일 source of truth를 유지하고, ClickHouse의 검증된 복제 메커니즘을 활용하시기 바랍니다.

ClickHouse Cloud의 자동화된 고가용성

지금까지 OSS 환경에서의 Multi-DC 구성을 살펴보았습니다. 보시다시피 안정적인 운영을 위해서는 Keeper 클러스터 관리, 네트워크 구성, 장애 대응 자동화 등 상당한 운영 부담이 따릅니다.

ClickHouse Cloud 특징

ClickHouse Cloud는 이러한 복잡성을 추상화하여 제공합니다. 모든 서비스는 기본적으로 다중 가용영역(Multi-AZ)에 분산 배포되어, AZ 레벨의 장애에 자동으로 대응합니다.

더 나아가, Cross-Region Replication 기능이 로드맵에 포함되어 있어, 서로 다른 지리적 리전 간의 데이터 복제가 완전히 자동화될 예정입니다. 글로벌 재해복구(DR) 요건과 데이터 지역성 규제를 손쉽게 충족할 수 있게 됩니다.

결론

Multi-Datacenter Replication은 미션 크리티컬한 워크로드에서 반드시 고려해야 할 아키텍처 패턴입니다. ClickHouse OSS는 유연하고 강력한 복제 기능을 제공하지만, 안정적인 운영을 위해서는 깊은 이해와 지속적인 관리가 필요합니다. 조직의 요구사항과 운영 역량을 고려하여 적합한 방식을 선택하시기 바랍니다.