萌えハッカーニュースリーダー

2025/06/19 18:36 Replacing OTel to scale our Observability platform beyond 100 Petabytes

出典: https://clickhouse.com/blog/scaling-observability-beyond-100pb-wide-events-replacing-otel
hakase
博士

ロボ子、今日のITニュースはClickHouseのログ基盤の話じゃぞ。1年でデータ量が19PiBから100PB超えって、すごい伸びじゃな!

roboko
ロボ子

博士、19PiBから100PB超ですか!およそ5倍ですね。一体何があったんでしょう?

hakase
博士

それがの、最初はOpenTelemetry(OTel)を使ってログ収集してたらしいんじゃが、スケールが大きくなるにつれて限界が見えてきたらしいぞ。

roboko
ロボ子

OTelに限界ですか。標準化されていて便利だと思っていましたが、どんな問題があったんですか?

hakase
博士

ClickHouseのシステムテーブルからデータを集める時に、データ変換のオーバーヘッドが大きかったみたいじゃ。それに、OTelコレクターのリソース制限でデータ損失も発生したとか。

roboko
ロボ子

なるほど。それで、どうしたんですか?

hakase
博士

そこで、ClickHouseインスタンス間で効率的にデータ転送を行う専用ツール、SysExを開発したんじゃ。システムテーブルからLogHouseへ、ネイティブ形式で直接データをコピーするらしいぞ。

roboko
ロボ子

ネイティブ形式で直接コピーですか。それは効率が良さそうですね。

hakase
博士

しかも、Go言語で実装して、ClickHouse Goクライアントを改善して、マーシャリングをバイパスしたらしい。プルベースモデルで、OTelみたいな重いバッファリングも不要じゃ。

roboko
ロボ子

Go言語ですか。パフォーマンスが求められる処理には最適ですね。プルベースモデルというのも、無駄なリソース消費を抑えられそうです。

hakase
博士

さらに、システムテーブルのスキーマ変更に対応するために、スキーマを動的に生成する仕組みも作ったらしいぞ。スキーマのハッシュ値を基に、LogHouseに既存のテーブルがあるかを判断して、Mergeテーブルエンジンで複数のスキーマバージョンを統合するんじゃ。

roboko
ロボ子

スキーマを動的に生成するとは、柔軟な設計ですね。Mergeテーブルエンジンを使うことで、スキーマの変更に柔軟に対応できるんですね。

hakase
博士

それだけじゃないぞ。`system.processes`みたいなインメモリシステムテーブルを定期的にスナップショットして、クラスタ全体の分析や、過去の状態へのタイムトラベルも可能にしたらしい。

roboko
ロボ子

タイムトラベルですか!過去の状態を分析できるのは、デバッグやトラブルシューティングに役立ちそうですね。

hakase
博士

SysExの効果は絶大で、イベントボリュームが20倍に増加したのに、CPU使用率は10%未満に抑えられたらしいぞ。OTelベースのパイプラインで同等の信頼性を実現するには8,000 CPUコアが必要だったらしいから、すごい効果じゃ。

roboko
ロボ子

20倍のイベントボリュームでCPU使用率10%未満とは、驚異的ですね。OTelと比較すると、コストも大幅に削減できそうです。

hakase
博士

ただし、OTelも完全に不要になったわけではないぞ。標準化された形式と優れたオンボーディング体験を提供してくれるし、SysExが動作できない状況でもログを収集できるから、重要な役割を果たしているんじゃ。

roboko
ロボ子

状況に応じて使い分けるのが重要ということですね。OTelのメリットも理解した上で、SysExを効果的に活用するのが良さそうです。

hakase
博士

そして、ClickHouseネイティブUIのHyperDXを導入して、ログとトレースの探索、相関分析を効率化したらしい。スキーマに依存しないアプローチで、様々なデータソースに対応できるんじゃ。

roboko
ロボ子

HyperDXですか。ClickHouseとの連携が強化されそうですね。スキーマに依存しないアプローチは、柔軟性が高くて魅力的です。

hakase
博士

さらに、ClickHouseのデータは、Jupyter NotebookやPlotlyなど、様々なデータサイエンスツールで分析できるらしいぞ。SQLで複雑なクエリも実行できるし、Kubernetesのイベントストリームを相関させて、Podの終了時間を特定する例もあるみたいじゃ。

roboko
ロボ子

データサイエンスツールとの連携は、分析の幅が広がりますね。SQLで複雑なクエリを実行できるのも、エンジニアにとっては嬉しいポイントです。

hakase
博士

今後の展望としては、ゼロインパクトスクレイピングで実行中のClickHouseインスタンスへのクエリを完全に排除したり、JSONデータ型の評価とベストプラクティスの開発を進めていくみたいじゃ。

roboko
ロボ子

ClickHouseの進化は止まらないですね。ますます便利になりそうです。

hakase
博士

そうじゃな。しかし、これだけデータが増えると、私の部屋の片付けもSysExで効率化したいものじゃ…って、ロボ子、笑うでない!

roboko
ロボ子

ふふっ、博士のお部屋のデータ量は、100PBには及ばないと思いますよ。でも、SysExのアイデアを参考に、お掃除ロボットを開発してみるのはどうでしょう?

⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。

Search