Lakebaseの舞台裏：パート3

このシリーズの第1部では、Databricks Lakebase上でBackstageを実行することで、1秒でのデータベースブランチ作成が可能になりました。一方、第2部では、Unity Catalogがその運用データベースをエンタープライズガバナンスプレーンに統合しました。

しかし、ここからが実際に組織図を変えるほどの真のメリットです。

通常のスタックでは、「クラウド支出を増加させているインフラストラクチャの所有者は誰で、コストはいくらかかったのか？」という問いに答えるには、2つの境界を越える必要があります。所有権のグラフはBackstage（プラットフォームエンジニアリングが管理）に存在し、コストデータはデータウェアハウス（データチームが管理）に存在します。この問いに答えるには、ETLパイプライン、Jiraチケット、またはSlackのスレッドが必要になります。

コンピュートの分離が共有を可能にする

FinOpsアナリストが、稼働中のポータルに影響を与えることなく、まったく同じ基盤ストレージに対して大規模な分析クエリを実行できる理由は、Lakebaseがワークロードごとにコンピュートを分離しているためです。

Backstageは、独自の分離された自動スケーリングコンピュート環境を取得します。通常のポータル使用時、カタログクエリのエンドツーエンドの実行時間は55〜65ミリ秒、検索は2〜4ミリ秒でした。Webアプリケーションと分析ワークロードが同じコンピュートクラスターを競合しないため、最終的に同じデータ基盤を安全に共有できるようになります。

回避策：レイクハウスフェデレーション認証

稼働中のPostgresデータと分析用課金データを結合するために、Databricks Lakehouse Federationを使用します。しかし、Lakehouse FederationのPostgresコネクタは現在、静的なユーザー/パスワード認証情報のみをサポートしています。LakebaseはOAuth JWTを介してアプリのアイデンティティを認証するため、フェデレーションエンジンには並行する認証パスが必要になります。

回避策は、SCRAM-SHA-256認証を使用するネイティブのPostgresロールを作成し、アプリが使用するOAuthアイデンティティとは別にフェデレーションに接続することです：

これで、同じデータベースに対して2つの認証パスを管理することになります。

FinOpsの結合

外部カタログが有効になると、FinOpsアナリストは、運用のPostgresテーブルからBackstageリソース名を直接取得し、それをsystem.billing.usage内のLakebase自体の課金行に結合する単一のクエリを記述できます。

実際の結果：

その行の左側は、稼働中のBackstage Postgresカタログの内部から直接取得されたものです。右側は、Unity Catalogのシステム課金テーブルから取得されたものです。これら2つは歴史的に同じSQLエンジンに存在したことはありませんでしたが、現在ではデータの移動なしで結合されています。

なぜETLを使わないのか？

懐疑的な人は、なぜ1時間に1回Pythonスクリプトを使用してRDSインスタンスをDeltaテーブルに同期しないのかと尋ねるかもしれません。

その答えはブランチ作成にあります。開発者がPRをテストするために一時的な1秒のデータベースクローンを作成する場合、その一時的なテスト環境のコストを可視化するためだけに、新しいETLパイプラインを動的にプロビジョニングする必要があります。Lakebaseを使用すると、ブランチが作成された瞬間に、その課金データと所有権データを即座にクエリできます。（このPOCでは、削除されたテストブランチに0.0107 DBUが自動的かつ個別に割り当てられました）。

統合の運用化

この3部構成のシリーズは、1秒のデータベースブランチから始まり、統合されたガバナンスを経て、ここにたどり着きました。それは、運用の所有権データとクラウドの課金データを、パイプラインを一切介さずに結合する単一のSQLクエリです。これが、技術的に統合が機能することの証明です。実務者が次に問いかけるのは、「これを運用化するには何が必要か？」ということです。

このパスを進むことを計画しているチームに向けて、このPOCから得られた注目べき2つのポイントがあります。

フェデレーション認証のギャップ

私たちが説明したLakehouse Federationの回避策（アプリが使用するOAuthアイデンティティとは別に接続された、静的な認証情報を持つネイティブのPostgresロール）は、現時点では適切なアプローチです。Lakebaseの運用データとUnity Catalogの分析テーブルを結合したいすべてのチームは、この並行する認証パスを設定する必要があります。そもそもフェデレーションはアプリケーションユーザーとして実行すべきではないため、この分離にはセキュリティ上のメリットがありますが、パスワードのローテーションは自己責任となります。このパターンを採用するチームの場合、手順を再利用可能なスクリプトにパッケージ化できます（安全なパスワードの生成、読み取り専用権限を持つロールの作成、接続の配線、外部カタログの作成）。パターンさえ分かれば、1回限りのセットアップで数分で完了します。FederationでOAuth JWTをネイティブにサポートすれば、この回避策は完全に不要になります。

開発チーム向けのブランチコストの可視化

FinOpsの結合は、「このインフラストラクチャのコストはいくらで、誰が所有しているのか？」というプラットフォームの問いに答えます。しかし、同じ課金データは、エンジニアリングマネージャーにとって重要なもう1つのストーリー、つまり「開発プロセス自体にどれだけのコストがかかっているのか？」を教えてくれます。

第1部のブランチ作成ワークフローでは、すべてのプルリクエストが一時的なCIブランチを作成し、すべての開発者が独自の機能ブランチを持ちます。これらは、branch_idとendpoint_idごとに分類され、system.billing.usageに独立したラインアイテムとして表示されます。エンジニアリングマネージャーは、チームの開発/テストブランチ作成がスプリント内で本番環境と比較してどれだけのコンピュートを消費したかを正確に把握し、ブランチのライフサイクルポリシーについて情報に基づいた意思決定を行うことができます。

重要なのは、一時的なブランチは課金データでも一時的なものとして扱うべきだということです。短いTTLで作成されたCIブランチは、メインへの直接プッシュ、ワークフローエラー、イベントの未検出など、何らかの理由でクリーンアップが失敗した場合に自動的に期限切れになります。ライフサイクル管理がないと、孤立したブランチが静かに蓄積され、それぞれがプロジェクトに対して課金されるアクティブなコンピュートエンドポイントを持つことになります。テストブランチのコストは0.0107 DBUでした。これは些細なものです。しかし、1か月間実行され続ける30個の孤立したブランチはそうではありません。

重要なのは、ブランチ作成が高コストであるということではなく、コスト対生産性の向上であるということです。チームがスプリントごとに2日間の環境待ち時間を排除し、コードベースの20〜30%をモックオブジェクトで維持するのをやめれば、ブランチあたり0.0107 DBUは管理すべきラインアイテムではなく、チームがこれまでに行った中で最も安価な生産性投資となります。そして、ほとんどの生産性投資とは異なり、これは測定可能です。インフラストラクチャが、ブランチごと、開発者ごと、スプリントごとに、正確にいくらかかったかを教えてくれます。これは、ほとんどのエンジニアリングチームがデータベースとこれまで交わすことができなかった会話です。

次のステップ

締めくくる前に、FinOpsのストーリーについてもう1つ指摘しておくべきポイントがあります。Lakebaseのエンドポイントはゼロにスケーリングされます。ブランチがクエリされていないとき、そのコンピュートは一時停止し、課金は止まります。0.0107 DBUという数字は実行されたブランチのコストであり、存在するブランチのコストではありません。テスト実行の間に置かれている一時的なブランチ群は、コストを一切発生させません。

このシリーズを通じて、実際のアプリケーション、実際のベンチマーク、実際のガバナンス、実際のコストデータを用いて、インフラストラクチャが機能することを証明しました。DatabricksとThoughtworksは共同で、実際の開発チーム、実際のスプリント、実際のベロシティ測定を導入し、これをPOCから実践へと移行させています。30年間にわたり運用データと分析データを別々の世界に分断していた制約は、解消されつつあります。

このシリーズのすべてのパートには、月曜日の朝からすぐに実践できる教訓があります。次のマイグレーションは、実際のスキーマ上でブランチを作成して実行してください。モックを多用したテストスイートの1つを、ブランチに対して書き換えてみてください。課金データを所有権グラフに結合しましょう。最初に動き出すチームが、次に来るものを定義することになります。

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