はじめに
OpenTelemetry だけではありませんデータ収集には OpenTelemetry (OTel) プロジェクトの使用を推奨していますが、Vector や Fluentd など、ほかのフレームワークやツールを使って同様のアーキテクチャを構築することもできます (Fluent Bit を使った例も参照してください) 。また、可視化ツールにも Superset や Metabase などの選択肢があります。
なぜ ClickHouse を使うのか？
- 圧縮 - オブザーバビリティデータには通常、HTTP コードやサービス名のように、値が限られた集合から取られるフィールドが含まれます。値をソートして保持する ClickHouse のカラム指向ストレージにより、この種のデータは非常によく圧縮されます。特に、時系列データ向けの各種専用 codec と組み合わせると効果的です。一般に JSON 形式の元データと同程度のストレージ容量を必要とする他のデータストアとは異なり、ClickHouse はログとトレースを平均で最大 14 倍圧縮します。これは大規模なオブザーバビリティ環境で大きなストレージ削減効果をもたらすだけでなく、ディスクから読み出すデータ量が減るため、クエリの高速化にもつながります。
- 高速な集計 - オブザーバビリティソリューションでは通常、たとえばエラー率を示す折れ線グラフやトラフィックソースを示す棒グラフなど、グラフによるデータの可視化が大きな割合を占めます。集計、すなわち GROUP BY は、こうしたグラフを支える基本機能であり、問題診断のワークフローでフィルタを適用した場合でも、高速かつ応答性に優れている必要があります。ClickHouse のカラム指向フォーマットとベクトル化クエリ実行エンジンの組み合わせは高速な集計に最適であり、さらにスパースインデックスによって、ユーザー操作に応じた高速なデータのフィルタリングが可能になります。
- 高速な線形スキャン - ログを高速にクエリするために転置索引に依存する代替技術もありますが、そのような方式は往々にしてディスク使用量とリソース消費が大きくなります。ClickHouse も追加の任意の索引タイプとして転置索引を提供していますが、線形スキャンは高度に並列化されており、マシン上の利用可能なすべてのコアを使用します (別途設定しない限り) 。これにより、高度に最適化されたテキスト一致演算子を用いて、1 秒あたり数十 GB (圧縮後) をスキャンして一致を検出できる可能性があります。
- SQL への親しみやすさ - SQL は、すべてのエンジニアになじみのある普遍的な言語です。50 年以上にわたる発展を経て、データ分析の事実上の標準言語としての地位を確立しており、現在も3 番目に人気の高いプログラミング言語であり続けています。オブザーバビリティもまた、SQL が理想的に適したデータの問題のひとつにすぎません。
- 分析関数 - ClickHouse は ANSI SQL を拡張し、SQL クエリをより簡潔で書きやすくする分析関数を提供しています。これは、データをさまざまな切り口で詳しく分析する必要がある根本原因分析において不可欠です。
- セカンダリ索引 - ClickHouse は、ブルームフィルタなどのセカンダリ索引をサポートしており、特定のクエリプロファイルを高速化できます。これらはカラム単位で任意に有効化できるため、ユーザーはきめ細かく制御でき、コストと性能のトレードオフを評価できます。
- オープンソースとオープン標準 - オープンソースデータベースとして、ClickHouse は OpenTelemetry のようなオープン標準を採用しています。ベンダーロックインの課題を回避しながら、プロジェクトに貢献し積極的に参加できる点も魅力です。
どのような場合にオブザーバビリティで ClickHouse を使うべきか
- あなたやチームメンバーが SQL に慣れている、または学びたいと考えている
- ベンダーロックインを避け、拡張性を確保するために、OpenTelemetry のようなオープン標準に準拠したい
- 収集から保存、可視化まで、オープンソースのイノベーションに支えられたエコシステムを運用する意思がある
- 管理対象のオブザーバビリティデータが中規模から大規模、あるいは非常に大規模にまで増える可能性がある
- TCO (総所有コスト) を自らコントロールし、オブザーバビリティのコストが際限なく膨らむのを避けたい
- コストを抑えるためだけに、オブザーバビリティデータの保持期間を短くせざるを得ない状況を避けたい、またはそうしたくない
- SQL を学ぶこと (あるいは生成すること) に、あなたやチームメンバーが魅力を感じない
- パッケージ化された、エンドツーエンドのオブザーバビリティ体験を求めている
- オブザーバビリティデータ量が非常に少なく、目立った違いが出ない (例: <150 GiB) うえ、今後の増加も見込まれない
- ユースケースがメトリクス中心で、PromQL を必要としている。その場合でも、メトリクスには Prometheus を使い、ログとトレーシングには ClickHouse を併用し、Grafana のプレゼンテーション層で統合できます。
- エコシステムがさらに成熟し、SQL ベースのオブザーバビリティがもっとすぐに使えるようになるのを待ちたい
ログとトレース
- ログ - ログは、システム内で発生するイベントをタイムスタンプ付きで記録したもので、ソフトウェア運用のさまざまな側面に関する詳細な情報を捉えます。ログ内のデータは通常、非構造化または半構造化されており、エラーメッセージ、ユーザーのアクティビティログ、システムの変更、その他のイベントを含むことがあります。ログは、トラブルシューティング、異常検知、そしてシステム内で問題に至るまでに発生した具体的なイベントを把握するうえで不可欠です。
- トレース - トレースは、分散システム内でリクエストがさまざまなサービスを横断する過程を捉え、それらの経路とパフォーマンスを詳細に示します。トレース内のデータは高度に構造化されており、タイミング情報を含むスパンとトレースによって、各リクエストがたどる各ステップが表現されます。トレースはシステムパフォーマンスに関する有用なインサイトを提供し、ボトルネックやレイテンシの問題の特定、さらにマイクロサービスの効率最適化に役立ちます。
メトリクスClickHouseはメトリクスデータの保存にも使用できますが、この領域はClickHouseではまだ成熟度が低く、PrometheusデータフォーマットやPromQLのサポートなどの機能にはまだ十分対応していません。