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

ClickHouseによる観測の利用

はじめに​

このガイドは、ClickHouseを使用して独自のSQLベースの観測ソリューションを構築しようとするユーザー向けに設計されています。特にログとトレースに焦点を当てています。これには、取り込みの考慮事項、アクセスパターンに最適化されたスキーマの設計、および非構造化ログからの構造の抽出を含む、独自のソリューションの構築に関するすべての側面が含まれます。

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

NEEDS ALT
Not just OpenTelemetry

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

なぜClickHouseを使用するのか？​

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

ユーザーがますますコストに敏感になり、これらのアウトオブボックスの提供がもたらす価値に比べてコストが高く予測不可能だと感じているため、クエリパフォーマンスが許容範囲内でコスト効率の良い安定したログストレージがかつてないほど価値があります。

そのパフォーマンスとコスト効率のために、ClickHouseは観測製品におけるログおよびトレースストレージエンジンのデファクトスタンダードとなっています。

より具体的には、以下の理由からClickHouseは観測データのストレージに最適です。

  • 圧縮 - 観測データには、たとえばHTTPコードやサービス名のように特定のセットから取得されるフィールドが含まれることが一般的です。ClickHouseの列指向ストレージでは、値がソートされた状態で保存されているため、特に時系列データ向けのさまざまな特殊なコーデックと組み合わせることで、このデータは非常に良く圧縮されます。他のデータストアが元のデータサイズ（通常はJSON形式）と同じだけのストレージを必要とするのに対し、ClickHouseは平均して最大14倍圧縮します。大規模な観測インストールにおけるストレージの大幅な削減を提供するだけでなく、この圧縮によりディスクから読み取る必要のあるデータが少なくなるため、クエリを加速する助けにもなります。
  • 高速集約 - 観測ソリューションは通常、エラーレートを示す線やトラフィックソースを示す棒グラフなど、データの可視化を通じて大きく関与します。集約やGROUP BYは、これらのチャートを充実させるための基本的な要素であり、問題診断のワークフローでフィルターを適用する際にも迅速かつ反応性が必要です。ClickHouseの列指向フォーマットとベクトル化されたクエリ実行エンジンは、高速集約に最適であり、スパースインデックスによりユーザーのアクションに応じてデータの迅速なフィルタリングを可能にします。
  • 高速リニアスキャン - 別の技術はログの高速クエリのために逆インデックスに依存していますが、これらは必然的に高いディスク及びリソースの使用を引き起こします。ClickHouseは追加オプションのインデックスタイプとして逆インデックスを提供していますが、リニアスキャンは非常に並列化されており、マシン上のすべてのコアを使用します（別に設定しない限り）。これは、最適化されたテキストマッチングオペレーターを使用してマッチを確認する際に、秒あたり数十GB（圧縮されて）のスキャンが可能です。
  • SQLの親しみやすさ - SQLはすべてのエンジニアに親しまれている普遍的な言語です。50年以上の開発を経て、データ分析のデファクト言語としての地位を確立し、現在も 3番目に人気のあるプログラミング言語 です。観測はSQLに理想的な別のデータ問題です。
  • 分析関数 - ClickHouseは、SQLクエリを簡単かつ書きやすくするために設計された分析関数をANSI SQLに拡張します。これらは、データを切り分ける必要がある根本原因分析を行うユーザーにとって重要です。
  • セカンダリインデックス - ClickHouseは、特定のクエリプロファイルを加速するために、ブルームフィルタなどのセカンダリインデックスをサポートしています。これらはカラムレベルでオプションとして有効化でき、ユーザーに対して詳細な制御を提供し、コストとパフォーマンスの利益を評価可能にします。
  • オープンソース＆オープンスタンダード - オープンソースデータベースとして、ClickHouseはOpen Telemetryなどのオープンスタンダードを採用しています。プロジェクトに貢献し、積極的に参加する能力は魅力的であり、ベンダーロックインの課題を避けることができます。

いつClickHouseを観測に使用すべきか​

観測データにClickHouseを使用するには、ユーザーがSQLベースの観測を受け入れる必要があります。SQLベースの観測の歴史についてはこのブログ記事を推奨しますが、要約すると：

SQLベースの観測は次の場合に適しています：

  • あなたやあなたのチームがSQLに精通している（または学びたい）場合
  • ロックインを避け、拡張性を実現するためにOpenTelemetryのようなオープンスタンダードに従うことを好む場合
  • 収集からストレージ、可視化までオープンソースの革新によって駆動されるエコシステムを運営する意欲がある場合
  • 管理する観測データが中程度または大規模に成長することを見込んでいる場合（または非常に大規模なボリューム）
  • TCO（総保有コスト）を管理し、観測コストが膨らむのを避けたい場合
  • コストを管理するための小さなデータ保持期間に縛られたくない場合

SQLベースの観測は次の場合には適さないかもしれません：

  • SQLを学ぶこと（または生成すること）があなたやあなたのチームにとって魅力的でない場合
  • パッケージ化されたエンドツーエンドの観測体験を探している場合
  • 観測データのボリュームが比較的小さく（例：<150 GiB）、成長が見込まれない場合
  • あなたのユースケースがメトリック重視で、PromQLが必要な場合。その場合、ClickHouseをログとトレースのために、Prometheusをメトリックのために使用し、Grafanaでプレゼンテーションレイヤーで統合できます。
  • エコシステムが成熟し、SQLベースの観測がよりターンキーになるのを待つことを好む場合

ログとトレース​

観測のユースケースには、3つの異なる柱があります：ログ、トレース、メトリクス。それぞれ異なるデータ型およびアクセスパターンを持っています。

現在、ClickHouseを使用した観測データの保存には2種類を推奨しています：

  • ログ - ログは、システム内で発生するイベントのタイムスタンプ付き記録であり、ソフトウェアの操作のさまざまな側面に関する詳細情報をキャプチャします。ログのデータは通常、非構造化または半構造化され、エラーメッセージ、ユーザーアクティビティログ、システムの変更、その他のイベントを含むことができます。ログはトラブルシューティング、異常検出、およびシステム内の問題に至る特定のイベントを理解する上で重要です。
  • トレース - トレースは、リクエストが分散システムのさまざまなサービスを通過する際の旅をキャプチャし、リクエストの経路とパフォーマンスの詳細を説明します。トレースのデータは非常に構造化されており、スパンとトレースによってリクエストが取る各ステップをマッピングし、タイミング情報を含みます。トレースはシステムパフォーマンスに関する貴重な洞察を提供し、ボトルネック、レイテンシ問題の特定を助け、マイクロサービスの効率を最適化します。
メトリクス

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

分散トレーシング​

分散トレーシングは観測の重要な機能です。分散トレース、単にトレースと呼ばれるものは、リクエストがシステムを通過する道筋をマッピングします。リクエストはエンドユーザーまたはアプリケーションから始まり、システム全体で広がり、通常はマイクロサービス間での一連のアクションを引き起こします。このシーケンスを記録し、後続のイベントを相関させることにより、観測ユーザーやSREがアプリケーションフローの問題を診断できるようにします。これはアーキテクチャがどれほど複雑であってもサーバーレスであっても関係ありません。

各トレースは複数のスパンで構成されており、リクエストに関連付けられた最初のスパンはルートスパンと呼ばれます。このルートスパンは、最初から最後までのリクエスト全体を捉えます。ルートの下にあるその後のスパンは、リクエスト中に発生するさまざまなステップや操作に関する詳細な洞察を提供します。トレースがなければ、分散システムにおけるパフォーマンス問題の診断は非常に困難になります。トレースは、システムを横断するリクエスト内のイベントのシーケンスを詳細に示すことで、デバッグや分散システムの理解を容易にします。

ほとんどの観測ベンダーは、この情報をウォーターフォールとして可視化し、相対的なタイミングを比例したサイズの水平バーで表示します。たとえば、Grafanaでは：

NEEDS ALT

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