博士

やあ、ロボ子。今日はCIにおけるオブザーバビリティ向上のお話じゃ。

ロボ子

CIのオブザーバビリティ、ですか。CIビルドの失敗原因特定が難しいという課題があるんですね。

博士

そうなんじゃ。そこでGitHub Actions向けのログプラットフォームを構築したらしいぞ。開発者がログ検索で苦労しているのを解決するのじゃ。

ロボ子

なるほど。ログ基盤としてClickHouseを採用したんですね。低い運用コストとチームの習熟度が理由とのことですが、具体的にはどういうことですか？

博士

ClickHouseは、データ量に応じたコスト効率が良いのが魅力じゃ。それに、約12倍という高い圧縮率もすごいぞ。KafkaやElasticsearchの運用が不要なのも大きい。

ロボ子

12倍の圧縮率！それはすごいですね。テキスト検索の高速化には、ClickHouseのn-gram Bloom filter indexを活用しているんですね。

博士

そうじゃ。文字列をn個のチャンクに分割して、Bloom filterで対象文字列が含まれる可能性のあるgranuleを特定するのじゃ。偽陽性はあり得るけど、偽陰性はないから安全にデータチャンクをスキップできる。

ロボ子

なるほど、Bloom filterの特性をうまく利用しているんですね。他にもClickHouseの機能を活用している点はありますか？

博士

materialized columnsを使ってログレベルを推測したり、row-level TTLでデータ保持期間を制御したりしておるぞ。

ロボ子

ログ取り込みパイプラインも工夫されていますね。Firecracker VMでジョブを実行し、`blacksmithd`デーモンでログファイルを監視してストリーミングする、と。

博士

そうじゃ。ClickHouseが大量のデータを処理できるから、キューは使わずにリトライ処理を実装しておる。`ReplacingMergeTree`エンジンとasync insertsで重複排除をClickHouseに任せるのもポイントじゃな。

ロボ子

`replicated_deduplication_window_for_async_inserts`と`replicated_deduplication_window_seconds`を調整して、最近挿入された行をキャッシュして重複排除するんですね。クエリ言語はLuceneのクエリ言語を参考にしているんですか？

博士

その通り。Substring matching、Property matching、Logical and comparison operatorsをサポートしておる。クエリ文字列をparse treeに変換して、`toSql()`メソッドでSQLに変換するのじゃ。

ロボ子

集計クエリもClickHouseの得意分野ですね。ヒストグラムやトレンドの集計クエリを高速に実行できるのは魅力的です。

博士

じゃろ？既存の顧客はもう利用できるらしいぞ。CIのログ分析が捗るのう。

ロボ子

CIの効率化に繋がりそうですね。私も使ってみたいです。

博士

そうじゃな。しかし、ログが多すぎて、どのエラーメッセージが重要か分からなくなる、なんてことになったら本末転倒じゃな。まるで、私の部屋の片付けみたいじゃ。

ロボ子

博士の部屋は、ログよりもカオスかもしれませんね…。