Ops Insights – ClickHouse 운영

Managed vs Self-hosted — TCO 크로스오버

Mon, 13 Jul 2026 00:00:00 +0000

Managed vs Self-hosted — TCO 크로스오버

판단을 좌우하는 축은 데이터 크기보다 운영 인력 보유 여부입니다 — 팀 <5명이면 Cloud, 전담 인프라 인력을 낀 10명+면 self-host.
크로스오버는 ~20TB / 24-7 구간. 인프라 비용은 거의 붙어서 결정은 월 $1,600~4,800의 people TCO에서 납니다.
SharedMergeTree(진짜 storage-compute 분리)는 ClickHouse Cloud 전용 — self-host는 RMT 강제. 이 선택은 가격 비교가 아니라 아키텍처 선택입니다.
인력이 이미 있으면 self-host가 비용·성능(로컬 NVMe 수십만 IOPS)에서 모두 앞섭니다.

ClickHouse를 어디에 둘지는 데이터 크기보다 운영 인력을 이미 보유했는지에 달렸습니다. 데이터가 ~5TB에 머물고 사용이 간헐적이면 Cloud가 압승합니다. 60TB+ / 24-7이면 self-host가 명확히 쌉니다. 접전 구간(~~20TB / 24-7)에서는 인프라 비용이 거의 붙어서 결정이 월 $1,600~~4,800의 people TCO ≈로 넘어갑니다. 인력이 이미 있으면 self-host의 유일한 약점이 상쇄돼 성능·비용 모두에서 앞섭니다.

스토리지 아키텍처 — 로컬 NVMe(i7i/i8g)

Mon, 13 Jul 2026 00:00:00 +0000

스토리지 아키텍처 — 로컬 NVMe(i7i/i8g)

로컬 NVMe(hot) + S3(cold) 2티어가 관측성 표준입니다. 수 GB/s·수십만 IOPS를 스토리지 한계비용 $0에 얻는데, EBS로는 물리적으로 낼 수 없는 수치입니다.
기본 인스턴스는 i8g(Graviton4)입니다 — i7i와 IOPS 동률에 ~9% 저렴합니다. x86 의존 바이너리가 있으면 i7i, 초고밀도는 i7ie/i3en.
내구성은 디스크가 아니라 복제로 삽니다: 멀티 AZ replica 2~3 + clickhouse-backup(S3) + Keeper(gp3 영속). zero-copy replication은 금지합니다.
티어링 ≠ 내구성. self-host는 shared-nothing이라 UltraWarm식 “S3 단일 사본” 절감이 없습니다 — 사본 배수(RF)는 그대로 냅니다.
“크게"의 상한은 디스크 용량이 아니라 재수화 시간(재수화 위험 창)이 정합니다.
S3를 primary로 두는 OSS 경로는 존재하지만 복제와 배타입니다 — plain_rewritable은 mutation·테이블 복제를 지원하지 않아 RMT를 포기해야 합니다. 우리가 S3를 cold로만 쓰는 이유입니다(아래 §S3 primary의 OSS 경로).

“i7i 같은 로컬 스토리지를 크게 가져가는 구성이 실제 가능한가” — 답은 가능하고 일정 조건에서는 EBS보다 명백히 낫습니다. 단 “크게"의 상한을 정하는 건 디스크 용량이 아닙니다. 노드 소실 시 재수화 시간이 정합니다. 로컬 NVMe(instance store)는 network block storage보다 5~10배 빠르지만 Ⓑ 휘발성입니다. 그러니 ClickHouse에서 내구성을 떠받치는 것은 **복제(replication)**입니다. 로컬 NVMe 전략의 본질은 “빠른 휘발성 디스크 + 멀티 AZ replica + S3 백업” 3종 세트입니다. 이 페이지는 스토리지 4전략 비교 → i7i/i8g 상세 → 내구성 설계 → 티어링(OpenSearch UltraWarm과의 구조 대응) → k8s local PV·Karpenter 운영 → 재수화까지를 의사결정 순서로 정리합니다. managed vs self-host의 큰 그림과 달러 TCO는 Managed vs Self-hosted가 담당합니다.

clickhouse-operator 선택

Mon, 13 Jul 2026 00:00:00 +0000

clickhouse-operator 선택 — ‘쓸까 말까’가 아니라 ‘어느 것이냐’

replica≥2·shard가 생기는 순간 수동 StatefulSet은 오류투성이가 됩니다. ClickHouse에서 operator는 사실상 필수입니다. “쓸까 말까"가 아니라 “어느 것이냐"의 문제입니다. 2026-07 기준 답은 Altinity clickhouse-operator(7년+ 트랙레코드, 사실상 표준)입니다.

operator 배포 플레이북 — 로컬 NVMe 실전 구성

Wed, 15 Jul 2026 00:00:00 +0000

operator 배포 플레이북 — 로컬 NVMe 실전 구성

Altinity operator + EKS + 로컬 NVMe로 ReplicatedMergeTree 클러스터를 CHK/CHI 필드 수준까지 처음 세우는 종합 문서입니다.

변경관리·스케일·롤링 업그레이드·복구

Wed, 15 Jul 2026 00:00:00 +0000

변경관리·스케일·롤링 업그레이드·복구

이미 서 있는 Altinity operator 클러스터를 규모 변화·업그레이드·장애 앞에서 어떻게 바꾸고 되돌릴지 정리합니다. 기준 버전은 Altinity Kubernetes Operator 0.27.1(2026-06-04)입니다.

프로덕션 운영 사례

Mon, 13 Jul 2026 00:00:00 +0000

프로덕션 운영 사례 — 검증된 것과 귀속(歸屬) 오류

ClickHouse를 PB~경 스케일 관측성 백엔드로 운영하는 사례는 넘치지만 ‘K8s + operator + 로컬 NVMe’ 조합의 순수 1차 실증은 얇습니다.

로컬 NVMe 하드 유저들 — 데이터스토어 횡단 벤치마킹

Tue, 14 Jul 2026 00:00:00 +0000

로컬 NVMe 하드 유저들 — 데이터스토어 횡단 벤치마킹

“휘발성 로컬 NVMe 1차 + 복제 내구성 + 오래된 데이터 S3 티어링"이 업계에서 어디까지 표준인지 9개 데이터스토어로 검증한 페이지입니다.

무신사 CDP — self-hosted ClickHouse에서 Cloud로

Wed, 12 Aug 2026 00:00:00 +0000

무신사 CDP — self-hosted ClickHouse에서 Cloud로

무신사는 CDP의 Audience Engine을 self-hosted ClickHouse에서 ClickHouse Cloud로 옮겼습니다. 노드에 결합된 스토리지가 스케일 국면에서 병목이 된 것이 계기였습니다.

Iceberg·레이크하우스 — 테이블 포맷이 뭐고, S3 메인의 답이 되는가

Wed, 12 Aug 2026 00:00:00 +0000

Iceberg·레이크하우스 — 테이블 포맷이 뭐고, S3 메인의 답이 되는가

Iceberg 는 “S3 를 싸게 쓰는 방법"이 아니라 “여러 엔진이 공유하는 개방 테이블을 만드는 방법"입니다. 그래서 우리의 “S3 를 메인 스토리지로” 문제의 답이 아닙니다 Σ.

ClickHouse 참고 자료

Mon, 13 Jul 2026 00:00:00 +0000

출처 — ClickHouse 배포·오퍼레이터·운영사례 조사 자료

이 페이지는 managed vs self-hosted, 로컬 NVMe 스토리지, 오퍼레이터, operator 배포 플레이북, 변경관리·복구, 프로덕션 운영사례, 데이터스토어 횡단 벤치마킹, 무신사 CDP, Iceberg·레이크하우스 아홉 페이지가 인용한 1차 조사 문서의 ## 출처 섹션을 모아 중복을 제거하고 주제별로 분류했습니다.