広範なイベントを取り入れ、OTelを置き換えることで観測性プラットフォームを拡張する

2025年6月21日原文(clickhouse.com)

概要

LogHouse は、ClickHouse Cloud監視のために構築された大規模な内部ログ基盤
データ量 は19 PiBから100 PB、行数は40兆から500兆行へと急増
OpenTelemetry (OTel) の限界を超え、独自のパイプライン（SysEx）を開発
CPU効率 は20倍のイベント増加に対し、従来の10%未満で処理可能に
HyperDX導入 により、ClickHouseネイティブな観測・分析UIを実現

観測基盤LogHouseの進化と課題

LogHouse はClickHouse Cloudの監視・分析基盤として自社開発
初期は19 PiB・40兆行のログ管理で、Datadogからのコスト削減にも成功
1年で100 PB・500兆行までスケール、設計やツールの大幅な見直しが必要に
OpenTelemetry (OTel) 採用でKubernetes全Podから統一的にログ収集
スケール増大に伴い、OTelのパース・マーシャリングがCPUボトルネック化
SysEx というClickHouse専用エクスポータを開発し、主要ログの収集効率化を実現
- SysEx はClickHouseのsystem tableからネイティブ形式でデータを直接転送
- OTel経由ではJSON→OTel形式→ClickHouse形式と多重変換が発生
- SysExはバイト単位でコピーし、変換コストやデータ劣化を排除
- スクレイパはHash Ringで分散、各Podのsystem tableを定期的にスキャン
- 過去5分程度の遅延バッファを持つことで、バッファフラッシュ漏れも回避
OTel 利用時は、Kubernetesノード上のCollectorがCPUリミットでドロップ発生
OTelパイプライン維持には8,000 CPUコア必要という非現実的な規模感
SysEx導入により、20倍のイベント増加でも従来の10%以下のCPUで安定運用

HyperDXとClickStackによる次世代観測UI

HyperDX はClickHouseネイティブな観測UIとして導入
Luceneライクなクエリ構文で探索・相関・根本原因分析が容易
これまでのGrafanaベースカスタムUIから、ClickHouse統合型UIへ移行開始
ClickStack はClickHouse中心のエンドツーエンド観測スタック
大規模データの安価な保存・高速クエリが可能となり、他チームでも採用拡大

SysExの技術的詳細と運用ノウハウ

SysExはGo製、ClickHouse Goクライアントに独自パッチを適用
データのマーシャリング/アンマーシャリングを完全バイパス
システムテーブルのスキーマは頻繁に変化するため、動的スキーマ生成＆管理
- ハッシュでスキーマバージョン管理、LogHouse側も自動で新テーブル作成
- クエリ時はClickHouseのUNION ALLで複数スキーマを横断的に検索
SysExはPull型で定期取得、LogHouse障害時もバックフィルでデータ欠損を防止
OTelのような大量バッファや複雑なリトライ処理は不要

今後の展望と他社への示唆

LogHouseの経験は、従来型ベンダー製品の限界やコスト課題に悩む他社にも有用
汎用的なOTelと、目的特化型パイプラインの適材適所が重要
ClickHouse/HyperDX/ClickStackの組み合わせで、スケーラブルかつコスト効率的な観測基盤構築が可能
ClickHouse Cloudは無料クレジット付きですぐに試用可能

参考:

LogHouse, SysEx, HyperDX, ClickStack, OpenTelemetry, ClickHouse Cloud
Go, Kubernetes, CPU効率, スキーマ管理, 大規模データ運用

Hackerたちの意見

ClickhouseからPostgresに戻ると、毎回びっくりするんだよね。20Gのダンプをインポートするのに、何で数分もかかるの？数秒で終わるべきじゃないの？

└

Clickhouseを使うたびに頭が爆発しそうになるよ、特にPostgresがあるって知ってるから。Clickhouseに場所がないとは言わないし、PostgresがClickhouseのすべてをできるとも思わない。ただ、Clickhouseでの作業がすごく嫌いなんだ、変な足元の銃が多すぎて。特定の、私の意見では限られた使い方をしない限り、あらゆる面でPostgresよりも悪く感じる。

注目すべき点: 「サービスがクラッシュループしているかダウンしている場合、SysExは必要なシステムテーブルが利用できないため、データをスクレイピングできません。一方、OpenTelemetryは受動的に動作します。サービスが失敗状態にあっても、stdoutやstderrに出力されたログをキャッチします。これにより、インシデント中にログを収集し、サービスが完全に健康でなくても根本原因分析が可能になります。」

└

私がやったOTelはすべてアクティブだったから、あんまり注目すべきことじゃないと思う。むしろ、間違った情報か不完全な情報だね。

そうだね、これはClickhouseからログを収集することにだけ関係ある話だ。他の何かのログには関係ない。彼らには良いことだけど、Clickhouseが大好きなんだけど、あんまり関係ないね。

└

パーティーでは楽しそうだね。

ClickHouseレベルのスケールで働いたことはないけど、このボリュームでログデータを検索できるの？ElasticSearchは小規模なログデータのクエリ機能があると思うけど、歴史的なログデータをjsonファイルとして保存する代わりにClickHouseを使う理由は何なの？

└

スケールとコストの問題。私の職場ではログのスケールに直面しているんだ。「jsonをsplunkにプッシュする」だけだと、年間600万ドル以上かかるけど、承認されるのはせいぜい5〜10%くらい。記事では、彼らのjsonログを処理するのに8kのCPUが必要だと言っているけど、その後は90CPUだけで済むって。

└

「このボリュームでログデータを検索できますか？」（文脈: 私はこのスケールで働いています）はい。ただ、想像できるように、処理コストはかなり大きくなる可能性があります。インデックス作成や順序付け、クラスタリングの戦略がうまく設定されていないと、「この文字列を含むレコードを探す」みたいな単純なクエリでも、1ドルから10ドルかかることが簡単にあります。私の経験も彼らと一致していて、ペタバイトのデータを移動するスケールでは、最良の最適化は「できるだけ少ないデータに触れること」と「できるだけ少ないデータを移動すること」だよね。シリアライズやデシリアライズを行うたび、ディスクやネットワークI/Oを行うたびに、パフォーマンスコストが増えて、結果的に財布へのコストも増える。だから、OTelは効率と真っ向から対立することがある。OTelコレクターは追加のI/Oとシリアライズのホップだからね。でも、ペタバイトスケールで運用しているなら、1つのホップを捨てることで節約できる金額は、シリアライザーやデシリアライザーのロジックを書くエンジニアの給料を十分にカバーできるかもしれない。

└

数年前、ClickHouseはフルテキスト検索があまり得意じゃなかったから、それが最大の欠点だったと思う。確かに速いし、ESスケールも扱えるけど、ユースケースによっては、事前にインデックスを作らずにFTSやグルーピングをする場合、ESをクエリする方がずっと速いよ。

└

なんでログデータを歴史的なログデータとしてJSONファイルに保存する代わりにClickHouseを使うの？理由はいくつかあるよ。1. ログに最適化されたデータベース（ClickHouseやVictoriaLogsなど）は、ログを圧縮された形で保存するんだ。各ログフィールドの値がグループ化されて個別に圧縮される（いわゆるカラム指向ストレージ）。これにより、JSONログのプレーンファイルと比べてストレージスペースが小さくなるんだ。たとえ圧縮してもね。2. ログに最適化されたデータベースは、JSONファイルに対するgrepよりもずっと速く典型的なクエリを実行できる。パフォーマンスの向上は1000倍以上になることもあるよ。これらのデータベースは不要なデータを読み飛ばすからね。詳細はここを見てね：https://chronicles.mad-scientist.club/tales/grepping-logs-re... 3. 100ペタバイトのJSONファイルをgrepするつもりなの？ログに最適化されたデータベースは、ストレージノードを追加して水平スケーリングできるから、そんなに大量のログをクエリできるんだ。

この業界は、半端な基準や進行中の基準で溢れていて、エコシステムの分断を招いてるんだよね。GraphQLからOpenAPI、MCPまで、完璧なものはないし、それでいいと思う。ただ、仕様を作った人たちが試行錯誤のアプローチをただ続けてるのは、ちょっと狂ってるよ。

Hacker Newsで議論の続きを見る

ハクソク