分散トレーシングの標準ツールとして広く普及しているJaegerが、最新バージョンとなるv2.18.0において、ついにストレージバックエンドとしてClickHouseを正式にサポートしました。
クラウドネイティブな環境におけるマイクロサービスの可観測性を向上させるため、膨大なトレースデータの効率的な保存と高速な検索は常に大きな課題となっています。
今回のアップデートでは、列指向データベースであるClickHouseの特性を最大限に活かすことで、従来のストレージと比較して圧倒的なパフォーマンス向上を実現しています。
特に大規模なテレメトリデータを扱う組織にとって、この統合は運用コストの削減と分析精度の向上を同時に叶える画期的な進化といえるでしょう。
本記事では、Jaeger v2.18.0におけるClickHouse対応の技術的詳細や、驚異的な圧縮率を実現したスキーマ設計の裏側について深く掘り下げて解説します。
なぜClickHouseが分散トレーシングの課題を解決するのか
これまでJaegerのストレージとしては、CassandraやElasticsearchが主流として利用されてきましたが、運用コストやスケーリングの複雑さが課題となるケースが多くありました。
分散トレーシングのデータは、サービス名、操作名、ステータスコード、タグといった繰り返し出現する情報の塊であり、これらは行指向のデータベースでは効率的に処理できません。
ClickHouseは列指向（カラムナー）のOLAPデータベースであり、同一カラム内のデータの重複を極めて高い効率で圧縮することが可能です。 このアーキテクチャは、追記型（Append-only）の大量書き込みストリームを飲み込み、ミリ秒単位で複雑な分析集計を行うテレメトリデータの特性に最適化されています。
さらに、ClickHouseを採用することで、外部のメトリクスパイプラインを介さずに、トレースデータから直接サービスレベルのレイテンシやエラー率を算出できるという利点もあります。
8.6倍の圧縮率を実現したスキーマ設計の最適化
Jaegerの開発チームは、v2.18.0のリリースにあたり、ClickHouseの性能を引き出すための高度なスキーマ設計を行いました。
ベンチマークテストでは、1,000万件のスパンを含むデータセットに対して、約8.6倍という驚異的な圧縮比率を記録しています。
元のデータサイズが約6 GiBであったのに対し、ディスク上の占有サイズをわずか722 MiB程度まで削減することに成功しました。
この高い圧縮率は、サービス名や操作名といった冗長な文字列データを、ClickHouseがカラムごとにまとめて圧縮する仕組みによって実現されています。
検索性能と取得性能のトレードオフの解消
データベースの主キー（Primary Key）の設計において、開発チームは「トレースIDによる一括取得」と「サービス名や時間範囲による検索」の両立という難題に直面しました。
トレースIDを主キーにすると特定のトレース取得は高速になりますが、UIから行われる「特定のサービスの遅いリクエストを探す」といった検索クエリが極端に低速になります。
そこでJaeger v2では、主キーを(service_name, name, start_time)の順で構成し、検索クエリの最適化を優先する設計を採用しました。
トレースIDによる取得性能の低下を防ぐため、bloom_filterスキップインデックスを活用し、不要なデータブロックの読み取りを劇的に削減しています。
この戦略的な設計により、多角的なフィルタリング検索を50msから140msという極めて低いレイテンシで維持しつつ、トレースの取得も実用的な速度を保っています。
OpenTelemetryモデルへの完全対応
Jaeger v2は、業界標準であるOpenTelemetry（OTel）のデータモデルをネイティブに採用しています。
OTelでは、属性（Attributes）がBoolean、Int64、Float64、Stringなど多様な型を持ち、かつリソース、スコープ、スパンといった5つの階層に存在します。
これらを効率的に扱うため、スキーマ内ではClickHouseのNested型（入れ子構造）を各プリミティブ型ごとに定義しています。
これにより、複雑な構造を持つトレースデータに対しても、型情報を保持したまま高速なフィルタリングが可能となりました。
マテリアライズドビューによるリアルタイム分析の高速化
Jaeger v2.18.0では、ClickHouseの強力な機能であるマテリアライズドビュー（Materialized Views）を積極的に活用しています。
UIで頻繁に表示されるサービス一覧や操作名のリストを、巨大なスパンテーブルからスキャンするのではなく、書き込み時に事前集計して専用のテーブルに保存します。
これにより、ユーザーが管理画面を開いた瞬間に必要な情報が表示される、ストレスのないユーザー体験を提供しています。
また、SPM（Service Performance Monitoring）機能においても、マテリアライズドビューを用いてスパンから直接サービス性能指標を算出しています。
Jaeger v2.18.0の設定例と導入方法
ClickHouseをストレージとして利用するための設定は、Jaeger v2の構成ファイルで定義可能です。
以下に、ClickHouseをバックエンドとして指定する場合の基本的な構成例を示します。
# Jaeger v2 configuration for ClickHouse storage
storage:
type: clickhouse
clickhouse:
# ClickHouse server connection details
endpoint: "tcp://localhost:9000"
database: "jaeger"
username: "default"
password: "your_password"
# Configuration for connection pooling
connection_params:
max_execution_time: 60
# Enable specific features like SPM
spm:
enabled: trueこの設定を適用して起動すると、Jaegerは自動的に必要なテーブルやインデックスをClickHouse上に構築します。
実行時のログを確認することで、正しく接続されているかを検証できます。
level=info msg="Storage primary strategy selected" strategy=clickhouse
level=info msg="Attempting to connect to ClickHouse" endpoint="tcp://localhost:9000"
level=info msg="ClickHouse storage initialized" compression_ratio=8.6大規模環境におけるベンチマーク結果の考察
シングルノードでのベンチマークでは、毎秒5万スパン以上の持続的なインジェクションが可能であることが確認されています。
これは、書き込み負荷が非常に高いマイクロサービス群のトレースを収集する際に、ストレージがボトルネックになりにくいことを示唆しています。
テーブルスキャンのコストを最小限に抑える設計により、数十億規模のスパンが蓄積された環境でも、実用的なクエリ速度を維持できる点が強みです。
特に属性メタデータテーブルを個別に管理する手法により、未知のタグが動的に追加される環境でも柔軟に対応できるようになっています。
まとめ
Jaeger v2.18.0におけるClickHouseの公式サポートは、分散トレーシングの運用を劇的に変える可能性を秘めています。
列指向ストレージによる8.6倍の圧縮率と、高度なスキーマ設計による高速な検索パフォーマンスは、これまでのストレージにおける妥協を過去のものにします。
OpenTelemetryモデルへの深い統合とマテリアライズドビューの活用により、単なるトレース保存を超えたリアルタイムな性能分析基盤としての価値も高まっています。
現在、この機能はアルファ版として提供されていますが、大規模なデータを扱うエンジニアは、次世代の可観測性プラットフォームの基盤としてClickHouseの採用を検討する価値が十分にあるでしょう。
今後、さらなる最適化が進むことで、JaegerとClickHouseの組み合わせは分散トレーシングの標準的な構成となっていくことが期待されます。