ClickHouseを使用した可観測性
はじめに
このガイドは、ClickHouseを使用してSQLベースの可観測性ソリューションを構築したいユーザー向けに設計されています。主にログとトレースに焦点を当てています。このガイドでは、インジェクションの考慮事項、アクセスパターンに最適化されたスキーマの構築、および非構造的ログからの構造の抽出を含む、自分のソリューションを構築するためのすべての側面をカバーします。
ClickHouse単体は、可観測性に対するアウト・オブ・ザ・ボックスのソリューションではありません。しかし、比類のない圧縮率と超高速のクエリ応答時間を持つ可観測性データのための非常に効率的なストレージエンジンとして使用できます。ユーザーが可観測性ソリューション内でClickHouseを使用するためには、ユーザーインターフェースとデータ収集フレームワークが必要です。現在、可観測性信号の可視化にはGrafana、データ収集にはOpenTelemetryを使用することを推奨しています（どちらも公式にサポートされている統合です）。
私たちの推奨はデータ収集のためにOpenTelemetry（OTel）プロジェクトを使用することですが、VectorやFluentdなどの他のフレームワークやツールを使用しても同様のアーキテクチャを構築できます（Fluent Bitを使用した例を参照してください）。SupersetやMetabaseなど、他の可視化ツールも存在します。
なぜClickHouseを使うのか？
中央集権的な可観測性ストアの最も重要な機能は、多様なソースからの膨大なログデータを迅速に集約、分析、および検索できる能力です。この中央集権化によりトラブルシューティングが効率化され、サービス中断の根本原因を特定しやすくなります。
ユーザーがますます価格に敏感になり、これらのアウト・オブ・ザ・ボックスのオファリングのコストが持つ価値に比べて高く予測不可能であると感じているため、クエリ性能が受け入れ可能で、コスト効率的かつ予測可能なログストレージは、これまで以上に価値があります。
その性能とコスト効率により、ClickHouseは可観測性製品におけるログおよびトレースストレージエンジンの事実上の標準となっています。
より具体的には、次の点からClickHouseは可観測性データのストレージに理想的です：
- 圧縮 - 可観測性データは通常、HTTPコードやサービス名など、特定のセットから取得された値のフィールドを含みます。値がソートされて保存されるClickHouseの列指向ストレージは、このデータを非常によく圧縮します。特に、時系列データ用のさまざまな専門コーデックと組み合わせると、効果的です。他のデータストアは通常、元のデータサイズ（通常はJSON形式）のストレージ量が必要ですが、ClickHouseはログとトレースを平均して最大14倍圧縮します。大規模な可観測性インストールのための重要なストレージコスト削減を提供するだけでなく、この圧縮はディスクから読み取るデータ量が減るため、クエリを加速するのに役立ちます。
- 高速集約 - 可観測性ソリューションは通常、エラーレートを示すラインやトラフィックソースを示す棒グラフなど、データをチャートで可視化することに大いに関与しています。集約、またはGROUP BYは、これらのチャートを支える基盤であり、フィルタを適用する際に迅速で応答性が必要です。ClickHouseの列指向フォーマットは、ベクトル化されたクエリ実行エンジンと組み合わさって、高速な集約に理想的であり、スパースインデクシングはユーザーのアクションに応じてデータを迅速にフィルタリングできます。
- 高速線形スキャン - 他の技術がログの高速クエリのために逆インデックスに依存するのに対し、これは高いディスクとリソースの使用を招くことがあります。ClickHouseは逆インデックスを追加のオプションインデックスタイプとして提供しますが、線形スキャンは高度に並列化され、マシンのすべてのコアを利用します（別途設定しない限り）。これにより、1秒あたりの圧縮されたマッチをスキャンできる可能性があり、高度に最適化されたテキストマッチングオペレーターを使って処理を行います。
- SQLの親しみやすさ - SQLはすべてのエンジニアに広く使われている言語です。50年以上の開発の成果、SQLはデータ分析の事実上の標準言語として証明され、なお3番目に人気のあるプログラミング言語です。可観測性はSQLが理想的な別のデータ問題です。
- 分析関数 - ClickHouseはANSI SQLを拡張し、SQLクエリを簡単かつ書きやすくするための分析関数を提供します。データをスライス＆ダイスする必要がある根本原因分析を行うユーザーには不可欠です。
- 二次インデックス - ClickHouseは、特定のクエリプロファイルを加速させるために、ブルームフィルタなどの二次インデックスをサポートしています。これらはカラムレベルでオプションとして有効にでき、ユーザーに細かい制御を提供し、コストパフォーマンスの利点を評価できるようになります。
- オープンソース & オープンスタンダード - オープンソースデータベースとして、ClickHouseはOpenTelemetryなどのオープンスタンダードを受け入れています。プロジェクトに貢献し、積極的に参加できる能力は魅力的で、ベンダーロックインの課題を回避できます。
可観測性に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のドキュメントを強くお勧めします。