Databricks、CI/CDテスト向けLakebaseブランチング機能の詳細を発表
Databricksは、自社のLakebase Postgresデータベースが備えるコピーオンライト方式のブランチング機能により、顧客であるSnorkel AIのCI/CDにおけるデータベースプロビジョニング時間を30分以上から60秒未満に短縮したと発表した。
ひとことで言うと
DatabricksはCI/CD向けのLakebaseデータベースブランチング機能について何を発表しましたか。
Databricksによると、同社のサーバーレスPostgresデータベース「Lakebase」はコピーオンライト方式のブランチ機能を採用しており、CI/CDのプルリクエストごとに本番データの独立した書き込み可能なコピーを60秒以内で作成できるという。従来の30分超という時間を大幅に短縮した形だ。顧客であるSnorkel AIの事例では、約2.5テラバイトのデータセットに対して同時に約100のブランチを運用している。
要点
- Databricksによれば、Lakebaseのコピーオンライト分岐機能により、顧客企業のSnorkel AIはCI/CDのプルリクエスト用データベースのプロビジョニング時間を、従来の30分超から60秒未満へと短縮できたという。
- 同ブログ記事によると、Snorkel AIは約2.5テラバイトの本番データセットに対し、プルリクエストのブランチを同時に約100本運用しているが、各ブランチが自身の変更のために追加するストレージはわずか5〜10ギガバイトにとどまるという。
- Databricksによると、各ブランチではプライベートネットワーキング、開発者向けのOkta単一サインオン、サービスプリンシパルとして動作するCIパイプライン向けの短期OAuthトークンによって、本番データの安全性を確保しているという。
- ブランチ有効期限設定により、不要になったプルリクエストのブランチは自動的に削除される。Databricksによれば、これによりストレージコストを本番環境と稼働中のブランチの合計に近い規模に抑えられるという。
- Databricksによれば、同じブランチ方式を用いることで、個々のAIエージェントのタスクに専用の、使い捨て可能なデータベースの複製を割り当てることができるという。
問題の背景
AIチーム向けのデータ開発ツールを手がけるSnorkel AIは、Kubernetes上でCI/CDパイプラインを運用しており、開かれたプルリクエストごとに一時的な名前空間を割り当ててテストを行っている。Databricksによると、Snorkelは本番データベースであるAmazon Aurora PostgreSQLクラスターの実データを使ってコードをテストしたいと考えていたが、データベース全体の復元には環境ごとに約20分かかっていた。Databricksは、開発者が一日中プルリクエストを開き続けるワークフローにはこれでは遅すぎると指摘する。そのため、Snorkelはこれまでプルリクエストごとに専用のデータベースコピーを用意することができなかった。
Lakebaseのブランチ機能による解決策
Databricksによれば、同社のサーバーレスPostgresデータベースであるLakebaseを使うことで、Snorkelは任意の時点からデータベースの独立した書き込み可能なブランチを、Gitのブランチのような形で作成できるようになった。Databricksはこれらのブランチを「コピーオンライト」方式と説明しており、新しいブランチは作成時にデータをコピーしない。代わりに親ブランチとストレージページを共有し、ブランチ側で変更が加えられたページだけが新たなストレージとして書き込まれる。同社のブログ記事によると、SnorkelはAWS Database Migration Serviceを使ってAuroraの本番データベースをLakebaseの「main」ブランチへ複製し、継続的な変更データキャプチャによって本番環境とのずれを約2分以内に保っている。Databricksによれば、Snorkelのパイプラインはプルリクエストが開かれるたびにLakebase APIを呼び出してmainから新しいブランチを作成し、有効期限を設定し、プルリクエストが閉じられると削除する仕組みになっている。この削除処理が実行されなかった場合でも、設定されたTTL(生存期間)が切れた時点でブランチは自動的に失効するという。
セキュリティ対策
Databricksによると、本番データはAurora、Lakebase、SnorkelのCIクラスターの間をパブリックインターネットではなくプライベートネットワーク経由で移動する。同社によれば、Snorkelの開発者はDatabricksアカウントに連携されたOkta シングルサインオンを通じて認証を行い、CIパイプラインはDatabricksのサービスプリンシパルとして動作し、Databricks SDKを通じて短期間有効なOAuthトークンを取得する。Databricksは、Postgresの監査ログがすべてのクエリの背後にあるサービスプリンシパルのIDを記録しているため、各クエリをそれを実行したパイプラインまで追跡できると説明している。
Databricksが報告した成果
Databricksによると、Lakebaseのブランチ機能を導入したことで、Snorkelのデータベース準備時間は30分以上から60秒未満に短縮された。また、このシステムは約2.5テラバイトの本番データセットに対して、約100件の並行プルリクエストブランチをサポートできるよう設計されているという。ブログ記事によれば、各プルリクエストブランチは共有ベースの上に約5〜10ギガバイトの変更を書き込み、Snorkelはこのシステムを各チームの60〜70人の開発者に展開した。Databricksは匿名のSnorkel開発者の発言を引用し、以前のデータコピー作業は「数時間かかり、さまざまなCIプラットフォームでネットワークその他のボトルネックにしばしば行き当たっていた」とし、チームにはバーチャルプライベートクラウドから外に出るデータに関するセキュリティとコンプライアンスの要件を満たすソリューションが必要だったと述べている。
CI/CD以外での活用
Databricksによると、同じブランチ方式はSQLを書いたり、マイグレーションを実行したり、データを変更したりするAIエージェントにも適用できる。各エージェントタスクにメインデータベースの専用ブランチを割り当てることで、本番環境や他のエージェントの作業に影響を与えずにデータを読み書きできるという。同社は、エージェントも短期間有効なOAuthトークンを持つサービスプリンシパルとして動作できるとし、エージェントによる変更が望ましくない場合はブランチをレビューして削除することも、有効期限の設定によって自動的に片付けることもできるとしている。
出典:Databricksブログ「Lakebase branching for CI/CD: lessons from 100 PR databases」、2026年10月31日公開。
よくある質問
- Lakebaseのブランチ機能とは何か
- Databricksによると、Lakebaseのブランチ機能を使えば、コピーオンライト方式のストレージによって、Postgresデータベースの任意の時点における分離された書き込み可能なコピーを、Gitのブランチ作成のような感覚で作れるという。
- Snorkel AIはLakebaseのブランチ機能をどのように活用したのか。
- Databricksによると、Snorkel AIはCI/CDテストのため、オープンにされたプルリクエストごとに、本番環境のAurora PostgreSQLデータベースのLakebaseブランチを個別に用意している。これにより、従来は環境構築に1件あたり30分以上かかっていた作業が不要になった。
- Databricksは、Lakebaseのブランチ機能がどのようにコストを抑えると説明しているのか。
- Databricksによれば、コピーオンライト方式のストレージにより、ブランチは変更したデータ分のみ追加ストレージを消費し、各ブランチのコンピュートはアイドル時にゼロまでスケールダウンするという。
- Lakebaseのブランチ機能はCI/CD以外の用途でも使えますか。
- Databricksによると、同じブランチング手法はAIエージェントにも応用できるという。エージェントのタスクごとに使い捨てのデータベースブランチを割り当て、本番環境に影響を与えることなく読み書きやテストを行えるようにする仕組みだ。