ClickHouse OSS 싱글 노드로 분석 시작하기
ClickHouse OSS 싱글 노드로 분석 시작하기

ClickHouse OSS 싱글 노드로 분석 시작하기

ClickHouse 분류
Core Architecture
Type
Lab
작성자

Ken

  • 들어가며
  • 왜 ClickHouse인가?
  • 싱글 노드의 놀라운 성능
  • 단일 노드로 충분한 경우
  • 소규모 분석 활용 사례
  • 1. 제품 애널리틱스 (Product Analytics)
  • 2. 애플리케이션 로그 분석 (Log Analytics)
  • 3. IoT 센서 데이터 모니터링
  • 4. A/B 테스팅 및 실험 플랫폼
  • 단일 노드의 한계와 클러스터로의 전환 시점
  • 단일 노드의 한계
  • 점진적 전환 전략
  • ClickHouse Cloud: 더 나은 선택이 될 수 있는 이유
  • 1. Automatic Idling: 사용하지 않을 때는 과금 중단
  • 2. Elastic Scaling: 워크로드에 따른 자동 확장
  • 3. Model Context Protocol (MCP) 지원: AI와 네이티브 통합
  • 4. 분리된 스토리지와 Compute 아키텍처
  • 5. 운영 부담 제로
  • 6. 실제 비용 비교
  • 7. 언제 ClickHouse Cloud를 선택해야 할까?
  • 결론: 상황에 맞는 선택
  • ClickHouse 시작하기
  • OSS 시작하기
  • Cloud 시작하기
  • 참고 자료

들어가며

"데이터 분석 시스템을 구축하려면 복잡한 클러스터와 막대한 인프라 투자가 필요하다"는 선입견이 있습니다. 특히 ClickHouse를 처음 접하는 개발자들은 공식 문서에서 다루는 클러스터 구성, Replication, Sharding 같은 용어들에 압도되곤 합니다.

하지만 놀랍게도 ClickHouse는 단 한 대의 서버로도 엄청난 성능을 발휘합니다. 실제로 단일 노드에서 초당 수백만 건의 이벤트를 처리하고, 수십억 건의 데이터를 몇 초 안에 집계할 수 있습니다. CloudQuery의 사례에서는 단일 ClickHouse 노드가 650억 개의 행(약 14TiB)을 초당 400만 행의 속도로 처리했습니다.

이 글에서는 ClickHouse OSS를 단일 노드로 구성하여 실제 분석 문제를 해결하는 방법을 다루고자 합니다. 그리고 어떤 경우 ClickHouse Cloud를 사용하는 것이 좋은 선택사항이 되는지 함께 다루고자 합니다.

왜 ClickHouse인가?

소규모 스타트업은 대부분 다음과 같은 상황에 직면합니다.

  • 제한된 리소스: 인프라 관리에 투입할 수 있는 인력과 예산이 제한적입니다. DevOps 전담 팀이 없는 경우가 많고, 개발자가 인프라까지 관리해야 합니다.
  • 빠른 검증 필요: 제품-시장 적합성(Product-Market Fit)을 찾기 위해 빠르게 실험하고 피봇해야 합니다. 복잡한 인프라 구축에 시간을 쏟을 여유가 없습니다.
  • 불확실한 데이터 볼륨: 초기에는 데이터가 많지 않지만, 성장하면서 급격히 증가할 수 있습니다. 확장 가능하면서도 초기 투자가 적은 솔루션이 필요합니다.
  • 비용 민감성: 매달 수백만 원의 데이터 웨어하우스 비용을 감당하기 어렵습니다. Snowflake나 BigQuery의 종량제 비용이 예상을 초과하는 경우가 빈번합니다.

싱글 노드의 놀라운 성능

ClickHouse의 싱글 노드는 생각보다 훨씬 강력합니다.

선형적 수직 확장: ClickHouse는 CPU 코어와 메모리를 추가할수록 거의 선형적으로 성능이 향상됩니다. 32코어 서버 한 대가 8코어 클러스터 4대보다 관리가 쉽고 성능도 우수할 수 있습니다.

효율적인 압축: Columnar storage와 압축 알고리즘으로 수백 GB의 원본 데이터가 수십 GB로 압축됩니다. 일반적으로 10:1에서 20:1의 압축률을 보입니다.

실제 사례의 스케일:

  • Craigslist는 단일 노드 ClickHouse로 전체 액세스 로그를 분석하여 실시간 Rate Limiting을 구현했습니다. 복잡한 집계 쿼리가 100ms 이내에 완료됩니다.
  • 한 SaaS 기업은 단일 노드로 일 10억 건의 이벤트를 처리하며, Postgres에서 마이그레이션하여 30% 이상의 비용을 절감했습니다.
  • ServiceNow는 모바일 애널리틱스를 단일 ClickHouse 인스턴스로 처리하며, 30개의 사전 집계 테이블을 제거하고 유연한 실시간 분석을 구현했습니다.

단일 노드로 충분한 경우

다음 조건에 해당한다면 단일 노드로 시작하는 것이 합리적입니다.

  • 데이터 볼륨: 일 1억 건 이하의 이벤트, 또는 총 데이터가 수 TB 이내
  • 쿼리 패턴: 복잡한 Join보다는 시계열 집계와 필터링이 주를 이루는 경우
  • 가용성 요구사항: 99.9% 이하의 가용성으로 충분한 경우 (미션 크리티컬하지 않은 분석 워크로드)
  • 팀 규모: DevOps 전담 인력 없이 개발자가 직접 관리하는 경우

이러한 조건은 실제로 많은 스타트업과 중소기업에 해당합니다. 나중에 유즈케이스가 성장하면 ClickHouse는 수평 확장을 수행하거나 Cloud로 마이그레이션이 가능하므로, 단일 노드로 시작하기에 적합합니다.

소규모 분석 활용 사례

1. 제품 애널리틱스 (Product Analytics)

시나리오: SaaS 제품을 운영하는 스타트업에서 사용자 행동을 분석하여 제품 개선 방향을 찾고자 합니다.

기존 문제점:

  • Mixpanel, Amplitude 같은 SaaS 솔루션은 MAU(월간 활성 사용자) 기반 요금제로 성장할수록 비용이 급증합니다.
  • Google Analytics는 무료이지만 커스텀 이벤트 분석에 한계가 있습니다.
  • PostgreSQL에 이벤트를 저장하면 시간이 지날수록 쿼리가 느려지고, 인덱스 관리가 복잡해집니다.

ClickHouse 싱글 노드 활용 기대 효과:

  • 수억 건의 이벤트를 수 초 내에 집계
  • 사용자 정의 이벤트와 속성을 자유롭게 추가 가능
  • 외부 서비스 비용 대비 90% 이상 절감

2. 애플리케이션 로그 분석 (Log Analytics)

시나리오: 마이크로서비스 아키텍처를 사용하는 스타트업에서 여러 서비스의 로그를 중앙화하여 문제를 빠르게 파악하고자 합니다.

기존 문제점:

  • Elasticsearch는 메모리 사용량이 크고, 클러스터 관리가 복잡합니다.
  • Splunk는 라이선스 비용이 매우 높습니다.
  • CloudWatch나 Stackdriver는 쿼리 기능이 제한적이고, 대용량 검색 시 비용이 증가합니다.

ClickHouse 싱글 노드 활용 기대 효과:

모든 애플리케이션 로그를 구조화된 형태로 ClickHouse에 저장합니다. Fluentd, Vector, Logstash 같은 로그 수집기를 사용하여 실시간으로 적재할 수 있습니다.

  • 초당 수십만 건의 로그를 실시간 수집
  • 전문 검색(Full-text search)과 구조화된 쿼리를 모두 지원
  • 자동 TTL로 오래된 로그 삭제하여 스토리지 관리 자동화

3. IoT 센서 데이터 모니터링

시나리오: IoT 디바이스를 관리하는 스타트업에서 수천 개의 센서로부터 실시간 데이터를 수집하고 모니터링합니다.

기존 문제점:

  • 시계열 데이터베이스(InfluxDB, TimescaleDB)는 고유한 쿼리 언어나 제한된 SQL 지원
  • 데이터가 증가하면서 쿼리 성능이 저하됨
  • 복잡한 집계나 조인이 어려움

ClickHouse 싱글 노드 활용 기대 효과:

  • 밀리초 단위의 센서 데이터를 실시간 처리
  • 표준 SQL로 복잡한 시계열 분석 수행
  • 장기간 데이터 보관 및 트렌드 분석 가능

4. A/B 테스팅 및 실험 플랫폼

시나리오: 제품 팀에서 다양한 기능의 효과를 측정하기 위해 A/B 테스트를 자주 실행합니다.

ClickHouse 싱글 노드 활용 기대 효과:

  • 실시간으로 실험 결과 모니터링
  • 복잡한 세그먼트 분석 가능
  • 과거 실험 데이터와 비교 분석

단일 노드의 한계와 클러스터로의 전환 시점

단일 노드의 한계

다음 상황이 발생하면 클러스터로의 전환을 고려해야 합니다.

  • 스토리지 용량 부족: 단일 서버의 디스크 용량이 한계에 도달했을 때. 일반적으로 수십 TB 이상에서 문제가 됩니다.
  • 쿼리 동시성 문제: 동시 쿼리가 많아지면서 CPU나 메모리가 부족해지는 경우. 일반적으로 초당 수백 개 이상의 쿼리에서 한계를 느낍니다.
  • 고가용성 요구: 다운타임이 허용되지 않는 미션 크리티컬한 워크로드로 발전한 경우.
  • 지리적 분산: 여러 지역에서 낮은 지연시간으로 데이터에 접근해야 하는 경우.

점진적 전환 전략

ClickHouse는 단일 노드에서 클러스터로 비교적 쉽게 전환할 수 있습니다.

  1. Replication부터 시작: 같은 데이터를 여러 노드에 복제하여 고가용성 확보
  2. Sharding 추가: 데이터를 여러 노드에 분산하여 용량과 성능 확장
  3. ClickHouse Cloud 고려: 직접 관리의 부담이 커지면 매니지드 서비스로 전환

ClickHouse Cloud: 더 나은 선택이 될 수 있는 이유

단일 노드 ClickHouse OSS로 시작하는 것은 훌륭한 선택이지만, 특정 상황에서는 ClickHouse Cloud가 비용 대비 더 나은 이점을 제공할 수 있습니다. 직접 인프라를 관리하는 부담 없이 다음과 같은 독특한 장점들을 활용할 수 있기 때문입니다.

1. Automatic Idling: 사용하지 않을 때는 과금 중단

ClickHouse Cloud의 가장 강력한 비용 절감 기능은 자동 Idling입니다.

작동 원리: 서비스에 일정 시간 동안 쿼리가 없으면 자동으로 Compute 리소스가 일시 중지됩니다. 이 상태에서는 Compute 비용이 전혀 발생하지 않으며, 스토리지 비용만 지불합니다. 새로운 쿼리가 들어오면 자동으로 재시작됩니다.

실제 비용 효과:

  • 개발/테스트 환경에서 업무 시간(9-6시) 외에는 자동으로 중단되어 하루 중 75%의 시간 동안 Compute 비용이 0원
  • 주말과 야간에 사용하지 않는 분석 대시보드는 실제 사용 시간만 과금
  • 한 달 평균 70-80%의 Compute 비용 절감 가능

적합한 사용 사례:

  • 업무 시간에만 사용하는 내부 분석 도구
  • 개발 및 스테이징 환경
  • 주기적으로 사용하는 배치 분석 작업
  • 간헐적으로 조회하는 데이터 아카이브

OSS 대비 장점: 직접 관리하는 환경에서는 서버를 수동으로 껐다 켜야 하며, 데이터 영속성과 빠른 재시작을 위한 추가 설정이 필요합니다. ClickHouse Cloud는 이 모든 것을 자동화합니다.

2. Elastic Scaling: 워크로드에 따른 자동 확장

ClickHouse Cloud는 수직(Vertical)과 수평(Horizontal) 확장을 모두 지원하며, 자동으로 리소스를 조정합니다.

수직 자동 확장:

  • CPU 사용률이 50-75%를 넘으면 자동으로 CPU와 메모리가 2배로 증가
  • 사용률이 임계값의 절반 이하로 떨어지면 자동으로 절반으로 축소
  • 최소/최대 메모리 범위를 설정하여 예측 가능한 비용 관리

수평 확장 (Scale/Enterprise 플랜):

  • API를 통해 Replica 수를 동적으로 조정
  • 대량 데이터 적재 시 Replica를 늘려 처리 속도 향상
  • 동시 쿼리가 많은 시간대에 자동으로 확장

Make-Before-Break 아키텍처: ClickHouse Cloud는 독특한 확장 방식을 사용합니다. 새로운 노드를 먼저 준비하고, 준비가 완료되면 기존 노드를 제거합니다. 이는 확장 과정 중에도 쿼리 성능에 영향이 없음을 의미합니다.

실제 시나리오:

평소: 8GB RAM, 2 vCPU (기본)
월말 리포트 시즌: 자동으로 32GB RAM, 8 vCPU로 확장
마케팅 캠페인 중: Replica 3대로 증가하여 동시 쿼리 처리

비용 최적화: 필요할 때만 리소스를 사용하므로, 최대 워크로드를 위해 과도하게 프로비저닝할 필요가 없습니다. 실제 사용량에 따라 과금되어 평균 40-60%의 비용 절감이 가능합니다.

3. Model Context Protocol (MCP) 지원: AI와 네이티브 통합

ClickHouse Cloud는 2024년부터 MCP (Model Context Protocol) 를 공식 지원하며, AI 에이전트와의 통합을 크게 단순화했습니다.

Remote MCP Server (Private Preview):

  • ClickHouse Cloud 서비스에 내장된 관리형 MCP 서버
  • OAuth 기반 인증으로 보안 보장
  • Read-only로 제한하여 안전한 데이터 접근
  • 별도 인프라 구축이나 관리 불필요

지원하는 AI 도구:

  • Claude (Anthropic) - 직접 대화하며 데이터 분석
  • ChatGPT - 자연어로 쿼리 실행
  • Cursor, Windsurf - IDE 내에서 데이터 컨텍스트 활용
  • 커스텀 AI 에이전트 및 Agentic 애플리케이션

실제 활용 예시:

사용자: "지난 주 가장 많이 팔린 제품 상위 10개를 보여줘"

AI Agent: ClickHouse MCP를 통해 자동으로:
1. 적절한 테이블 스키마 확인
2. SQL 쿼리 생성 및 실행
3. 결과를 자연어로 설명하고 차트로 시각화
  • Ask AI Agent (Beta): ClickHouse Cloud 콘솔에 내장된 AI 어시스턴트로, 자연어 질문을 SQL로 변환하고 결과를 설명합니다. SQL을 모르는 비즈니스 사용자도 데이터에 직접 접근할 수 있게 됩니다.
  • Agent-Facing Analytics: ClickHouse는 사람뿐만 아니라 AI 에이전트가 주요 사용자가 되는 미래를 준비하고 있습니다. 에이전트는 기계 속도로 쿼리를 실행하고, 컨텍스트를 유지하며, 반자동으로 인사이트를 생성합니다.
  • OSS 대비 장점: OSS에서 MCP를 사용하려면 별도로 mcp-clickhouse 서버를 설치하고 관리해야 하며, 인증 및 보안 설정을 직접 구성해야 합니다. ClickHouse Cloud는 이를 완전히 관리형으로 제공합니다.

4. 분리된 스토리지와 Compute 아키텍처

ClickHouse Cloud는 Object Storage (S3/GCS/Azure Blob)를 백엔드로 사용하는 SharedMergeTree 엔진을 기반으로 합니다.

장점:

  • 독립적인 확장: 스토리지와 Compute를 각각 독립적으로 확장 가능
  • 비용 효율성: 스토리지 비용이 매우 저렴 (TB당 $25.30/월)
  • 무제한 스냅샷: 백업과 복구가 저렴하고 빠름
  • Zero-downtime 확장: 스토리지를 건드리지 않고 Compute만 변경

OSS의 한계: 전통적인 MergeTree는 스토리지와 Compute가 결합되어 있어, 디스크가 가득 차면 전체 시스템을 확장해야 합니다.

5. 운영 부담 제로

자동화된 운영:

  • 자동 백업 및 복구
  • 자동 패치 및 보안 업데이트
  • 자동 성능 튜닝 및 최적화
  • 24/7 모니터링 및 알림

비용 투명성:

  • Billing API를 통한 상세한 사용량 추적
  • Vantage 같은 FinOps 도구와 통합
  • 예상치 못한 비용 증가에 대한 알림
  • Compute 자동 확장 상한선 설정으로 비용 제어

OSS 운영 시 필요한 작업:

  • 정기적인 보안 패치 적용
  • 모니터링 시스템 구축 및 관리
  • 백업 전략 수립 및 테스트
  • 성능 튜닝 및 문제 해결
  • 디스크 공간 관리 및 확장

6. 실제 비용 비교

시나리오: 소규모 스타트업의 분석 플랫폼

조건:

  • 일 평균 1억 건의 이벤트 수집
  • 압축 후 약 200GB 스토리지
  • 업무 시간(9-6시) 동안만 주로 사용
  • 주말은 거의 사용 안 함

ClickHouse OSS (직접 관리):

  • AWS EC2 r6g.2xlarge (8 vCPU, 64GB RAM): $0.403/시간
  • EBS 스토리지 300GB: $30/월
  • 매월 총 비용: $0.403 × 24 × 30 + $30 = $320/월
  • 추가 비용: DevOps 시간 (모니터링, 백업, 패치 등)

ClickHouse Cloud (Development Tier):

  • 스토리지 200GB: $5.06/월
  • Compute (Idling 활용): 평균 30% 사용률
    • $0.22/시간 × 24시간 × 30일 × 0.3 = $47.52/월
  • 매월 총 비용: 약 $53/월
  • 추가 이점: 운영 자동화, MCP 지원, 자동 확장

비용 절감: 약 83% 절감 + 운영 시간 절약

7. 언제 ClickHouse Cloud를 선택해야 할까?

다음 경우에 ClickHouse Cloud가 더 적합합니다.

비용 관점:

  • 워크로드가 간헐적이거나 예측 불가능한 경우 (Idling 활용)
  • 빠르게 성장하여 자주 확장이 필요한 경우
  • DevOps 리소스가 제한적인 경우 (운영 비용 절감)

기능 관점:

  • AI/LLM과 통합하여 자연어 인터페이스를 제공하고 싶은 경우
  • 빠른 프로토타이핑과 출시 속도가 중요한 경우
  • 자동화된 백업, 모니터링, 확장이 필요한 경우

조직 관점:

  • 데이터 인프라보다 제품 개발에 집중하고 싶은 경우
  • 보안 및 규정 준수를 전문 팀에 맡기고 싶은 경우
  • 글로벌 확장을 계획하는 경우

결론: 상황에 맞는 선택

ClickHouse OSS 단일 노드는 다음 경우에 적합:

  • 완전한 제어와 커스터마이징이 필요
  • 24/7 연속 실행되는 워크로드
  • 이미 DevOps 역량과 인프라가 있음
  • 특수한 네트워크 또는 보안 요구사항

ClickHouse Cloud는 다음 경우에 적합:

  • 빠른 시작과 운영 단순화
  • 변동이 큰 워크로드 (Idling/Scaling 활용)
  • AI/자연어 인터페이스 통합
  • 제한된 DevOps 리소스

많은 경우, ClickHouse Cloud의 Idling과 자동 확장을 활용하면 직접 관리하는 것보다 실제 비용이 더 저렴하면서도 훨씬 편리합니다. 특히 소규모 스타트업에서는 인프라 관리에 쏟는 시간을 제품 개발에 투자하는 것이 더 큰 가치를 만들어낼 수 있습니다.

OSS로 시작하든 Cloud를 선택하든, 중요한 것은 빠르게 시작하여 데이터 기반 의사결정의 가치를 검증하는 것입니다. ClickHouse는 두 가지 경로 모두에서 탁월한 성능과 유연성을 제공합니다.

ClickHouse 시작하기

OSS 시작하기

ClickHouse OSS 바이너리는 공식 사이트에서 다운로드 받을 수 있으며, 쉽게 Docker 기반으로 테스트를 수행하고자 하는 경우를 위해 다음과 같은 스크립트를 작성하였습니다.

clickhouse-hols/oss-mac-setup at main · litkhai/clickhouse-hols

ClickHouse Hands-on Labs . Contribute to litkhai/clickhouse-hols development by creating an account on GitHub.

github.com

clickhouse-hols/oss-mac-setup at main · litkhai/clickhouse-hols

Cloud 시작하기

다른 글에서 Cloud 시작에 대해서 다루고 있습니다.

ClickHouse Cloud 시작하기ClickHouse Cloud 시작하기

참고 자료

  • ClickHouse Official Documentation
  • ClickHouse Docker Hub
  • ClickHouse Examples Repository
  • CloudQuery - Six Months with ClickHouse
  • ClickHouse Community: Creative Use Cases
  • ClickHouse Cloud Pricing
  • ClickHouse Cloud Automatic Scaling
  • ClickHouse MCP Integration
  • Agent-Facing Analytics