要約
GitLabは、膨大なスケールに対応しながらサブ秒レベルのインサイトを提供できる、専門的な分析機能を必要としていました。そこで彼らは、製品分析プラットフォームをClickHouse上に構築するという選択をしました。
本記事では、初期のボトルネックや他のデータベース管理システムとのベンチマーク比較から、ClickHouse CloudやGitLab Dedicated、セルフマネージド環境でGitLab.com全体のインサイトを支える本格的な移行までの道のりを追います。
結果は明白です。かつて30〜40秒かかっていた1億行超のクエリが、今では1秒未満で返ってくるようになりました。ClickHouseは、Contribution AnalyticsやGitLab Duo、SDLCトレンドなどの重要な機能を支え、エンジニアリング成果やAI導入状況をリアルタイムで追跡できるようにしており、GitLabは全社の分析基盤をClickHouseに標準化しつつあります。
はじめに #
Dennis Tang は2018年からGitLabに在籍しており、当初はプラットフォーム機能を担当するエンジニアとしてキャリアをスタートし、その後Analyticsチームのリーダーに就任しました。現在はAnalyticsステージのシニアエンジニアリングマネージャーとして、インストルメンテーションから顧客向けインサイトに至るまで、分析ライフサイクル全体を担う複数のチームを統括しています。
GitLab社内では、プロダクト向けの分析と社内ビジネスインテリジェンスを区別しています。社内ワークフローは別グループが所管しており、Dennisのチームは 5,000万人の登録ユーザー に対してプラットフォーム全体で提供される分析機能の計装と提供にフォーカスしています。
GitLabが共有しているSaaSおよびオンプレミスのコードベースが進化するにつれて、リアルタイムでスケーラブルなユーザー向け分析への需要は急速に高まりました。歴史的に、GitLabは分析ワークロードとトランザクションワークロードの両方にPostgresを利用してきました。Postgresは後者で依然として優れていますが、チームはユーザーが求めるパフォーマンスとスケーラビリティを提供するには、分析ワークロードに最適化された専門技術が必要だと認識していました。
そこで登場したのがClickHouseです。PostgresとClickHouseはそれぞれの領域でリーダー的存在となり、強力なペアを形成しています。Postgresは信頼性と機能性で信頼される定番のトランザクションデータベースとして、ClickHouseはスケールを前提に構築された高性能リアルタイム分析エンジンとして、です。
本記事では、2022年から現在までのGitLabにおけるClickHouseの歩みを紹介します。実験として始まった取り組みは、すぐにプラットフォームの基盤の一部となりました。今日では、ClickHouseはGitLab.com上のContribution Analytics、GitLab Duo、SDLCトレンドレポートなど、重要なワークロードを支えています。これは、ClickHouseがサイドプロジェクトからGitLabにおける分析のデフォルトOLAPデータベースへと進化していった物語です。
増大する要求から新たな分析基盤へ #
GitLab.comは、セルフマネージド版と同一のソフトウェアで稼働しています。このアーキテクチャ上の決定は一貫性を確保しますが、同時にスタック上のあらゆる制約がすべてのユーザーに影響することを意味します。分析データのスケールは専用インフラを必要とし、特定機能向けの 専用シャード などの最適化を施したPostgresを使っても、多くのダッシュボードはGitLab社内のパフォーマンス基準である15秒に迫るところで停滞していました。それより遅いものはリリースされません。 その典型例がCIデータベースで、これはプラットフォーム全体の継続的インテグレーションに関するすべてのユーザーアクティビティを取り込みます。
Dennisと彼のチームは、ユーザー、特にハイブリッドなSaaS/オンプレミス環境のユーザーに対して高速でスケーラブルな分析を提供するためには、分析ワークロード専用に構築された新しい基盤が必要だと認識していました。
評価の中でClickHouseは際立った存在でした。単にベンチマークが速かっただけでなく、GitLabのアーキテクチャ原則とも合致していました。単一バイナリであるためどこでも動かせます。容易にスケールします。そしてオープンソースです。この組み合わせにより、ClickHouseがGitLabの分析を前進させる明確な選択肢となりました。
結果は明白です。かつて30〜40秒かかっていた1億行超のクエリが、今では1秒未満で返ってくるようになりました。
:::global-blog-cta:::
分析の選択肢を評価する #
Dennisが、GitLabの次の分析アーキテクチャを評価する社内ワーキンググループに加わった頃には、専門的な分析技術の必要性はすでに広く認識されていました。チームは、高いインジェスト速度、大量の履歴データ、そして高速で柔軟なクエリを、運用面の複雑さを増やすことなく扱える代替手段の検討を始めていました。
GitLabの評価は、固有の要件を満たすシステムを見つけることに重点を置きました。テストにおいて、ClickHouseはほぼすべての観点で他の選択肢を大幅に上回りました。
- インジェスト速度: ClickHouseはメトリクスを桁違いに高速にロードでき、GitLabの高スループット環境にとって極めて重要でした。
- ストレージフットプリント: 同じデータセットに対してClickHouseは約10分の1のディスク容量しか使用しませんでした。
- クエリレイテンシ: 95パーセンタイルでも、ClickHouseのクエリははるかに速く結果を返し、外れ値も少ない結果となりました。
チームには、水平スケール可能で、運用オーバーヘッドを最小化でき、クラウドとセルフマネージドの両方でシームレスに動作するシステムが必要でした。
ClickHouseは速いだけでなく、シンプルでもありました。Dennisはこう述べています。「必要ならノートPC上でも動かせるシステムが欲しかったのです。」
ClickHouseはカラム指向の分散データベースの力を単一バイナリで提供してくれました。オープンソースで、デプロイが容易で、GitLabの「サテライトサービス」モデル、つまり独立してスケールし、既存のアーキテクチャに自然に組み込まれる自己完結型コンポーネントの考え方と合致していました。そして決定的に重要だったのは、メトリクスだけでなく、ログやイベントなど、より幅広い観測性・分析データにも対応できる点でした。
このパフォーマンス、柔軟性、デプロイの移植性の組み合わせにより、ClickHouseは明確な選択肢となりました。GitLabは単にデータベースを探していたのではなく、プラットフォーム全体であらゆるスケールの高度な分析を支えるアーキテクチャ基盤に投資していたのです。
PoCから本番運用へ #
ClickHouseに焦点を当てた分析の取り組みは、単なるインフラのアップグレードではなく、プロダクト施策そのものでした。Dennisのチームには、GitLab内に統一された分析プラットフォームを構築し、顧客にスムーズなレポート機能と製品の使い方に関するインサイトを提供するというミッションが課されていました。目標は、ユーザーがワークフロー最適化の機会を見つけ、利用が深まるにつれて価値を引き出せるようにすることであり、それをGitLab顧客がすでに利用しているのと同じコードベースの中で実現することでした。ClickHouseは、すべての評価基準を満たした唯一の選択肢でした。 GitLabのData Insights Platform は、この取り組みの背後にあるアーキテクチャを示しています。
しかし、有望なベンチマークから本番運用に移るには、単にデータベースを差し替えるだけでは足りませんでした。GitLabは、ClickHouseがGitLab.comだけでなく、エンタープライズや政府機関の顧客が使用するセルフマネージドおよびエアギャップ環境でも動作することを保証する必要がありました。
スケールに対応した提供には、GitLab自身がデプロイの問題を解決する必要がありました。ClickHouse Cloudを採用する前、チームは独自の ClickHouseオペレータを構築・維持しており、これは現在もオープンソースとして公開されています。オブジェクトストレージで動作し水平スケール可能でしたが、運用上のオーバーヘッドは大きなものでした。本番環境での管理は容易ではなく、この経験がGitLabのその後のアプローチを形作りました。
得られた教訓は次のとおりです。
「本当に必要な場合を除いて、セルフマネージドはやめた方がいい。私たちは実際に独自のオペレータを構築し、ClickHouseをオブジェクトストレージ上で動かし、水平スケールできるようにしました。しかしそれは大きな運用負担でした。ほとんどのチームにとっては、環境を完全にコントロールしなければならない特別な事情がない限り、そのオーバーヘッドに見合いません。」
Dennis Tang, GitLab
ClickHouse Cloudは、はるかに少ない労力で同等のパフォーマンスを提供し、GitLabの開発を加速させました。エンジニアはローカルでプロトタイプを作成し、その後インフラを気にすることなくワークロードを本番にスケールできます。チームはハイブリッドモデルへの移行を始め、SaaS環境ではClickHouse Cloudを使用しつつ、エアギャップ環境やオンプレミス顧客向けにはOSS版のClickHouseを動かせる選択肢を保持しました。
ClickHouseによって、GitLabの分析スタックは変革を遂げつつあります。 Contribution Analytics のような機能は、データセットに対してサブ秒のパフォーマンスを実現するようになりました。この機能はチームのアクティビティや個人のパフォーマンスに関するインサイトを提供し、ワークロード分散、ハイパフォーマーやサポートが必要なメンバーの特定、コラボレーションパターンの評価、トレーニングニーズの発見、実データに基づくふりかえりの充実といったユースケースを支援します。これらのシナリオは理論上は以前から可能でしたが、運用負担を抑えながらスケールでも実用に耐えるかたちで実現できたのはClickHouseだけでした。
最近では、GitLabはClickHouseが支えるGitLab DuoとSDLCトレンドを有効化しました。これによりAIがソフトウェアデリバリーパフォーマンスにどのような影響を与えているかについて即時のインサイトを提供できます。このダッシュボードは、デプロイ頻度、変更のリードタイム、変更失敗率、サービス復旧時間といった従来のDORAメトリクスに加えて、Duoシートの導入状況、コードサジェスチョンの受け入れ率、Duo Chatの利用状況といったAI特有の指標も追跡します。AI導入とエンジニアリング成果を結びつけることで、GitLabはチームがGitLab Duoの価値を定量化し、ライセンス利用を最適化し、開発速度と信頼性に対するAIの実世界での影響をスケールで測定できるよう支援します。
「私たちはずっと、ユーザーが必要としていた分析機能を提供する能力を制限してきた、スケーリングとパフォーマンスのボトルネックに何度もぶつかってきました。ClickHouseは、これまで温めてきた機能を提供するために必要なブレークスルーをもたらしてくれました。」
Dennis Tang, GitLab
これらの改善は単なる漸進的なものではなく、機能を出荷するか棚上げするかを分けるほどのものでした。ClickHouseは、妥協なくGitLabの厳しいパフォーマンス基準を満たす能力を解放しました。その一例が、GitLabの深くネストしたデータモデル — 組織、グループ、サブグループ、プロジェクト、そしてそれぞれが持つissue、マージリクエスト、ユーザーといった共有ビジネスオブジェクト — を横断する 階層クエリです。この多層JOINはサブ秒でのパフォーマンスに最適化するのが難しく、Postgresでは1億行以上のデータに対してしばしば30〜40秒かかっていました。ClickHouseでは、同じクエリが0.24秒で実行できるようになり、運用上のボトルネックを実質的にリアルタイム機能へと変えました。
自信が深まるにつれ、チームは戦略的な転換を行いました。ClickHouseをすべてのGitLabデプロイメントにおける分析のデフォルトOLAPエンジンとし、PostgresはOLTPワークロードという本来の強みに集中し続けることにしたのです。
GitLab社内のベンチマークもこの転換の価値を裏付けました。あるPoCでは、チームは同一のクエリを比較し、大規模なチューニングなしに実行時間が分単位からミリ秒単位に短縮されることを確認しました。違いは単に目に見えるだけでなく、チームが何を出荷できるかを再定義するものでした。
ClickHouse CloudのSharedMergeTreeはこれをさらに推し進め、オブジェクトストレージの活用によってストレージとコンピュートを分離し、ほぼ無限のスケールを提供しながらこの性能を実現します。
全員にClickHouseを使えるようにする #
GitLab全体でのClickHouseのロールアウトは、単一の機能を有効にしたり単一のパフォーマンスボトルネックを解消したりすることだけが目的ではありませんでした。組織全体の力を引き出すことが目的だったのです。Dennisの長期的なビジョンはさらに野心的です。すなわち、ClickHouseを単に利用可能にするだけでなく、GitLab.com、GitLab Dedicated、セルフマネージドインスタンスを含むあらゆるGitLabデプロイメントにおける分析のデフォルトにすることです。
これを支えるために、GitLabはClickHouseの社内導入を極めて容易にすることに注力しました。設定さえ済めば、ClickHouseが支える機能は追加のセットアップなしで「ただ動く」状態になります。これはクラウドユーザーにもセルフマネージドユーザーにも当てはまります。
ハイブリッドなデータアクセス層が、データ範囲やユースケースに応じてクエリを既存のトランザクションデータベースまたはClickHouseに動的にルーティングします。この抽象化により既存機能のスムーズな移行が可能になり、ユーザー体験を維持しながら段階的にワークロードを移し替えていけます。
これらすべては、個別の成功にとどまらない意図的な取り組みを反映しています。GitLabはClickHouseをプラットフォーム全体の分析基盤として投資しているのです。目標は、すべての顧客に対して、GitLabをどのように、どこで動かしていても、高速でスケーラブルなインサイトを届けることです。
戦略的シフト #
GitLabにおいてパフォーマンス改善として始まったものは、スケール、柔軟性、そして分析プロダクトのあらゆる部分にわたるリアルタイムインサイトに焦点を当てた、ClickHouseベースの新しいアーキテクチャの基盤となりました。
そしてこの変革は今や、イベント駆動で分析を最優先とするプラットフォームへの広範な転換を推し進めています。GitLabは、プロダクトがどのように動作し進化するかという中核に、分析を組み込もうとしています。
ClickHouseの柔軟性は、このロールアウトを実現するうえで決定的でした。GitLabはインジェストにHTTP経由のTSVを使用しています。これは軽量なアプローチで、エンジニアは特別なツールなしに使い始めることができます。社内のCDCフレームワーク Siphon と組み合わせることで、GitLabは1時間あたり100ギガバイトを超える運用分析データをClickHouseにストリーミングする準備が整っています。HTTPエンドポイントと組み合わせれば、オンボーディングは非常にシンプルです。GitLabの分析フットプリントが拡大するにつれ、レジリエンスや運用性といったインフラ面の懸念がますます重要になりました。ClickHouse Cloudの自動スケーリング、マルチAZサポート、シームレスなバックアップなどの組み込み機能は、運用負荷を軽減しながらチームの動きを加速させてきました。最近の 「Make Before Break」 ポッドローテーションのような開発は、安定性とコスト効率の両面を向上させました。
このイベント駆動の戦略的シフトは、DORAダッシュボードであれ、プロダクト利用状況のチャートであれ、AI利用状況の監査であれ、あらゆる機能が一貫してスケーラブルで超高速な分析エンジンに支えられる未来を切り開きます。
ClickHouseを分析の標準とすることで、GitLabはエンジニアに対し、顧客が運用するどんな環境でもパフォーマンスを発揮し、スケールし、稼働することを確信して構築できるプラットフォームを提供しています。
学び #
GitLabは、ClickHouseをオブジェクトストレージ上で動かし水平スケールさせるための独自オペレータを構築しました。効果的ではあったものの、運用上のオーバーヘッドは相当なものでした。ほとんどのチームにとっては、ClickHouse Cloudがはるかに少ない複雑さで同等のパフォーマンスを提供し、エンジニアはインフラではなく機能に集中できるようになります。
運用上の成熟度も重要です。GitLabのデータは基本的にイミュータブルですが、削除や更新といったミューテーションは依然として慎重な検討を要します。例えば、大量削除が完了したかどうかを判断するのは常に明確とは限りません。ClickHouseはミューテーションをパートやブロック単位でバックグラウンドで処理します。システムテーブルやログを確認することによる現在のオブザーバビリティは機能はしますが、直感的とは言えません。「アクティブなミューテーション」専用のダッシュボードがあれば、GitLabにとって可視性が大きく向上するでしょう。
とはいえ、プロダクトの成熟は急速に進んでいます。GitLabにとって特に際立っていたのは、組み込みのバックアップ機能の追加です。チームはちょうど独自のバックアップツールを構築し始めていたところで、その機能がリリースされ、即座に時間と労力を節約でき、カスタムスクリプトの必要性をなくしてくれました。
パフォーマンス面では、マテリアライズドビューが定番の最適化ツールとなっています。GitLabには、特に大量データを集計する際に、いつどのように使うかについての社内ガイドラインがあります。辞書（Dictionary）やプロジェクションなどのより高度な機能はまだ本格的には利用していませんが、ロードマップには載っています。
総じて、ClickHouseは驚異的な速度と柔軟性を提供しますが、チームは依然として、データのモデリング、運用、分析アーキテクチャの進化のさせ方について慎重に考える必要があります。
これから #
GitLabが分析インフラのスケーリングを続ける中、チームは現在、より幅広いカバレッジ — より豊富なダッシュボード、より深いオブザーバビリティ、よりきめ細やかなプロダクト分析 — を模索しています。この転換により、GitLabはこれまでのスタックでは到底実現できなかったインサイトや機能を提供できるようになります。
例えば、AIエージェントは分析クエリに対して高速・低レイテンシのレスポンスを必要とし、しばしば大量のリクエストを生成します。これは従来のトランザクショナルデータベースでは効率的に対応できないワークロードパターンです。これらの要求に応えるには、ClickHouseのようなカラム指向のリアルタイムOLAPデータベースが必要です。GitLabが統合された分析機能をさらに発展させていくにつれ、これらの機能はプロダクト全体にわたるより深く、AIネイティブなインサイト生成への扉を開くことになります。
