コードのようにデータベースをブランチする：Glaspoortで本番稼働するLakebaseのCI/CDパターン

無視できない課題

Glaspoortはオランダでファイバー（光回線）インフラの構築と運営を行っています。すべてはファイバー接続数の拡大を中心に回っており、長い間、データチームはその目標をサポートするためにBIレポートの作成に日々を費やしていました。しかし、レポートが完成する頃には、そのレポートの背景にある問い自体がすでに時代遅れになっていました。その結果、単発のレポートが乱立し、ユーザーは追加の質問をどこに持っていけばよいかわからなくなっていました。

そこで、私たちはこの依存関係を断ち切りました。次のレポートを提供する代わりに、プロジェクトマネージャーが自分のプロジェクトの機会がどこにあるかを直接確認できるカスタムフロントエンドアプリケーションを構築しました。新しいのはその仕組み（内部）です。Databricks製品をアプリケーションのビルディングブロックとして直接使用しています。データとチャットして迅速な分析を行うためのGenie、インサイトとセルフサービス分析のためのAI/BIダッシュボード、プロジェクトで何か異常が発生した瞬間にプロジェクトマネージャーにアラートを送信するAgent Bricksによる自動化されたワークフロー、そしてアプリケーションのトランザクションデータのためのDatabricksのOLTPデータベースであるLakebaseです。

この組み合わせにより、最近まで切り離されていた2つの世界、すなわち分析環境と、分析データとトランザクションデータが交わる運用フロントエンドが統合されます。データチームは現在、単発のレポート作成ではなく、Genieスペースとメタデータに時間を費やしています。しかし、CI/CD、データ品質テスト、Infrastructure as Code、データガバナンスといった強固な基盤がなければ、このスピードを維持することはできません。その基盤の中で最も慎重な設計を必要としたのが、このストーリーの残りのテーマである「アプリケーションの背後にあるデータベースへの変更をどのようにデプロイするか」という部分です。

そのアプリケーションの背後には、Databricks Lakebaseデータベースがあります。これは、レイクハウスに後から無理やり継ぎ足したものではなく、その隣で動作するサーバーレスのPostgres OLTPです。データフローの説明は簡単ですが、実際に運用してみると、見た目以上に興味深いものであることがわかりました。

• レイクハウスからキュレーションされたデータがLakebaseの本番（production）ブランチに同期され、読み取り専用のアプリケーションスキーマに格納されます。
• アプリケーションは独自の状態を同じブランチの別のスキーマに書き戻すため、レイクハウスから読み取られたデータとアプリによって書き込まれたデータが衝突することなく共存します。
• その上で、開発（development）、受入（acceptance）、本番（production）の3つの論理環境を実行しています。アプリケーションコードへの変更をデプロイするのと同じように、プルリクエスト（PR）、CI、およびゲート付きプロモーションを通じて、このデータベースへの変更をデプロイします。

最後の点こそが、興味深い疑問が存在する場所です。OLTPデータベースにアプリケーションコードと同等の厳密さを持たせると決めた瞬間、1つの難しい問いに答えなければならなくなります。

メンバー同士が干渉し合うことなく、またテストを有意義なものにする最新データを失うことなく、すべてのPRを本番環境のようなデータベースに対してテストするにはどうすればよいでしょうか？

ここでの失敗パターンは、チームでデータベースを共有したことがある人なら誰でも聞き覚えがあるでしょう。単体ではパスするものの、一緒にマージされると壊れるPR。本番環境の実際の姿からいつの間にか乖離（ドリフト）してしまった開発環境や受入環境。そして、誰も望まない「リフレッシュの日」。クリーンなデータを取り戻すために環境を破棄し、すべての接続文字列を再設定し、すべての権限（grant）を手動で再適用しなければなりません。

この記事では、私たちがその大部分をどのように回避したか、そして現在も活発に議論している1つの決定について説明します。

60秒でわかるLakebaseのブランチ機能

Lakebaseのブランチ機能をまだ使ったことがない場合、この記事を読むために必要なメンタルモデルはこれだけです。

Lakebaseのブランチは、親ブランチから作成されたコピーオンライト（copy-on-write）のPostgresブランチです。ブランチを作成してもデータはコピーされません。低コストかつ瞬時に状態をフォークし、書き込みを行うときにのみ親ブランチから分岐します。各ブランチは完全に分離されており、独自のエンドポイントと独自のデータを持っています。数秒で作成でき、同じくらい素早く破棄できます。

Gitに似ていると思われるかもしれませんが、まさにそれが狙いです。以下にまとめるアナロジーはシンプルです。Gitのフィーチャーブランチは、Lakebaseのデータベースブランチに対応します。PRには独自のコードブランチと独自のデータベースブランチが割り当てられ、テストは両方に対して実行されます。作業が良好であれば、本番環境へとプロモートされます。

次のセクションに進む前に、Gitのブランチ機能との重要な違いである制約を1つ頭に入れておく必要があります。親からブランチをリセットするには、まずそのブランチ自身の子ブランチを削除する必要があります。親ブランチは、それに依存している子ブランチが存在する状態ではリセットできません。

親からのリセットの罠

ホワイトボードに環境図を描くときと同じように、ほとんどのチームが最初に思いつく設計は以下の通りです。

• 本番環境から分岐した、単一の長寿命な開発（development）ブランチ。
• 開発環境から分岐した受入（acceptance）ブランチ。
• 開発環境から分岐したフィーチャーブランチ。

ルートに本番環境があり、その下に開発環境、さらにその下に受入環境とフィーチャー環境がぶら下がる、すっきりとした階層構造です。しかし、これには予測可能な2つの失敗パターンも導入されます。ブランチが乖離（ドリフト）することと、その乖離の修正コストが高すぎるため、チームが修正を行わなくなってしまうことです。

まず、開発環境と受入環境が本番環境から乖離します。本番環境は常に同期された最新データと実際のアプリケーションの書き込みを受け取り続けますが、長寿命の開発ブランチや受入ブランチはそれを受け取りません。1〜2スプリントもすれば、デプロイ先とは似ても似つかないデータベースに対してテストを行うことになります。

明らかな解決策は開発環境を本番環境からリフレッシュすることですが、ここで前述の制約が「重荷」となります。開発環境をその親からリセットするには、まず開発環境の子ブランチを削除しなければなりません。このトポロジー（構成）では、受入環境と、開発環境にぶら下がっているすべてのフィーチャーブランチを意味します。そのため、日常的な「最新データを取得する」という作業が、受入環境とすべてのフィーチャーブランチの削除、開発環境のリセット、環境の再作成、古いブランチを指していたすべての接続文字列の再設定、そして削除されたブランチに紐づいていたすべてのPostgres権限（grant）の再適用、という連鎖的な作業へと変わってしまいます。

これらのステップは、単体ではどれも難しくありません。しかし、これが定期的に繰り返されると、チーム全体がリフレッシュを密かに避けるようになり、全員が古く乖離したデータに対してテストを行う状態に戻ってしまいます。それこそが元の問題でした。単純すぎるトポロジーは、午後の時間を無駄にするだけでなく、環境を健全に保つための習慣を損なうことになります。

Glaspoortの設計：常に本番環境からブランチを作成する

解決策は、トポロジーに対する考え方を少し変えるだけであり、それには絶大な効果があります。それは、すべての長寿命な環境ブランチを、他の環境ではなく、本番環境（production）の子ブランチにすることです。

開発環境と受入環境は、どちらも本番環境から直接作成されたブランチです。これらは本番環境の下に並んで配置され、積み重ねられることはありません。どちらも他方の親ではないため、一方をリフレッシュしても、もう一方を削除する必要は決してありません。

この1つの変更で、罠を回避できます。開発環境や受入環境が乖離したときは、1スプリントに1回程度、または最新データが欲しいときにいつでも、本番環境からリセットします（現在はUI操作で行えます）。開発環境や受入環境の下には何もぶら下がっていないため、最初に削除すべき子ブランチも、チーム全体で再設定すべき接続文字列も、権限を再適用するマラソンもありません。リセットが低コストであるため、実際に実行され、環境が健全に保たれます。万が一、リセットで変更が漏れたとしても、次のマイグレーションの再実行で単に再適用されるだけです。

アニメーション：PRごとのライフサイクル。公開されたブログで再生されます。このドキュメント内では静止フレームとして表示されています。

PRごとのフロー

1. 開発者が一時的なPR（TTLは1時間に設定）を開きます。
2. CIが本番環境から新しい一時的なpr-xxxxブランチを切り出します。私たちはすべて本番環境からブランチを作成し、データベースをマージして戻すことは決してありません。これらのPRごとのブランチは使い捨てです。PRがクローズした瞬間にアーカイブするため、プロジェクトあたり10個というLakebaseのデフォルトの未アーカイブブランチ制限を下回るように維持できます。
3. CIはその新しいブランチに対してマイグレーションを再実行（リプレイ）します。git diffチェックによってマイグレーションのリハーサルが実際に必要かどうかが判断されるため、マイグレーションを変更しないPRでは再実行がスキップされます。
4. マイグレーションを単体でテストするだけではありません。CIは新しいアプリイメージをステージングスロットにデプロイし、新しくマイグレーションされたブランチを指すように設定して、そのペアに対してフルテストスイートを実行します。
5. すべてのPRは、実際の環境に触れる前に、マイグレーションと新しいアプリケーションイメージを一緒に検証します。
6. PRがマージされると、CIがこれを再度実行します。PRが最初にパス（グリーン）してから状況が変わっている可能性があるため、productionから再度ブランチを作成し、マイグレーションを再実行して、再テストを行います。マイグレーションが成功すると、そのターゲットブランチに直接適用されます。最初のマージでは、そのターゲットはdevelopmentになります。
7. acceptance、そしてproductionへの昇格は、手動で承認されるゲートを介して行われ、それぞれが次の対象ブランチに対してマイグレーションを再実行します。

git中心の開発環境から移行するチームに向けて、1つ特筆すべき詳細があります。gitにはmasterブランチのみを保持します。ソース管理に長寿命のdevelopやreleaseブランチは存在しません。devからacceptance、そしてproductionへの昇格パスは、すべてAzure DevOpsの手動承認ゲートを介して表現されます。これがCIを起動し、変更を次のブランチへと移動させます。環境のトポロジーはLakebaseとパイプラインに存在するため、gitはシンプルな状態に保たれます。

マイグレーションの再実行が信頼できる唯一の情報源（Source of Truth）である理由

これらすべてを安全にしているのは、データベース同士をマージすることが決してないという点です。フィーチャーブランチからdevelopmentにデータをコピーして変更を昇格させることはしません。ターゲットブランチに対してマイグレーションを再実行することで昇格させます。ステージングスロットに対してスモークテストを実行するために、vitestを使用しています。

このモデルでは、ブランチは意図的に短寿命で使い捨てにされます。スキーマのあるべき姿を示す、永続的で信頼できる記述は、ドリフト（乖離）している可能性のある長寿命のデータベースではありません。順序付けられたマイグレーションのセットです。そのため、何かを見落としていたとしてもリセットは安全です。更新されたブランチに変更が不足していても、次のマイグレーション再実行で再度適用されるからです。マイグレーションが中心的な役割を果たすため、稼働中のデータベースはそこからいつでも再現可能であり、データベース自体を貴重なものとして扱う必要はありません。

これこそが真のブレイクスルーです。productionからブランチを作成することで、データは常に最新に保たれます。マイグレーションを信頼できる唯一の情報源として扱うことで、スキーマが正しく保たれます。これらが組み合わさることで、破棄して再構築できないような「特別すぎる」環境は存在しなくなります。

分岐点：2つの昇格モデル

これは他のチームにとっても最も役立つ部分だと考えています。なぜなら、1つの正解があるベストプラクティスではなく、真の分岐点だからです。上記のトポロジーを構築したら、次にPRのマージをいつ許可するかを決定する必要があります。私たちは2つのモデルを評価しましたが、それらは相反するトレードオフの関係にあります。

簡単に言えば、オプション1は緊密に連携するチーム内での開発速度を最適化します。オプション2は、独立性と明確なホットフィックスパスを最適化します。チームが重複する変更に取り組み、CIを信頼している場合は、スタッキングを使用するのが最も迅速です。進行中の他の変更を待てないような修正を頻繁にリリースする必要がある場合は、PRごとの昇格を導入する価値が十分にあります。

私たちはオプション1を選択しました。私たちは、重複する変更に取り組む小規模なチームです。誰かが自分の作業をベースに開発を始める前に、acceptanceがパスするのを待つのは、毎日支払うコスト（税金）のようなものです。一方で、スタッキングのリスクが発生するのはたまにしかありません。また、リスクが発生した場合でも、その影響は限定的です。すべての昇格ゲートは、実際のブランチに触れる前に、productionの新しいフォークに対してスタックされたマイグレーションを再実行するため、スタックはユニットとして検証されます。本当に緊急のケースに備えて、同じ事前チェック（プリフライト）を実行してproductionに直接デプロイする、別の緊急用パイプラインを維持しています。基本はスピード重視、緊急時の脱出ハッチも用意、という体制です。

補足：これまでの過程で生じた課題

ワーキングセッションでは、いくつかのトピックが繰り返し議論されました。これらはストーリーの本筋ではありませんが、このパターンが本番環境（production）での運用に耐えられるかどうかを左右する重要な詳細です。

データベース認証とトークンのローテーション。アプリケーションは、長寿命のデータベースシークレットを保持しません。Azure Key Vault内の静的パスワードを使用して、`databricks postgres generate-database-credential`を介して短寿命のデータベース資格情報（TTLが60分のトークン）を発行します。トークンは1時間で期限切れになるため、クライアントはプロアクティブに更新する必要があります。私たちは、接続プール上の非同期パスワード関数を使用してこれを処理し、資格情報をキャッシュして期限が切れる前にローテーションしています。

権限付与とアクセスプロビジョニング。テーブルのDDLはマイグレーションで管理しておらず、オブジェクトレベルの権限付与（GRANT）は現在、コードではなく手動で適用されています。これは改善リストの中で最も明確な項目です。しかし、これらの権限はproductionに適用され、環境ブランチはproductionから再フォークすることでリセットされるため、子ブランチは更新のたびに自動的にそれらを継承します。手動での権限付与ステップはproductionで1回発生するだけで、各子ブランチで繰り返されることはないため、現時点では許容できる頻度にとどまっています。

データベースアクセス：単一のアプリケーションユーザー。エンドユーザーごとにPostgresロールをプロビジョニングすることはありません。アプリケーションは単一のアプリケーションユーザーを介して接続し、個々のユーザーの認可はデータベースではなくアプリケーションレイヤーで行われます。これによりプロビジョニングがシンプルに保たれます。トレードオフとして、ユーザーごとのアクセス制御はPostgresではなく、その上位レイヤーで強制されます。

これがGlaspoortにもたらしたもの

以前はチーム全体で数ヶ月の作業を要していたユースケースが、今では小規模なチームで数日以内に本番稼働できるようになりました。イテレーションは10倍に増加し、1つのチームが組織とともに成長するプラットフォーム上で継続的に新しい価値を提供しています。—Raymon Veldman氏（Business Control & IT マネージャー）

最も顕著な変化は、不安が減り、スピードが向上したことです。すべてのPRに、productionと同じ構成のデータベースが数分で個別に割り当てられるようになったため、開発者が共有のdev環境やacceptance環境をめぐって調整する必要がなくなり、「誰がacceptanceを壊した？」という会話は完全に姿を消しました。環境ブランチは常にproductionの子ブランチであるため、「親からのリセット」作業に追われる日は二度とありません。子ブランチの削除も、接続文字列の再配線も、権限の再適用で午後が丸ごと潰れることもなくなりました。昇格の各ステップでマイグレーションが再実行され、新しくマイグレーションされたブランチに対してステージングスロットに新しいアプリケーションイメージをデプロイし、実際の環境に触れる前に完全なテストスイートを実行します。そのため、productionに到達するものはすでに2回検証されています。また、緊急事態が発生した場合でも、ホットフィックスはパイプラインをバイパスすることなく、他のすべての変更と同じ安全なパスを、より迅速に通過します。

アプリケーションデータベースにLakebaseを選択し、同様のCI/CDの課題に取り組んでいますか？まずはここから始めましょう：productionから直接分岐した長寿命の環境、PRごとの一時的なブランチ、そして信頼できる唯一の情報源としてのマイグレーション。Databricks Lakebaseの詳細はこちら

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