---
title: "ClickHouseのオブザーバビリティ向けにClickStackを5倍高速化した方法"
date: "2026-08-19T00:21:01.103Z"
author: "Aaron Knudtson"
category: "Engineering"
excerpt: "ClickStackチームがベンチマーク駆動のプロセスを用いて、主キーの再設計、テキストインデックス、エイリアスカラム、マテリアライズドビューを組み合わせることで、一般提供開始に先立ちオブザーバビリティクエリのレイテンシを5倍以上削減した方法をご紹介します。"
---
# ClickHouseのオブザーバビリティ向けにClickStackを5倍高速化した方法
## 概要
* Managed ClickStack の GA に向けて、ログとトレースのスキーマをベンチマーク駆動で再設計し、代表的なオブザーバビリティクエリのレイテンシを5倍以上短縮しました。
* 主キーの再設計、テキストインデックス、エイリアスカラム、マテリアライズドビューを組み合わせ、ClickHouseの新機能を最大限活用しています。
* OpenTelemetry Collector から継承したデフォルトスキーマは厳密なベンチマークを経ていなかったため、ペタバイト規模では遅いクエリやタイムアウトが顕在化していました。
* 実際にユーザーがよく使うクエリパターン（トレースID検索、属性検索、ログ本文検索、ヒストグラム集計）を洗い出し、優先的に最適化しました。
* すべての変更を現実的な本番ワークロードで検証し、取り込み・ストレージ・運用効率のバランスを保っています。
## TLDR; {#tldr}
私たちは、主キーの再設計、テキストインデックス、クエリ書き換え、マテリアライズドビュー、そして ClickHouse の新機能を組み合わせたベンチマーク駆動プロセスで、ClickStack のオブザーバビリティスキーマを再構築しました。ユーザーが最も頼りにするクエリパターンに最適化し、あらゆる変更を現実的な本番ワークロードで検証することで、代表的なクエリのレイテンシを 5 倍以上短縮しつつ、取り込み・ストレージ・運用効率のバランスの取れたプロファイルを維持しました。
## はじめに {#introduction}
Managed ClickStack は、昨年のプライベートプレビュー、2 月のベータ版リリースを経て、[先日 GA に到達しました](https://clickhouse.com/ja/blog/observability-mcp-server-ai-notebooks-jp)。GA までの道のりでは、UX の改善から運用面の成熟度に至るまで、スタック全体で大きな製品開発が行われました。しかし、他のすべてを超える 1 つの課題がありました。それは、ユーザーが期待する高速でインタラクティブな体験を維持しながら、増大するオブザーバビリティワークロードの要求に応えられるよう ClickStack をスケールさせることでした。
ClickStack のパフォーマンスの中核にあるのは、ログとトレースのスキーマです。これらのスキーマはデータの保存・圧縮・インデックスの仕組みを決定し、取り込み効率とクエリ速度の両方に直接影響します。同様に重要なのは、ClickStack の UI がそうしたスキーマ最適化を活用するよう設計されており、基盤となるストレージレイアウトやインデックスを効果的に利用するクエリを生成する点です。したがってパフォーマンスは、スキーマ設計とクエリ設計の両方の産物であり、両者は共に進化していきます。
本記事では、GA を前に ClickStack のパフォーマンスを一変させたログスキーマとクエリの最適化について解説します。テレメトリデータの保存・インデックス・クエリの方法を根本から見直し、UI がこれらの改善を最大限活用できるようにすることで、代表的なオブザーバビリティワークフローにわたってクエリのレイテンシを 5 倍以上短縮しました。
## デフォルトスキーマの継承 {#inheriting_a_default_schema}
ClickStack のデフォルトスキーマは、もともと ClickStack が推奨する取り込みパイプラインである [OpenTelemetry Collector 用 ClickHouse エクスポーター](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/exporter/clickhouseexporter/README.md)から継承したものです。しっかりとした基盤と OpenTelemetry データとの幅広い互換性を提供していたものの、コミュニティが提供したものであり、ClickHouse の新しい機能を完全に活用するようには進化していませんでした。
また、ペタバイト規模で運用する誰もが直面するであろう根本的な課題もありました。プライベートプレビューやベータ期間中に大規模顧客と協働する中で、遅いクエリ、短い時間範囲での Top N クエリ、タイムアウトする検索や集計クエリが次第に一般的になっていきました。
こうした課題に特定のサービス単位で対応するには、多くの場当たり的あるいはリアクティブな最適化が必要でした。中にはクエリの構造をわずかに変更する程度の製品更新もありました。しかし、潜在的なスキーマ最適化のリストは膨らみ続けました。おそらくより重要なのは、このスキーマが大半のワークロードで依然として最適かどうか、また ClickHouse のバージョン間でどのように振る舞うかを判断するために必要な、厳密なベンチマークとワークロード分析を受けたことが一度もなかったという点です。
## 改善余地の特定 {#identifying_areas_for_improvement}
こうした課題を受けて、今年初めに私たちはクエリパフォーマンスの問題に対処し、すべてのユーザーにとって out-of-the-box のパフォーマンスを向上させるための一大取り組みに着手しました。
このグループの任務は、製品でよく使われるクエリパターンを特定し、活用できそうな ClickHouse の最適化を洗い出し、ClickHouse を最適化しようとするコアエンジニアのマインドセットで取り組むことでした。
調査により、ユーザー体験に最も大きな影響を与える一般的なクエリパターンがいくつか明らかになり、それらが最適化の優先対象となりました:
| クエリ名 | アクセスパターン | 使い方 |
| :---- | :---- | :---- |
| 12_trace_id, 04_rare_body_text_term | 正確な属性による干し草の中の針的な Top N クエリ | 検索(例: ユーザー ID による検索) |
| 02_map_high_freq_search, 03_map_high_freq_search | 属性カラムに対する高頻度な語での Top N クエリ | 検索(例: Kubernetes namespace での検索) |
| 01_high_freq_servicename_body_search, 04_rare_body_text_term | Body 式に対する Top N クエリ | ログ本文の検索 |
| 06_map_low_freq_histogram, 08_rare_body_text_histogram | 正確な属性による干し草の中の針的クエリに対する集計 | 検索ページのヒストグラム(例: 既知のユーザー ID を SeverityText でグルーピングしたカウント) |
| 07_map_high_freq_histogram | 高頻度語クエリに対する集計 | 検索ページのヒストグラム(例: Kubernetes namespace を SeverityText でグルーピングしたカウント) |
| 05_high_freq_servicename_body_histogram, 08_rare_body_text_histogram | Body フレーズクエリに対する集計 | 検索ページのヒストグラム(例: Body 中のフレーズを SeverityText でグルーピングしたカウント) |
| 09_specific_log_lookup | 特定ログのルックアップ | 個別ログの確認 |
| 10_distinct_keys | 非構造化キーの distinct なイントロスペクション | 補完キーの表示 |
| 11_distinct_values, 13_distinct_column_values | 非構造化値の distinct なイントロスペクション | 補完/フィルタ値の表示 |
*Kubernetes namespace による検索とチャート*
これらのカテゴリの一部はかなり似ているように見えます。3 つのカテゴリにおける検索と集計は、6 つの別々の問題として個別に列挙されています。しかしそれらは実質的に異なる問題であり、一部のスキーマ更新は 1 つのクエリパターンのためだけに行われます。
## ベンチマークの必要性 {#the_need_for_a_benchmark}
理論に基づいて場当たり的に変更を適用することで改善に至ることはあるかもしれませんが、何らかの検証層が必要でした。反復的な性質を持つ[科学的方法](https://en.wikipedia.org/wiki/Scientific_method)は、私たちの製品に対して実測可能な真の改善を推進するモデルとして魅力的でした。
並行して、ClickCannon という新しいツールを用いたベンチマークの取り組みも進行中で、ワークロードを支えるのに必要なリソースを特定すること、つまり「ClickStack を運用するにはどれくらいのリソースが必要か?」という問いに答えるための取り組みでした。
OpenTelemetry のログとトレースを使って ClickHouse インスタンスに対する調整可能な取り込みとベンチマークを可能にするプログラムとして、ClickCannon はテストパラメータを定義して反復的なテストを連続実行することで、実際のワークロードをシミュレートすることを可能にしました。ClickCannon の詳細については、[こちら](https://clickhouse.com/blog/building-clickcannon-a-tool-for-benchmark-clickhouse#intro)をご覧ください。
> **スキーマ最適化とキャパシティプランニングは相補的な取り組みです。** ベンチマークは特定のスケールで ClickStack を運用するために必要なリソースを理解するのに役立ちますが、スキーマ最適化はリリースする製品のパフォーマンスと効率の改善に焦点を当てます。両者は継続的に相互に影響し合います。スキーマ変更はリソース要件を変えることがあり、ベンチマークはボトルネックとさらなるスキーマ改善の機会を明らかにすることがよくあります。その結果、大きなスキーマ改訂には必ず新たなベンチマークが伴い、パフォーマンス向上とインフラへの影響の両方を検証するようにしています。
ClickCannon に加え、正式なテストフレームワークとインスタンス管理システムが必要でした。これには少し手間がかかりましたが、Kubernetes 環境を駆動してテストを実行し、エフェメラルな ClickHouse Cloud インスタンスを立ち上げ、ライフサイクルを管理するプログラムを作成しました。
これらの基盤が整うことで、スキーマ変更を迅速に評価し、イテレーションごとに結果を比較し、制御可能で再現性のある条件下でその影響を測定できるようになりました。
## テストアプローチ {#testing_approach}
ユーザーを代表するテストワークロードを最初に構築しようとしたとき、調整できるパラメータは実質無限にあるように思えました。取り込みスループット、インスタンスサイズ、レプリカ数、データサイズ、想定テスト期間、行あたりの平均データサイズ、Map 内の要素数などはそのごく一部です。
最終的に、スキーマ、クエリワークロード、ClickHouse のバージョンだけを変数とし、それ以外は固定した設定に落ち着きました。スループットは 640 MiB/s(月あたり約 1.5 PB)に固定し、デプロイは各 24 CPU コアの 3 レプリカ構成、すべてのテストで実際の取り込みパターンを模倣するために timestamp 順に並んだ代表的なデータセットを使用しました。
> これは現実的な本番環境を表しており、スキーマ変更を評価するための強力なベースラインを提供しました。個々のデプロイは特定の要件に基づく追加のチューニングで恩恵を受ける可能性があるものの、ここから得られる最適化は、私たちがユーザーベースで見てきた幅広いオブザーバビリティワークロードにおいて効果を発揮します。
まずはログスキーマを対象に、[ClickCannon ベンチマークの取り組み](https://clickhouse.com/blog/building-clickcannon-a-tool-for-benchmark-clickhouse#intro)で使用したものと同じ OpenTelemetry コーパスから派生したデータセットを使用することにしました。このデータセットは、`ResourceAttributes` 内のキー数などの特性が、本番で見られる平均的なテレメトリプロファイルにより近くなるように調整されています。私たちは今後もこのデータセットを進化させ続け、匿名化されたプラットフォームテレメトリからの知見を活用して、本番ワークロードと顧客が最も頼りにするクエリパターンを代表し続けるようにしていきます。
## 改善の評価 {#evaluating_improvements}
スキーマ変更の成功を測定することは、単にクエリレイテンシを見るよりも微妙です。あらゆる最適化にはトレードオフがあり、ある領域での改善が別の領域でのリグレッションを生む可能性があります。私たちの目標は、単一のクエリに対する最速のベンチマーク結果を出すことではなく、ClickStack 全体の効率、つまりバランスの取れた運用プロファイルを保ちながらクエリパフォーマンスを向上させることでした。これを達成するため、あらゆるスキーマ改訂は、採用が検討される前に一貫した指標と適格基準に照らして評価されました。
> すべてのベンチマークは [ClickHouse Cloud ウェアハウス](https://clickhouse.com/docs/cloud/reference/warehouses)を用いて実施しました。書き込みは親サービスに向けられ、クエリは専用の子サービスに対して実行されるため、取り込みとクエリのワークロードを分離し、それぞれ独立して評価できます。
私たちは常に、スループット、書き込みサービスの CPU 使用率、書き込みサービスのメモリ消費量、そして ClickHouse がインサートとマージのバランスをどれだけ効果的に取っているかを示す `MaxPartCountForPartition` を測定して、取り込みパフォーマンスの評価から始めます。最適化の性質によっては、**他の場所で意味のある向上をもたらすのであれば**、これらの指標の一部の劣化は許容できることがあります。
次に、CPU とメモリ要件の変化を考慮し、コンピュートコンピュート分離型のリードサービスへの影響を評価します。ここでも、これらが目立って影響を受ける場合には、クエリパフォーマンスで得られたゲインと照らし合わせて評価する必要があります。
追加コストが許容範囲であると判断できたら、個別のクエリのパフォーマンスを評価します。ほとんどの最適化は特定のクエリパターンを対象としていますが、すべてのベンチマーク実行にはより広範なワークロードも含めることで、改善が製品の他の部分でのリグレッションと引き換えに達成されていないことを確認します。
## スキーマ最適化 {#schema_optimizations}
私たちは幅広い最適化案を検討しましたが、最も効果の大きかった変更は 5 つのカテゴリーに集約されました。主キーの変更、インデックスの更新、新規インデックスの追加、クエリの書き換え、テーブル設定です。
念のため、これが元のスキーマです:
CREATE TABLE IF NOT EXISTS ${DATABASE}.otel_logs (
`Timestamp` DateTime64(9) CODEC(Delta(8), ZSTD(1)),
`TimestampTime` DateTime DEFAULT toDateTime(Timestamp),
`TraceId` String CODEC(ZSTD(1)),
`SpanId` String CODEC(ZSTD(1)),
`TraceFlags` UInt8,
`SeverityText` LowCardinality(String) CODEC(ZSTD(1)),
`SeverityNumber` UInt8,
`ServiceName` LowCardinality(String) CODEC(ZSTD(1)),
`Body` String CODEC(ZSTD(1)),
`ResourceSchemaUrl` LowCardinality(String) CODEC(ZSTD(1)),
`ResourceAttributes` Map(LowCardinality(String), String) CODEC(ZSTD(1)),
`ScopeSchemaUrl` LowCardinality(String) CODEC(ZSTD(1)),
`ScopeName` String CODEC(ZSTD(1)),
`ScopeVersion` LowCardinality(String) CODEC(ZSTD(1)),
`ScopeAttributes` Map(LowCardinality(String), String) CODEC(ZSTD(1)),
`LogAttributes` Map(LowCardinality(String), String) CODEC(ZSTD(1)),
`__hdx_materialized_k8s.cluster.name` LowCardinality(String) MATERIALIZED ResourceAttributes['k8s.cluster.name'] CODEC(ZSTD(1)),
`__hdx_materialized_k8s.container.name` LowCardinality(String) MATERIALIZED ResourceAttributes['k8s.container.name'] CODEC(ZSTD(1)),
`__hdx_materialized_k8s.deployment.name` LowCardinality(String) MATERIALIZED ResourceAttributes['k8s.deployment.name'] CODEC(ZSTD(1)),
`__hdx_materialized_k8s.namespace.name` LowCardinality(String) MATERIALIZED ResourceAttributes['k8s.namespace.name'] CODEC(ZSTD(1)),
`__hdx_materialized_k8s.node.name` LowCardinality(String) MATERIALIZED ResourceAttributes['k8s.node.name'] CODEC(ZSTD(1)),
`__hdx_materialized_k8s.pod.name` LowCardinality(String) MATERIALIZED ResourceAttributes['k8s.pod.name'] CODEC(ZSTD(1)),
`__hdx_materialized_k8s.pod.uid` LowCardinality(String) MATERIALIZED ResourceAttributes['k8s.pod.uid'] CODEC(ZSTD(1)),
`__hdx_materialized_deployment.environment.name` LowCardinality(String) MATERIALIZED ResourceAttributes['deployment.environment.name'] CODEC(ZSTD(1)),
INDEX idx_trace_id TraceId TYPE bloom_filter(0.001) GRANULARITY 1,
INDEX idx_res_attr_key mapKeys(ResourceAttributes) TYPE bloom_filter(0.01) GRANULARITY 1,
INDEX idx_res_attr_value mapValues(ResourceAttributes) TYPE bloom_filter(0.01) GRANULARITY 1,
INDEX idx_scope_attr_key mapKeys(ScopeAttributes) TYPE bloom_filter(0.01) GRANULARITY 1,
INDEX idx_scope_attr_value mapValues(ScopeAttributes) TYPE bloom_filter(0.01) GRANULARITY 1,
INDEX idx_log_attr_key mapKeys(LogAttributes) TYPE bloom_filter(0.01) GRANULARITY 1,
INDEX idx_log_attr_value mapValues(LogAttributes) TYPE bloom_filter(0.01) GRANULARITY 1,
INDEX idx_lower_body lower(Body) TYPE tokenbf_v1(32768, 3, 0) GRANULARITY 8
)
ENGINE = MergeTree
PARTITION BY toDate(TimestampTime)
PRIMARY KEY (ServiceName, TimestampTime)
ORDER BY (ServiceName, TimestampTime, Timestamp)
TTL TimestampTime + ${TABLES_TTL}
SETTINGS index_granularity = 8192, ttl_only_drop_parts = 1;
-- Before
PRIMARY KEY (ServiceName, TimestampTime)
ORDER BY (ServiceName, TimestampTime, Timestamp)
-- After
PRIMARY KEY (toStartOfFiveMinutes(TimestampTime), ServiceName, TimestampTime)
-- Before
`TimestampTime` DateTime DEFAULT toDateTime(Timestamp),
PARTITION BY toDate(TimestampTime)
PRIMARY KEY (toStartOfFiveMinutes(TimestampTime), ServiceName, TimestampTime)
-- After
PARTITION BY toDate(Timestamp)
PRIMARY KEY (toStartOfFiveMinutes(Timestamp), ServiceName, Timestamp)
-- Before
INDEX idx_lower_body lower(Body) TYPE tokenbf_v1(32768, 3, 0) GRANULARITY 8
-- After
INDEX idx_lower_body lower(Body) TYPE text(tokenizer = 'splitByNonAlpha')
-- Before
INDEX idx_trace_id TraceId TYPE bloom_filter(0.001) GRANULARITY 1,
-- After
INDEX idx_trace_id TraceId TYPE text(tokenizer='array'),
-- Before
SETTINGS index_granularity = 8192, ttl_only_drop_parts = 1;
-- After
SETTINGS index_granularity = 8192, ttl_only_drop_parts = 1, enable_block_number_column = 1, enable_block_offset_column = 1;
この課題に対応するため、ClickStack のデフォルトスキーマの一部としてマテリアライズドビューを提供するようにしました。クエリ実行時にテレメトリテーブルをスキャンする代わりに、ClickStack はメタデータ探索専用のコンパクトなロールアップテーブルを維持するようになっています。これらのビューは [`AggregatingMergeTree`](https://clickhouse.com/docs/engines/table-engines/mergetree-family/aggregatingmergetree) エンジンを使用して、属性のキー、値、およびそれらの出現頻度を15分単位のバケットで(挿入時に)事前集計します。
CREATE MATERIALIZED VIEW IF NOT EXISTS otel_logs_attr_kv_rollup_15m_mv
TO otel_logs_kv_rollup_15m
AS WITH elements AS (
SELECT 'NativeColumn' AS ColumnIdentifier,
toStartOfFifteenMinutes(Timestamp) AS Timestamp,
'SeverityText' AS Key,
CAST(SeverityText AS String) AS Value
FROM otel_logs
UNION ALL
-- similar UNION ALL branches for ServiceName, ScopeName, etc.
)
SELECT Timestamp, ColumnIdentifier, Key, Value, count() AS count
FROM elements
GROUP BY Timestamp, ColumnIdentifier, Key, Value;
INDEX idx_res_attr_key mapKeys(ResourceAttributes) TYPE bloom_filter(0.01) GRANULARITY 1,
INDEX idx_res_attr_value mapValues(ResourceAttributes) TYPE bloom_filter(0.01) GRANULARITY 1
ResourceAttributeItems Array(String) ALIAS arrayMap((arr) -> concat(arr.1, '=', arr.2), ResourceAttributes::Array(Tuple(String, String)))
CREATE TABLE IF NOT EXISTS ${DATABASE}.otel_logs (
`Timestamp` DateTime64(9) CODEC(Delta(8), ZSTD(1)),
`TraceId` String CODEC(ZSTD(1)),
`SpanId` String CODEC(ZSTD(1)),
`TraceFlags` UInt8,
`SeverityText` LowCardinality(String) CODEC(ZSTD(1)),
`SeverityNumber` UInt8,
`ServiceName` LowCardinality(String) CODEC(ZSTD(1)),
`Body` String CODEC(ZSTD(1)),
`ResourceSchemaUrl` LowCardinality(String) CODEC(ZSTD(1)),
`ResourceAttributes` Map(LowCardinality(String), String) CODEC(ZSTD(1)),
`ScopeSchemaUrl` LowCardinality(String) CODEC(ZSTD(1)),
`ScopeName` String CODEC(ZSTD(1)),
`ScopeVersion` LowCardinality(String) CODEC(ZSTD(1)),
`ScopeAttributes` Map(LowCardinality(String), String) CODEC(ZSTD(1)),
`LogAttributes` Map(LowCardinality(String), String) CODEC(ZSTD(1)),
`EventName` String CODEC(ZSTD(1)),
`__hdx_materialized_k8s.cluster.name` LowCardinality(String) MATERIALIZED ResourceAttributes['k8s.cluster.name'] CODEC(ZSTD(1)),
`__hdx_materialized_k8s.container.name` LowCardinality(String) MATERIALIZED ResourceAttributes['k8s.container.name'] CODEC(ZSTD(1)),
`__hdx_materialized_k8s.deployment.name` LowCardinality(String) MATERIALIZED ResourceAttributes['k8s.deployment.name'] CODEC(ZSTD(1)),
`__hdx_materialized_k8s.namespace.name` LowCardinality(String) MATERIALIZED ResourceAttributes['k8s.namespace.name'] CODEC(ZSTD(1)),
`__hdx_materialized_k8s.node.name` LowCardinality(String) MATERIALIZED ResourceAttributes['k8s.node.name'] CODEC(ZSTD(1)),
`__hdx_materialized_k8s.pod.name` LowCardinality(String) MATERIALIZED ResourceAttributes['k8s.pod.name'] CODEC(ZSTD(1)),
`__hdx_materialized_k8s.pod.uid` LowCardinality(String) MATERIALIZED ResourceAttributes['k8s.pod.uid'] CODEC(ZSTD(1)),
`__hdx_materialized_deployment.environment.name` LowCardinality(String) MATERIALIZED ResourceAttributes['deployment.environment.name'] CODEC(ZSTD(1)),
`ResourceAttributeItems` Array(String) ALIAS arrayMap((arr) -> concat(arr.1, '=', arr.2), ResourceAttributes::Array(Tuple(String, String))),
`ScopeAttributeItems` Array(String) ALIAS arrayMap((arr) -> concat(arr.1, '=', arr.2), ScopeAttributes::Array(Tuple(String, String))),
`LogAttributeItems` Array(String) ALIAS arrayMap((arr) -> concat(arr.1, '=', arr.2), LogAttributes::Array(Tuple(String, String))),
INDEX idx_trace_id TraceId TYPE text(tokenizer = 'array'),
INDEX idx_res_attr_key mapKeys(ResourceAttributes) TYPE text(tokenizer = 'array'),
INDEX idx_res_attr_items ResourceAttributeItems TYPE text(tokenizer = 'array'),
INDEX idx_scope_attr_key mapKeys(ScopeAttributes) TYPE text(tokenizer = 'array'),
INDEX idx_scope_attr_items ScopeAttributeItems TYPE text(tokenizer = 'array'),
INDEX idx_log_attr_key mapKeys(LogAttributes) TYPE text(tokenizer = 'array'),
INDEX idx_log_attr_items LogAttributeItems TYPE text(tokenizer = 'array'),
INDEX idx_lower_body lower(Body) TYPE text(tokenizer = 'splitByNonAlpha')
)
ENGINE = MergeTree
PARTITION BY toDate(Timestamp)
ORDER BY (toStartOfFiveMinutes(Timestamp), ServiceName, Timestamp)
TTL toDateTime(Timestamp) + ${TABLES_TTL}
SETTINGS index_granularity = 8192, ttl_only_drop_parts = 1, enable_block_number_column = 1, enable_block_offset_column = 1;