클릭하우스(ClickHouse)는 설치와 초기 구성이 비교적 쉬운 편이다. 진짜 어려움은 그다음, 즉 클러스터를 장기간 안정적으로 굴리는 데 있다. 타인버드(Tinybird)의 한 엔지니어는 버전 18.4 시절부터 약 6년간 페타바이트급 클러스터를 운영하며 데이터베이스 프로젝트에 직접 변경 사항을 기여해 온 경험을 정리해 공개했다. 새로운 엔진, 대규모 성능 개선, 분산 조인 등을 기여한 오픈소스 사용자 관점에서 나온 이야기라, 마케팅 문구보다는 실제 운영에서 부딪히는 문제에 초점이 맞춰져 있다.
샤드보다 먼저 고민할 것은 레플리카와 부하 분산
클릭하우스가 대규모 클러스터에 권장하는 표준 구조는 데이터를 hash(user_id) 같은 기준으로 여러 버킷에 나눠 각 버킷을 샤드에 배치하고, 샤드마다 복제본(레플리카)을 두는 방식이다. 그러나 필자의 팀은 초기에 샤드 없이 레플리카만 두는 단순한 구성으로 출발했다. 큰 쿼리는 레플리카를 수직 확장해 감당하고, 트래픽이 늘면 레플리카를 추가하는 식이다. 재샤딩(re-sharding)이 워낙 까다롭고, 스키마 설계를 잘해두면 샤드 도입 시점을 상당히 미룰 수 있었기 때문이다.
이 구조의 핵심은 로드밸런서다. 필자의 팀은 HTTP 로드밸런서를 두고 요청 유형, 부하, 레플리카 종류, 캐시 활용을 위한 일관성 해싱 등을 근거로 백엔드가 트래픽을 어느 레플리카로 보낼지 판단하게 했다. 기본 설치에 이 모든 로직이 필요한 것은 아니지만 일부는 반드시 필요하다. 또 클릭하우스가 제공하는 네이티브 TCP 프로토콜 대신 HTTP를 쓰는데, 검증된 도구 생태계를 활용할 수 있다는 이점 때문이다. 애플리케이션 코드에서 붙는다면 파이썬·자바·고 등 언어별 클라이언트가 두 프로토콜을 모두 처리해 준다.
모든 데이터를 모든 머신에 두는 비용의 함정
로컬 SSD 기반 레플리카 구조는 지연시간 측면에서 유리하지만 비용이 급격히 불어난다. 가용성 구성에 따라 모든 머신이 전체 데이터의 사본을 가져야 하기 때문이다. 예를 들어 300TB 테이블에 1000 QPS를 처리해야 하는데 레플리카 하나가 100 QPS를 감당한다면 10개가 필요하고, 저장 용량은 3000TB로 불어난다. 그래서 필자는 쓰기 전용 레플리카를 따로 두는 컴퓨트-컴퓨트 분리를 기본으로 권한다. p99 목표가 있는 실시간 서브초 쿼리는 부하를 40% 이하로 유지해 높은 백분위 지연을 안정화하도록 별도 레플리카로 격리하고, 저렴한 배치 작업과 섞지 않는 편이 낫다.
여기서 이 글이 짚는 클릭하우스 오픈소스의 근본적 약점이 나온다. 바로 클라우드 스토리지 지원의 한계다. 스노플레이크가 10여 년 전에 정립한 컴퓨트-스토리지 분리를 클릭하우스 오픈소스는 여전히 충분히 따라가지 못하고, 스타로켓 같은 시스템에 뒤처져 있다는 지적이다. S3 기반 제로카피 복제(zero-copy replication)가 존재하긴 하지만 이는 외부 기여자가 넣은 기능으로, 버그가 있고 특정 파트 연산에서는 데이터 손실이나 S3 잔여 파일 문제가 생길 수 있다. 클릭하우스 클라우드의 자체 스토리지는 오픈소스가 아니다.
스토리지와 압축, 그리고 비용 최적화
그럼에도 한계를 알고 쓰면 제로카피 복제는 실사용 가능하다는 것이 필자의 판단이다. 다만 클릭하우스의 S3 저장 방식은 기본적으로 쓰기 연산을 많이 발생시켜 비효율적이다. 원래 쓰기가 사실상 '공짜'인(IOPS 제약만 있는) 로컬 스토리지를 전제로, 수많은 파일로 데이터 파트를 저장하고 OS 페이지 캐시를 캐시로 쓰도록 설계됐기 때문이다. 티어드 스토리지를 염두에 둔 구조가 아니라는 뜻이다. 낮은 지연이 중요한 워크로드에는 로컬 SSD와 S3를 결합한 핫/콜드 아키텍처로 S3만으로는 낼 수 없는 지연 성능을 확보하는 방식을 쓴다. 압축은 대체로 ZSTD(1) 또는 ZSTD(2)가 속도와 압축률의 균형에서 LZ4보다 낫고, 컬럼 단위로 지정할 수 있으니 데이터 특성에 맞춰 주기적으로 다른 포맷도 테스트해보라고 권한다.
운영에서 가장 값진 대목은 업그레이드다. 첫 업데이트는 2주 준비에 3시간이 걸렸지만, 결국 무중단·무손실은 물론 성능 저하 없이 CI/CD 파이프라인의 일부로 편입하는 데 성공했다. 여기에 4년이 걸렸다는 점이 이 작업의 난이도를 말해준다. 이를 가능하게 한 것은 하위 호환되는 복제 프로토콜이었고, CI가 업그레이드를 테스트해 릴리스 전에 문제를 발견하고 PR로 고칠 수 있었다. 테스트는 운영 중인 버전, master, 올릴 대상 버전을 모두 대상으로 하되, 단일 인스턴스가 아니라 최소 두 대와 주키퍼(또는 클릭하우스 키퍼)로 구성된 클러스터에서 해야 한다. 테이블 생성 실패나 복제 지연 등 단일 인스턴스에서는 드러나지 않는 동작들이 있기 때문이다.
소스 코드를 읽어야 하는 데이터베이스
한국 실무자에게 특히 새겨둘 만한 조언은 두 가지다. 첫째, 클릭하우스를 제대로 운영하려면 소스 코드를 읽어야 한다는 것이다. 수백 개의 포스트그레스 클러스터를 다뤄본 필자조차 다른 DB에서는 필요 없던 일이었다고 말한다. 대형 사용자 상당수가 업스트림에 자체 패치를 유지하는 이유이기도 하다. 버전 간 설정 변경을 자동으로 추적하는 체계를 갖추라는 권고도 같은 맥락이다. 둘째, 인력 산정이다. 소규모 클러스터는 파트타임 한 명으로 충분하지만, 초당 2만 행이 넘고 여러 사람이 변경을 밀어 넣는 환경이라면 클러스터와 '이상한 쿼리'를 전담할 풀타임 인력이 필요하다. 기본 규칙만 지켜도 필요한 하드웨어가 3~4배 차이 나므로, US 수준 급여가 아니라면 전담자를 두는 편이 결국 이득이라는 계산이다. 참고로 하드웨어 규모의 대략적 감을 잡으려면 32코어 머신이 압축 해제 기준 초당 약 5GB를 건강하게 처리한다는 수치를 기준선으로 삼을 수 있다.