페타바이트급 ClickHouse 클러스터 운영 및 확장 가이드
I've operated petabyte-scale ClickHouse clusters for 5 years
Hacker News페타바이트급 규모의 ClickHouse 클러스터 운영 경험을 바탕으로, 구축보다 안정적인 유지보수와 확장에 초점을 맞춘 심층 가이드입니다.
- 대용량 데이터 시스템은 비용 효율성을 위해 컴퓨팅과 스토리지를 분리하고 클라우드 스토리지(S3 등)를 활용하는 아키텍처가 필수적입니다.
- 다운타임 없이 클러스터를 업그레이드하는 체계적인 워크플로우와 함께, 데이터 손실 및 성능 저하를 막는 실질적인 운영 노하우를 얻을 수 있습니다.
- 클라우드 스토리지를 사용할 경우 데이터 손실 위험을 인지하고, 배포 전 모든 쿼리 동작과 성능 변화를 철저히 검증해야 합니다.
대용량 데이터 시스템의 아키텍처는 일반적으로 복제본(replicas)과 샤드(shards)를 사용하여 데이터를 분할하고 관리합니다. 초기에는 섀드가 없는 단순한 복제본 구조로 시작하여 수직 확장을 했으나, 현대적인 시스템에서는 컴퓨팅과 스토리지를 분리하는 방식이 선호됩니다. 이 과정에서 클라우드 스토리지 활용은 비용 효율성과 독립적인 자원 확장에 큰 장점을 제공합니다.
대규모 데이터셋을 처리할 때 복제본 구조는 막대한 비용 문제를 야기할 수 있습니다. 예를 들어, 300TB 테이블에 대해 10개의 복제본이 필요하다면 총 3000TB의 저장 공간이 요구됩니다. 이러한 비용 효율성을 확보하기 위해 클라우드 스토리지를 활용한 제로-카피 복제나 로컬 SSD를 이용한 핫/콜드 스토리지 아키텍처가 사용됩니다. 다만, 제로-카피 기능은 버그 발생이나 데이터 손실 위험이 있어 주의 깊게 관리해야 합니다.
클러스터의 안정적인 운영을 위해서는 다운타임 없이 업그레이드를 수행하는 체계적인 워크플로우가 필수적입니다. 새로운 버전의 복제본을 추가하고 로그를 모니터링하며, DDL 변경과 같은 구조 변경을 피하는 것이 좋습니다. 이후 읽기 트래픽 테스트와 쓰기/삽입 테스트를 거쳐 실제 트래픽을 점진적으로 이동시키는 방식으로 진행됩니다.
운영 중 발생할 수 있는 주요 문제점으로는 데이터 저장 형식의 비호환성 변화, SQL 동작 방식 변경으로 인한 쿼리 오류, 성능 변화 등이 있습니다. 따라서 클러스터가 정상화된 후에도 모든 예상 데이터를 테스트하고, 시스템 로그(query_log)를 지속적으로 확인하는 것이 중요합니다.