メインコンテンツまでスキップ
メインコンテンツまでスキップ

ClickHouseを使った可視化

はじめに​

このガイドは、ClickHouseを使用して独自のSQLベースの可視化ソリューションを構築しようとしているユーザー向けに設計されています。主にログとトレースに焦点を当てています。データの取り込み、アクセスパターンに最適化されたスキーマの構築、非構造化ログからの構造の抽出など、独自のソリューションを構築するためのあらゆる側面をカバーしています。

ClickHouse自体は、可視化のための即時利用可能なソリューションではありません。ただし、比類のない圧縮率と高速なクエリ応答時間を誇る可視化データのための非常に効率的なストレージエンジンとして使用することができます。ユーザーが可視化のソリューションにClickHouseを使用するためには、ユーザーインターフェイスとデータ収集フレームワークが必要です。現在、可視化信号の可視化にはGrafanaを、データ収集にはOpenTelemetryの使用を推奨しています（どちらも公式にサポートされている統合です）。


OpenTelemetryだけではない

データ収集にOpenTelemetry（OTel）プロジェクトを使用することを推奨していますが、VectorやFluentdなどの他のフレームワークやツールを使用して類似のアーキテクチャを構築することも可能です（Fluent Bitを使用した例を参照）。SupersetやMetabaseなどの代替の可視化ツールも存在します。

ClickHouseを使用する理由​

中央集中的な可視化ストアの最も重要な機能は、さまざまなソースからの膨大な量のログデータを迅速に集約、分析、検索できる能力です。この集中化はトラブルシューティングを効率化し、サービスの中断の根本原因を特定するのを容易にします。

ユーザーはますます価格に敏感になっており、これらの即時利用可能な提供物のコストがその提供価値に比して高く予測不可能であると感じています。そのため、クエリパフォーマンスが許容範囲であるコスト効率の高い予測可能なログストレージは、かつてないほど価値があります。

そのパフォーマンスとコスト効率のために、ClickHouseは可視化製品のロギングおよびトレースのストレージエンジンの事実上の標準となりました。

より具体的には、次の理由によりClickHouseは可視化データのストレージに最適です：

  • 圧縮 - 可視化データは通常、HTTPコードやサービス名など、特定のセットから取得される値のフィールドを含んでいます。ClickHouseの列指向ストレージでは、値がソートされた状態で保存されるため、このデータが非常に効果的に圧縮されます。特に、時系列データのための様々な専門のコーデックと組み合わされるとさらに圧縮効果が高まります。通常、JSON形式の元のデータサイズと同じだけのストレージを必要とする他のデータストアとは異なり、ClickHouseは平均して最大14倍の圧縮を実現します。この圧縮は大規模な可視化インストールでのストレージ節約に貢献するだけでなく、ディスクから読み込むデータ量が減少するため、クエリの加速にも寄与します。
  • 高速な集約 - 可視化ソリューションは、エラーレートを示す線やトラフィックソースを示す棒グラフなど、データをチャートで可視化することに大きく関与しています。集約、すなわちGROUP BYは、これらのチャートを駆動するために不可欠であり、問題診断のためのワークフロー内でフィルターを適用する際にも迅速かつ反応的である必要があります。ClickHouseの列指向フォーマットとベクトル化されたクエリ実行エンジンの組み合わせは、高速な集約に理想的であり、スパースインデックスによりユーザーのアクションに応じた迅速なデータフィルタリングが可能です。
  • 高速な線形スキャン - 代替技術がログの高速クエリのために逆インデックスに依存する一方、これらは必然的に高いディスクおよびリソースの使用率を引き起こします。ClickHouseは逆インデックスを追加のオプショナルインデックスタイプとして提供しますが、線形スキャンは非常に並列化されており、機械上のすべてのコアを使用します（他に設定されない限り）。これは、高度に最適化されたテキストマッチングオペレーターを使用して、1秒あたり（圧縮状態で）数十GBをスキャンし、一致するものを見つける可能性があります。
  • SQLの親しみやすさ - SQLはすべてのエンジニアが親しんでいる普遍的な言語です。50年以上の開発の歴史があり、データ分析の事実上の言語としてその地位を確立し、3番目に人気のあるプログラミング言語であり続けています。可視化はSQLにとって理想的なデータ問題です。
  • 分析関数 - ClickHouseは、SQLクエリをシンプルで書きやすくするために設計された分析関数をANSI SQLに拡張しています。これは、データをスライスしたりダイスしたりする必要がある根本原因分析を実行するユーザーにとって欠かせません。
  • セカンダリインデックス - ClickHouseは、特定のクエリプロファイルを加速するためのブロームフィルターなどのセカンダリインデックスをサポートしています。これらはオプションでカラムレベルで有効にでき、ユーザーに granularなコントロールを提供し、コストとパフォーマンスの利点を評価できるようにします。
  • オープンソース＆オープンスタンダード - オープンソースデータベースとして、ClickHouseはOpen Telemetryなどのオープンスタンダードを受け入れています。プロジェクトに貢献し、積極的に参加する能力は魅力的であり、ベンダーロックインの課題を回避します。

いつClickHouseを可視化に使用すべきか​

ClickHouseを可視化データに使用するためには、ユーザーがSQLベースの可視化を受け入れる必要があります。SQLベースの可視化の歴史についてはこのブログ投稿を推奨しますが、要約すると次のようになります：

SQLベースの可視化があなたに適しているかもしれない場合：

  • あなたまたはあなたのチームがSQLに親しんでいる（または学びたいと考えている）
  • ロックインを避け、拡張性を達成するためにOpenTelemetryのようなオープンスタンダードに従うことを好む
  • 収集から保存、可視化に至るまで、オープンソースの革新によって推進されるエコシステムを運用する意欲がある
  • 管理する可視化データの中程度または大規模なボリュームへの成長を見込んでいる（または非常に大規模でも）
  • TCO（総保有コスト）をコントロールしたいと考え、かさむ可視化コストを避けたい
  • コストを管理するために、可視化データの保持期間を短くすることができない、またはしたくない

SQLベースの可視化があなたに適していないかもしれない場合：

  • SQLの学習（または生成）があなたやあなたのチームに魅力的でない
  • 包装されたエンドツーエンドの可視化体験を求めている
  • 可視化データのボリュームが小さすぎて重要な差を生むことができない（例：<150 GiB）と予測されている
  • あなたのユースケースがメトリクス重視で、PromQLを必要としている。その場合、メトリクス用にPrometheusと共にClickHouseを使用し、Grafanaのプレゼンテーションレイヤーで統合でる
  • エコシステムがより成熟するのを待ちたい、またはSQLベースの可視化がより簡単になるのを望んでいる

ログとトレース​

可視化のユースケースには、ログ、トレース、メトリクスの3つの明確な柱があります。各々は異なるデータタイプとアクセスパターンを持っています。

現在、ClickHouseを可視化するために次の2種類のデータを保存するのを推奨しています：

  • ログ - ログはシステム内で発生するイベントのタイムスタンプ付きレコードであり、ソフトウェアの操作に関するさまざまな側面の詳細情報をキャプチャします。ログ内のデータは通常、非構造化または半構造化されており、エラーメッセージ、ユーザーアクティビティログ、システムの変更、およびその他のイベントを含むことがあります。ログはトラブルシューティング、異常検出、およびシステム内の問題に至る特定のイベントを理解するために重要です。
  • トレース - トレースは、リクエストが分散システム内のさまざまなサービスを横断する過程を捉え、これらのリクエストの経路とパフォーマンスを詳細化します。トレース内のデータは非常に構造化されており、各ステップにかかる時間情報を含むスパンとトレースで構成されています。トレースはシステムパフォーマンスに関する貴重な洞察を提供し、ボトルネックやレイテンシ問題を特定し、マイクロサービスの効率を最適化するのに役立ちます。
メトリクス

ClickHouseをメトリクスデータを保存するために使用することはできますが、この柱はClickHouse内では成熟度が低く、PrometheusデータフォーマットとPromQLのサポートなどの機能が待たれています。

分散トレース​

分散トレースは可視化の重要な機能です。分散トレースは単にトレースと呼ばれ、リクエストがシステムを通じてどのように進むかをマッピングします。リクエストはエンドユーザーまたはアプリケーションから発生し、システム全体に広がり、一般的にマイクロサービス間のアクションの流れが生じます。このシーケンスを記録し、後続のイベントを相関させることにより、可視化のユーザーやSREがアプリケーションフローの問題を診断することができるようになります。

各トレースは複数のスパンで構成され、リクエストに関連する最初のスパンはルートスパンと呼ばれます。このルートスパンはリクエスト全体を最初から最後までキャプチャします。その下にあるスパンは、リクエスト中に発生するさまざまなステップや操作を詳細に説明します。トレースがなければ、分散システム内のパフォーマンス問題を診断することは非常に困難です。トレースは、システム内でリクエストが進む際のイベントのシーケンスを詳細に記述することにより、分散システムのデバッグおよび理解のプロセスを容易にします。

ほとんどの可視化ベンダーは、この情報を滝のように視覚化し、相対的なタイミングを比例サイズの水平バーで示します。たとえば、Grafanaでは：

ログとトレースの概念に深く慣れる必要があるユーザーには、OpenTelemetryのドキュメントを強く推奨します。