ClickHouse (self-hosted on EKS) — 통합 저장소로서의 야심

컬럼형(column-oriented) OLAP 데이터베이스입니다. Yandex에서 출발해 오픈소스로 공개된 Apache-2.0 프로젝트이고 대규모 분석 쿼리에 최적화된 성숙한 엔진입니다. 로그·트레이스·이벤트·웹 RUM을 한 스키마 계열·SQL 인터페이스로 흡수하는 “통합 관측성 저장소” 후보로 자주 거론됩니다.

강점

• 압축·저장 밀도가 이 클래스에서 최상급입니다. 컬럼 파일 위에 타입별 codec을 깔고 그 위에 LZ4/ZSTD를 한 번 더 겁니다 — timestamp에는 DoubleDelta, 느린 float에는 Gorilla, 단조 int에는 Delta. Elasticsearch처럼 _source(원본 JSON의 거의 완전한 사본)와 inverted index를 함께 들고 있지 않고 컬럼에서 행을 재구성하므로 디스크가 근본적으로 작습니다.
  • OTel 로그 벤치에서 CH 내부 압축 ~16.3x, 디스크 상 Elasticsearch 대비 ~4.95x 작음 Ⓑ (ClickHouse blog, OSS v26.3, 2026-04-23; 1B/10B/50B rows 전 구간에서 유지).
  • 실무 관측치로는 구조화 로그 ~10:1–20:1 ≈/Ⓥ, Uber는 보수적으로 3x, 경우에 따라 30x Ⓥ. nginx류처럼 반복성이 높은 access log는 >100x(178x 인용 사례)까지 갑니다 Ⓥ. 용량 계획용 raw→디스크 비율은 8~12x가 보수적이고 좋은 schema면 10~30x 도달도 가능합니다 ≈.
• 분석 쿼리 성능이 뛰어납니다. 대규모 병렬 컬럼 스캔과 벡터화 실행으로 aggregation·필터가 매우 빠릅니다. Uber는 단일 노드에서 300K logs/s ≈ ES 노드의 약 10x를 처리하고 타입드 schema에서 aggregation 50x 빠름을 보고했습니다 Ⓥ. Trip.com은 ES 대비 4~30x 빠른 쿼리(P90 <300ms, P99 <1.5s) Ⓥ, Cloudflare는 96조(96T) 이벤트를 <2s에 스캔 Ⓥ.
• 인프라 비용이 크게 낮습니다. OpenSearch/ELK 대비 인프라 기준 큰 절감(대략 7~15배 보고 사례) Ⓥ. Uber의 ELK 대비 hardware >50% 절감 주장은 2026-07 적대 검증에서 원문 근거 불충분으로 기각됐습니다(1-2) ?. Didi는 machine cost ~30% 절감(2024-04 스냅샷, 엔지니어링·마이그레이션 비용 제외)을 보고했습니다 Ⓥ. 한 crypto-derivatives 플랫폼은 OTel 통합으로 관측성 청구를 high-six-figures에서 **~$50K(약 90% 절감)**까지 내렸습니다 Ⓥ.
• 통합 저장소 잠재력. 로그·트레이스·이벤트를 한 스키마 계열로 다루고 SQL로 조회합니다. TTL 티어링, materialized view, AggregatingMergeTree 같은 프리미티브로 pre-aggregation·다운샘플·hot→cold 이동을 엔진 안에서 처리합니다. 로그 검색에 필요한 풀텍스트 text index GA(2026-03), **native JSON GA(25.3)**도 이미 정식입니다.
• PB 스케일에서 실전 검증됨. Trip.com은 **4PB→50PB+**로 성장했습니다 Ⓥ. Cloudflare는 quadrillion-row 스케일을 active-active로 운영합니다. 성능·비용 방향은 매우 큰 규모에서도 일관됩니다.
• 넓은 생태계와 성숙한 운영 도구. 드라이버/BI/OTel/Vector 연동이 풍부합니다. Altinity clickhouse-operator는 약 7년간 사실상 표준입니다(라인 0.27.x, 0.27.1은 2026-06-04·FIPS 지원). ClickHouse Inc.의 공식 first-party operator도 2026-01 등장했습니다. 조율 계층인 ClickHouse Keeper는 JVM/GC가 없어 ZooKeeper보다 가볍습니다 — Bonree는 교체로 CPU/메모리 >75% 절감, IO·성능 ~8x Ⓥ. clickhouse-backup, Terraform EKS blueprint 등 도구가 갖춰져 있습니다.
• 유연한 스토리지 티어링. EBS gp3(churn 이후 생존, snapshot 용이), 로컬 NVMe(최고 throughput·최저 latency; i7ie는 노드당 최대 120 TB, i3en 대비 실시간 성능 ~65%↑·I/O latency ~50%↓ Ⓥ), TTL MOVE로 S3 콜드 티어까지 워크로드에 맞춰 조합할 수 있습니다. 인스턴스 패밀리 선택의 현재 권고(i8g 기본, i7i/i7ie는 대용량·x86 의존 시)는 ClickHouse 스토리지 · 로컬 NVMe 참고.

약점 · 한계

• 스키마·테이블 설계가 상시 스킬 요구사항입니다. 좋은 ORDER BY·partition·codec·TTL·materialized view에는 보상하고 나쁜 설계에는 낮은 압축과 느린 쿼리로 벌을 줍니다. “JSON을 index하고 시작"하는 OpenSearch와 달리 CH는 의도적인 설계를 요구하고 로그 형태가 바뀌면 그 설계를 다시 검토해야 합니다. 특히 field와 query pattern을 알 때 빛나며 unknown/volatile field가 지배적이면 효율이 “may suffer significantly depending on schema.”
• 셀프호스트 운영 부담이 실재합니다. 잦은(때로 breaking) 버전 업그레이드 검증, multi-TB 테이블의 ALTER/INSERT SELECT backfill, 백업 운영이 사용자 몫입니다. 표준 도구 clickhouse-backup의 incremental 체인은 fragile합니다 — incremental restore에 체인의 모든 이전 백업이 필요하고 하나라도 손상되면 복구 불가라 weekly-full + daily-incremental·정기 restore drill을 직접 소유해야 합니다. TCO 추정으로 대략 엔지니어 시간 10–20%($2–4k/월) ≈이며 관리형 이전은 ops를 ~10 hrs/월 줄이는 대신 10 TB에서 비용을 ~3.4x 올린 사례가 있습니다 ≈/Ⓥ.
• 진짜 storage-compute 분리는 Cloud 전용입니다. SharedMergeTree는 proprietary·Cloud 전용이고 self-host의 zero-copy-S3는 사실상 폐기됐습니다(데이터 손상 이력 #39560, 22.8부터 default off, ~2024-04 이후 upstream 기여 거부). self-host는 shared-nothing이고 RF2는 S3에서도 사본이 두 배가 되며 스케일아웃 = 리샤딩입니다. OSS 대안인 Altinity Antalya(Iceberg/Parquet + stateless swarm)는 유망하나 아직 성숙 중입니다.
• EKS stateful 엣지케이스. EBS는 AZ 고정이라 node churn 시 volume node affinity conflict가 나 WaitForFirstConsumer + per-AZ node group / shard-per-AZ 설계가 필요합니다. 로컬 NVMe는 ephemeral이라 RF2 + node 손실 시 네트워크 rebuild가 전제됩니다. PDB maxUnavailable:1, topology spread는 필수입니다.
• S3 콜드 티어의 숨은 비용. data가 S3에 있어도 part metadata는 로컬 디스크에 남고 desync 시 orphan S3 파일이 생깁니다(백업 필요). disk cache가 사실상 필수이며 콜드 쿼리는 로컬보다 느립니다.
• turnkey 로그 UI가 아닙니다. Kibana/OpenSearch Dashboards에 대응하는 내장 로그 검색 UI가 없습니다 — Grafana나 HyperDX / ClickStack를 따로 붙여야 합니다.

적합 / 부적합

적합

• 대규모(수십 TB~PB/day) 로그·이벤트
• 알려진/안정적 schema와 query pattern
• 강한 aggregation·analytics 요구
• SQL 친화 팀
• 통합 저장소 야심
• 비용 최적화가 절실하고 전담 오너가 있는 조직

부적합

• unknown/volatile field가 지배적인 로그(임의 access log 등)
• 소규모·오너 없는 팀
• turnkey 관리형을 원하는 경우
• self-host에서 즉시 storage-compute 분리가 필요한 경우

StarRocks와의 정면 비교는 ClickHouse vs StarRocks 참고.

우리 케이스에서는

우리는 PLG 방치 이력이 있는 소규모 플랫폼 팀입니다. self-hosted CH는 managed OpenSearch보다 운영 부담이 더 크지 덜하지 않습니다 — 여기서 지배적 위험은 기술이 아니라 오너십입니다. 명시적 오너 + 런북 + 정기 리뷰를 정해 두지 못한다면 관리형(ClickHouse Cloud / Altinity.Cloud) 견적과 반드시 비교해야 합니다. volatile한 istio access log 경로에는 단일 바이너리로 임의 field를 처리하는 VictoriaLogs가 더 가벼운 후보입니다. self-hosted CH를 1차 채택안으로 밀지 않습니다.

채택을 전제했을 때의 배포·스토리지·operator 운영 전략 심화(how)는 ClickHouse 운영 도메인 참조 — 여기(로그 내재화 관점의 채택 여부)와 전제가 다릅니다.