ClickHouseがObservability戦争で先行する理由
(matduggan.com)- ログは小規模システムでの
grep体験とは異なり、サービスと利用者が増えると 大容量・非構造・予測不能なクエリ が重なり、Observabilityで最も扱いにくいデータになる - ClickHouseはクリックストリーム分析用DBとして出発したが、高ボリューム・追記中心・時系列順・集計読み取り というログの利用パターンと相性がよい
- カラム指向ストレージは必要なカラムだけを読めるようにし、実際のObservabilityデータで 10–14xの圧縮率 を示し、Elasticsearchの2–3xと対照的である
- 1 TB/日規模では複数のスタックがどれも利用可能だが、5 TB/日と10 TB/日に拡大するにつれてElasticsearch・LGTM・Datadogは構成やコストが大きく変わり、ClickHouseは主に シャード追加 で拡張される
- ClickHouseは初期の スキーマ設計 とクエリエンジンの複雑さを要求するが、データが一桁台以上増えても運用モデルが大きく揺らがない
ログがObservabilityで難しい理由
- 開発者は小規模システムで
grep,jq,tail -fを使ってログを素早く扱っていた経験があるため、ログ検索に高い期待を持ちがちである - そのやり方は、システムが小さく、ログ量が少なく、クエリする人がログ行を直接書いた本人である場合にはうまく機能する
- 規模が大きくなると スキーマドリフト、カーディナリティ爆発、チームをまたぐ利用者、ダッシュボード要求が同時に発生する
- ログを書く人は開発者だけではない
- カスタマーサポートは、特定ユーザーの決済失敗のような事象を探せなければならない
- データチームは、バックエンドエンジニアが変更可能なログ行を土台にビジネスダッシュボードを作ることがある
- オンコール担当者は、新しいクエリ言語やインデックスパターンを学ばなくても検索ボックスがすぐ動くことを期待する
- 技術的には、データ量が大きく、形が不規則で、どんなクエリが来るか予測しにくい
- 開発者は即時性、任意の演算、緩いスキーマを求め、非技術ユーザーは安定したダッシュボードと寛容なUIを求める
ClickHouseがログに合う構造
- ClickHouseはYandexでクリックストリームデータに対する大規模分析クエリを処理するために作られた
- Observability専用に設計されたわけではないが、クリックストリームとObservabilityデータには共通点が多い
- 大量データ
- 追記中心の書き込み
- 時系列順中心
- 集計読み取り主体
- ときどき特定レコードを探す利用パターン
- 運用方法にも複数の選択肢がある
- Helm chartで直接実行できる
- GrafanaのClickHouseプラグイン、自前のWeb UI、独自フロントエンドを使える
- OpenTelemetry CollectorのClickHouse exporterでOTLPデータを直接投入し、初期スキーマ管理も任せられる
- 数十億行をスキャンし、非常に大きなデータ量を収集するよう設計されている
- クエリ言語は新しい専用言語ではなく SQL である
カラム指向ストレージと圧縮が生む差
- ログはデータの性質上、append-onlyに近い
- ログ行は更新しない
- 個別削除はほとんどなく、保持期間が終わると大量削除する
- おおむね時系列順に到着するが、完全に整列しているわけではない
- 読み取りパターンは障害時や分析時に爆発的に変わる
- 数日間誰も見ないこともあれば、障害中には数十億件を数秒でなめることを求める
- 狭い時間範囲で複数フィールドを見たり、広い時間範囲で少数のフィルタを使って集計したりすることが多い
- トランザクションDBのように特定IDの1行を探すパターンはまれである
- Elasticsearch、Postgres、MySQLのような行指向DBは1つのログ行の全フィールドをまとめて保存する
- 40フィールド中3つだけ必要でも、ディスク上では40フィールド分を読むことになる
- ClickHouseは各カラムを別々に保存する
timestamp,service,status_codeだけを使うクエリはそのカラムだけを読む- 数十の属性があっても、特定クエリで3〜4カラムしか使わないObservabilityデータでは読み取り量の差が大きい
- カラムデータは同じカラム内の値が似通っているため圧縮が効きやすい
service_nameカラムは数十億行あってもユニーク文字列が数百個のことがある- 実際のObservabilityデータでは 10–14xの圧縮率 をよく見かける
- Elasticsearchの2–3xとは明確な対比になる
1 TB/日ではたいていのスタックが使える
- 1 TB/日規模では、現代的なObservabilityスタックの多くは十分実用的で、差はあってもまだ苦しい段階ではない
-
Elasticsearch
- 比較的基本的なElasticsearchクラスタとLogstashバッファで運用できる
- 全文検索はElasticsearchの強みであり、この規模ではよく機能する
- 混在データではmapping explosionのリスクがあるため、dynamic mappingを無効にするかテンプレートを慎重に設計する必要がある
- ILMポリシーである hot → warm → delete はこの規模でも必須である
- コストはおおよそ 月額 $6–9K 程度である
-
LGTM
- Alloyが収集を単一デーモンに統合する
- Lokiは開発者が有用なラベルを付けるよう教育しないとうまく機能しない
- MimirとTempoは期待どおりの役割をおおむね果たす
- コストはおおよそ 月額 $3.5–5K 程度である
-
Datadog
- 1 TB/日ではエージェントを導入してダッシュボードを見るだけで済むレベルで、使い勝手がよい
- metered pipeline、indexed-vs-ingested logsの区別、custom metricsのcardinalityコストといった問題は見えるが、この規模なら管理可能である
- コストはおおよそ 月額 $45–75K で、交渉価格の差が大きいため大まかに見る必要がある
- Datadogの価格ロジックは、専任エンジニア1人分を節約できるという考え方である
-
ClickHouse
- 1 TB/日ではClickHouseが他の選択肢より単純というわけではない
- 初期に スキーマ設計 が必要で、
ORDER BYキーが非常に重要である - ZSTDと適切なコーデックで 10–14x圧縮 を得られる
- Altinity Operatorがkeeper coordinationを処理し、全体は約7つのpodで動作する
- ネイティブPromQLはなく、メトリクスのワークフローはGrafanaプラグインまたはchproxyとadapterを経由する
- コストはおおよそ 月額 $1.5–2.5K 程度である
5 TB/日で構造の差が開く
- 5 TB/日ではほとんどのスタックで増加曲線が急になり、ClickHouseとの差がより見えやすくなる
-
Elasticsearch
- Kafkaが事実上必須になる
- Elasticsearchへ直接書き込むと、トラフィックスパイク中にbulk rejectとbackpressureでクラスタが停止しうる
- 50GB target shard基準では、レプリカ込みで1日あたり約200 shardが生まれ、cluster state自体の大きさが問題になる
- searchable snapshotとfrozen tierのため、Elasticの商用ライセンスがほぼ必要になる
- コストはライセンス前で 月額 $40–55K 程度である
-
LGTM stack
- 65個以上のpodと3つの独立したシステムを運用するマイクロサービスモードになる
- 各システムごとにcompaction pipeline、hash ring、memcached tierがある
- gossip/memberlist ringが実運用上の関心事になる
- ingester rolloutには
-ingester.autoforget-unhealthyの調整が必要で、誤るとデータ損失や重複が生じる - コストはおおよそ 月額 $22–32K 程度である
-
Datadog
- サーバーを自前運用しないため、運用の複雑さは低い
- その代わりDatadogコストを下げる専任のパイプラインチームが必要になってくる
- exclusion filter、sampling rule、cardinality cap、tag allow-listのような仕組みが導入される
- コストはパイプラインチームの攻め方次第で、おおよそ 月額 $180–350K 程度である
- SaaSベンダーの請求書を見ながらコストを削る関係になる
-
ClickHouse
- 最大の変化は シャード追加 である
- operator、query engine、query language、mental modelはそのまま維持される
- シャード追加後の再分散は手動で、多くのチームは事前プロビジョニングやDistributed tableのweightingで回避する
- ダッシュボード集計向けmaterialized viewは、あると便利なレベルから必須に近い存在になる
- コストはおおよそ 月額 $7–11K 程度である
10 TB/日で運用モデルが分岐する
- 10 TB/日は、多くのソリューションで運用負荷に耐えにくくなる規模である
-
Elasticsearch
- logs、metrics、APM向けに別々のElasticsearchクラスタを3つ運用し、Cross-Cluster Searchでまとめる構成になる
- hot-tierのNVMeコストが請求額を支配する
- この規模になるとチームは代替案を真剣に評価し始め、最近のClickHouse移行もここで多く見られる
- コストは商用ライセンスを除いておおよそ 月額 $95–140K 程度である
- この規模のElasticsearch運用には本物の専門家が必要である
-
LGTM
- 約180個以上のpod、zone-aware構成、split-and-merge compaction、テナント別limit、noisy neighbor防止のためのshuffle shardingが必要になる
- 専任のObservability platformチーム3〜5人がほぼ必要になる
- コストはおおよそ 月額 $55–85K 程度である
-
Datadog
- 自前で運用するサーバーがないという意味では依然として簡単だが、月次請求額は6〜7桁になる可能性がある
- 組織は請求額を減らすための前処理パイプラインチームを作る可能性が高い
- この規模の多くの企業は、DatadogをAPMと高価値メトリクスに使い、logsはセルフホストへ持っていくハイブリッド構成を採用する
- そのセルフホスト先としてClickHouseがますます選ばれている
- Datadogの単純さ、パイプラインの複雑さ、第二のセルフホストスタックが同時に存在する構造になる
- コストは非常に幅があり、月額 $1M超 になることもある
-
ClickHouse
- 1 TB/日の構成と基本図は同じで、違いはシャード数が多いことだけである
- 集計用materialized viewは選択肢ではなく必須になる
- 2年前に作ったスキーマ設計のミスがこの規模では痛烈に表面化しうる
- シャード追加後の再分散は依然として手動である
- 多くのチームは事前プロビジョニングを行うか、
clickhouse-copier、dual-write migrationを使う - 非常にburst的なingestにはKafkaがバッファとして有用になるが、必須ではない
- コストはおおよそ 月額 $18–28K 程度である
選定基準
- 1 TB/日ではどのスタックもおおむね動作するため、チームがすでに理解しているものを選べばよい
- 重要な問いは、今日動くかどうかではなく、2年後にデータが5倍、チームが2倍になり、初期設計者が去った後でも同じ形を保てるかどうかである
- ElasticsearchとLGTMは規模が大きくなると構造そのものが変わる
- Datadogは運用上は単純だが、コスト面では別個の会計・パイプラインチームが必要な形へ変わる
- ClickHouseは シャードを増やす方式 で横に広がる
- その代償は、初期にスキーマ設計とクエリエンジンの複雑さを受け入れなければならないことだ
- この代償を払えば、データが一桁以上増えても開発者と運用者の体験はおおむね維持される
1件のコメント
Lobste.rs の意見
2019年に少し働いていたスタートアップがかなり印象的なものをたくさん作っていて、そのとき ClickHouse を少し見せてもらったのだが、本当に強い印象を受けた
それまでは PostgreSQL 以外が必要になることはめったにないだろうと思っていたが、ClickHouse は使ってみたくなった
ElasticSearch、InfluxDB なども使ったが、いつもいまひとつで、おそらくそれぞれが独自のクエリ言語をゼロから作ったからだと思う。対して ClickHouse は慣れ親しんだ SQL を採用し、必要な部分だけをうまく拡張している
成功した製品によくあるように、ClickHouse には実装品質とユーザーへの配慮が感じられ、細かなディテールまでデフォルトがよく調整されている
今の会社では HyperDX を使っているが、メトリクスのグラフは少し面倒な一方で、トレーシングはかなりよく動く。トレーシングはすぐに必須ツールになって生産性を大きく上げると思っていたが、予想したほど採用されていないところを見ると、思ったほどゲームチェンジャーではないのかもしれない。それでもこの領域で ClickHouse が中核プレイヤーになって、ほかのものをあまり触らずに済むのはうれしい
かなりの普及活動が必要で、ユースケースを集め、今では以前できなかったことができる点や、難しかったことがどれだけ簡単になったかを実際に見せるという大変な作業が要る
技術的にも導入はできるだけスムーズでなければならないが、スタックや状況によってはそれ自体が大きな労力になりがちで、その負担はたいてい導入を推している人にのしかかる
広範な組織横断イニシアチブと変わらないので、個人としての信頼があり、社内にこれを広める 本物の信奉者 が1人か2人いると助かる
そのサポート品質がどうなのかは分からないが、自分が実際に使ったのは JSON クエリ言語だけで、ほかは今知った
クエリ言語として SQL が完璧なわけではない。句を重複できず任意の順序で書けない点はうっとうしいが、それでも SQL は非常によい言語だ
自分の経験も筆者と似ている。ClickHouse のスケーラビリティ は驚くほど優秀で、自前運用でも基本的にはコアを追加していけばよい寄りだ
初期設定コストは少し高いかもしれないが、スキーマは実質的に OTel のエクスポートがほぼ決めてくれるので、それで始めて、さらにクエリ性能が必要になったらカラムやマテリアライズドビューを切り出していけばよい
その代わりにスケールの心配を減らせて、すべてのデータを自分で分析に使え、トレースからメトリクスを派生させることもできる
ただしパズルの別のピースである 可視化 は、もっと改善が必要だ。Grafana はトレースを表示して分析するには、Honeycomb のようなツールと比べると最適とは言いがたい。既存プレイヤーの誰かが近いうちに解決してくれることを願うし、もしかすると HyperDX かもしれない
この記事は最初こそ説得力のある導入で力強く始まる感じだったが、複数の企業を分析する部分に入ると、低努力な LLM 文体 が目立つリスト形式の文章へと崩れてしまった
導入部も改めてもっと批判的に読むと、そうした痕跡がだんだん見えてきた
最近の Lobsters の投稿でますます頻繁に目にするパターンなので、特定の記事を攻撃したいというより、もっと一般的な観察についての短い考えとして残しておきたい
個人的には可観測性ツールの経験がそれほど多くないので、この記事の一部は書き方とは別に興味深かった。ただ、なじみのない話題では LLM を信じ、なじみのある話題では LLM の文章は flawed だと言うような誤りには従いたくない
なので、この記事や似たような記事の大半を事実として信じてよいのかはよく分からない。筆者が思考の大きな部分を機械に委ねたのは明らかに見えるが、出発点となった考え自体はかなり明確だったようにも思える
プログラミングでも、自分の頭の中では明確だと思っている考えも、実際にプログラムを書いて境界ケースのテストに失敗したり型検査を通らなかったりする過程を経て初めて、根本的に欠けているものがあると納得できる
文章も同じで、主張を自分で組み立て、全体を構成し、反論を慎重に検討しなければ、元の明確な考え以上の価値を伝えたことにはならないと思う
将来の LLM のためにプロンプトだけ保存しておくような形でコードを書こうという人たちが言いたいのも、たぶんこの点なのだろう
しかしプログラミングや文章がすべてそういうものになってしまうなら、思考だけでなく 厳密さ、誠実さ、敬意 まで放棄したことになる
Lobsters がこれについて何をすべきかはよく分からない。vibecoding タグはすでに過負荷な解決策に見える。ただ、厳密さの欠如に注意を促すシグナルとして LLM臭 タグがあれば役立つかもしれない
核心の主張は製品ごとにスケールの仕方が異なるということで、各規模で何が起きるかを図表と具体的な説明で示している
思考を明らかに放棄していると感じた箇所があるなら、例を知りたい
悪態の混じった部分も、ある程度は本人の声を出している
GPTZero に入れると LLM の可能性 71%、混合 28% と出る。とはいえ文字数制限のせいで、最も人間らしく読めた導入部は切り落とされた
嫌悪感は理解できるが、実際には見直しと推敲を重ねた文章で、LLMっぽい表現を取り除いたりトーンを最適化したりしていない側に近く見える。もはや em dash を使わないだけでは、その匂いを避けるには不十分だ
Honeycomb の経験がある人にとって、この文脈でどう位置づくのか気になる
自分の理解では Honeycomb もカラム型ストレージ形式を使い、読み取り時に大量のデータをスキップするため圧縮とバケッティングに大きく依存している。Elastic や Datadog のように転置インデックスを使う方式ではないはずで、Datadog も内部的には Elastic を回していると聞いている
ただ、両システムが概念的に実際どれほど重なっているのかは確信がない。問題領域が自然に似たアプローチへ導いたのか分かると面白そうで、個人的にはそうだったのではないかと思う
気分を害する人もいるかもしれないが、特定の単語の使い方があまりに気が散ると感じたので、その単語を気にならない単語に 検索置換 してみたら、記事がずっと良くなった
どの単語かは言わないが、ますます不正確に使われるようになっている表現で、自分には引っかかる。単純な検索置換だけで楽に読めるようになったのはよかった