본문으로 바로가기
본문으로 바로가기

성공 사례

이 가이드는 커뮤니티 밋업에서 얻은 인사이트를 모은 컬렉션의 일부입니다. 더 많은 실전 솔루션과 인사이트는 문제 유형별로 찾아보기를 통해 확인할 수 있습니다. 운영 환경 이슈를 디버깅하는 데 도움이 되는 팁이 필요하다면, 커뮤니티 가이드인 Debugging Insights를 참고하십시오.

이 사례들은 다양한 기업이 ClickHouse를 각자의 사용 사례에 적용하여 성공을 거둔 방법을 보여 줍니다. 일부는 전통적인 데이터베이스 분류 체계를 뛰어넘으며, 때로는 「잘못된」 도구처럼 보이던 것이야말로 정확히 맞는 해결책이 될 수 있음을 증명합니다.

ClickHouse as rate limiter​

Craigslist는 사용자 보호를 위한 최우선 순위(rate limiting) 기능을 추가해야 했을 때, 모든 엔지니어링 팀이 마주치는 동일한 결정을 해야 했습니다. 기존의 관행을 따르고 Redis를 사용할 것인지, 아니면 다른 방식을 시도해 볼 것인지였습니다. Craigslist에서 일하고 있던 Brad Lhotsky는 Redis가 표준 선택이라는 것을 알고 있었습니다. 거의 모든 rate limiting 튜토리얼과 예제가 Redis를 사용하는 데에는 그럴 만한 이유가 있습니다. rate limiting 작업을 위한 풍부한 기본 연산, 잘 정립된 패턴, 검증된 사용 이력이 있기 때문입니다. 그러나 Craigslist의 Redis 사용 경험은 교과서적인 예제와는 달랐습니다. "우리의 Redis 경험은 영화에서 본 것과 다릅니다... Redis 클러스터의 노드를 재부팅하면 이상한 유지 보수 문제가 많이 발생했고, 그때마다 프런트엔드 쪽에서 지연(latency) 스파이크가 발생했습니다." 작은 팀 입장에서 유지 보수의 단순성을 중요하게 생각하는 상황에서, 이러한 운영상의 골칫거리는 점점 더 큰 문제가 되고 있었습니다.

그래서 Brad가 rate limiting 요구 사항을 전달받았을 때, 그는 다른 접근을 택했습니다. "상사에게 이렇게 물었습니다. '이 아이디어에 대해 어떻게 생각하세요? ClickHouse로 시도해 봐도 될까요?'" 이 아이디어는 다소 비전통적이었습니다. 일반적으로 캐시 계층 문제로 여겨지는 것을 분석형 데이터베이스로 처리하는 것이었기 때문입니다. 하지만 이 접근은 Craigslist의 핵심 요구 사항을 충족했습니다. fail open 방식으로 동작하고, 추가 지연 시간을 유발하지 않으며, 소규모 팀도 무리 없이 운영할 수 있어야 했습니다. 이 솔루션은 Kafka를 통해 액세스 로그가 이미 ClickHouse로 유입되고 있는 기존 인프라를 활용했습니다. 별도의 Redis 클러스터를 운영하는 대신, 액세스 로그 데이터로부터 요청 패턴을 직접 분석하고 기존 ACL API에 rate limiting 규칙을 주입할 수 있었습니다. 이 접근 방식은 Redis보다 약간 더 높은 지연 시간을 의미했는데, Redis는 "사실상 해당 데이터 세트를 미리 인스턴스화해 두어" 실시간 집계 쿼리를 수행하는 대신 일종의 편법을 쓰고 있기 때문입니다. 그럼에도 불구하고 쿼리는 100밀리초 이내에 완료되었습니다.

핵심 결과:

  • Redis 기반 인프라 대비 극적인 개선
  • 자동 정리를 위한 내장 TTL 덕분에 유지 보수 오버헤드 제거
  • SQL의 유연성으로 단순 카운터를 넘어서는 복잡한 rate limiting 규칙 구현
  • 별도 인프라 없이 기존 데이터 파이프라인을 그대로 활용

고객 분석을 위한 ClickHouse​

ServiceNow가 모바일 분석 플랫폼을 업그레이드해야 할 때, 하나의 단순한 질문에 직면했습니다. "잘 돌아가는 것을 왜 바꿔야 하지?" ServiceNow의 Amir Vaza는 기존 시스템이 신뢰할 수 있다는 것을 알고 있었지만, 고객 요구 사항이 시스템이 처리할 수 있는 범위를 넘어 성장하고 있었습니다. Amir는 이렇게 설명했습니다. "신뢰할 수 있는 기존 모델을 교체하려는 동기는 사실 제품 관점에서 비롯됩니다." ServiceNow는 웹, 모바일, 챗봇 솔루션의 일부로 모바일 분석을 제공하고 있었지만, 고객은 사전 집계 데이터를 넘어서는 분석 유연성을 원했습니다.

이전 시스템은 약 30개의 서로 다른 테이블을 사용했고, 사전 집계된 데이터를 애플리케이션, 앱 버전, 플랫폼과 같은 고정된 차원으로 분할해 저장했습니다. 고객이 전송할 수 있는 커스텀 속성—key-value 쌍—에 대해서는 각 그룹마다 별도의 카운터를 만들었습니다. 이 접근 방식은 대시보드 성능을 빠르게 제공했지만, 치명적인 한계가 있었습니다. Amir는 *"이 방식은 값을 빠르게 나눠서 보는 데에는 훌륭하지만, 제가 언급한 제약 때문에 분석 맥락이 많이 손실됩니다"*라고 지적했습니다. 고객은 복잡한 고객 여정 분석을 수행하거나, 「'research RSA token'이라는 검색어로 시작된 세션이 몇 개였는가」와 같은 질문을 던진 뒤 그 사용자들이 다음에 무엇을 했는지 분석할 수 없었습니다. 사전 집계 구조가 다단계 분석에 필요한 순차적 컨텍스트를 파괴했고, 새로운 분석 차원이 추가될 때마다 사전 집계와 저장을 위한 엔지니어링 작업이 필요했습니다.

이러한 한계가 분명해지자, ServiceNow는 ClickHouse로 전환하여 이러한 사전 계산 제약을 완전히 제거했습니다. 모든 변수를 사전에 계산하는 대신, 메타데이터를 개별 데이터 포인트로 분해해 모든 내용을 직접 ClickHouse에 삽입했습니다. 이들은 ClickHouse의 async insert queue를 사용해 데이터를 효율적으로 수집했는데, Amir는 이를 *"정말 놀라운 기능"*이라고 표현했습니다. 이 접근 방식 덕분에 고객은 자체 세그먼트를 생성하고, 어떤 차원이든 자유롭게 데이터를 잘라서 분석하며, 이전에는 불가능했던 복잡한 고객 여정 분석을 수행할 수 있게 되었습니다.

핵심 결과:

  • 사전 계산 없이 어떤 차원이든 동적 세분화 가능
  • 복잡한 고객 여정 분석이 가능해짐
  • 고객이 자체 세그먼트를 만들고 데이터를 자유롭게 분할해 분석 가능
  • 새로운 분석 요구 사항에 대한 엔지니어링 병목 현상 제거

동영상 출처​

이 사례들은 기존 데이터베이스에 대한 통념에 의문을 제기하는 것이 분석형 데이터베이스에서 가능한 것의 범위를 다시 정의하는 혁신적인 해법으로 이어질 수 있음을 보여 줍니다.