SIGQはなぜBigQueryからClickHouseに移行したのか

株式会社SIGQは、インシデント管理に特化したAIエージェント「Incident Lake」を提供しています。同社はもともとBigQueryをデータ基盤としていましたが、約半年前にClickHouseへ移行し、現在は複数の顧客のワークロードをClickHouse上で本番運用しています。

4月下旬、都内某所で、ClickHouse共同創業者・CTO Alexey Milovidov氏(以下、Alexey)と、株式会社SIGQ代表取締役 金築 敬晃（以下、金築）による対談が行われました。本記事では、SIGQが直面していた課題に、ClickHouseがどのように応えたのか、移行の背景を探ります。

本記事は対談記事の前編です。後編は「データとインシデント管理から探る、AI時代のSREのあり方とは」をご覧ください。

C++エンジニアが、世界最大級のトラフィックを分析するデータベースを生み出した経緯

Q. Alexeyさんは2009年からClickHouseの開発を続けていますが、そもそも、どんなきっかけでデータベースに関わるようになったのでしょうか。最初に直面していた課題も含めて、教えてください。

Alexey：もともと私はデータベース開発者ではなく、大きな会社のC++エンジニアでした。担当していたのは、Webサイト運営者に訪問者の分析レポートを提供するサービスです。ここで大きな課題に直面しました。毎日数千億件ものイベントが発生する規模のプラットフォーム上で、レポートをほぼ無制限にカスタマイズ可能にし、ユーザーが望む集計を何でも取得できる機能を提供しなければなりませんでした。しかも、ユーザーがレポートを定義した瞬間、即座に結果が表示されるレベルのリアルタイム性が求められました。

当然MySQLではこのユースケースに対応できず、さまざまなデータベースを試し始めました。その過程でカラム指向データベースやビッグデータ基盤の存在を知り、性能・圧縮率・コストの観点で既存製品を比較しました。その結果、集計・ソート・フィルタリングに特化したカラム指向ストレージなら自分でも開発できるのではないかと考えるようになりました。こうして開発したのが、「OLAPServer」というプロトタイプで、これが既存システムよりうまく動くことが分かりました。

※OLAP(OnLine Analytical Processing)：データウェアハウスなどに蓄積された膨大なデータを即時に多次元分析する技術。例えば、売上データを地域や時間など複数の軸で分析する用途に用いられる。

Q. それが今のClickHouseにつながったわけですね。

Alexey：その時点では、ClickHouseに繋がる明確なビジョンがあったわけではありませんが、漠然と、様々なクエリに対応できるようシステムを汎用化したいと考えていました。最初は空き時間に、やがて勤務時間中にも取り組むようになり、2012年にリリースされたのがClickHouseの最初のバージョンです。それは、私のチームだけでなく、Eコマースやビジネス分析など社内の他の部門でも利用されました。その後、技術カンファレンスに参加するうちに、こうしたデータベースには極めて大きな需要があることに気づきました。多くの企業のエンジニアが、私のものと似たプロトタイプを個別に作っていたのです。これはオープンソース化すべきだと確信し、会社を説得して2016年に公開しました。今年6月で、ClickHouseのオープンソース化からちょうど10周年を迎えます。

Incident Lakeが直面していたBigQueryの制約

Q. SIGQは最近、Incident Lakeのデータ基盤をBigQueryからClickHouse Cloudへ移行しました。どのような課題を解決するために移行したのでしょうか。

金築：まずは、Incident Lakeの特徴を簡単に紹介します。Incident LakeはAIを統合したインシデント管理プラットフォームです。多くの既存ツールが開発者向けなのに対し、私たちのツールはインシデント対応を統括するマネージャー層にフォーカスしています。

インシデント対応の現場では、障害対応やレポート作成依頼が飛び交っていますが、これらは大変負担の大きい作業です。そこでIncident LakeのAIエージェントが、タイムライン生成やレポート生成といった作業を支援します。そのため、障害が発生すると、Incident Lakeはエラーログだけでなく、SlackやTeamsなどのコミュニケーションログも収集します。

Alexey：集まったデータを使って、自動的にサマリを生成するということですね。

金築：その通りです。そして、この仕組みを実現する上で最も重要なのがデータ鮮度です。今のデータが正しいのか、何が最新なのかを把握できなければ、AIエージェントによる支援はそもそも信頼できないものになってしまいます。

私たちが保存しているデータは2種類あります。ユーザーメッセージのような生データと、ベクトル化されたデータです。生成したデータやレポートはすべてベクトル化してセマンティック検索に近いことを実現しています。

刻々と変化するインシデント対応の状況を追跡するためには、データ鮮度が極めて重要です。そのため、収集したデータを最新のタイムラインに応じて更新する必要があります。

しかし当時のBigQueryには、挿入直後のデータを更新できないという制約があり、データ鮮度を維持するうえで課題になっていました。そこで、これを機にClickHouse Cloudへ移行することにしたのです。

Alexey：ClickHouseのユーザーには、長年BigQueryを利用してきた企業がたくさんいます。SIGQと同様、レイテンシが理由で移行する企業も多いです。また、ClickHouseの方ができることが多いので、機能の充実度を理由に移行する企業も多いです。加えて、重要なのがコストの問題です。BigQueryは、クエリごと・処理データ量ごとに課金される従量課金料金モデルです。人間が時々クエリを投げる分にはいいのですが、大量のクエリを実行するユーザー、特にAIエージェントにはあまり向いていません。AIエージェントは一つのリクエストで10回、20回とクエリを実行することがよくあり、BigQueryではコストが跳ね上がってしまうのです。

Q. ClickHouseの機能を、Incident Lakeでどのように活用していますか。特に、金築さんが価値を実感している機能があれば教えてください。

金築：一例を挙げると、ClickHouseの近似ベクトル検索機能があります。Incident Lakeでは、この機能を類似インシデントの取得に活用しています。

インシデント対応では、過去に同じような事例があったかどうかを把握することが重要です。しかし、単純なベクトル検索で類似インシデントを見つけるのは、実はとても難しいのです。そこでIncident Lakeでは、ClickHouseの近似ベクトル検索を活用し、類似度を数値で示せるようにしています。お客様からも、この類似度表示と類似インシデント検索機能は大変好評です。

ClickHouseに移行する前は、自前で類似度計算を実装していましたが、非常に重いワークロードでした。ClickHouseの近似ベクトル検索を活用することで、負荷を大きく下げながら、Incident Lakeの価値を高められたと感じています。

Q. SIGQは、ClickHouseの近似ベクトル検索機能を日本で最初に利用した企業だと聞きました。

金築：はい。私たちはこの新機能が、ClickHouse Cloudで利用できるようになったその日から使い始めました。実は、ずっとリリースを待っていた機能で、ClickHouseのメンバーにも「いつ使えるようになるのか」と問い合わせていたほどです。

Alexey：こうしたお客様の存在は、私たちにとって本当にうれしいものです。私たちは常に、実際のビジネスにおけるワークロードで、新機能を検証してくれる技術パートナーを探しています。金築さんの熱意が、この機能をClickHouse Cloudでリリースする上での後押しになったのかもしれません。

なぜ世界最大級のAI企業がClickHouseを選ぶのか

Q. ClickHouseは、ペタバイト規模のデータや複雑なテレメトリへのクエリに、サブ秒(1秒未満)でレスポンスを返せるほど、高速な分析データベースとして知られています。それほどのスケールのデータとリアルタイム性を両立できるのはなぜでしょうか。

Alexey：まず大前提として、ClickHouseではトランザクション（OLTP)データと分析用（OLAP)データを分離する必要はありません。ビッグデータに関する典型的な誤解の一つに、トランザクションデータと、分析に使う鮮度の高いデータを分けて管理すべきだという考え方があります。

※OLTP(Online Transaction Processing)：銀行の振込やECサイトの注文など、少量のデータを正確に読み書きすること（トランザクション）を目的とする技術

例えば、「すべての履歴データはS3やRDBMSに置き、リアルタイム分析に必要な少量の新鮮なデータだけを分析データベースに入れよう」という発想は、よく見られる誤解です。しかし実際には、複数の技術を組み合わせることで、リアルタイムに近いデータ挿入と、分析クエリに対するサブ秒以下のレスポンスを両立できます。具体的には、高速なクエリ処理を実現するカラム指向ストレージや、データの高速挿入を可能にするMergeTreeデータ構造といった技術です。

さらにClickHouseでは、すべてのデータを共有ストレージに保存し、階層化キャッシュを組み合わせています。ローカルマシンのSSDとメモリにキャッシュを配置することで、頻繁にアクセスされるデータにはインメモリ並みの性能を、大部分のデータにはNVMe SSDの性能を、そしてシステム全体としてはオブジェクトストレージのコスト効率を活用できます。

これらすべてを一つの統合されたシステムとして提供できることが、ClickHouseの強みです。

Q. OpenAI, Anthropicといった世界最大級のAI企業の多くが、ClickHouse上でオブザーバビリティを運用しています。彼らがClickHouseを選んだ理由は何でしょうか。

Alexey：その答えはシンプルです。AI企業が必要とする、途方もないスケールのデータは、他のどの技術でも扱えないからです。実際には、多くの技術を試してきましたが、すべて壊れてしまいました。しかしClickHouseは驚くほどうまく動いたので、結果として彼らは使い続けているのです。

ClickHouseの強みはスケーラビリティにあります。AI企業は、毎日流入する数十ペタバイトという規模のデータを扱わなければなりません。ClickHouseでは数千台規模のクラスタを構築でき、その上で分散クエリを実行できます。膨大なログデータに対するテキストインデックスも効率的に作成できます。既存のシステムよりも、ClickHouseはこれらの物事をはるかにうまく処理できるのです。

加えて、データ圧縮率の高さも大きな特徴です。ComcastやeBayといった企業では20倍、30倍という圧縮率を達成しています。他のシステムはこれほど高いストレージ効率を備えていないので、数十ペタバイト規模のデータを保存するような環境では、ClickHouseの独壇場になります。さらに、オブジェクトストレージとの組み合わせによって、ほぼ完璧なソリューションとなるのです。

実際に、OpenAI、Anthropic、Tesla、xAIといった最大級のAI企業は、オブザーバビリティのためにClickHouseを大規模に活用し、鮮度の高いデータをそのままの規模で分析しています。

金築：今のお話は、とても腑に落ちました。ノードがどのようにスケールアップし、データがどのように分散されるのか。その仕組みを理解すると、ClickHouseがペタバイト級のデータを扱い続けられる理由を、直感的に理解できますね。 

データベースの未来は、OLTPとOLAPの統合へ

Q. 先ほどAlexeyさんから、「ClickHouseではトランザクションデータと分析用データを分離する必要はない」というお話がありましたが、AI時代の大規模データ基盤では、今後両者は統合されていくのでしょうか。次世代データベースの展望について、二人の考えをお聞かせください。

金築：実は私は、事業の傍ら、データベースの産業での研究もしており、HTAPというアプローチについて研究しています。前職では大規模データ分析システムの運用に携わっていましたが、OLTPからOLAPにデータを送り込む際のレイテンシ管理に悩まされていました。そこで、データ統合の作業そのものを不要にするHTAPのアプローチに強い関心を持ち、研究を始めました。今年の3月には、EDBT/ICDT(ヨーロッパで最も有名なデータベースカンファレンスのうちの一つ)併設のDOLAPでも論文発表をしました。

※HTAP：トランザクション処理（OLTP）と分析処理（OLAP）を単一のプラットフォーム上で実行する技術

HTAPの現在の課題はデータ同期です。内部的には、OLTPに書き込んだデータをOLAPへ転送する処理が行われていますが、高コストな処理で、データフローの維持が難しいという問題があります。書き込んだデータをすぐ分析したいのに、クエリのレイテンシが1時間もかかれば、結局最新の状況は把握できません。

Alexey：HTAPデータベースを作ろうとすると課題になるのが、それぞれのワークロードに求められる内部データ構造が根本的に異なることです。OLAPのデータベースには、高速処理を実現するためのカラム指向ストレージと、圧縮ブロック上の疎なインデックスが必要です。しかし、このデータ構造では、単一レコードを効率的に読み取ったり更新したりすることは困難です。一方、OLTPのデータベースには、各レコードに対する細かなインデックスと、レコードを素早く置き換えられるデータ構造が必要になります。

そこで、2つのアプローチがあります。1つは、単一のデータ構造の中で妥協点を見つけるアプローチです。インメモリデータベースがその代表例ですが、実際にはあまり成功していません。大規模なデータを扱う場合、統合されたデータ構造は分析処理にあまり適しておらず、データがメモリに収まらなくなった時点で破綻してしまうためです。

もう1つは、2つの異なるデータ構造を高速に同期する方法です。現在はこちらのほうが、より一般的な方法です。ClickHouse Cloudでも、このアプローチを採用しています。具体的には、ClickHouseとClickHouse Postgresを高速NVMeストレージ上で提供し、両者を同期しています。これにより、Postgres上のデータを妥当なレイテンシでClickHouseから扱えるようにしています。

金築：Incident LakeでもPostgresとClickHouseを併用しています。現在は、両者の同期をしているわけではありませんが、私たちとしては、できるだけ多くのデータをClickHouseに統合していきたいと考えています。IDのユニークインデックスや、SQLの互換性などがネックになっているのですが、今後の開発の予定はありますか。

Alexey：答えはイエスで、すでに開発中です。またSQLの互換性についても、既にSQL Logic Testでテストすると、97%以上の互換性が得られるなど、標準SQLの機能を十分にサポートしています。

AI時代のデータ基盤に必要なもの

ここまでの対談を通じて見えてきたのは、SIGQがClickHouseへ移行した理由が、単なるコスト削減ではないということです。より本質的な動機は、AI時代のインシデント管理に求められるデータ基盤要件を満たすこと、そしてその要件がClickHouseの歴史と技術的特性に深く一致していたことにあります。

後編では、このデータ基盤の上でAI時代のインシデント管理やSREのあり方がどう変わっていくのかを掘り下げます。