制限よ、さようなら。データよ、こんにちは。Qontoが ClickHouse Cloud でオブザーバビリティを再構築する方法

Qonto は、ヨーロッパ8か国で60万を超える中小企業やフリーランサーにサービスを提供するデジタルバンクです。決済の失敗、請求書が通らない、アカウントにアクセスできない――こうしたトラブルが起これば、その影響は即座に顧客に及びます。

QontoのSRE Observability担当テックリードであるJavier Ortiz氏にとって、これこそがツール選定の判断を左右する重大な前提です。「一秒一秒が勝負です」と、2026年2月にパリで開催されたClickHouseミートアップで氏は語りました。「インシデントの原因により早くたどり着き、何が起きたのかを正確に理解して、学び、再発を防ぐ――そのために多大な労力を投じています」

私たちはJavier氏に話を聞き、QontoのClickHouseへの道のり、つまりなぜ以前のシステムでは不十分だったのか、ClickHouse Cloud を選んだ決め手は何か、そしてそれがチーム全体のオブザーバビリティに対する考え方をどのように根本から変えたのかを掘り下げました。

より優れたデータベースの必要性 #

ClickHouseを導入する前、Qontoのオブザーバビリティチームはログとメトリクスについてはしっかりとした基盤を持っていました。問題はトレースだったとJavier氏は言います。「トレースに大きな価値を見出していて、ファーストクラスの存在として扱いたかったのです」と振り返ります。「しかし、より負荷をかけたり、wide events（広い構造化イベント）に踏み込もうとしたとき、以前のシステムでは限界に突き当たりました」

Grafana Tempoを中心とした構成では、集計やクエリが非常に遅く、システムから適切なインサイトを得られませんでした。トレースからオンザフライでメトリクスを生成することは苦痛であり、チームは事実上それを試みることすらしませんでした。「いつもこのゲームをしなければなりませんでした」とJavier氏は振り返ります。「データの取得は2〜3時間だけ。それより長くするとクラッシュしてしまう。常にシステムを守ろうとしていました。唯一の選択肢は積極的にサンプリングすることでしたが、それは多くの情報を失うことを意味しました」

チームはサービス概要のダッシュボードが欲しかった。意味のある時間範囲でP95レイテンシをクエリしたかった。データを収集する前に捨ててしまうことをやめたかった。しかし、既存の構成では何ひとつ実現できませんでした。Javier氏の言葉を借りれば、「私たちが描いていた夢、トレースの上に積み上げたかったすべてのユースケース……どれも実現できなかったのです」

そこでチームはより良い選択肢を探し始めました。Honeycombは理論的には魅力的でしたが、実運用ではコストが高くつきました。SigNoz（ClickHouseの上で動作する）は求めるものに近かったものの、チームは自分たちでスキーマを管理し、クエリインターフェースとしてGrafanaを使い続けたいと考えていました。

その後Javier氏は、HoneycombのCo-founder兼CTOであるCharity Majors氏の投稿に興味を抱きました。彼女は、3本柱モデルを置き換え、ClickHouseのようなカラム型ストレージエンジンに格納されたwide structured eventsを単一の真実の情報源とする、いわゆる Observability 2.0 について書いていました。「あれが私たちの目を引きました」とJavier氏は語ります。

チームはClickHouse Cloudにサインアップし、PoC（概念実証）を実施しました。Javier氏によれば、それは事実上止まることなく走り続けています。「クラウドをセットアップしたら、Kubernetesオペレーターや容量計画に対処する必要はありませんでした」と氏は言います。「すべてがただ動いていました」

メトリクスからClickHouseのwide eventsへ #

そこから始まったのは、戦略的な方向転換というよりは、徐々に開けていく気づきでした。チームは自問しました。「ClickHouseでまる1日分のトレースデータをクエリできるか?」できました。続いてウィンドウを2週間に拡大しました。そして、これまで構築できなかったサービス概要ダッシュボードを作り始めました。

新しい機能が解放されるたびに、当初の要件リストには載っていなかったユースケースが新たに開かれ、そして新たなユースケースが増えるたびに、古いメンタルモデル（ログ、メトリクス、トレース）は外せる足場のように感じられるようになっていきました。Javier氏はこれを「好循環」だと表現します。「ClickHouseを掘り下げれば掘り下げるほど、これまで考慮していなかったユースケースが見つかり、それが要件になっていきました」

最良の例がカーディナリティです。Prometheusの世界では、カーディナリティは慎重かつ防御的に管理すべき制約でした。ラベルは高コスト。チームは後で必要になるかもしれない次元すら、保存するコストに見合わないという理由でドロップするよう求められました。

Javier氏はチームリードとして、これを取り締まることに少なからぬ時間を費やしてきました。エンジニアに対して特定のラベルを追加しないように伝える――もしインシデントで予期せぬ問いが浮上したとき、それに答えるデータが存在しないかもしれないと知りつつ。「インシデントが起きて、システムに対して投げかける必要があるとは思ってもみなかった問いを投げかける必要が出てくるんです」と氏は言います。「そして、データがそこにない」

ClickHouseはカーディナリティを安価にしました。たとえばQontoのResourceAttributesとSpanAttributesのカラム（トレースを生成するすべてのサービス、Pod、クラスタ、ライブラリバージョン、デプロイメントに関するあらゆるメタデータ）は、231 TBの非圧縮データをわずか376 GBに格納しています。これは定義上ほぼ高カーディナリティであるデータに対して、99.84%の圧縮率です。S3ストレージの節約だけで年間およそ7万ドルの削減になります。

「コスト削減だけではありません」とJavier氏は付け加えます。「オブザーバビリティの担当者にとって、カーディナリティは恐ろしい言葉でした。今では私が積極的に応援する対象になっています」。現在では、エンジニアがスパンにもっと属性を追加すべきか尋ねてきても、氏はためらいません。「はい、すべて追加してください」と伝えます。「コストはかかりませんし、システムは処理できます。そうすれば本当に賢い質問を投げかけ、本物の答えを得られるようになります」

QontoのClickHouseベースのアーキテクチャ #

新しい構成では、Qontoのスタック全体（アプリケーション、フロントエンド、Kubernetesインフラ、GitHub）から流れてくるデータはOpenTelemetryコレクターに集まり、コレクターはAWS PrivateLinkを介してすべてをClickHouse Cloudに送出します。コレクターの観点からはClickHouseはローカルに見えるため、大量のテレメトリデータをネットワーク境界をまたいで移動させる際のレイテンシや転送コストを排除できます。Grafanaはダッシュボードや従来型のオブザーバビリティワークフローのプライマリインターフェースとして使われています。

アプリケーション、フロントエンド、Kubernetes、GitHubからのデータが、OpenTelemetryコレクターを経由してAWS PrivateLink経由でClickHouse Cloudへ流れ、Grafanaがダッシュボードと可視化を担う構成。

ClickHouseがQontoの新しいオブザーバビリティレシピの第一の材料（Javier氏言うところの「エンジン」）だったとすれば、第二の材料がOpenTelemetryで、これがセマンティクスを提供しました。OTelは広く採用された標準であるため、そのフィールド名や構造はLLMにとって馴染みのあるものです。つまり、エンジニアはAIに対してスキーマを説明したり、データディクショナリを保守するためにトークンを消費する必要がありません。データはすでに「読み取れる」状態になっているのです。

ClickHouse MCPによるAIパワード・オブザーバビリティ #

なんでも処理できるデータベースと、AIが理解できるセマンティック層が揃ったところで、第三のステップは、Javier氏が「インシデント・コンパニオン」と呼ぶものを構築することでした。これにより、Qontoの誰もが平易な英語でインシデントを調査したり質問したりして、データに裏付けられた本物の答えを得られるようになります。

その中核にあるのが ClickHouse MCPサーバー で、Qontoはこれに薄いセキュリティレイヤーを重ねて使っており、特定のインスタンスへの読み取り専用アクセスを強制しています。そのレイヤーはおよそ30行のPythonコードです。MCPはClaudeクライアントや会話型UIなど、さまざまなクライアントを通じてアクセスされます。Dust.ttを使った例では、画面を左右に分割し、左に自然言語の会話、右にはエージェントが何をしているかが完全に透過的に表示されます。推論、実行中のSQLクエリ、扱っている結果が見えます。エンジニアはどのクエリも検査でき、必要であれば手動で引き継ぐこともできます。エージェントは常にトレースIDを表示するため、調査結果はGrafanaで直接検証できます。

Qontoが構築したAIインシデント・コンパニオンの実動の様子。左に平易な言葉での入力、右にエージェントの推論とClickHouse MCPクエリが表示される。

パリでのミートアップでJavier氏は、システムが動作する実例を示しました。わずか1分半足らずで、エージェントは短い自然言語の入力とタイムスタンプを解釈し、アプローチを計画し、ClickHouse MCPサーバー経由でクエリを実行し、リクエストのタイムアウトを根本原因として特定する構造化された調査サマリーを返したのです。

インシデント対応が高速になっただけではありません。スコープを絞り込むプロセスもはるかに簡単になりました。以前はエンジニアリングの労力と専門知識を要した作業（どの顧客が影響を受けたか、どの国か、どのアカウントタイプか）が、今では誰もがタイプして尋ねられる質問になっています。Javier氏はある事例を振り返ります。チームは問題の影響を受けた顧客を正確に特定でき、全員に一斉通知するのではなく、対象者だけにターゲットを絞ったコミュニケーションを送ることができました。「このシステムが、SREの枠を超えるものをどう可能にしてくれるかが分かるでしょう」と氏は言います。

QontoのAIインシデント・コンパニオンが支える、リアクティブ・ビジネス・プロアクティブの各ユースケースの一部。

民主化という目標は当初から明確でした。あるコンポーネントを構築したエンジニア本人でなければ、それに関するインシデントを調査できない――そんな状況であってはならない、ということです。「誰もがどんなインシデントも解決できるべきです」とJavier氏は言います。Qontoにとって、現実は当初の目標すら超えるものになりました。プロダクトチームも同じデータをクエリして、機能の採用状況やユーザーの行動を理解しています。かつての障壁がクエリ構文やスキーマの知識だったとすれば、今やそれはただ「価値ある問いを持っているか」だけになりました。

QontoとClickHouseの次のステップ #

Qontoのオブザーバビリティの物語はまだ終わっていません。Javier氏にとって、それこそが要点です。「今はすべてが少し曖昧で、私たちはまさにそこにいたいのです」と氏は言います。オブザーバビリティをデータの問題として扱うことで、チームが今もくぐり抜けつつあるドアが開かれたのです。

進行中の取り組みのひとつが、Qontoのデータエンジニアリングチームとのコラボレーションです。以前は、オブザーバビリティチームとデータチームは十分にサイロ化されており、データチームのApache Flinkに関する専門知識がオブザーバビリティの世界に渡ってくることはありませんでした。しかし、オブザーバビリティデータがClickHouseに住まうようになったことで、対話が可能になりました。両チームは今、リアルタイム事前集計のパイプラインを模索しており、Flinkでローリングウィンドウ上のP95メトリクスを計算し、結果をClickHouseに戻し入れることを試みています。「システムが『トレース、メトリクス、ログ』ではなく、ただの『データ』になったことで、データチームの同僚たちの専門知識を活用できるようになりました」とJavier氏は語ります。

Qontoはまた、ログストレージの統合（現在は低コストストアとElasticsearchに分散）をClickHouseで進めることも検討しており、ClickHouseの統合オブザーバビリティスタックである ClickStack も試行しています。「ClickHouseは非常に良いプレイグラウンドです。誰もが自由に試せるようにドアを開けっぱなしにしておけますから。以前のシステムでは、これを守る必要があり、長くて複雑なクエリは投げないでくれと頼まなければなりませんでした」とJavier氏は語ります。「これによって学習体験が完全に変わるのです」

通底するテーマはシンプルです。インフラを「守る」ことをやめ、その上に「築く」ことを始める、ということです。データベースが制約でなくなった瞬間から、チームはその管理者であることをやめ、ユーザーとなり、ロードマップには絶対に載らなかったであろうユースケースを次々と発見するようになりました。

「私が一番誇りに思っていることは、3本柱について考えるのをやめて、wide eventsについて考え始めるという決断です」とJavier氏は語ります。「そのためには、それを支える技術的基盤が必要で、オブザーバビリティのサイロを打ち破る必要があります。ClickHouseに出会えたこと、そしてまさに同じタイミングでAIが整っていたこと――私たちはとても幸運でした」