LakebaseとBackstage、パート2

このシリーズの パート1では、Backstageの基盤となるデータベースを Databricks Lakebaseに移行することで、リスクの高いスキーマ移行が1秒のブランチ＆テスト操作に変わる様子を探りました。しかし、セキュリティおよびガバナンスチームが運用データベースを依然としてブラックボックスのように扱っている場合、開発サイクルが高速化しても限界があります。

従来のスタックでは、アプリケーションデータベースとデータレイクは、まったく異なる2つのセキュリティパラダイムに存在します。インフラストラクチャの所有権グラフはBackstageにあり、分離されたRDSインスタンスによって支えられ、複雑なIAMロールとPostgresネイティブの権限によって管理されています。一方、ウェアハウスデータは、データチームがUnity Catalogを使用して管理しています。 Unity Catalogは、Databricksが作成したオープンソースフレームワークで、データ、AI、そして現在は運用データベース向けの統合ガバナンスレイヤーを提供します。これは、プラットフォーム上のあらゆるものに対するアクセス制御、監査証跡、リネージ、コンプライアンスを管理する単一の場所です。

RDSでの単一のテーブル削除を監査するには、IAMプリンシパルについてはCloudTrail、 pg_stat_activity または pgaudit SQLステートメントのログ、タイムスタンプについてはCloudWatchを相互参照する必要があります。3つのサービス、3つのクエリ言語、3つのアクセスポリシーです。運用データベースはコンプライアンスのサイドチャネルとなります。

Unity Catalogが運用DBを統合

BackstageをLakebaseに向けたとき、データの保存場所を変えただけでなく、アクセスポリシーの保存場所も変えました。

LakebaseはDatabricks内にネイティブに組み込まれているため、Unity Catalogは運用Postgresデータベースに直接拡張されます。このPOCでは、Lakehouse Federationを使用して、BackstageカタログをUnity Catalogの外部カタログ (lakebase_bs) として公開しました。一度公開されれば、標準のUC権限で誰が何を見られるかを制御でき、Postgresレベルのロール管理は不要です。

このPOCではBackstageのエンドツーエンドの行レベルセキュリティポリシーを構築しませんでしたが、アーキテクチャ的には、機密性の高い請求テーブルを保護するのとまったく同じRLSルールをこれらの運用テーブルに直接適用できます。「運用」と「分析」の間の壁は物理的な境界ではなくなり、単なるアクセスパターンになります。

すぐに使える統合監査証跡

パート1で実行した1秒のコピーオンライトブランチを覚えていますか？従来のセットアップでは、開発者がデータベースを1時間だけブランチして破棄したことをセキュリティエンジニアに証明するのは手作業です。

Lakebaseを使用すると、運用データベースに対するすべてのコントロールプレーンアクションが自動的に system.access.auditに記録されます。これを証明するために、パート1の災害復旧実験からの正確なブランチ操作について監査ログをクエリしました。

結果:

パート1の実験からのすべてのブランチ作成と削除がログに記録されます。各イベントは特定のOAuthユーザーIDとソースIPに関連付けられ、自動的にキャプチャされ、Unity Catalogの他のすべての監査テーブルとまったく同じ行レベルセキュリティ制御によって管理されます。CloudTrailの相互参照は不要です。RDSログの解析も不要です。1つのSQLクエリで済みます。

ブランチごとのコスト自動割り当て

ガバナンスチームは、誰がブランチを作成したかだけでなく、そのコストも知りたいと考えています。

従来のAWS環境では、一時的なRDSインスタンスのコストを追跡するには、短期間のワークロードを見落としがちなカスタムCloudWatchタグ付け戦略が必要です。LakebaseはUnity Catalogのシステム請求テーブルとネイティブに統合されているため、コンピューティングコストは自動的に project_id、 branch_id、および endpoint_idによって分類されます。

このPOCでは、本番ブランチは 31.6130 DBUで課金され、削除されたテストブランチには個別に 0.0107 DBUが割り当てられました。監査証跡とコスト証跡はまったく同じ場所で管理されます。

毎日ブランチを作成するチームにとっての意味

私たちのガバナンスの物語は、コンプライアンスの問いに答えます。誰が、いつ、何を行い、そのコストはいくらだったのかを証明できるか？答えはイエスです。3つのサービスではなく、1つのSQLクエリで済みます。しかし、パート1のブランチワークフローを採用する開発チームにとって、同様に重要な2つ目のガバナンスの問いがあります。チームがスプリントごとに何十ものブランチを作成する場合、ガバナンスはどうなるのか？

パート1では、すべての機能ブランチとすべてのプルリクエストが独自の分離されたデータベースコピーを取得するワークフローについて説明しました。2週間のスプリントを実行する6人の開発者チームは、1つのスプリントで30〜40のブランチを作成および破棄する可能性があります。これは、顧客の個人情報、財務記録、健康データなどの機密フィールドを潜在的に含む、本番データの30〜40のコピーです。

ここで、Unity Catalogのブランチレベルのガバナンスは、単なる利便性だけでなく、重要な役割を果たすようになります。Lakebaseブランチが作成されると、Unity Catalogの属性レベルのマスキングポリシーが新しいブランチに自動的に伝播されます。機能ブランチで作業する開発者は、マスクされていない本番データを見ることはありません。誰かが設定を忘れたからではなく、ガバナンスレイヤーが作成時にそれを強制するからです。PRテストを実行するCIブランチは、本番環境とまったく同じようにガバナンスされます。テスターが破壊的なシナリオを実行するQAブランチも、本番環境とまったく同じようにガバナンスされます。誰かがポリシーの適用を忘れたために機密データが漏洩するような「非本番環境の例外」は存在しません。

これは見た目以上に重要です。Perforceの2025年データコンプライアンスレポートによると、組織の60%が、機密データが不適切に匿名化された非本番環境で侵害または盗難を経験しています。開発/テスト環境をプロビジョニングする際にデータを手動でマスキングする従来のアプローチは、環境が数秒で作成および破棄される場合にはスケールしません。ガバナンスは自動化される必要があります。さもなければ、それは実現しません。

DBAの新たな機会

監査証跡とコスト割り当てデータは、より静かな変化も示しています。DBAの役割が、受動的なチケット作業から戦略的なプラットフォームアーキテクチャへと進化しているのです。

現在、DBAの時間の多くは、環境プロビジョニング、スキーマレビュー、データ更新、アクセス許可といった運用リクエストに費やされています。6人の開発者チームはスプリントごとに30以上のチケットを生成でき、DBAのスケジュールはキューと化します。DBAを価値ある存在にする専門知識、つまりデータ整合性、パフォーマンス、ガバナンスを深く理解する能力は、反復的なプロビジョニング作業の下に埋もれてしまいます。

ブランチングがセルフサービスになり、ガバナンスが自動化されると、その反復的な作業はなくなります。開発者は1秒で自身の環境をプロビジョニングできます。スキーマ変更はプルリクエストで非同期にレビューされます。DBAはCIによって投稿されたフォーマット済みのスキーマ差分を確認し、自身のスケジュールでレビューし、通常のPRワークフローを通じて承認または変更を要求します。利用可能になった時間で、これらのレビューはより深くなります。DBAはチームメンバーが本番環境の既存データと構造を理解するのを助け、より良い解決策に到達するために協力し、データ整合性とガバナンス基準を維持するための徹底的なレビューを実施します。データマスキングは手動介入ではなく、ポリシーによって強制されます。コスト配分は自動であり、月次の調整作業ではありません。

開かれるのは、DBAの専門知識を実際に活用する作業です。ブランチングポリシーの定義、ガバナンスルールの設計、プロモーションワークフローの構築、パフォーマンスチューニング、そしてセルフサービスを安全にするためのガードレールの確立です。DBAは作業を行うことから、作業の実行方法を設計することへと移行します。スプリントごとに30以上の運用チケットを処理する状態から、5件未満の価値の高いポリシーレビューへと変わります。上記で示された監査証跡は、単なるコンプライアンスの成果物ではありません。それはDBAの新しい戦略的ダッシュボードであり、プラットフォームがどのように使用されているか、次にどこに投資すべきかをリアルタイムで示すものです。

役割の転換からツールへ

DBAが運用チケットからプラットフォーム設計へと軸足を移すのは、ツールが役割に合わせて変化する場合にのみ機能します。プラットフォームはルーチン作業を自律的に行う必要があり、DBAはその作業がどのように行われるかを 設計する場所が必要です。

2つのオープンソースツールは、どちらもDatabricks Appsとしてデプロイされ、上記で説明した同じUnity Catalogの権限と監査証跡によって管理されており、このループを閉じます。

LakebaseOpsは、プラットフォームが自律的に行うことです。プロビジョニング、パフォーマンス、ヘルスという3つのエージェントが、DBAが以前チケットを起票していた51のタスクを置き換えます。そのうち7つはスケジュールされたDatabricks Jobsとして実行され、DBAが手動でメンテナンスしていたpg_cronのcrontabを置き換えます。モニタリングUIは、リアルタイムのpg_statメトリクス、低速クエリの回帰、ブランチTTLの強制、および9つのKPI採用ダッシュボードを表示します。マイグレーションウィザードは、10のソースエンジン（Aurora、RDS、Cloud SQL、AlloyDB、Cosmos DBなど）をLakebaseに対して評価し、AWSおよびAzure APIからのリアルタイム価格情報を提供します。

Lakebase MCPは、DBAがプラットフォーム上で行うことです。任意のMCP対応AIエージェント（Claude、Copilot、GPT）に46のツールを公開するモデルコンテキストプロトコルサーバーです。DBAはpgAdminを開くのをやめ、意図を記述し始めます。

2つの設計上の選択肢がこれを安全に保ちます。まず、二層ガバナンスです。SQLステートメントガードとツールごとのアクセスガードがあり、上記で示されたUCアクセスパターンにマッピングされる4つの事前構築済みプロファイル（read_only、analyst、developer、admin）があります。コーディングアシスタントは read_onlyとして実行され、物理的にテーブルを削除することはできません。

次に、すべてのクエリは帰属可能です。サーバーはすべてのステートメントに元のツールをタグ付けします。

以前示されたブランチレベルのコスト配分と組み合わせることで、「どのブランチのどのエージェントが午前4時のCPUスパイクを生成したか？」という問いに1つのSQLクエリで答えることができます。

LakebaseOpsはチームの ために実行されます。Lakebase MCPはチーム と共に実行されます。どちらも、先ほど見たガバナンス体制を継承します。

このシリーズのパート3では、最終的な成果について見ていきます。Backstage内のインフラ所有権データを取得し、単一のSQLクエリでクラウド請求データに直接結合する方法です。

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