교훈 - 창의적 활용 사례

느린 쿼리, 메모리 오류, 연결 문제, 구성 문제를 비롯해 가장 일반적인 ClickHouse 문제에 대한 해결책을 찾아보십시오.

이 가이드는 커뮤니티 밋업에서 얻은 인사이트를 모아 놓은 모음집의 일부입니다. 더 많은 실제 해결책과 인사이트를 보려면 특정 문제별로 찾아보기를 확인하십시오. 프로덕션 환경에서 발생한 문제를 디버깅하는 팁이 필요하십니까? 커뮤니티 가이드 Debugging Insights를 확인해 보십시오.

이 사례들은 여러 기업이 각자의 활용 사례에 ClickHouse를 적용해 어떻게 성공을 거두었는지 보여줍니다. 일부는 기존 데이터베이스 범주의 경계를 넘어서며, 때로는 “잘못된” 도구처럼 보이는 선택이야말로 정확히 맞는 해법이 될 수 있음을 증명합니다.

​

속도 제한기로서의 ClickHouse

Craigslist에서 사용자를 보호하기 위해 최상위 수준의 속도 제한을 추가해야 했을 때, 모든 엔지니어링 팀이 마주하는 것과 같은 선택에 직면했습니다. 즉, 일반적인 통념대로 Redis를 사용할지, 아니면 다른 접근 방식을 모색할지였습니다. Craigslist에서 일하던 Brad Lhotsky는 Redis가 사실상 표준 선택지라는 점을 알고 있었습니다. 온라인의 거의 모든 속도 제한 튜토리얼과 예시에서 Redis를 사용하는 데에는 그만한 이유가 있기 때문입니다. Redis는 속도 제한 작업에 필요한 풍부한 기본 기능을 제공하고, 잘 확립된 패턴과 입증된 운영 이력도 갖추고 있습니다. 하지만 Craigslist의 Redis 운영 경험은 교과서적인 예시와는 달랐습니다. “Redis를 사용한 저희 경험은 흔히 알려진 이야기와는 좀 다릅니다… Redis 클러스터의 노드를 재부팅하면 프런트엔드에 지연 시간 급증이 발생하는 등 이상한 유지 관리 문제가 많이 있었습니다.” 유지 관리의 단순성을 중시하는 소규모 팀에게 이런 운영상의 골칫거리는 점점 더 현실적인 문제가 되고 있었습니다.

그래서 Brad는 속도 제한 요구사항을 받았을 때 다른 접근 방식을 택했습니다. “상사에게 ‘이 아이디어는 어떻게 생각하세요? ClickHouse로 한번 해볼 수 있을 것 같은데요?‘라고 물었습니다.” 이 아이디어는 이례적이었습니다. 일반적으로는 캐싱 계층의 문제로 여겨지는 영역에 분석용 데이터베이스를 사용하는 방식이었기 때문입니다. 하지만 이 방식은 이들의 핵심 요구사항을 충족했습니다. 즉, 장애 시 차단하지 않고 허용하는 fail-open 방식이어야 하고, 지연 시간 측면의 불이익이 없어야 하며, 소규모 팀이 무리 없이 운영할 수 있어야 했습니다. 이 솔루션은 기존 인프라를 활용했습니다. 액세스 로그가 이미 Kafka를 통해 ClickHouse로 유입되고 있었기 때문입니다. 별도의 Redis 클러스터를 유지 관리하는 대신, 액세스 로그 데이터에서 요청 패턴을 직접 분석하고 기존 ACL API에 속도 제한 규칙을 주입할 수 있었습니다. 이 접근 방식은 Redis보다 다소 높은 지연 시간을 감수해야 했습니다. Redis는 실시간 집계 쿼리를 수행하는 대신 “해당 데이터 세트를 미리 메모리에 올려두는 일종의 편법” 을 쓰기 때문입니다. 그럼에도 쿼리는 여전히 100밀리초 미만으로 완료되었습니다.

주요 결과:

• Redis 인프라 대비 큰 폭의 개선
• 기본 제공 TTL을 통한 자동 정리로 유지 관리 오버헤드 제거
• SQL의 유연성으로 단순 카운터를 넘어서는 복잡한 속도 제한 규칙 구현
• 별도 인프라 없이 기존 데이터 파이프라인 활용

​

고객 분석을 위한 ClickHouse

ServiceNow가 모바일 분석 플랫폼을 업그레이드해야 했을 때, 마주한 질문은 단순했습니다. “잘 작동하는 것을 왜 바꿔야 할까?” ServiceNow의 Amir Vaza는 기존 시스템이 안정적이라는 점을 알고 있었지만, 고객 요구는 이미 시스템이 감당할 수 있는 범위를 넘어가고 있었습니다. *“기존의 안정적인 모델을 교체해야 하는 동기는 사실 제품 측면에서 나옵니다,“*라고 Amir는 설명했습니다. ServiceNow는 웹, 모바일, 챗봇 솔루션의 일부로 모바일 분석을 제공했지만, 고객은 사전 집계된 데이터만으로는 충족되지 않는 분석 유연성을 원했습니다.

기존 시스템은 애플리케이션, 앱 버전, 플랫폼 같은 고정된 차원별로 구분된 사전 집계 데이터를 담은 약 30개의 테이블을 사용했습니다. 고객이 전송할 수 있는 사용자 정의 속성인 key-value 쌍에 대해서는 각 그룹별로 별도의 카운터를 만들었습니다. 이 접근 방식은 대시보드 성능은 빨랐지만, 큰 한계가 있었습니다. *“이 방식은 값을 빠르게 나눠 보는 데는 매우 좋지만, 앞서 말씀드린 한계 때문에 분석 맥락이 많이 손실됩니다,“*라고 Amir는 말했습니다. 고객은 복잡한 고객 여정 분석을 수행할 수 없었고, “얼마나 많은 세션이 ‘research RSA token’이라는 검색어로 시작되었는가” 같은 질문을 한 뒤 그 사용자가 다음에 무엇을 했는지도 분석할 수 없었습니다. 사전 집계 구조는 다단계 분석에 필요한 순차적 맥락을 없애버렸고, 새로운 분석 차원이 추가될 때마다 이를 사전 집계해 저장하기 위한 엔지니어링 작업이 필요했습니다.

이러한 한계가 분명해지자 ServiceNow는 ClickHouse로 전환해 이런 사전 계산 제약을 완전히 없앴습니다. 모든 변수를 미리 계산하는 대신, 메타데이터를 데이터 포인트로 나누고 모든 것을 ClickHouse에 직접 삽입했습니다. 또한 데이터를 효율적으로 수집하기 위해 ClickHouse의 async insert 큐를 사용했으며, Amir는 이를 *“정말 놀랍다”*고 평가했습니다. 이 접근 방식 덕분에 이제 고객은 직접 세그먼트를 만들고, 어떤 차원에서든 자유롭게 데이터를 나누어 보며, 이전에는 불가능했던 복잡한 고객 여정 분석도 수행할 수 있게 되었습니다.

주요 결과:

• 사전 계산 없이 모든 차원에서 동적 세분화 지원
• 복잡한 고객 여정 분석 가능
• 고객이 직접 세그먼트를 만들고 자유롭게 데이터를 나누어 볼 수 있음
• 새로운 분석 요구사항에 더 이상 엔지니어링 병목이 발생하지 않음

​

영상 자료

• Breaking the Rules - ClickHouse로 속도 제한기 구축하기 - Brad Lhotsky (Craigslist)
• ServiceNow의 분석 솔루션으로서의 ClickHouse - Amir Vaza (ServiceNow)

이 사례들은 기존 데이터베이스에 관한 통념에 의문을 제기하는 것이 분석용 데이터베이스의 가능성을 새롭게 정의하는 획기적인 해결책으로 이어질 수 있음을 보여줍니다.