ClickHouse Cloud 개요 (SharedMergeTree, 티어, 리전, 셀프 호스팅과 차이)

한 줄 정리

ClickHouse Cloud 는 ClickHouse Inc. 가 운영하는 완전 관리형 서비스입니다. 오픈소스 ClickHouse 와 같은 SQL, 같은 포맷, 같은 클라이언트를 쓰지만, 저장은 오브젝트 스토리지(S3, GCS, Azure Blob)에 두고 컴퓨트는 필요할 때만 켜는 구조라서 운영 방식이 꽤 다릅니다. 고객에게 제안할 때는 "ClickHouse 를 쓴다" 보다 "SharedMergeTree 위에서 컴퓨트를 빌려 쓴다" 고 설명하는 쪽이 오해가 적습니다.

구조: 저장과 컴퓨트의 분리

Cloud 아키텍처 문서가 말하는 핵심은 세 가지입니다.

• 오브젝트 스토리지 기반 저장: 용량이 사실상 무제한이고 샤딩을 손으로 할 필요가 없습니다. 자주 안 읽는 데이터도 싼 값에 둘 수 있습니다.
• 컴퓨트 자동 조정: 미리 크게 잡아 둘 필요가 없고, 아무도 안 쓰면 자동으로 멈춥니다(유휴 종료). 기본으로 고가용성입니다.
• 격리: 서비스마다 별도 Kubernetes 파드와 네트워크 격리, 저장소는 AWS 와 GCP 는 공유 버킷의 서비스별 하위 경로(IAM 역할은 서비스마다 고유), Azure 는 서비스별 컨테이너입니다.

같은 데이터를 여러 컴퓨트 묶음이 나눠 쓰는 compute-compute 분리(웨어하우스) 와, 쿼리 하나에 임시 워커를 빌리는 On-Demand Compute (PrPr) 는 컴퓨트와 스케일링 문서에서 다룹니다.

SharedMergeTree

Cloud 의 모든 MergeTree 계열 테이블은 SharedMergeTree 계열로 자동 치환됩니다. CREATE TABLE 에 ENGINE = MergeTree 라고 써도, 심지어 엔진을 생략해도(default_table_engine = MergeTree) 결과는 SharedMergeTree 입니다. Replicated* 라고 써도 같은 Shared* 엔진으로 바뀌고, SHOW CREATE TABLE 에서 치환된 이름이 보입니다.

CREATE TABLE events (
    ts DateTime,
    user_id UInt64,
    event String
)
ORDER BY (user_id, ts);

SHOW CREATE TABLE events;
-- ENGINE = SharedMergeTree('/clickhouse/tables/{uuid}/{shard}', '{replica}')

ReplicatedMergeTree 는 데이터가 S3 에 있어도 메타데이터는 각 서버에 있어서 레플리카가 늘어날 때마다 메타데이터를 복제해야 했습니다. SharedMergeTree 는 레플리카끼리 통신하지 않고 공유 저장소와 ClickHouse Keeper 로만 조정합니다(비동기, 리더 없는 복제). 그래서 INSERT 처리량, 백그라운드 머지와 뮤테이션 처리량, 스케일 업과 다운 속도가 좋아지고, SELECT 의 일관성 확보도 가벼워집니다. 자세한 엔진 동작은 MergeTree 엔진 과 복제와 샤딩 을 보세요.

운영에서 달라지는 점은 다음과 같습니다.

• insert_quorum, insert_quorum_parallel 은 필요 없습니다. 모든 INSERT 가 공유 저장소에 쓰는 쿼럼 INSERT 입니다.
• select_sequential_consistency 는 Keeper 에 부하를 주니 평소에는 쓰지 않습니다. 같은 세션이나 같은 노드에서 쓰고 읽으면 이미 최신 메타데이터를 봅니다.
• system.replication_queue 와 system.replicated_fetches 가 없고, 대신 system.virtual_parts (현재 파트와 진행 중인 머지, 뮤테이션, 파티션 삭제) 와 system.shared_merge_tree_fetches 가 있습니다.

팁 셀프 호스팅용 운영 스크립트를 그대로 옮기면 system.replication_queue 조회에서 깨집니다. Cloud 로 갈 때는 모니터링 쿼리를 먼저 점검하세요. 모니터링 문서에 Cloud 와 OSS 양쪽에서 쓰는 쿼리를 정리해 두었습니다.

Shared Catalog 와 Shared 데이터베이스 엔진

Shared Catalog 는 상태 없는(stateless) 엔진을 쓰는 데이터베이스와 테이블의 메타데이터와 DDL 을 레플리카 전체에 복제하는 Cloud 전용 구성 요소입니다. 테이블 데이터는 복제하지 않고 정의만 맞춥니다. 모든 메타데이터와 DDL 이력은 ZooKeeper(Keeper) 에 중앙 저장되고 로컬 디스크에는 아무것도 남지 않아서, 컴퓨트 노드가 완전히 무상태가 되고 새 레플리카 기동이 빨라집니다.

Shared 데이터베이스 엔진은 Replicated 데이터베이스 엔진을 개선한 것으로 CREATE TABLE ... AS SELECT 가 원자적으로 실행됩니다(전부 되거나 테이블이 안 만들어짐). Shared, PostgreSQL, MySQL, DataLakeCatalog 데이터베이스 엔진의 복제를 지원합니다.

티어: Basic, Scale, Enterprise

티어는 조직 단위로 정해지고 조직 안의 모든 서비스가 같은 티어입니다. 올리는 것은 언제나 가능하지만(Basic 에서 Scale, Scale 에서 Enterprise), 내리려면 프리미엄 기능을 먼저 꺼야 합니다.

• Basic: 부서 단위, 작은 데이터, 강한 가용성 보장이 필요 없는 곳. 단일 레플리카라 크기가 고정이고 스케일링이 없습니다. 유휴 종료가 기본으로 켜져 있습니다.
• Scale: 레플리카 2개 이상의 SLA, 확장성, 프라이빗 네트워킹이 필요한 운영 워크로드. 대부분의 고객 제안은 여기서 시작합니다.
• Enterprise: 표준 프로필은 vCPU 대 메모리 1:4, HighMemory 커스텀 프로필은 1:8. SSO, 강화 암호화, 요일과 시간대를 고르는 예약 업그레이드, HIPAA 와 PCI 리전.

주의 티어 표의 "가능, 없음" 은 2026년 10월 기준 공식 티어 문서를 옮긴 것입니다. 티어 구성은 자주 바뀌니 견적 전에 꼭 티어 문서 를 다시 보세요.

배포 옵션 네 가지

BYOC 와 Private 는 Cloud 와 같은 바이너리를 쓰기 때문에 SharedMergeTree, 웨어하우스 같은 Cloud 기능이 그대로 옵니다. 자세한 조건과 제약은 BYOC, 백업, Cloud API, Terraform 에서 다룹니다.

리전

2026년 10월 기준 공식 리전 표에서 한국 고객이 자주 보는 것만 뽑으면 다음과 같습니다. Public 은 누구나 바로 만들 수 있는 리전, Private 은 요청해야 열리는 리전, BYOC 는 BYOC 가 되는 리전입니다.

GCP 에는 서울 리전이 없고 Azure 는 한국 리전이 없어서, 국내 지연 시간이 중요하면 AWS 서울이 사실상 유일한 답입니다. Enterprise 티어는 Private Region 을 따로 요청할 수 있는데, 이 리전은 자동 스케일링과 유휴 종료가 되지 않습니다.

가동률은 status.clickhouse.com 에서 리전별로 볼 수 있고 장애 알림을 구독할 수 있습니다. SLA 는 약정 계약 고객에게만 제공되며 영업팀과 협의합니다.

오픈소스와 다른 점 (호환성)

• 인터페이스는 HTTPS, 네이티브 TCP, MySQL 와이어 프로토콜을 지원합니다. PostgreSQL 와이어 프로토콜은 아직 "곧 지원" 입니다.
• 지원 테이블 엔진: Shared 계열 외에 URL, View, MaterializedView, GenerateRandom, Null, Buffer, Memory, IcebergS3, IcebergAzure, DeltaLake, Hudi, MySQL, MongoDB, NATS, RabbitMQ, PostgreSQL, S3, Kafka. 실험적 Paimon 엔진은 지원팀에 문의해 켭니다.
• MySQL 데이터베이스 엔진은 지원하지 않고 MySQL 테이블 엔진만 지원합니다.
• 딕셔너리 소스는 PostgreSQL, MySQL, 원격과 로컬 ClickHouse, Redis, MongoDB, HTTP 를 지원합니다.
• 설정 변경은 config.xml 을 만질 수 없고 SQL 의 SETTINGS, 설정 프로필, 지원팀 요청으로 합니다. 서버 설정 전반은 서버 설정 을 보세요.

참고 사용 한도(가드레일) 는 Cloud 가 성능을 지키기 위해 두는 소프트 리밋입니다. 데이터베이스 1,000개, 테이블 5,000개, 파트 10,000개(max_parts_in_total), 파트 크기 150 GB, 레플리카당 동시 쿼리 1,000 같은 숫자가 있고, 가까워지면 경고가 옵니다. 숫자는 컴퓨트와 스케일링 끝부분에 표로 두었습니다.

처음 만들 때 체크리스트

1. IP 액세스 리스트 를 바로 좁히세요. 기본값은 "어디서나 허용" 이고, 인터넷 크롤러가 유휴 서비스를 깨워서 비용이 나올 수 있습니다. 네트워크와 보안.
2. 운영이면 레플리카 2개 이상 으로 만드세요. 웨어하우스의 첫 서비스는 API 로 만들 때 numReplicas 가 2 이상이어야 합니다.
3. 릴리스 채널 을 정하세요. Basic 은 fast 채널에 자동 등록되고, Scale 과 Enterprise 는 regular 가 기본, Enterprise 는 slow 와 예약 업그레이드를 고를 수 있습니다. BYOC, 백업, Cloud API, Terraform.
4. 백업 주기와 보관 기간 을 RPO 에 맞춰 조정하세요. 기본은 24시간마다 1회, 1일 보관입니다.
5. 지출 알림 을 걸고 자동 스케일링 최대 메모리를 정해 두세요. 비용 구조와 절감.
6. 테이블은 셀프 호스팅과 같은 원칙으로 설계하세요. 정렬 키가 8할입니다. 정렬 키, 기본 키, 파티션.

공식 문서

• ClickHouse Cloud 티어
• Cloud 아키텍처
• SharedMergeTree
• 배포 옵션
• 지원 리전
• Cloud 호환성