ClickHouse 성능 병목 현상, Cloudflare의 3가지 패치로 해결!
Cloudflare는 ClickHouse 테이블 파티셔닝 키 변경 후, 빌링 시스템의 쿼리 성능 저하(Query Performance Degradation) 문제를 겪음
쿼리 계획 단계(Query Planning Phase)에서 락 경합(Lock Contention)이 주요 원인임을 파악하고, 공유 락(Shared Lock) 적용, 벡터 복사 제거, 이진 검색(Binary Search) 도입을 통해 해결
3가지 패치를 통해 쿼리 지연 시간(Latency)을 50% 감소시키고, 데이터 파트 증가에 따른 성능 저하 문제(Performance Degradation)를 해결함
파티셔닝 키 변경의 기술적 배경
Cloudflare는 데이터 격리 아키텍처(Data Isolation Architecture)를 위해 ClickHouse 테이블의 파티셔닝 키를 변경했다. 기존 (day)에서 (namespace, day)로 변경하여 네임스페이스(Namespace)별 데이터 보존 정책을 구현하고자 했다.
Table-per-Namespace 방식은 테이블 관리에 대한 오버헤드(Overhead) 발생
새로운 파티셔닝 키는 기존 보존 시스템을 재사용 가능
결과적으로, 이 결정은 데이터 파트(Data Part) 증가를 야기했고, 이는 예상치 못한 성능 병목 현상(Bottleneck)으로 이어졌다.
성능 저하의 원인 분석
빌링 시스템의 성능 저하 원인을 찾기 위해 Cloudflare는 ClickHouse의 trace_log를 활용하여 플레임 그래프(Flame Graph)를 생성했다. 초기에는 CPU 사용량에 집중했으나, 실제 문제는 쿼리 계획 단계(Query Planning Phase)에서 발생했다.
CPU 기반 플레임 그래프: filterPartsByPartition 함수에서 45%의 CPU 시간 소비
Real 플레임 그래프: MergeTreeData 뮤텍스(Mutex) 획득을 위한 락 경합(Lock Contention)으로 인해 쿼리 지연 시간(Latency) 증가
수백 개의 동시 쿼리가 단일 뮤텍스(Mutex)를 공유하면서 병목 현상이 발생했다.
3가지 ClickHouse 패치 상세 분석
Cloudflare는 락 경합(Lock Contention) 문제를 해결하기 위해 3가지 패치를 적용했다. 첫 번째는 공유 락(Shared Lock)을 사용하여 쿼리 계획 단계(Query Planning Phase)의 동시성을 높였다.
공유 락(Shared Lock) 적용: 쿼리 플래너(Query Planner)가 MergeTreeData 뮤텍스(Mutex)를 공유 락으로 획득
벡터 복사 제거: 파트 리스트(Part List) 복사 비용을 줄이기 위해 Shared Copy 방식 도입
이진 검색(Binary Search) 도입: 파티션 키(Partition Key)를 기반으로 이진 검색(Binary Search)을 수행하여 필터링 성능 향상
이러한 패치를 통해 쿼리 지연 시간(Latency)을 50% 감소시키고, 데이터 파트 증가에 따른 성능 저하 문제를 해결했다.
패치 적용 후 성능 개선 효과
각 패치 적용 후 성능 개선 효과는 명확하게 나타났다. 공유 락(Shared Lock) 적용으로 락 경합(Lock Contention) 문제가 즉시 해결되었고, 벡터 복사 제거를 통해 추가적인 성능 향상을 달성했다.
공유 락(Shared Lock) 적용: 쿼리 지연 시간(Latency) 즉시 감소
벡터 복사 제거: 추가적인 성능 향상
이진 검색(Binary Search) 도입: 쿼리 지연 시간(Latency) 50% 감소 및 데이터 파트 증가에 따른 성능 저하 문제 해결
이러한 개선을 통해 Cloudflare는 빌링 시스템의 안정성을 확보하고, 데이터 파트 증가에 따른 성능 저하 문제를 해결했다.
향후 과제 및 아키텍처적 고려 사항
이번 최적화는 ClickHouse의 성능 문제를 해결했지만, 근본적인 파티셔닝 방식의 적합성에 대한 의문을 제기한다. 데이터 파트(Data Part)가 증가함에 따라 ZooKeeper의 성능에도 영향을 미칠 수 있다.
파티셔닝 방식의 장단점: 현재는 패치로 문제를 해결했지만, 장기적인 관점에서 다른 아키텍처 고려 필요
ZooKeeper 성능 문제: 데이터 파트 증가에 따른 메타데이터 관리 문제 발생 가능성
결과적으로, Cloudflare는 지속적인 성능 개선과 함께 데이터 격리 아키텍처(Data Isolation Architecture)의 장기적인 전략을 재검토해야 한다.
