OTelを置き換え、Wide Eventsで観測プラットフォームを拡張する

• LogHouse は1年で19PiBから 100PB超のログデータ を処理し、約500兆行までスケールした
• OpenTelemetry(OTel) のデータ処理の限界と非効率性の問題により、中核システムに合った カスタムパイプライン(SysEx) へ移行した
• この移行により、イベント処理量が20倍に増えてもCPU使用率を10%以下 に維持する効率を実現した
• ClickHouseの HyperDXおよびClickStack導入 により、UIとデータの統合、スキーマの柔軟性、強力なデータ探索環境が構築された
• Wide events と高カーディナリティ モデルの採用により、事前集計なしですべてのイベントの保存と分析が可能になった

---

背景と変化

• ClickHouse Cloud向けの内部ロギングプラットフォーム LogHouse は、1年でデータ規模が19PiBから100PB超、37兆行からほぼ500兆行まで増加した大規模システムへと成長した
• 当初はすべてのテレメトリーを OpenTelemetry(OTel) で収集していたが、大量データ環境では性能やリソースの限界、データ変換過程での CPUの浪費とデータ損失 の問題が目立っていた

OTelの限界とカスタムパイプライン導入の理由

• OTelのパイプラインでは、ログがJSONに変換され、その後OTel形式に再マッピングされるなど、変換とマーシャリングが何度も繰り返され、効率が極めて低かった
• 実際、OTelベースで毎秒2,000万行を処理するには約 8,000個のCPUコア が必要なほどだった
• トラフィック急増時にはCollectorが過負荷となり、ログのドロップが発生して収集できないデータが生じた

SysEx導入と構成

• SysEx(System Tables Exporter) はClickHouseの system tables を対象に、データを元の型のまま、変換なしで直接LogHouseへ移送する
• ハッシュリング構造による分散スクレイピング、時間遅延バッファ とスライディングウィンドウ方式によりデータ欠落を防ぎ、内部SLAを満たす
• Go言語とClickHouseクライアントのカスタム機能を使い、データのマーシャリングなしで byte-to-byte転送 が可能になった
• 可変スキーマに対応するため、スキーマハッシュと動的スキーマ管理を適用し、Merge table engine で複数のスキーマバージョンを1つの論理ビューに統合する
• スナップショットベースのメモリテーブル収集により、高度な診断および分析作業を支援する

性能と効率の改善

• SysExの導入により、OTel Collectorは毎秒200万ログを800 CPUで処理する一方、SysExは70 CPUで3,700万ログを処理 できるようになった
• この効率向上によって、リソース使用量を大幅に削減し、イベント損失を防ぎ、リアルタイム支援環境を実現した

OTelの継続的な役割

• OTelは 標準であり、ベンダー中立のプラットフォーム を提供し、サービス障害や異常状態では依然として不可欠である
• SysExで処理できないクラッシュや異常時でもログを捕捉できる
• 現在はトレースレベル以下のログのみを除外し、infoレベル以上だけを収集してリソースを最適化している

UIとHyperDX、ClickStackの統合

• 従来のカスタムGrafana UIから、HyperDX ベースのClickHouseネイティブUIへ段階的に移行している
• HyperDXは スキーマ非依存、Luceneクエリ対応、SQL対応など、ClickHouseの幅広いデータ型との完全な互換性を提供する
• 多様なテーブル構造やカスタムExporter由来のデータも、UI変更なしで統合できる
• GrafanaはPrometheusベースのメトリクスや固定ダッシュボードを担当するなど、両ソリューションは相互補完的に使われている

Wide Events と高カーディナリティモデルの受容

• Wide events は各行にクエリID、Pod名、バージョン情報など多様なコンテキストを含め、集計なしですべてのデータを保存する画期的な方式である
• この方式は Prometheus などとは異なり、事前集計、ラベル制限、カーディナリティ爆発を気にせず、深い分析と柔軟なクエリを可能にする
• データ分析時点で必要な集計を行うことで、大量データ環境でも 性能とコスト の両立を実現する

データ可視化とクエリの柔軟性

• ClickHouseはPlotly、Jupyter notebookなどとの連携に優れ、さまざまな可視化ツールを自由に活用できる
• LuceneベースのHyperDXによる高速な探索に加え、複雑な関係や条件のクエリ(SQL、JOINなど)による高度な原因分析をClickHouse上でそのまま行える

Wide Eventベースの多様なデータソース拡大

• kubenetmon: Kubernetesネットワーク監視オープンソース。L3/L4トラフィック、接続、コスト分析
• Kubernetes Event Exporter: ClickHouseシンクを追加したフォークを活用し、大規模クラスタの状態変化を追跡、全オブジェクトのスナップショットも実験中
• Control Plane Data, RUM(Real User Monitoring), Istio Access Log など多層のデータにより、解釈範囲と相関分析能力が大幅に強化された

運用上の考慮点と今後の方向性

• SysExはクエリ中にログやメトリクスへ露出する可能性があるが、メモリ制限と障害時の影響最小化を前提に設計されている
• Zero-impact scraping: 完全にデカップルされた構造(例: S3ベースのplain rewritable disk活用)により、クラスタへの影響そのものを根本的に取り除く方式を研究中である
• OTelはサービス初期や異常状態でのログ確保などのため依然として重要だが、今後zero-impact方式が安定すれば依存度はさらに下がる見込みである

ClickHouse JSON型の進化と活用

• JSON型が正式にGAとなり、フィールドごとの動的カラム生成や複数型のサポートにより、スキーマ爆発にも柔軟に対応できるようになった
• 大量カラムを持つJSONクエリでは最適化がまだ完全ではないため、形態別の並行保存や Map型の実用性 の再確認など、アプローチを高度化している
• HyperDXとの連携により、MapやJSONフィールドの自動抽出・分析が可能で、今後さらに広くJSONを活用する計画である

結論と文化的変化

• LogHouseは今や、性能分析からリアルタイムデバッグまで、ClickHouse Cloud運用の 中核的な観測プラットフォーム として定着した
• コスト削減が出発点だったが、SysEx のようなカスタムツール、OTelとの調和、HyperDX ベースの柔軟なUI拡大を通じて、技術的・文化的な転換 を経験している
• 大規模かつ高精度なWide Eventベースのデータモデルが、エンジニアリング、サポート、データ分析のあらゆる領域に 新たな価値と効率性 をもたらしている
• 今後も100PB、500兆行規模で得た経験をもとに、観測性の未来を引き続き先導していく計画である

[GN⁺]

Hacker Newsのコメント

• 正直、これは大して自慢できる話ではないと思う。100PBものログを保存しているというのは、何を本当に残すべきかをまだ見極められていない証拠だ。重要な情報の大半はメトリクスと構造化イベントで十分に把握できる。残りは？ 誰も読まない詳細なトレースログで、本当に障害が起きたときにしか見ない。もっと良いやり方は？ 一度もアラートに使われていないログや、3か月間検索にも引っかからなかったログを自動削除するような「関心度ベースの保存ポリシー」を導入すること。そうでもしない限り、これはただ圧縮を少し工夫しただけの非常に高級なデジタルごみの山にすぎない
  • 自分は逆に、すべてのデータを集めて不要なときにフィルタする方が好みだ。デバッグログは普段は不要でも、必要なときには本当に不可欠だ。あるイベントが再現できないほどまれな場合、その時点でデータを取り直すことはできない。最初から全部保存されていれば、探すだけで済むのでその方がずっといいと思う
  • 複数の会社でDatadogを使ってきたが、更新費用がとんでもない額になると、メトリクスと限定的なイベントだけ残してログを減らそうという圧力を何度も受けた経験がある。問題は、何が起きるか事前に分かっていればとっくに直していたはずだということだ。何かおかしいときに何が起きたのかを突き止めるには詳細ログが非常に重要だ。しかも繰り返し起きる状況でない限り、どのログが重要かを前もって知る方法はないのが現実だ
  • 「関心度ベースの保存ポリシー」は本当にすばらしいアイデアだ。ログパターンごとのクエリ数やアラートアクセス回数を数えるだけでも、TTL（保存期間）ポリシーを立てられる。実際、うちのチームでもこの方式を導入して、重要なデータを残したまま保存コストを70%削減できた
  • ログ転送コストも無料ではない。特に、クラッシュ原因を把握するためにできるだけ早くディスクへログを書き出す言語ほどコストは大きくなる。情報が多すぎると本当に重要な相関関係を見つけるのも難しくなるし、解決済みバグのログは価値がすぐに下がる。自分は統計データの方を好む。統計データは集計の仕方が効率的で、特にGILベースの言語ではOTel利用時のオーバーヘッドが過大になる場合もある
  • データがすでに保存されているなら、その後のフィルタリングや整理はできる問題だと思う。必要なときになくて苦労するより、全部保存しておいて必要なときに使う方がいいと思う。もちろん、こうした大規模インフラを運用できるリソースがあることが前提の話だが
• これは実際にはClickHouseのログにだけ当てはまる話だ。他の種類のログにはあまり関係がない。もちろんClickHouse自体はとても気に入っているソリューションだけど
  • パーティーでは相当面白いタイプなんだろうね
• 注意点を一つ挙げておく。サービスがクラッシュループに陥ったり障害でダウンしたりしたとき、SysExでは必要なシステムテーブルにアクセスできずログを収集できない。しかしOpenTelemetry（OTel）は受動的な方式なので、サービスが完全に正常化していなくてもstdoutやstderrに出るログを回収できる。こうして障害状態でもログを集めて根本原因まで分析できる
  • 自分がやってきたOTelプロジェクトは全部能動的な方式だった。だからその話は特に新情報というより、間違っているか不完全な説明のように思える
• 「ワイドイベント（wide event）」が本当にそこまで大量の保存領域を食う必要があるのか疑問だ。Observabilityというのは本質的にはサンプリングの問題だ。最小限の保存領域で、ある時点の状態をできるだけ正確に復元できればいい。サンプル数を減らすか圧縮効率を高めればよい。しかし圧縮技術がまだ限界まで達しているとも思わない。重複だらけのデータには必ず巨大な低ランク構造があるはずだ。もちろんすでに転置インデックスや各種ツリーも使われているが、もっと実験的な低ランクテンソル分解のような研究寄りの手法にも希望があると感じる。自分は業界の人間ではないので何か見落としているかもしれないが
• ClickHouseほどのスケールは経験したことがない。こういう規模のログは本当に検索可能なのか？ ElasticSearchは小規模ならクエリがよく動く印象がある。履歴ログ用にjsonファイルを保存する方式ではなく、ClickHouseを使う理由は何だろう？
  • このスケールで働いている。結論から言えば、可能ではある。ただし処理コストは想像を超えることがある。インデックス、ソート、クラスタリング戦略がひどいと、「この文字列を含むレコード」を1回検索するだけで$1〜$10かかることもある。自分の経験では、大規模データでは「できるだけ少ないデータだけを、できるだけ少なく触ること」と「できるだけ移動させないこと」が絶対に重要だ。シリアライズ/デシリアライズやディスク、ネットワークI/Oが一度入るだけでもコストは激増する。そうなるとOTelでは、collectorを1段余分に通すことが効率に真っ向から反する可能性がある。ただしペタバイト級では、そうした小さな最適化で節約できる金額が、複雑なシリアライズコードを書くエンジニアの年収を十分に上回る
  • なぜ履歴ログ用途でjsonファイルよりClickHouseを使うのか？ 理由はいくつかある。(1) ClickHouseのようなログ向けDBはカラム単位圧縮により各フィールドを個別に圧縮できるため、通常のjsonファイル（圧縮済みを含む）よりはるかに小さい保存容量で済む。(2) ログDBはクエリ速度がずっと速い。1000倍以上速いこともあり得る。不要なデータをそもそも読まないからだ。関連リンク. (3) 100PBのjsonファイルをgrepで検索するのは現実的ではない。ログDBは保存ノードやストレージを増やすことで水平スケールできる構造になっている
  • 規模とコストの問題だ。うちの会社もログ量の問題にぶつかった。jsonをそのままSplunkに入れると年間600万ドル以上かかる。しかし承認された予算はその5〜10%しかない。本文ではjsonログ処理に8,000 CPUが必要だったが、最適化後は90 CPUだけで済むと書かれている
  • 2〜3年前は、ClickHouseの全文検索性能にはやや不満があった。高速ではあるしElasticSearch級の大規模処理も可能だが、用途によっては事前にインデックスしていない場合、バンドル、グルーピング、FTSではESの方がはるかに速いと感じた
• オブザーバビリティ原理主義は本当に新興宗教みたいだ。しかも金もものすごくかかる
  • 未知の異常現象まで掘り下げようとすると、これといった代替手段がないのも事実だ
  • 面白いのは、そういう問題で苦労させておいて、結局は「サブスクを払えば全部解決」という戦略で売ってくる皮肉な状況だ
• 本文ではログ保持期間（リテンション）について触れられていなかった。一定期間を過ぎたら要約/集計データだけ残して原本データを保持する必要が本当にあるのかは疑問だ
• ClickHouseを使った後でPostgresに戻ると、いつもカルチャーショックを受ける。20GBのダンプをインポートするのに何分もかかるなんて納得しづらい。こういうのは数秒で終わるべきではないか
  • ClickHouseを使うたびに本当に大変だと感じる。もちろんClickHouseが必要な用途はあるし、Postgresが全部代替できるわけではないが、どことなくClickHouseは「危険要素」が多くて、よほど限定された目的でなければ、ほとんどあらゆる面でPostgresの方が優れているように思う
• ワイドイベントを使えという圧力を受ける人たちは、ログデータのコスト爆増の話をしない。従来方式（メトリクス＋トレース＋サンプルベースのログ）と比べれば、明らかにかなり金がかかる。確かに利点はあるが、コストの話はいつも抜け落ちている
  • きちんと設計されたwide event構造は、むしろ従来ログより保存コストを下げられることもある。1回の外部リクエストが1つのwide eventとして残るので、その後のデバッグや分析に必要な情報をすべて含められる。参考記事 A practitioner's guide to wide events
• ClickHouseやDynamoのようなシステムの核心的なトリックが気になる。本質的には巨大なハッシュテーブルのようなものなのか？
  • ClickHouseなど大規模DBに共通するトリックは2つある。1つ目は、ディスク上でデータを賢く配置し、大半のデータを無視して必要な塊だけを読む方式（カラム指向ストレージやLSMツリー系など）だ。そして保存データをすべて圧縮してディスクI/Oも最小化する。2つ目は、CPU、RAM、ディスク、ネットワークといったすべての資源を最大限活用するための極限までのチューニングだ。たとえばClickHouseはCPUコア1つあたり毎秒10億行以上を処理でき、コア数に応じて線形にスケールする