トラブルは向こうからやってくる: Cloudflareがクアドリリオン(千兆)行規模の分析をスケールするためにClickHouseをどう活用しているか

Cloudflare のJamie Herre氏にとって、トラブルとはエンジニア版のマーフィーの法則のようなものです。起こり得ることは必ず起こる。そして大規模なシステムでは、それが起こるかどうかではなく、いつ起こるかという問題なのです。ドライブが壊れる。サーバーがダウンする。証明書が期限切れになる。リンクが切れる。「ポケベルを持って働いているなら、私の言っていることがわかるはずです」とJamie氏は語ります。「常にどこかで何かが壊れていると思っていていいんです。」

Jamie氏が2018年にシニア・ディレクター・オブ・エンジニアリングとしてCloudflareに入社したとき、同社のイベントパイプラインは彼がそれまで見てきた中で「ダントツに」最大規模でした。それから7年が経った今、同社は世界中のWebサイトの約5分の1にサービスを提供するまでに成長しました。当時巨大だと感じたものも、Cloudflareが今日処理する数千兆件のイベントと比較すると、控えめに思えるほどです。

Jamie氏に言わせれば、スケーリングはマイルストーンでもチェックボックスでもありません。それは絶え間ない適応の旅路——より多くのデータ、より高い複雑性、より多くの障害への適応です。新しい天井はやがて、次に来るものの床になります。「スケーリングについて話すとき、それは終わりのあるプロセスではないのです」と彼は言います。「規模が大きくなるにつれて、物事はより頻繁に失敗するようになります。」

その意味で、トラブルとスケーリングは表裏一体です。突然のトラフィック急増は、障害で容量の半分を失うのとよく似ていますし、その逆も同様です。どちらの場合も、システムは昨日までの限界を超えて引き伸ばされます。Jamie氏によれば、設計者やエンジニアの課題はそのストレスを避けることではなく——それは不可能ですから——壊れずに曲がるインフラ、そして必然的な障害に直面しても回答を返し続けるインフラを構築することなのです。

「よいトラブル」とはどんなものか #

「壊れずに曲がる」とは実際にはどんなものか。それを示すために、Jamie氏はサンフランシスコのCloudflareオフィスで開催された2025年8月のClickHouseミートアップで、自身のチームの分析システムをデモしました。

最初の結果が示したのは、システムの規模感です。たった1つのクエリが1時間あたり96兆件のイベントをスキャンし、2秒未満で結果を返しました。誤差は1%未満。範囲を1日に広げると、同じクエリは1.61京件のイベントを対象にしましたが、それでも2秒未満で完了しました。Jamie氏にとっては「クアドリリオン（千兆）」と口に出して言えること自体が楽しみの一部でした（「ちょっとした見栄ですね」と冗談を言います）が、彼の主張は真面目なものでした。多くのチームにとっては想像を超えるようなボリュームでも、システムは瞬時に正確に応答し続けるのです。

そして次はストレステストです。トラブルがトラフィック急増ではなく、容量の喪失として襲ってきたらどうなるでしょうか？Jamie氏は北米の主要なデータセンターを切断し、続いて北米全域を一度に切断するシミュレーションを行いました。予想通りエラーは急増しましたが、クエリは結果を返し続けました。Cloudflareの分散型・アクティブ-アクティブ設計により、世界中に300以上のデータセンターがあり、欧州のクラスタが自動的に負荷を引き受け、結果は同じ厳しい誤差範囲内で一貫していました。

クエリのウィンドウを1時間から1日、1週間、1か月、さらには1年へと拡大しても、システムのパフォーマンスは安定していました。「どれだけ要求しても、2秒未満で結果を返してくれます」とJamie氏は言います。

このデモは、Cloudflareの分析システムが弾力性と応答性の両方を備えていることを証明しました。大規模な障害や規模の変動にも崩れることなく耐え、負荷や容量、ボリュームに関係なく数秒でクエリを返します。他のシステムであれば、極端な規模でこのレベルの応答性を維持するには、複雑な調整や積極的なチューニング、大きなアーキテクチャ上のトレードオフが必要になりますが、ClickHouseはCloudflareが設計上このように運用することを可能にしています。基本的な前提は「常に何かが最適ではない」というものですが、それは成功した応答を妨げません。

「Cloudflareでは、常にスケーリングしています」とJamie氏は言います。「明日には常により多くのトラブルがあります。でも、私たちはそれに対処できるよう、ClickHouseを中心にシステムを設計してきました。」

なぜClickHouseがCloudflareに合っているのか #

「ClickHouseの何がそんなにすごいのか？」とJamie氏は問いかけます。実は、たくさんあります。

Cloudflareはオープンソース版のClickHouseを約10年間運用しており、このOLAPデータベースの最も早い大規模採用者の一つです。その長い歴史が、Jamie氏とチームがグローバル規模での弾力性とパフォーマンスをどう考えるかを形作ってきました。

Jamie氏によれば、「過小評価されている機能」の一つはHTTPプロトコルです。Cloudflareの分析クライアントは、ClickHouseとのやり取りをすべてHTTP経由で行います。これにより、統合がシンプルかつ普遍的になります。「活用できるツールやモードがたくさんあります」と彼は言います。

彼はまた、「必要となる調整が最小限である」点も強調します。常にRaftやPaxosで交渉するシステムとは異なり、ClickHouseのノードは動作を維持するために大掛かりなオーケストレーションを必要としません。「デモでやったように容量の3分の1を取り除いても、それほど多くは壊れません。なぜなら、残りのノードはすべてまだそこにあるからです」と彼は説明します。

その思想は、Jamie氏が「ソフトクラスタ」と呼ぶもの——任意のノードに問い合わせて動的な組み合わせを選べる機能——にも及んでいます。「これにより、動作していて健全なノードを見つけるための制御と柔軟性が大きく得られます」と彼は言います。さらに「オプショナルな複雑性」、つまり必要に応じて機能をオン・オフできる能力もあります。「私たちは、特定のユースケースに合うものを活用するよう努めてきました」と彼は付け加えます。

SQLの方言でさえ、「意外な利点」だとわかってきました。慣れるのに少し時間はかかりましたが、時間が経つにつれてJamie氏は、それがチームのワークロードに対していかに表現力豊かで効率的かを評価するようになりました。「本当にクールです」と彼は言います。

最後に、Jamie氏はClickHouseのオープンソースコミュニティとソースコードの価値を強調します。Cloudflareにとって、データベースの進化を理解し、貢献し、信頼できることは大きな価値を持ちます。「このコミュニティの一員であることで、長年にわたって多くのものを得てきました」と彼は言います。

Jamie氏のアドバイス——とにかくやるべし！ #

Jamie氏は、スケーリングに終わりはないというリマインダーで講演を締めくくりました。準備を始めるのに最適なタイミングは、まさに今です。「早すぎることも、遅すぎることもありません」と彼は言います。「終わりは決して訪れないのですから。」

重要なのは、トラブルに迫られる前にスケーリングについて考えることだ、と彼は主張します。「ワークロードが突然10倍、100倍にスケールしたとしましょう——それはよい形で失敗しますか、それとも悪い形で失敗しますか？逆に、容量の10分の9を失ったらどうでしょう？単に倒れてしまうのか？それとも引き続き正常に使えるのか？」

Cloudflareにとって、これらは仮定の話ではありません。1日あたり数千兆件のイベント、世界中に数百のデータセンターがあり、障害は遍在し不可避である中、同社は爆発的な成長と壊滅的な損失の両方に対して同時に設計しなければなりません。ClickHouseはJamie氏とチームに、速度や弾力性を犠牲にせずに、どちらのシナリオにも対処できる柔軟性を提供します。

あなたの会社はCloudflareほどの規模で運用していないかもしれませんが、同じ設計原則は、ギガバイトから始めるにせよ、テラバイトからペタバイトへとスケールするにせよ、変わらず適用できます——目標は単純に、スケールが訪れたときに準備ができていることです。

その教訓は普遍的です。トラブルは保証されています。問われるのはただ一つ、それがあなたを見つけたときに、あなたに準備ができているかどうかだけです。