バックステージとLakebase

30年間、運用データベースと分析データベースは、ETLジョブで接続された2つのアーティファクト、2つのガバナンスプレーン、2つの予算、そして通常は2つのオンコールローテーションでした。この分割は設計上の選択ではなく、物理的な制約でした。OLTPとOLAPは、実際に異なるストレージレイアウト、異なるコンピューティングプロファイル、異なる障害モードを持っていたため、2つのプラットフォームを構築し、後からそれらを接続していました。

その制約は解消されつつあります。ストレージが共有され、コンピューティングがサーバーレスでワークロードごとに分離され、ガバナンスがカタログレイヤーに存在する場合、「運用」と「分析」はアーキテクチャ上のカテゴリではなくなり、同じ基盤に対するアクセスパターンになります。

それが実際に機能するかどうかをテストするために、私たちはSpotifyの非常に状態が多い内部開発者ポータルであるBackstageを使用し、標準のPostgresデータベースから切り離して、DatabricksのLakebaseに向けました。この3部構成のシリーズでは、運用アプリケーションとデータプラットフォームの間の壁を崩したときに、デプロイメントサイクル（パート1）、ガバナンス（パート2）、FinOps（パート3）に何が起こるかを探ります。

セットアップ：BackstageをLakebaseに向ける

Lakebaseは、Databricksプラットフォーム内に存在するサーバーレスPostgresサーフェス（内部でNeonのアーキテクチャを活用）を公開します。ワイヤプロトコルPostgresを使用するため、BackstageはRDSと通信していないことを認識せず、気にもしません。

接続するには、app-config.yamlをLakebaseに向け、Backstageのデフォルトのインメモリ検索をPgSearchEngineに切り替える必要がありました。すぐに直面した課題：Lakebaseは、OAuth JWTを期待するため、従来のDatabricks Personal Access Tokenを拒否します。CLIはdatabricks postgres generate-database-credentialを提供しており、これは特定のエンドポイントに対してスコープされた短命のJWTを生成します。これは、アプリケーションやCIの意図されたアプローチです。このPOCでは、トークンの有効期限を処理するために、そのコマンドを軽量なcronスクリプトにラップし、50分ごとに.envファイル内のDATABRICKS_TOKENを書き換えました。

認証が解決された後、Knexのマイグレーションは正常に実行され、ポータルはライブになりました。

ブランチングはデータベース開発サイクルを変える

従来のPostgresで最も過小評価されているのは、その機能セットではありません。それは、それを所有するチームに強制するテンポです。

Thoughtworksは、Technology Radarを通じてBackstageをIDP基盤として一貫して支持してきたため、このPOCでBackstageを選択したのは、そのスキーマイグレーションが非常に壊れやすく、Lakebase統合をテストするのに最適な機会だと思われたからです。従来のRDSでは、リスクの高いマイグレーションをテストするには、スナップショットを並列インスタンスに復元するために数分または数時間待つ必要があります。コピーを作成するのは遅くてコストがかかるため、チームはテストしません。彼らは指をクロスして、メンテナンスウィンドウでマイグレーションを実行します。

コピーの作成が無料になると、「この変更は実行するのに十分安全か？」と尋ねるのをやめ、「最初にどの本番環境のフォークを試したいか？」と尋ねるようになります。

Lakebaseはコピーオンライトアーキテクチャを使用してストレージとコンピューティングを分離しているため、ブランチを作成してもデータはコピーされず、同じ基盤ページへのポインタが作成されるだけで、書き込み時にのみ分岐します。だからこそ、操作は瞬時に行われます。

ドキュメントでは明確にされていない注意点があります：リクエストボディはすべてspecオブジェクト内にネストする必要があり、ttl、expire_time、またはno_expiryを指定する必要があります。それがない場合、APIは「Expiration must be specified.」と返します。

コントロールプレーンは即座にそれを認識しました。約63MBのBackstageカタログの実際のデータプレーンクローンは、1.09秒で着陸しました。

Point-in-Time Recovery：元に戻すボタン

ブランチングとPoint-in-Time Recovery（PITR）は基本的に同じプリミティブです。ブランチングは、source_branch_time = nowを使用したPITRにすぎません。実際に削除されたデータに対してリカバリをテストするために、final_entitiesテーブルをすべて消去し、カウントを32から0に減らしました。

その後、削除の数秒前にキャプチャされたタイムスタンプからリカバリブランチを作成しました。

エンドツーエンドの経過時間は3.78秒でした。

データの検証により、リカバリされたブランチには32個のエンティティすべてが戻っていることが確認されました。本番環境はまだゼロのままで、削除が実際に行われたことと、ブランチが完全に分離されていることが確認されました。注目すべきは、22:56:02Zを要求しましたが、LakebaseはWALレコードに最も近いものにスナップバックし、12秒前の22:55:50Zにスナップしました。このWALレベルの粒度は、時間依存のリカバリワークフローにとって重要な注意点ですが、インシデントサイクルは1分未満で実行されました。

データベースの状態が2TBのEBSボリュームではなく、安価でフォーク可能なアーティファクトになると、すべてのリスクの高い操作にドライランがあり、すべてのインシデントに元に戻すボタンがあります。

インフラストラクチャ機能から開発者ワークフローへ

上記で示したように、データベースブランチングが機能することを示しています。1秒のクローン、4秒のリカバリ、そして違いがわからない実際のアプリケーションです。しかし、「データベースはブランチできる」ということと、「私のチームはコードをブランチするのと同じくらい自然にデータベースをブランチする」ということの間にはギャップがあります。そのギャップを埋めることで、客観的な利益として開発者の生産性に大きな影響を与えることができます。

私たちは過去数ヶ月間、開発チームと協力して特定の質問に答えてきました。データベースブランチングが目に見えなくなったとき、つまり、コマンドを実行するのではなく、エディタで作業する方法の一部として自動的に発生するとき、チームの速度はどうなるでしょうか？Gitとデータベースのブランチを自動的に同期してこれを証明するためのVS Code/Cursor拡張機能の開発が進んでいますが、ツールはそれが可能にするものに次ぐものです。

ブランチングが可能にすること

私たちが経験してきたチーム全体で、データベースブランチングのないスプリントサイクルは次のようになります。

1. 機能開発のためのGitブランチを作成する
2. テスト目的で、すべてのデータベースインターフェイスのモックオブジェクト（MockUserRepository、MockOrderServiceなど）を記述する
3. モックまたはインメモリデータベース（H2、SQLite）を使用して単体テストを記述する
4. PRを送信し、レビューを受けてコードをマージする
5. 共有ステージング環境にデプロイする
6. スキーマイグレーションが実際のデータに対して機能しない、またはデータのサイズがブロッカーであることが判明する
7. スキーマイグレーションを修正し、再デプロイし、繰り返す

データベースのブランチ機能が利用可能になったことで、開発者の機能開発サイクルは次のように変化します。

1. Gitブランチを作成 – Lakebaseデータベースのブランチは1秒未満で自動的に作成できます
2. IDEは実際のブランチデータベースに即座に接続します
3. 最初のコード行から、実際のライブデータベースデータに対してコードを記述し、マイグレーションを実行します
4. 実際のデータベースに対して統合テストを記述します – データベースモックではありません
5. データベースの変更のロールバックは簡単なので、複数のソリューションを試すことができます
6. プッシュしてPRを開く – CIは独自のデータベースブランチを作成し、コードとスキーマの両方を検証し、スキーマ差分を公開します
7. QAチームメンバーは、破壊的テストのために独自のデータベースブランチを取得できます – 数秒でリセットできます
8. マージ – マージされると、CDパイプラインはUATや本番などの上流環境に移行し、すべてのブランチ（コードとデータ）をクリーンアップできます。

モックオブジェクトはなくなります。ステージングの競合はなくなります。「私のマシンでは動作するのにステージングでは壊れる」という問題はなくなります。開発者は複数のソリューションを試すためのライブデータベースを利用できます。デプロイ時に発見されていたデータベースの変更は、修正が容易な開発中に検出されるようになります。パフォーマンステスト用のインスタントブランチ、ファンクショナルテスト用の使い捨てで分離されたブランチ、UATステークホルダー用の実行中のブランチが容易になります。

私たちの経験では、このワークフローを評価した複数のパートナーチームにおいて、モックオブジェクトはテストコードの20〜30％を占めていました。これはテストカバレッジではなく、テストインフラストラクチャです。時間の経過とともに本番環境の動作から乖離し、誤った自信を生み出すインフラストラクチャです。本番環境相当のデータベースのブランチ作成にコストがかからなくなると、モックは高価な選択肢になります。

さて、もはや存在しない制約に対する回避策に、スプリントのどれだけの時間を費やしているでしょうか。

このシリーズのパート2では、この運用データベースがDatabricksの統合ガバナンスレイヤーであるUnity Catalogに直接取り込まれた場合に、セキュリティとコンプライアンスに何が起こるかを見ていきます。

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