Cloudflare の請求パイプラインが突然遅延した原因は ClickHouse の隠れたボトルネックだった

Cloudflare では、オープンソースの分析用データベース管理システムである ClickHouse を大規模に活用しています。私たちは、数百もの内部チームが利用するテーブルに対してテナントごとのデータ保持期間を可能にするため、パーティショニングキーに列を追加する形で、最も大きな ClickHouse テーブルの一つのリデザインを行いました。この設計は、最終的なアプローチにたどり着くまでに、複数のチームのエンジニアたちによる数回の改訂とレビューを経て完成しました。しかし、ロールアウトから数週間後、Cloudflare の請求書の大部分を生成するジョブが、厳格な毎日の期限に直面し始めました。 通常疑われる要因はすべて正常でした：I/O、メモリ、スキャンされた行数、読み込まれたパーティション。ClickHouse クエリが遅くなる際に通常確認する項目はすべて正常に見えました。しかし、問題の正体はクエリ計画におけるロック競合であり、これは以前から原因を調べる理由がなかった箇所でした。 この移行が ClickHouse の内部に隠されたボトルネックを明らかにし、私たちがそれを修正するために作成したパッチについての物語です。 環境設定：ペタバイト規模の分析プラットフォーム 私たちは、数十のクラスターにまたがる 100 ペタバイト以上のデータを保存するために ClickHouse を使用しています。多数の内部チームに対するオンボーディングを簡素化するため、2022 年初頭に「Ready-Analytics」と呼ばれるシステムを構築しました。 前提は単純です。新しいテーブルを設計する代わりに、チームはデータを単一の巨大なテーブルにストリーミングできます。データセットは名前空間によって曖昧さを解消し、各レコードは標準スキーマ（例：20 個の浮動小数点フィールド、20 個の文字列フィールド、タイムスタンプ、および indexID）を使用します。 ClickHouse では、データをどのようにソートするかがクエリパフォーマンスに決定的な影響を与えます。ここで indexID が重要な役割を果たします。これは主キーの一部を形成する文字列フィールドであり、各名前空間ごとに、その名前空間の所有者が実行すると予想されるクエリに対して最適な方法でデータをソートできるようにしています。全体として、以下のような主キーが得られます：(namespace, indexID, timestamp)。 このシステムは非常に人気があり、数百ものアプリケーションで使用されています。2024 年 12 月にはデータ量がすでに 2PiB を超え、毎秒数百万行の取り込み速度を記録していました。しかし、一つの決定的な欠陥がありました：その保持ポリシーです。 問題点：すべてのルールに適用される単一の保持ポリシー Cloudflare は、ネイティブの Time-to-Live (TTL) 機能が備わる以前から長年 ClickHouse を使用しています。そのため、パーティショニングに基づいた独自の保持システムを構築しました。Ready-Analytics テーブルは日付ごとにパーティション分割されており、保持ジョブは単純に 31 日以上前のパーティションを削除するだけでした。 この「一律適用」の31日間保持ポリシーは大きな制限要因でした。法的または契約上の義務により、一部のチームではデータを数年間保存する必要がありましたが、他のチームでは数日間の保存で十分でした。この制限により、これらのユースケースは Ready-Analytics を利用できず、オンボーディングプロセスがはるかに複雑な従来のセットアップを選択せざるを得ませんでした。 私たちは名前空間ごとの保持を可能にする新しいシステムが必要でした。 解決策：新しいパーティショニングスキーム 私たちは主に2つのアプローチを検討しました: 名前空間ごとのテーブル: これは自然に保持問題を解決しますが、オンデマンドで数千のテーブルを管理するための大幅な新自動化が必要になります。 新しいパーティションキー: パーティションキーを (日付) のみから (名前空間，日付) に変更できます。 私たちは2番目のオプションを選択しました。これにより、既存の保持システムが引き続きパーティションを管理できるようになりますが、粒度は名前空間単位となります。 テーブル内のデータパーツの総数が増加することは承知していましたが、重要な仮定を立てました：すべてのクエリが特定の名前空間でフィルタリングされるため、単一のクエリが読み込むパーツ数は変わらないはずです。これによりパフォーマンスには影響しないと私たちは考えました。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/6d3ywoUP3OE2DCRAJtAgF7/5aa62c5702a923e30889ebf787925ae8/BLOG-3299_image4.png) これは、単一の名前空間のデータを安価に削除できるようになったパーティショニングの変更を示しています この新システムにより、高度なストレージ管理層を構築することも可能になりました。最大最小公平性アルゴリズム（max-min fairness algorithm）を用いることで、ターゲットとなるディスク利用率（例：90%）を設定し、利用可能なスペースを自動的に「共有」できるようになります。割り当てられた公平なシェアよりも少ない容量しか使用していない名前空間は、その未使用容量をより必要とする他の名前空間に譲渡します。これにより、クラスターを 90% の利用率で安全に運用することが可能になりました。 移行作業は 2025 年 1 月に開始されました。ClickHouse の Merge テーブル機能（Merge table feature）を活用し、旧テーブルと新テーブルを結合させました。これにより、新しいデータはすべて新しいパーティション化されたテーブルへ書き込まれながら、古いデータは徐々に期限切れとなりました。 謎解き：請求処理が突然破綻したとき 2 ヶ月後、2025 年 3 月下旬のことでした。請求チームから、日次集計ジョブ（daily aggregation jobs）の速度が遅くなっているとの報告がありました。これらのジョブは時間厳守であり、完了しなければ請求書が発行されません。ジョブの処理時間は次第に遅延し、期限が迫っていました。 調査を進めましたが、いつもの犯人候補には当てはまりませんでした。I/O は正常でした。メモリも問題ありませんでした。個々のクエリのメトリクスを見ても、以前よりも多くのデータやパーティション（parts）を読み込んでいないことが示されました。当初の仮説は正しかったように思われましたが、システムは完全に停止状態に陥っていました。 理論を構築するまでに数日を要しました。最終的に、クラスター内の総パーティション数に対するクエリ実行時間のプロットを作成したところ、その相関関係は疑う余地のないものでした。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/69SY5BVn3bPW5O9n5LrVjU/c7b99fda71d57156fa2784947db675f4/BLOG-3299_image2.png) Ready Analytics の ClickHouse クラスターにおける平均 SELECT クエリ実行時間。段階的なパフォーマンス劣化を示しています。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/2mt08KB04Y3n0vsNJAfK81/86da06fe572126e0e777f7dc4c00d7fb/BLOG-3299_image1.png) 新しい (namespace, day) パーティションスキームに従った、テーブルレプリカごとのデータパーティ総数の線形的な増加。 しかしなぜでしょうか？追加のパーティを読み込んでいないのに、その存在自体がどうしてパフォーマンスを低下させたのでしょうか？ 調査：フレイムグラフによるボトルネックの特定 フレイムグラフ（flame graph）を生成するために、ClickHouse の組み込み機能である trace_log を利用しました。これは実行中の ClickHouse サーバーからのトレース記録を保持する組み込みテーブルです。ここで記録されるのは単にどのコードが実行されているかというトレースだけでなく、特定のユーザー、クエリ ID、その他のメタデータとの関連付けも含まれるため、必要に応じて非常に精密なイベントセットに絞り込むことが可能です。今回のケースでは、特にリーフ（leaf）SELECT クエリに焦点を当てて調査を行いました。このテーブルに含まれる利用可能なメタデータのおかげで、これは容易に行えました。 最初に作成した CPU ベースのフレイムグラフは、私たちの懸念をすぐに裏付けました：膨大な時間がクエリプランニング（query planning）に費やされていました。これは実行前のフェーズであり、ClickHouse がどのパーティを読み込むかを決定する段階です。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/4Tppo6pF4ePCWTTC1lWi03/a1582ce51ef60116a1848cab83fe9516/BLOG-3299_image7.png) パーティション ID に基づいてパーツのベクトルをフィルタリングする際に、リーフクエリの CPU 時間の 45% が消費されていることを示すフレームグラフ フレームグラフは明確でした：サンプリングされた CPU 時間の 45% が、filterPartsByPartition という単一の関数内で消費されていました。 私たちの最初の修正試みは、この特定のコードパスに対する小さなパッチでした。プランナーはパーツを剪断するためのヒューリスティックを評価しますが、私たちはそれがテーブルに対して最適な順序で評価されていないと考えていました。私たちのパッチはこの順序を変更し、わずかに 5% の改善をもたらしました。私たちは正しい方向に進んでいましたが、真の問題を見落としていたのです。 私たちは「CPU」トレースを生成していましたが、これはアクティブなスレッドのみをサンプリングするものでした。私たちはすべてのスレッド（非アクティブまたは待機中のスレッドを含む）をサンプリングする「Real」トレースに切り替えました。新しいフレームグラフは驚くべき発見でした。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/715i8uMnak2T9Sdf4Jtcsy/1c962dbef3692257679136f6c3d36dca/BLOG-3299_image10.png) リーフクエリの持続時間の半分超が、アクティブなパーツのリストを保護するミューテックス（mutex）の取得待ちに費やされていることを示すフレームグラフ 問題は CPU 負荷の高い作業ではなく、大規模なロック競合でした。クエリ持続時間の半分以上は、テーブルのパーツリストを保護する単一のミューテックス（MergeTreeData）を取得するために待機することに費やされていました。クエリを計画するためには、すべてのスレッドが次の手順を実行する必要がありました： このミューテックスに対して排他的ロックを取得する。 テーブル内のすべてのパーツのリストを完全にコピーする。 ロックを解放する。 そのリストから関連するパーツのみをフィルタリングする。 数万個のパーツと数百の並行クエリが存在する状況では、すべてが単一のファイルラインで順番待ちの状態でした。 対策：3 つのパッチ群 この洞察により、これらのホットスポットを緩和するための一連の最適化計画を立てることができました。ClickHouse に対して行うすべてのパッチと同様に、私たちはそれらを汎用的なものとし、最終的にアップストリームのコードベースにコントリビュートされるように努めています。これにより、フォークのメンテナンスが容易になり、コミュニティも私たちの変更から恩恵を受けることになります！ 最適化 1：共有ロックの使用 クエリプランナーはパーツリストを変更するのではなく、単に参照するだけです。排他的ロックを使用する必要はありませんでした。 対策：コードを修正し、排他的ロックの代わりに共有ロック (std::shared_lock) を取得するようにしました。これにより、すべてのクエリプランナーがクリティカルセクションに同時にアクセスできるようになりました。 結果：クエリ実行時間が劇的かつ即座に短縮されました。ロック競合は解消されました。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/5Kj9AqPYFnhQjQya9C1U5y/122aff70ba4aae88c7fdbc479edd0147/BLOG-3299_image8.png) 共有ロック最適化（最適化 1）が平均 SELECT クエリ実行時間に与えた即時的な影響。ロック競合の解消を示しています。 最適化 2：ベクトルのコピーを停止する パフォーマンスは大幅に改善されましたが、まだベースラインには戻りませんでした。私たちはトレースログに戻り、もう一つの「リアル」なフレイムグラフを作成しました。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/77AAAaeIqq6wRHaG8LjVeI/6dccdbf2c8b0c334c1d05b930572ab05/BLOG-3299_image5.png) フレイムグラフは、リーククエリ（leaf query）の持続時間の 4 分の 1 を全パーツのベクトルをコピーすることに費やし、さらに別の 4 分の 1 をその中からフィルタリングする（再度コピーする）ことに費やしていることを示しています。 新しいフレイムグラフは、ボトルネックが単に移動しただけであることを示しました。今では、共有ロックを使用しているにもかかわらず、巨大なパーツのベクトルをコピーすることに時間が費やされています。直感的にはベクトルのコピーは安価に思えますが、それが数万個の要素を含み、1 秒間に数百回実行される場合、その合計は無視できません。 解決策：私たちはコピーを完全に遅延させることにしました。パーツリストの「共有コピー」を作成します。読み取り専用操作（クエリ計画など）はこのコピーから直接読み取ります。パーツセットを変更する操作（新しい挿入など）はキャッシュを再生成します。プランナーは、実際に必要なフィルタリングされたパーツリストのみをコピーするように変更されました。 結果：さらに顕著なパフォーマンスの改善が達成されました。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/1d63suwP2kJZPqbzMQN1XQ/8ed1c519d1929f27d920d5a740b6b09f/BLOG-3299_image6.png) ベクトルコピー最適化（最適化 2）をロールアウトした後のさらなるパフォーマンス改善。 これらの内部での大幅なコスト削減を確認した後、私たちはこれらの変更をコミュニティにも提供することを決定しました。ClickHouse Inc. のメンテナーとのいくつかの小さな設計の反復を経て、変更は PR #85535 としてマージされました。これらは ClickHouse バージョン 25.11 から利用可能になっています。 最適化 3: パーツに対するバイナリ検索 まだ完了していません。パーツ数が成長するにつれて、パフォーマンスは依然として低下しますが、その速度は大幅に緩やかです。パーツ数との相関関係はまだ存在していました。数ヶ月後にこの問題に戻ると、新しいフレイムグラフ（図 3 と同じ外観）が、時間がフィルタリングコードパス（最初に修正を試みたもの）で消費されていることを示しています。このコードはすべてのパーツに対して線形走査を実行し、各パーツに対して述語を評価します。数ヶ月後には、最適化前の選択実行時間に戻ってしまいました。 しかし、私たちはこのパーツリストがパーティショニングキーによってソートされていることを知っています。パーティションキーの最初の列は名前空間であり、これは「テナント」を識別するため、绝大多数のクエリがこの項目でフィルタリングします。これをどのように活用できるでしょうか？ 解決策：パーティション ID の名前空間部分に基づいた二分探索を実装しました。これはベクトルがソートされているため、実際に見ることなく多くのエントリをフィルタリングできるからです。特に、名前空間がこのソートキーの最初の部分であるため、この手法は非常に効果的です。この最初のパスの二分探索の後、確認する必要があるパーティションの範囲が大幅に縮小されます。その後、残りのパーティションについては以前と同じロジックを適用し、他の条件に基づいて除外します。 結果：2026 年 3 月にこのパッチを展開した後、クエリの実行時間が 50% 短縮されました（図 8 を参照）。さらに重要なのは、これでついにクエリ実行時間とパーティション数の相関関係が解消されたことです。残念ながら、この解決策は任意のクエリ条件（例：namespace IN (5,10) のような条件）に対して一般化して適用するのは容易ではありません。私たちは、パーティションフィルタリングをカバーするようにクエリ条件キャッシュを拡張するなど、より汎用的なアプローチを検討中です。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/4leNlnUeD3RIQVPT2VN1IB/90b76933cfdd24955c51d4c00287b9b0/BLOG-3299_image3.png) パーティションプルーニングのための二分探索（最適化 3）の実装に伴う持続的なレイテンシの削減。 不安定な休戦協定 これらの最適化により、請求システムにおける即座の危機は解決されました。しかし、この旅を通じて、私たちのパーティショニング選択が持つ深遠で直感的でないコストが明らかになりました。 他の問題も残っています。このブログ記事では、部分数の増加が select の実行時間に与えた影響についてのみ記述しましたが、ClickHouse 内のすべての部分のメタデータを追跡する ZooKeeper にも問題を引き起こしました。いつか 100 ギガバイト規模の ZooKeeper クラスターに関する物語を語る日が来るかもしれません。 私たちは十分な猶予を得ましたが、根本的な問いは依然として残っています：このパーティショニングスキームは長期的に正しい選択だったのでしょうか？それとも最終的に覚悟を決めて別のアーキテクチャへ移行する必要があるのでしょうか？現時点ではパッチが機能していますが、今回の経験は、計画された変更であっても誤った前提によって失敗しうることを明確に示す事例となりました。 請求チームがこの問題を最初に報告した時点では、レプリカあたり 30,000 個の部分がありました。部分数の増加率は止まることなく、1 年後にはレプリカあたり 160,000 個に達しましたが、ここで実施した最適化のおかげでクエリの実行時間は安定しています。 Cloudflare では、大規模な複雑なエンジニアリング問題に取り組んでいます。ここで紹介したデバッグや最適化が、あなたが探しているような挑戦に見える場合は、現在募集しているオープンポジションをぜひご覧ください。

Cloudflare の請求パイプラインが突然遅延した原因は ClickHouse の隠れたボトルネックだった

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト