D. E. Shaw グループが ClickHouse で大規模な高カーディナリティのオブザーバビリティを実現した方法

グローバルな投資およびテクノロジー開発企業である D. E. Shaw グループの内部では、大規模なハイパフォーマンスコンピューティングインフラ上で毎月数百万件ものコンピュートワークロードが実行されています。研究者、エンジニア、クオンツチームが短時間の実験から長時間稼働するサービスまで多岐にわたるジョブを投入しており、それぞれ異なる量のコンピュートリソースを消費しています。

これらのリソースがどのように使用されているかを把握することは、各チームがシステムのスムーズな稼働を維持しつつ、キャパシティプランニングを行い、組織全体にコンピュートを効率的に割り当てるために役立ちます。その可視性を支えるため、同社ではグリッド上で実行されるすべてのタスクについてメトリクスを収集し、ワークロードが要求したコンピュート量と最終的に消費した量の両方を記録しています。

これらのメトリクスは Prometheus スタイルの時系列データに似ています。時系列で収集された測定値であり、各タスクを識別するメタデータが付与されています。しかし、重要な違いが 1 つあります。サービスやホストのレベルでメトリクスを集約するのではなく、D. E. Shaw グループでは個々のタスク単位で使用状況を追跡している点です。このアプローチによりきわめて高いカーディナリティが生じ、既存のソリューションでは対応しきれないことが判明しました。

私たちは D. E. Shaw グループのサイトリライアビリティエンジニア(SRE)である Mike Vasiliou 氏に話を伺い、チームがこの規模でどのようにオブザーバビリティに取り組んでいるのか、そして高カーディナリティのメトリクスを長期的な分析やプランニングに実用的なものとするうえで ClickHouse がどのように重要な役割を果たしたのかを聞きました。なお、D. E. Shaw グループはユーザーであるだけでなく、傘下の D. E. Shaw Ventures チームを通じ、運用ファンドの 1 つを経由して最近 ClickHouse への出資も行っています。

メトリクスプラットフォームのスケーリング #

当初、D. E. Shaw グループの以前のオブザーバビリティプラットフォームは、クラスターノードから収集されたリソース使用率のメトリクスを保存していました。各マシンは InfluxDB ラインプロトコルを使ってテレメトリを送信し、チームはダッシュボードを通じて使用状況の監視やパフォーマンスの可視化を行っていました。

同社のニーズが進化するにつれ、チームはメトリクスプラットフォームをさらに改善し、長期的なキャパシティプランニングや戦略的な意思決定を可能にする好機を見出しました。既存の構成も十分に役立っていましたが、データ量と粒度が増加するにつれて、異なるスケールを想定して構築されたプラットフォームが必要になりました。すべてのワークロードに対して一意のタスク ID を保持することで、システムはコンピュート使用状況をきめ細かく把握するために必要なテレメトリを収集できましたが、時間が経つにつれてそのアプローチは何百万もの異なる時系列を生み出しました。詳細な粒度と、より広範な過去データの分析の両方をサポートするため、チームはこのタスクに適したプラットフォームを探し始めました。

ClickHouse の選定 #

チームは、D. E. Shaw グループで増大する高カーディナリティなオブザーバビリティワークロードを処理できる競合データベースをテストするため、評価プロジェクトを開始しました。

公平な条件で比較するため、エンジニアは同一のハードウェアとデータセットを使用して候補をベンチマークし、取り込みスループットとクエリパフォーマンスの両方を測定しました。

「ClickHouse を競合製品と比較したところ」と Mike 氏は語ります。「ClickHouse はほぼすべてのパフォーマンスメトリクスにおいて総合的に優れていました」

特に大きな差が出たのが取り込み性能です。ある競合ソリューションの単一ノードでは毎秒約 48 万サンプルを処理しました。これに対し、ClickHouse は毎秒約 350 万サンプルを取り込みました。本番環境において、D. E. Shaw グループのクラスターはすでに毎秒約 50 万サンプルのスループットで稼働しています。チームは、ClickHouse のより強力な取り込みパフォーマンスにより、将来のユースケースに向けたスケーリングの余力が大幅に広がると判断しました。

クエリパフォーマンスもその決定を後押ししました。「テストした一部のデータベースソリューションではクエリが 1 分後にタイムアウトしましたが、同様のクエリが ClickHouse では数秒で完了しました」と Mike 氏は述べています。「また、データのバックフィルにも ClickHouse が適していることがわかりました」。長期的な分析とキャパシティプランニングを支えるシステムにとって、ClickHouse のパフォーマンスと信頼性は明白な勝者となる理由でした。

他の評価と同様にトレードオフもありました。既存のダッシュボードは Prometheus スタイルのクエリに依存していたため、エンジニアはワークフローを SQL に変換する必要がありました。「プロジェクトのその部分はより骨が折れましたが、それだけの価値はありました」と Mike 氏は語ります。

高カーディナリティなオブザーバビリティプラットフォーム #

ClickHouse の選定後、チームは既存のワークフローへの中断を最小限に抑えてデプロイすることに注力しました。

全社的なメトリクスの生成方法を変更するのではなく、既存の取り込み経路を維持しました。グリッドノードは引き続き InfluxDB ラインプロトコルを使用してテレメトリを送信し、内部サービスが受信メッセージをバッチ処理して ClickHouse に挿入します。Influx プロトコルを維持して影響を最小限に抑えたいという意向があったため、ある程度のカスタム開発が必要となり、この移行作業は困難を伴うものでした。

D. E. Shaw グループは、長期的なキャパシティプランニングをサポートするために過去データを ClickHouse にバックフィルすることに多大なエンジニアリングリソースを投じました。当初は以前の時系列プラットフォームのクエリ API を利用しようと試みましたが、これはすぐに非現実的であることが判明しました。API では必要なスループットでデータを提供できず、抽出プロセスはパフォーマンス面でもリソース効率の面でも不十分でした。最終的に、ディスクからデータファイルを直接読み取り、列指向フォーマットに変換して、その結果を ClickHouse にストリーミングするカスタムツールを構築しました。このアプローチにより、大量の過去メトリクスデータを移行するために必要な速度と効率が得られました。

メトリクスは、ハードウェアコンポーネントの使用率を記述するリソース固有のテーブルに編成されています。各レコードには一意のタスク識別子が含まれており、個々のワークロードレベルでの可視性が維持されています。一意の ID によってエントロピーが高くなり、一部のフィールドでは圧縮効率が制限されるものの(それでも最大 5 倍の圧縮を達成しています)、コンピュート使用状況を分析するユーザーにとってクエリの実行がより直感的になります。

現在、この環境には複数年にわたる圧縮後で約 68 TB のメトリクスデータが保存されています。クラスターは NVMe ストレージを備えた 4 台のレプリカサーバーで稼働しており、今後の成長に対しても十分な余裕があります。チームは現在、複数の他のデータセットを社内の ClickHouse クラスターに取り込んでおり、平均で毎秒 53 万レコード、ピーク時には 100 万レコードを超える挿入レートを処理しています。マテリアライズドビューにより長期にわたるデータが事前集約され、過去分析やキャパシティプランニングに使用されるダッシュボードを支えています。

インフラからビジネスへのインパクトへ #

長期保存と信頼性の高い集約が可能になったことで、D. E. Shaw グループにおけるオブザーバビリティはインフラ監視の域を超え、運用上の意思決定へと広がり始めました。

コンピュートグリッド上で実行される各タスクは特定の割り当てを要求しますが、これは実際に消費される量よりも多い場合もあれば少ない場合もあります。要求された量と実際に使用された量の両方を保存することで、チームは個々のワークロードやユーザーのレベルで効率性を評価できます。「効率性を測定できることは私たちにとって重要です」と Mike 氏は説明します。「これにより、リソース割り当ての決定に直結する使用率の可視化が可能になるからです」

ワークロードが一貫して使用量以上のリソースを要求している場合、チームはそれに応じてキャパシティを調整できます。逆に、制限を定期的に超えているワークロードは、クォータを増やすか追加のコンピュートをプロビジョニングするための明確な根拠となります。

大規模な環境において、このプラットフォームはさまざまなモデルや研究ワークロードが長期にわたってどれだけのコンピュートを消費しているかに関する共有の信頼できる情報源(Single Source of Truth)を提供します。この可視性により、同社は将来のキャパシティニーズをより正確に予測し、それに応じてハードウェアの調達を計画できます。

トレーシングおよびその先への拡張 #

最近、D. E. Shaw グループは分散トレーシングを皮切りに、ClickHouse を他のオブザーバビリティ領域へ拡張し始めています。OpenTelemetry を使用し、サービスはトレースデータを中央のコレクター経由で送信し、そこでイベントをバッチ処理して ClickHouse に転送しています。

Grafana をベースとした探索環境への移行により、チームがトレースデータを扱う方法に新たな可能性が開かれています。ユーザーはサービスやトレース ID で検索し、システムの挙動をより直感的に追跡し、パフォーマンスを損なうことなく大量のトレースデータを分析できます。

ClickHouse の圧縮は、この拡張を実現するうえで大きな役割を果たしました。トレースデータセットは現在、約 12.5 倍の圧縮率を維持しています。「圧縮は私たちにとって大きな要素です」と Mike 氏は言います。「他のデータソースと比較してより高く圧縮できるため、結果として使用するハードウェアを削減できます」

現時点ではチームはトレースを二重書き込みしており、導入が完了した段階でワークフローを統合する予定です。トレーシングと並行して、エンジニアは構造化ログやスキーマが明確に定義されている分析ワークロード向けに、より広範なイベントデータパイプラインを検討しており、メトリクスストレージを超えて統合オブザーバビリティプラットフォームへと ClickHouse の役割を広げています。

ClickHouse を最大限に活用する #

Mike 氏は「単一のオブザーバビリティツールがあらゆるユースケースに適合するとは限らない」と前置きしつつも、次のように語っています。「ClickHouse は、高カーディナリティな時系列メトリクスデータの全体像の把握と詳細な低レイヤー分析の両方を実現する優れたツールであることがわかりました。高性能なオブザーバビリティプラットフォームを求めているチームは、有力な候補として間違いなく検討すべきだと思います」

要となるのは、システムの設計をどのように活かすかを理解することだと同氏は説明します。「SUV のように、何も意識しなくてもそこそこのパフォーマンスが得られるツールもあります」と彼は言います。「ClickHouse はどちらかといえばレーシングカーに近く、本当に非常に高速なパフォーマンスを得られますが、そのための工夫に少し頭を使う必要があります」

その工夫とは、複雑さというよりも慣れの問題であると同氏は付け加えています。チームが MergeTree やデータモデリングなどの概念に慣れると、ClickHouse はオブザーバビリティと大規模分析のための強力で頼もしいプラットフォームになりました。

大量かつ高カーディナリティなデータに対して同様の課題を抱えるチームにとって、D. E. Shaw グループの経験は、適切な設計上の選択と分析基盤があれば、大規模環境での現代的なオブザーバビリティが実用的かつ持続可能なものになることを示しています。