Databricks Backstage、FinOpsを1つのクエリに統合するも、難題は上流へ移る

Databricksは、Backstageを用いた3部構成の実験を完了し、注目すべき結果を示した。単一のクエリで、インフラの所有情報と日次のLakebase利用量を結び付けられるという。databricks backstageの設計は、通常はプラットフォームエンジニアリングとFinOpsを隔てる統合上の境界を取り除く。ただし同時に、正確なサービスメタデータへの依存という、より難しい課題も露わにする。

このデモでは、両データセットを別個のレポーティングシステムへ移すことなく、BackstageのライブなソフトウェアカタログとDatabricksの請求レコードを結合する。FinOpsアナリストは、Lakebaseリソースを特定し、その所有者を確認し、利用状況を1つのSQL文で調べられる。

これは単なるダッシュボード統合以上の意味を持つ。Backstageは通常、運用上の所有情報を保持し、データウェアハウスはコスト記録を保持する。チームはETLジョブ、エクスポート、チケット、手作業で維持されたマッピングを通じて、これらのシステムを接続している。

新しいアプローチは、こうした移動の多くをフェデレーションに置き換える。フェデレーションは、共通のSQLレイヤーを通じてシステム横断でデータを照会する仕組みだ。しかし、チャージバックの背景にある組織的な作業をなくすわけではない。むしろ、その作業をカタログアノテーション、リソース識別子、アクセス制御、請求セマンティクスへと移す。

Databricks Backstageの実験、FinOpsで成果を示す

第3の実験では、Backstageの所有関係グラフがクラウドコスト分析への直接的な入口となる。

DatabricksとThoughtworksは、このシリーズを通じて、Spotifyのオープンソース内部開発者ポータルであるBackstageを運用アプリケーションとして利用した。Backstageは、サービス、コンポーネント、所有者、依存関係、インフラ参照を含むソフトウェアカタログを管理する。

チームはポータルのPostgreSQL状態を、Databricksが提供するマネージドPostgresサービスであるLakebaseへ移行した。Lakebaseはストレージとコンピュートを分離し、トランザクションデータをより広いDatabricks環境と統合する。

第1部の焦点はデータベースブランチだった。著者らによれば、Lakebaseは約1秒でデータベースブランチを作成した。これにより、本番データベースを変更する前に、隔離されたコピーに対してBackstageのマイグレーションをテストすることが現実的になった。

第2部では、運用データベースをデータおよびAI資産向けのDatabricksガバナンスレイヤーであるUnity Catalogの管理下に置いた。このステップにより、Backstageデータベースは分析データと同じコントロールプレーンを通じて可視化された。

第3回では、これらの先行する変更をFinOpsに適用している。その中心となるクエリは、BackstageのレコードとDatabricksのシステム請求テーブルを組み合わせるものだ。

Backstage側では、カタログで処理済みのエンティティレコードを含むテーブルfinal_entitiesを使用する。各関連エンティティには、そのLakebaseプロジェクトを識別するdatabricks/project-idアノテーションが含まれる。

請求側では、課金対象となるDatabricks利用量を記録するsystem.billing.usageを使用する。このクエリは、カタログアノテーションとusage_metadata.project_idを照合し、Lakebaseの利用に絞り込む。

公開された例では、Backstageリソース名、LakebaseプロジェクトID、日付ごとに利用量をグループ化している。サンプル出力では、2026年4月8日に39.8667 DBU、4月7日に43.6231 DBUを割り当てている。

DBU（Databricks Unit）は、プラットフォームの処理消費量を表すために用いられる標準化された指標だ。クエリは最終的な通貨ベースの料金ではなく、DBUを報告する。

この違いは重要である。このデモは、利用量をカタログ化されたリソースに帰属できることを示している。一方で、あらゆる割引、コミットメント、調整、共有費用を対象とする完全な会計モデルを確立するものではない。

それでも、一般的なFinOps調査の時間を短縮する。アナリストは、ウェアハウスの請求データと比較する前に、サービス所有情報のエクスポートを依頼する必要がなくなる。

この結果は、開発者がすでにサービスを見つける場所にコスト情報を結び付ける。クラウドリソース名だけでなく、システム、チーム、製品ごとに整理されたコストビューへの道筋をつくる。

したがって、このシリーズは開始時とは異なる地点で終わる。データベースブランチはエンジニアリングのワークフローを改善した。統合ガバナンスは運用状態を照会可能にした。最後のステップは、これらの技術的変更を組織的なレポーティングの仕組みに変換する。

1つのクエリがプラットフォームチームの役割を変える理由

重要な変化はSQLが短くなることではない。プラットフォーム、データ、財務の各チーム間で繰り返される調整をなくすことにある。

典型的な内部開発者ポータルは、誰がサービスを所有しているか、どのリポジトリに含まれるか、どのインフラがそれを支えているかといった問いに答える。請求システムは、リソースがどれだけの従量消費を発生させたかを示す。

これらの回答は、しばしば互換性のない識別子を用いる。開発者はcheckout-apiというサービスを認識する一方、クラウド請求書にはアカウント、プロジェクト、クラスター、あるいは不透明なリソースIDが示される。

FinOpsチームは、タグ、配賦ルール、レポーティングモデル、手動レビューによってこの不一致に対処する。FinOps Frameworkは、未配賦コストが説明責任と予測を弱めるため、配賦を中核的な能力として位置付けている。

Backstageは、このプロセスのための所有情報レイヤーとなる可能性がある。そのカタログはすでに、ソフトウェアエンティティをチームおよびインフラと関連付けている。課題は、これらの関連付けを請求レコードへ確実に接続することだ。

Databricksの実験では、この接続をデータプラットフォーム内に配置する。従来の取り込みを行わずに外部または運用ソースを照会できるLakehouse Federationにより、ライブのBackstageカタログをシステム請求データと並べて公開する。

このアプローチは、所有レコードをウェアハウスへコピーする専用パイプラインの必要性を減らす。また、コストに関する疑問を解決するまで、そのパイプラインの次回スケジュール実行を待つ必要もなくなる。

コンピュートの分離は、この提案の中心である。LakebaseはBackstageのトランザクションリクエストを処理しつつ、別のコンピュートリソースが関連データに対する分析クエリを実行できる。

DatabricksはLakebase Postgresについて、オートスケーリング、スケールトゥゼロ、ブランチ、読み取りレプリカ、即時リストアをサポートすると説明している。また、Unity CatalogおよびDatabricks Appsとも統合される。

このアーキテクチャは、アナリストのワークロードからポータルを保護することを狙う。同じ基礎状態を参照しているというだけで、大規模な集計がBackstageの対話的リクエストと直接競合すべきではない。

この分離は、プラットフォームチームが提供できるものを変える。所有情報と消費量を、複数回の引き継ぎ後に接続される2つのデータセットではなく、同一のリソースグラフに対する2つのビューとして扱える。

FinOpsアナリストは、コストから説明責任を負う所有者への直接的な経路を得る。プラットフォームエンジニアは、どの内部サービスがLakebase容量を消費しているかについての根拠を得る。エンジニアリングリーダーは、チーム単位のレポーティングに向けた基盤を得られる可能性がある。

開発者も、より可視性の高い説明責任に直面する。カタログエントリの識別子がインフラ消費量の割り当て先を決めるとき、それは単なるドキュメントではなくなる。

この変化は、プラットフォームチームにカタログ品質の改善を迫る。どのアノテーションを必須にするか、識別子をどう検証するか、リソースが所有者間で移動した場合にどう扱うかを決めなければならない。

データチームにも関連する変化がある。ガバナンスされたアクセスと請求セマンティクスには引き続き責任を負うが、運用メタデータと分析レコードを結ぶすべての統合パイプラインを所有する必要はなくなる。

FinOpsチームも適応を迫られる。迅速なアクセスは配賦ポリシーを定義する必要性をなくさない。それらのポリシーを、現在の運用モデルにより近い場所で適用できるようにする。

したがって、その成果は役割分担の変化にある。プラットフォームエンジニアリングは信頼できる所有関係グラフを維持し、データプラットフォームはガバナンスされた結合を提供し、FinOpsは消費量をどのように説明責任へ変換するかを定義する。

この配置が魅力的なのは、待ち時間をなくすからだ。一方で、所有関係グラフの誤りが財務レポーティングへ直接流れ込むため、要求水準も高い。

仕組みは新しいコストデータベースではなくフェデレーション

Databricksは、運用カタログデータを別のコストレポーティングストアへコピーする代替手段としてフェデレーションを提示している。

中核となるクエリは、Backstageの処理済みエンティティテーブルから始まる。Backstageは、YAMLファイル、プラグイン、外部システムなどのソースからカタログ定義を取り込み、正規化した後、この表現を作成する。

ソフトウェアカタログは、エンティティをコンポーネント、システム、API、リソース、グループ、ユーザーを記述するメタデータレコードとして扱う。リレーションは、それらのエンティティを所有関係および依存関係のグラフへ接続する。

この実験では、Backstageリソースはアノテーション内にLakebaseプロジェクト識別子を含む。SQLクエリは、エンティティのJSONドキュメントからその識別子を抽出する。

続いて、その識別子を請求テーブルのプロジェクトメタデータに結合する。リソース、プロジェクト、日付ごとにグループ化することで、人間が理解できる配賦結果が得られる。

この仕組みには、重要な性質が3つある。

第一に、運用レコードは運用レコードのまま残る。Backstageは、分析用レプリカが更新を受け入れるのを待つことなく、通常のカタログ活動にPostgreSQLを使い続ける。

第二に、請求レコードはDatabricksのシステムテーブルに残る。このデモでは、アナリストが利用する前にカスタムエクスポートを作成する必要がない。

第三に、結合はガバナンスされたクエリ環境を通じて行われる。Unity Catalogは、参加するオブジェクト全体にわたる検出とアクセスを制御できる。

Databricksはこれをゼロデータ移動と呼ぶ。より正確には、ユーザーは分析実行前に、別の結合済みデータセットを実体化するための独立したパイプラインを構築しないという意味だ。

クエリ実行では、関連するインターフェースをまたいでリクエストと結果が依然として転送される。フェデレーションはコネクター、認証情報、メタデータ、パフォーマンス制御にも依存する。

このニュアンスは利点を損なうものではない。ETLパイプラインがなくなった後、複雑性がどこへ移るかを明確にする。

従来のパイプラインは、変換コードでマッピングを表現する。フェデレーション設計では、Backstageエンティティに付与されるアノテーションを通じて重要なマッピングを表現する。

マッピングは見つけやすくなる一方、見落としやすくもなる。アノテーションが欠けている、あるいは誤っている場合、クエリはリソースと所有者のつながりを失う。

成熟した実装では、カタログ取り込み時にそのアノテーションを検証するだろう。不正な形式のプロジェクト識別子を拒否したり、存在しないLakebaseプロジェクトを参照するエンティティにフラグを付けたりできる。

チームにはライフサイクルルールも必要となる。削除されたサービス、移管されたアプリケーション、名称変更されたプロジェクトは、現在のカタログスナップショットだけでは答えられない履歴上の配賦問題を生み出し得る。

チャージバックでは、特定時点における所有情報がとりわけ重要になる。今日の所有者が、サービス移管以前に発生した消費量を自動的に引き継ぐべきではない。

このデモの日次グループ化は出発点となるが、履歴配賦には永続的な所有履歴が必要だ。チームはカタログ変更、請求スナップショット、あるいは有効期間を持つマッピングテーブルを保持することになるかもしれない。

アクセス制御は、もう1つの設計判断を加える。エンジニアは、自らのサービスを確認する必要がある一方、全社的な請求レコードへの無制限のアクセスまでは必要としない場合がある。

Unity Catalogは権限の定義に役立つが、各組織は適切な粒度を定めなければならない。基礎となるシステムテーブルへの広範なアクセスを付与するよりも、チーム単位のビューの方が安全な場合がある。

パフォーマンスにも注意が必要です。サンプルクエリは簡潔ですが、本番のBackstageカタログには多数のエンティティや大規模なJSONレコードが含まれる可能性があります。

JSONからの抽出を繰り返す処理は、規模が拡大すると非効率になる場合があります。チームは、ソースカタログを変更せずに、選択したアノテーションを整備済みビューとして公開できます。

この最適化を行っても、より広いモデルは維持されます。違いは、切り離されたエクスポートパイプラインではなく、ライブの運用データの上にガバナンスされたセマンティックレイヤーが置かれる点です。

したがって、databricks backstageアーキテクチャはデータエンジニアリングを不要にするものではありません。エンジニアリング作業を、メタデータ契約、アクセス方針、クエリインターフェースに集中させます。

組織がより厳格なカタログ運用を受け入れるなら、これはより戦略的な仕事の位置づけです。

真の競合はETLの引き渡し

この実験が問い直すのは、PostgreSQLの競合製品や他の開発者ポータルではなく、パイプライン優先の統合モデルです。

チームは従来、オンライン・トランザクション処理とオンライン分析処理を分離してきました。トランザクションシステムは頻繁かつ低レイテンシの書き込みを優先し、分析システムははるかに大きなデータセットをスキャンして集計します。

この分離により、2つの運用領域が生まれました。アプリケーションチームはPostgreSQLなどのデータベースを管理し、データチームは選択したレコードをウェアハウスやレイクハウスにコピーしていました。

両者はストレージレイアウト、スケーリングモデル、障害に関する懸念が異なるため、このアーキテクチャは合理的でした。直接的な分析クエリはアプリケーションのパフォーマンスを脅かす可能性があります。

現代のクラウドプラットフォームでは、ストレージ、コンピュート、ガバナンスの分離が進んでいます。その結果、一部のデータには、ワークロードごとに異なる複数のコンピュート経路からアクセスできるようになっています。

Lakebaseはこの潮流の中にあります。Databricksは、レイクハウスデータへの近接性も必要とするトランザクションアプリケーション向けのマネージドPostgreSQLとして位置づけています。

Backstageの実験は、この近接性を利用して、専用の所有権エクスポートを回避します。主な代替案は別のPostgresベンダーではありません。カタログレコードを抽出し、識別子を変換して、レポーティングモデルへロードする従来のプロセスです。

ETLには依然として重要な利点があります。マテリアライズされたデータセットは、予測可能なパフォーマンス、永続的なスナップショット、品質チェック、ソーススキーマ変更からの隔離を提供できます。

また、複数のポータルやクラウドプロバイダーからのデータを標準化することも可能です。単一のBackstageデータベースに対するフェデレーテッドクエリでは、複数のカタログや請求環境を持つ企業をカバーできない場合があります。

ETLのコストは、レイテンシと責任の所在に表れます。誰かがパイプラインをスケジュールし、障害を監視し、スキーマを更新し、マッピングを照合し、ユーザーが出力を信用しない場合に対応しなければなりません。

これらの責務は、しばしばチーム間の隙間に落ちます。プラットフォームエンジニアリングはサービスカタログを理解し、データエンジニアリングはウェアハウスを所有し、FinOpsは配賦モデルを理解しています。

フェデレーション優先のアプローチは、一部のコピーとスケジュールを排除します。ライブソースを利用可能にする一方で、その可用性、スキーマ、メタデータ品質、クエリ挙動への依存度を高めます。

これが中心的なトレードオフです。ETLはソースとの距離を作り、ソースの不安定性を吸収します。フェデレーションは鮮度とコピー削減をもたらしますが、利用者を運用上の変更に近づけます。

適切な選択は、支援する意思決定によって異なります。対話的な調査には現在の所有権データが有用です。一方、監査対象となる月次チャージバックには、安定した履歴と再現可能なルールが必要です。

大規模な組織では、ハイブリッドモデルが有力でしょう。アナリストはフェデレーテッドクエリで直近の利用状況を調査し、その後、承認済みの配賦結果を永続的なレポーティングレイヤーに公開できます。

このモデルは実証を無効にするものではありません。フェデレーションで探索時の摩擦を減らしながら、正式な財務プロセスのためにマテリアライズされたレコードを維持するものです。

他のマネージドPostgreSQLプラットフォームも、フェデレーテッドアーキテクチャに参加できます。AWS、Google Cloud、Microsoft、独立系データベースプロバイダーは、分析統合を備えたトランザクションシステムを提供しています。

Backstage自体はデータベースに依存しません。PostgreSQLのサポートにより、組織は運用、規制、商業上の要件に基づいてインフラを選択できます。

この実験におけるDatabricksの優位性は、プラットフォーム上の近接性にあります。Lakebase、システム請求テーブル、フェデレーション、Unity Catalogが、単一のガバナンスされた環境に存在します。

この利便性は、集中リスクも生み出し得ます。完全なパターンを採用するチームは、Databricksの識別子、請求スキーマ、権限、クエリサービスへの依存を強めます。

したがって、この記事が示す競争圧力は、断片化した社内スタックに向けられています。ベンダーとプラットフォームチームは、ガバナンスされたクエリでソースに到達できる場合でも、なぜ所有権メタデータのコピーが必要なのかを説明しなければなりません。

ただしDatabricksは、よりシンプルな図が運用の現実に耐えられることを証明する必要があります。これには、カタログ規模、スキーマ進化、アクセス境界、月末レポーティングの要件が含まれます。

1クエリの結果だけでは判断できないこと

概念実証の成功は、信頼できるエンタープライズ・チャージバックを保証しません。なぜなら、クエリの正しさは請求システムの外にある組織メタデータに依存するからです。

サンプル結果は、BackstageリソースをLakebaseの利用状況に対応付けられることを示しています。しかし、大規模組織のインフラのどれほどをこの方法で配賦できるかは示していません。

最初の未解決の問題はカバレッジです。チームは、関連するLakebaseプロジェクトのうち、有効なBackstageエンティティとプロジェクトアノテーションを持つ割合を把握する必要があります。

結果は技術的に正しくても、財務上は不完全であり得ます。カタログ化されていないプロジェクトは、アナリストが別途特定しない限り、所有権に焦点を当てたクエリから単に消えてしまいます。

2つ目の問題は正確性です。有効なプロジェクトIDでも、誤ったサービス、古い所有者、あるいは複数の製品を支える共有リソースを指している可能性があります。

1つのプロジェクトが複数のチームに利用される場合、共有インフラは帰属を複雑にします。単一のBackstageアノテーションでは、あらゆる比例配賦ルールを表現できません。

請求セマンティクスは3つ目の制約を生みます。DBUは消費量を表しますが、完全なコストビューにはクラウドインフラ料金、クレジット、コミットメント、税金、組織上の調整が必要になる場合があります。

FinOpsチームは、このクエリがショーバック、チャージバック、異常調査、容量計画のどれを支援するのかを決めなければなりません。これらの目的には異なる水準の精度が求められます。

履歴上の所有権も、未解決の課題です。ライブカタログは、過去の責任よりも現在の状態を自然に記述します。

4月15日のサービス移管によって、4月7日の消費を誰が所有していたかまで書き換えるべきとは限りません。信頼できる履歴レポートには、時点を考慮した所有権レコードが必要です。

スキーマの安定性も重要です。このクエリはJSONエンティティ内部にアクセスし、特定のアノテーション名に依存します。チームはこのフィールドをサポート対象の契約として管理する必要があります。

Backstageプラグイン、カタログプロセッサ、組織上の慣行は、エンティティの形状を変える可能性があります。Lakebaseの発展に伴い、Databricksも請求メタデータを進化させる可能性があります。

本番利用者は、これらの契約を自動的にテストすべきです。検証ジョブにより、欠落したアノテーション、不明なプロジェクト、重複した割り当て、所有者のいない利用状況を特定できます。

セキュリティには別の圧力があります。Backstageメタデータは社内システムやチーム構造を明らかにする可能性があり、請求データは機微な消費パターンを露出する可能性があります。

両方のデータセットを組み合わせると、1つのクエリから利用できる情報が増えます。これは分析には有用ですが、過度に広い権限がもたらす影響を高めます。

組織には、運用モデルに合致する行レベルまたはビューレベルの境界が必要です。サービス所有者には1チームの利用状況だけで十分かもしれませんが、中央のFinOpsには全社的なカバレッジが必要です。

運用上の依存関係も残ります。フェデレーテッド分析は、ソースデータベース、クエリサービス、アイデンティティ設定、ガバナンスレイヤーが利用可能であることに依存します。

Databricksは、Lakebaseが異なるワークロードのコンピュートを分離すると述べています。それでも、レイテンシ、同時実行性、障害復旧、予測可能な分析パフォーマンスについては、独立した本番環境での検証が重要になります。

元の連載では、認証上の複雑さにも直面しました。Lakebaseには従来のDatabricks個人用アクセストークンではなく、スコープ付きOAuth認証情報が必要でした。

概念実証では、チームはスクリプトを通じて短命な認証情報を更新しました。本番環境のデプロイには、更新済みトークンを安全でない場所に保存しない、サポートされたローテーションプロセスが必要です。

Databricks Appsでは、チームがLakebase resourceをアタッチすると、アプリケーションのサービスプリンシパル向けにPostgreSQLロールを作成できます。この管理された経路は、場当たり的なローカル更新ループより適しています。

より広い教訓は、フェデレーションがガバナンス作業をなくすわけではないということです。ユーザーがビジネス上の質問をした瞬間に、ガバナンスを可視化します。

databricks backstageパターンが成功するのは、カタログの完全性が運用指標になった場合に限られます。この規律がなければ、1クエリのFinOpsは迅速でも部分的な回答を生む可能性があります。

パターンが成立するかを示す3つのシグナル

次の段階では、簡潔なSQL文を称賛するのではなく、採用状況、配賦カバレッジ、本番環境での信頼性を測定する必要があります。

1つ目のシグナルは、Databricks、Thoughtworks、またはBackstageコミュニティによる再利用可能な実装です。チームは、このパターンを支える、保守されたカタログプロセッサ、検証ルール、ダッシュボード、テンプレートに注目すべきです。

サポートされたパッケージがあれば、このアーキテクチャが個別最適化された実証を超えられるという主張を強めます。そのパッケージには、アノテーションスキーマ、認証情報の取り扱い、権限、デプロイメントの実践が定義されるべきです。

再利用可能なコンポーネントが存在しなければ、この主張は弱まります。採用者はそれぞれ、最も障害が発生しやすいマッピングと制御を独力で再現する必要があります。

2つ目のシグナルは、実際のカタログにおける配賦カバレッジです。有用な指標は、現在有効化・検証されたBackstageエンティティと所有者に紐付くLakebase利用量の割合です。

変化する本番環境全体で高いカバレッジが得られれば、フェデレーションが実用的なFinOps入力であることを裏付けます。配賦されない利用状況が継続すれば、メタデータ保守が依然として制約条件であることが示されます。

カバレッジは、鮮度と例外件数と組み合わせて評価すべきです。チームは、新規プロジェクトがどの程度速く現れるのか、またマッピングがどの程度の頻度で検証に失敗するのかを知る必要があります。

3つ目のシグナルは、混在ワークロード下での本番挙動です。組織は、アナリストが大規模カタログに対してフェデレーテッド請求クエリを実行する間のBackstageレイテンシを測定すべきです。

安定したポータル性能は、Databricksのコンピュート分離に関する主張を補強します。クエリ中断、認証情報の障害、ガバナンスのボトルネックが生じれば、重要なワークフローではマテリアライズされたレポーティングレイヤーが有利になります。

1クエリのケーススタディは、明確な仮説を提示しています。共有ガバナンスと分離されたコンピュートは、運用上の所有権と分析コストデータを再接続できる、という仮説です。

現在チームに必要なのは、この仮説が複数アカウント、共有リソース、サービス移管、正式な財務統制にまたがってどのように機能するかについての証拠です。

開発者にとって、直ちに取るべき行動はシンプルです。カタログアノテーションを本番データとして扱い、インフラ識別子を検証し、所有権の変更を明確に定義してください。

プラットフォームリーダーは、既存のコストパイプラインが現在の要件のために存在するのか、それとも古いアーキテクチャ上の制約のためなのかを問い直すべきです。公式レポートがマテリアライズされたままであっても、フェデレーションは調査を短縮できる可能性があります。

FinOpsチームは、拡大する前に、既知の配賦結果に対してdatabricks backstageクエリをテストしてください。重要なのは、1つのクエリが実行できるかどうかではありません。組織が変化しても、その回答が完全で、説明可能で、再現可能であり続けるかどうかです。