Cloudflare: ClickHouse로 Quadrillion 단위 분석을 견디는 회복탄력성

원문: Trouble will find you: How Cloudflare uses ClickHouse to scale analytics at quadrillion-row scale

Cloudflare는 전 세계 웹사이트의 약 1/5에 트래픽을 제공하며, 하루에 quadrillion(천조) 단위의 이벤트를 처리합니다. Senior Director of Engineering인 Jamie Herre는 "페이저를 차고 다닌다면 무슨 말인지 알 것이다. 항상 어딘가는 고장 나 있다고 가정해야 한다"고 말합니다. 이 글에서는 Cloudflare가 어떻게 ClickHouse를 중심으로 bend without breaking(휘어지지만 부러지지 않는) 분석 시스템을 설계했는지 살펴봅니다.

규모의 문제

Cloudflare가 운영하는 시스템의 규모는 다음과 같습니다:

• 전 세계 300개 이상의 데이터센터 운영
• 하루 quadrillion(천조) 단위 이벤트 처리
• 거의 10년간 오픈소스 ClickHouse 운영 — OLAP 데이터베이스의 초기 대규모 도입 기업 중 하나

Scaling은 "끝없는 여정"이다

Jamie는 확장(scaling)을 "체크박스로 끝나는 마일스톤"이 아니라 "끊임없는 적응의 여정"이라고 정의합니다.

• 더 많은 데이터, 더 큰 복잡도, 더 잦은 장애에 대응
• 어제의 천장이 오늘의 바닥이 되는 구조
• 트래픽 폭증과 용량 손실은 결국 같은 코인의 양면 — 시스템이 어제의 한계를 넘어선다는 점에서

데모로 증명한 회복탄력성

2025년 8월 샌프란시스코 ClickHouse 밋업에서 Jamie는 라이브 데모를 진행했습니다.

1. 압도적인 쿼리 성능

• 단일 쿼리로 1시간 동안 96조 개 이벤트 스캔 → 2초 미만 응답, 오차 1% 미만
• 하루 단위로 확장하면 1.61 quadrillion 이벤트 → 여전히 2초 미만
• 1시간, 하루, 1주, 1개월, 1년 어떤 기간으로 확장해도 "2초 미만"이라는 응답 시간은 유지

2. 장애 시뮬레이션

• 북미의 주요 데이터센터 1곳, 그리고 북미 전체를 통째로 분리
• 에러는 예상대로 급증했지만, 쿼리는 계속 결과를 반환
• 유럽 클러스터가 자동으로 부하를 인수하며 동일한 오차 범위 내 결과 제공
• Cloudflare의 distributed, active-active 설계 + ClickHouse 덕분에 가능

ClickHouse를 선택한 이유

Jamie가 꼽은 ClickHouse의 강점들:

1. HTTP 프로토콜 — "가장 저평가된 기능"

• 분석 클라이언트가 전적으로 HTTP로 ClickHouse와 통신
• 통합이 단순하고 보편적이며, 활용할 수 있는 도구와 모드가 풍부

2. 최소한의 조정(coordination)만 요구

• Raft나 Paxos 같은 무거운 합의 프로토콜에 의존하지 않음
• "용량의 1/3을 제거해도 큰 문제가 생기지 않는다" — 나머지 노드들이 그대로 동작

3. "Soft cluster" 구조

• 어느 노드든 질의 가능, 동적인 조합 선택 가능
• 정상 동작 중인 노드를 찾아 라우팅하는 유연성 제공

4. Optional complexity (선택 가능한 복잡성)

• 필요한 기능만 켜고 끌 수 있는 구조
• 자사 사용 사례에 맞는 부분만 활용 가능

5. 표현력 있는 SQL 방언

• 처음엔 적응이 필요했지만, 워크로드에 매우 효율적이고 표현력 있음

6. 오픈소스 커뮤니티와 코드베이스

• 소스 코드 이해, 기여, 의존 가능
• 수년간 커뮤니티로부터 많은 것을 얻었다고 평가

Jamie의 조언: Just do it!

"It's never too early, and it's never too late. You'll never be done."

Jamie가 강연을 마무리하며 강조한 핵심 메시지:

• 확장은 끝나지 않는다 — 가장 좋은 준비 시점은 "지금"
• 두 가지 시나리오 모두 대비해야 함:
• 워크로드가 10배, 100배로 갑자기 늘어났을 때 "좋게" 실패할 것인가, "나쁘게" 실패할 것인가?
• 용량의 9/10을 잃었을 때 그대로 쓰러질 것인가, 계속 사용 가능할 것인가?
• Cloudflare에게 이것은 가설이 아니라 매일의 현실

교훈과 시사점

폭발적 성장과 재앙적 손실을 동시에 설계하라

Cloudflare는 quadrillion 단위 이벤트, 수백 개 데이터센터, 장애의 필연성을 모두 전제로 시스템을 설계합니다. ClickHouse는 "속도"와 "회복탄력성" 중 어느 하나도 희생하지 않고 두 시나리오에 대응할 수 있는 유연성을 제공합니다.

규모와 무관하게 적용되는 원칙

GB에서 시작하든, TB에서 PB로 확장하든 동일한 설계 원칙이 적용됩니다 — 핵심은 "스케일이 찾아왔을 때 준비되어 있는가"입니다.

결론

Cloudflare의 ClickHouse 사례는 "항상 무언가는 최적이 아니다"라는 전제를 받아들이면서도, 어떻게 성공적인 응답을 보장하는 시스템을 만들 수 있는지를 보여줍니다. > "At Cloudflare, we're always scaling. There's always more trouble tomorrow. But we've designed our system around ClickHouse to be able to deal with that." — Jamie Herre, Senior Director of Engineering

트러블은 반드시 찾아옵니다. 유일한 질문은, 그것이 찾아왔을 때 당신이 준비되어 있는가입니다.