CI/CD 向けの Lakebase ブランチ機能：100個の PR データベースから得られた教訓

課題: 本番データに対するテストに30分以上かけるべきではない

Snorkel AIは、AIチーム向けにデータ開発ツールを構築しており、熟練したデータアノテーターや最先端モデルのプロバイダーに利用されています。この特定のユースケースでは、SnorkelはKubernetes上に構築されたCIパイプラインを通じてコードをリリースしています。すべてのオープンなプルリクエスト（PR）とアドホックなコミットには、それぞれ独立した一時的なKubernetes名前空間（「PR名前空間」）が割り当てられます。開発者はそのブランチにコードをデプロイし、マージ前に完全なテストスイートを実行します。

これらのテストは、実際のデータに対して実行されるときに最も価値を発揮します。Snorkelの本番データベースは、Amazon Aurora PostgreSQLクラスターです。各PR名前空間にそのデータベースのコピーを個別に用意することが、困難な点でした。コピーの復元には環境あたり約20分かかっていましたが、開発者が一日に何度もPRを作成し、マージキューが実行ごとに新しい環境を必要とする状況では、この処理速度では遅すぎます。代替手段（共有ステージングデータベース、トリミングされたフィクスチャ、または合成データ）を採用すると、本番環境に近いテストが解決しようとしている問題が再び発生してしまいます。例えば、テスト同士の干渉、古いスキーマ、実際のデータの形状でのみ現れるバグなどです。

成功基準

Snorkelは、Lakebaseが次の基準を満たしている場合に、CI/CDにおいて成功したとみなします。

• 迅速なプロビジョニング: 新しいPRブランチが60秒未満（p95）で準備完了する。
• スケール: ピーク時には約100の同時PRブランチをサポートし、それぞれが独立した読み取りと書き込みを行う。
• 互換性: 既存のアプリケーションとCIスイートが標準のPostgresを介してLakebase上で実行され、パフォーマンスはAuroraと同等で、大規模なJSONB/LOB列をサポートする。
• 最新データ: 継続的なDMSレプリケーションにより、メインブランチが本番のAuroraから約2分以内の遅延に保たれる。
• セキュリティ: 本番データはプライベートネットワーク上に保持され、パブリックインターネットを横断せず、開発者はOkta SSOでサインインし、CIパイプラインはサービスプリンシパルとして認証を行う。

データベースのブランチ機能がCI/CDに適している理由

Lakebaseは、DatabricksのサーバーレスPostgresデータベースです。ストレージとコンピュートが分離されており、ブランチ機能をサポートしています。Gitブランチを作成するのと同じように、どの時点からでもデータベースの新しい、独立した、書き込み可能なブランチを作成できます。

ブランチはコピーオンライト（Copy-on-Write）方式です。ブランチの作成はメタデータの操作であるため、ブランチ作成時にデータがコピーされることはありません。新しいブランチは親とストレージページを共有し、ブランチによって変更されたページのみが新しいストレージとして書き込まれます。CIにおいて、これは次のようなメリットをもたらします。

• ブランチの作成に数分ではなく数秒しかかからない。 データベースのサイズに依存しません。
• データベースのサイズではなく、各ブランチが行った変更の量に応じてストレージが増加する。 Snorkelの各PRブランチは、約1 TBのベースに対して約5〜10 GBの変更を書き込みます。
• コンピュートはブランチごとに提供され、ゼロにスケーリングする。 各ブランチには独自の自動スケーリングコンピュートがあり、CIの実行間にはゼロにスケールダウンします。100のプロビジョニングされたブランチがある場合でも、Snorkelでは同時にトラフィックを処理するのは約20〜30程度であり、ピーク時にはそれぞれ秒間約5クエリを見込んでいます。

アーキテクチャ

1. メインブランチに本番の最新コピーを維持する。 Lakebaseは標準のPostgresであるため、カスタムツールなしでAWS DMSのターゲットとして機能します。SnorkelはDMSタスクを本番のAuroraデータベースに向け、Lakebaseプロジェクトのメインブランチにレプリケートします。まずフルロードを行い、その後継続的な変更データキャプチャ（CDC）を実行して、メインブランチを本番から約2分以内に維持します。フルLOBモードにより、10〜20 MBのJSONB値が引き継がれます。チームはすでにDMSを実行しているため、新しく構築または維持すべきレプリケーションパイプラインはありませんでした。メインブランチは、すべてのPRブランチの起点となる「ゴールデンコピー」です。

2. PRのオープン時にブランチを作成する。 開発者がPRを開くと、CIパイプラインがLakebase APIを呼び出してメインからブランチを作成し、有効期限を設定して、そのブランチの接続情報をPR名前空間に渡します。ブランチは1分以内に準備完了します。

3. 実データに対してテストを実行する。 PR名前空間内のアプリケーションは、標準のPostgresを介して自身のブランチに接続します。テストでは、本番環境、メインブランチ、または他のPRに影響を与えることなく、マイグレーションの実行、データの書き込み、スキーマの変更を行うことができます。

4. PRのクローズ時またはテストの合格時にブランチを削除し、セーフティネットとしてTTLを使用する。 PRがマージまたはクローズされると、パイプラインはブランチを削除します。そのクリーンアップステップが実行されなかった場合でも、TTL（生存時間）が切れるとブランチは自動的に期限切れになります。

セキュリティ: プライベートネットワーキングと、人間およびパイプラインのためのアイデンティティ

2つのセキュリティ要件により他の選択肢が除外されたため、ここで個別に説明します。

プライベート接続。 本番データはAuroraからLakebaseへ、そしてLakebaseからCIクラスターへと、パブリックインターネットではなくプライベートネットワークを介して移動します。

アイデンティティ。 Snorkelには2種類のデータベースユーザーがいます。PR環境をデバッグするためにインタラクティブに接続する開発者と、人間が介在せずに実行されるCIパイプラインです。Okta SSOはインタラクティブなブラウザログインを前提に設計されているため、ユーザータイプごとに設計を分割しています。

• 開発者: OktaはDatabricksアカウントとフェデレーションされ、ユーザーはSCIMを通じてプロビジョニングされます。開発者は通常のOktaアイデンティティでサインインします。
• CIパイプライン: 各PR名前空間は、Databricksのサービスプリンシパル（チームごとまたはリポジトリごとにスコープ設定）として実行され、これもSCIMを通じてプロビジョニングされます。PRポッドは、サービスプリンシパルの認証情報を使用してDatabricks SDK経由で短命なLakebase OAuthトークンを取得し、長時間のテスト実行中にそれを更新します。CI内に長期的なデータベースパスワードは存在しません。
• 監査: Postgresの監査ログには、各クエリに対するサービスプリンシパルのアイデンティティが記録されるため、すべてのクエリを実行したパイプラインまで追跡できます。

コピーオンライトとブランチの有効期限がCIの高速化とコスト削減をもたらす理由

このパターンを大規模に機能させるのは、コピーオンライトによるブランチ機能とブランチの有効期限（TTL）という2つのLakebaseの機能です。

コピーオンライトによりブランチが瞬時に作成される。 新しいブランチはデータを一切コピーしません。親の既存のストレージページを指し示し、ブランチによって変更されたページのみが新しいストレージとして書き込まれます。約1 TBの本番コピーからのブランチ作成は、1 GBのデータベースからの作成とほぼ同じ時間（数分ではなく数秒）で完了します。フルリストアに要していた約20分の待ち時間はありません。各PR名前空間は、本番環境の独立した書き込み可能なコピーを即座に取得できます。

コピーオンライトによりコストが削減される。 すべてのブランチがメインとデータの大部分を共有するため、ストレージはデータベースのサイズではなく、各ブランチが行った変更の量に応じて増加します。Snorkelの場合、共有ベースに加えて各PRブランチあたり約5〜10 GBとなります。コンピュートはブランチごとに提供され、アイドル時にはゼロにスケーリングするため、実際にテストを実行しているブランチのみがコンピュートを使用します。

ブランチの有効期限により、長期的なコストが抑えられる。 コピーオンライトは、ブランチの生存期間が短い場合に最大の効果を発揮します。ブランチは、作成時に存在していたデータのバージョンを保持します。DMSが本番の変更でメインを更新し続ける一方で、長期間存続するブランチは古いページを保持し続けるため、使用するストレージは時間の経過とともに増加します。すべてのCIブランチにTTLを設定することで、PRの完了時に各ブランチが自動的に削除されます。これにより、ストレージの容量を本番ベースのサイズとアクティブなPRからの変更分の合計に近づけることができます。

このパターンはAIエージェントでも機能します。

PR名前空間だけが、本番環境の使い捨てコピーを必要とするワークロードではありません。SQLの記述、マイグレーションの実行、データの変更を行うAIエージェントも、安全に試行錯誤できる場所を必要としており、コピーオンライトのブランチ機能がそれを実現します。

エージェントのタスクごとに1つのブランチ。 各エージェントの実行には、メインの独自のブランチが割り当てられます。エージェントは、本番環境や他のエージェントの作業に影響を与えることなく、実際のデータの読み取り、書き込み、さらにはスキーマの変更まで行うことができます。データベースのサイズに関係なくブランチ作成は数秒で完了するため、タスクごとに作成することが現実的です。

多数のエージェントの並行実行。 ストレージは各ブランチが変更したページ分のみ増加し、各ブランチのコンピュートはアイドル時にゼロにスケーリングします。数十のエージェントを並行して実行しても、データベースのコピーを数十個作成するコストではなく、それらのエージェントが行った変更分のコストと同等に抑えられます。

変更のレビュー、または破棄。 チームは、本番環境に適用する前に、エージェントがブランチ上で何を変更したかを確認できます。結果が正しくない場合はブランチを削除するだけでよく、ロールバックの必要もありません。

TTL でエージェントの後片付けを自動化します。 エージェントは短命なブランチを大量に作成することがあります。各ブランチに有効期限を設定することで、CI のブランチと同じように、使われなくなったブランチを自動的に削除できます。

エージェント用のスコープ付きアイデンティティ。 CI パイプラインと同様に、エージェントは短命な OAuth トークンを持つサービスプリンシパルとして実行できるため、エージェントが実行するすべてのクエリを監査ログで追跡できます。

結果

• プロビジョニング時間: 従来は 30 分以上かかっていましたが、Lakebase を使用することで 60 秒未満になりました ([VERIFY p95 measured])
• スケール: 約 2.5 TB の本番データセットに対して約 100 件の同時 PR ブランチを処理できるように設計されています
• 互換性: CI スイートは Lakebase に対して実行され、「大きな互換性の問題はなく」、Aurora と同等のパフォーマンスを発揮します
• 導入: 複数のチームにまたがる 60 〜 70 人の開発者への展開
• 開発者のコメント: 「以前はデータを物理的にコピーする必要があり、そのコピー処理に何時間もかかっていました。また、さまざまな CI プラットフォーム (GitHub Actions、CircleCI など) でネットワークやその他のボトルネックが頻繁に発生していました。データが VPC 外に出る場合でも、セキュリティとコンプライアンスの要件を満たせるソリューションを探していました」

CI/CD での Lakebase ブランチングのベストプラクティス

1. 継続的に同期されるメインブランチから作成された、PR ごとに 1 つのブランチ。
2. 常に TTL を設定する。 有効期限は任意ではなく必須として扱います。PR やテストの通常の実行期間に合わせます。
3. 古いブランチを維持するのではなく、新しいブランチを作成する。 PR により新しいデータが必要な場合は、メインから新しいブランチを作成します。数秒で完了します。
4. コンピュートをゼロまでスケールさせる。 プロビジョニングされたブランチのほとんどは、どの時点でもアイドル状態です。
5. パイプラインにはサービスプリンシパルと短命な OAuth トークンを使用し、ユーザーには SSO を使用します。
6. ブランチごとのストレージを監視し、長期間残っているブランチを早期に検出します。

すべてのプルリクエストに本番環境同等のデータベースを用意する準備はできましたか？ Lakebase の使い方の確認に進み、ブランチングドキュメントを読んで CI パイプラインでブランチの有効期限を設定してください。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事