によって ブライアン・スミス（Bryan Smith） による投稿
nOpsは、年間40億ドル以上のクラウド支出を管理するDatabricks Built Onパートナーであり、本番アプリケーションをDatabricks Lakebaseに移行しました。その結果、アプリケーションと分析の間の連携を排除した、より高速でシンプルなアーキテクチャと、同様のことを目指すISV向けのプレイブックが実現しました。
Databricks上で構築するすべてのISVは、最終的に同じアーキテクチャの岐路に立たされます。分析はLakehouseにありますが、アプリケーションは低レイテンシの読み書きのためにリレーショナルデータベースを必要とします。そこで、別のPostgresインスタンス（RDSかもしれないし、自己管理型かもしれない）を追加すると、2つのシステムを同期させるためだけにETLパイプライン、cronジョブ、変更検出ロジックを維持することになります。
nOpsは何年もその現実を生きてきました。そして、より良い方法を見つけました。
ご存知ない方のために説明すると、nOpsはAWS、GCP、Azure全体でコミットメントベースの割引を管理する自動化されたクラウドコスト最適化プラットフォームです。彼らのアプローチは明確に「常時稼働」です。機械学習を使用して、コミットメントのロックインリスクに対する効果的な節約率をバランスさせながら、コミットメントを時間単位で購入および交換します。モデルはパフォーマンスベースです。nOpsは、生成した増分節約の一部しか請求しません。
これはデータ集約型の操作です。nOpsは毎時間、数千の顧客アカウントの使用パターンを分析し、3つの主要なクラウドプロバイダーと数十のサービスにわたるコミットメントポートフォリオを評価し、自動化された購入決定を行います。さらに、集中化されたFinOpsプラットフォームを通じて、コストの可視性、予測、異常検出を提示します。
これらすべてのアナリティクスのバックボーンは、長年Databricks Lakehouseでした。しかし、顧客が節約額を確認し、予算を管理し、コストデータを探索するためにログインするプラットフォームであるフロントエンドアプリケーションには、さらに多くのものが必要でした。
nOpsの以前のアーキテクチャは、Databricks上のISVにとってよくあるパターンでした。高度な分析とメトリック計算はLakehouseで実行されていました。顧客向けのデータ（アカウント構成、ユーザー設定、急速に変化するクライアント固有の状態）は、サードパーティベンダーと自社開発ソリューションによって強化された別のリレーショナルデータベースに存在していました。
これら2つのシステム間の継ぎ目は、実際の摩擦を生み出しました。フロントエンドデータベースとLakehouseを同期させるために、スケジュールされたジョブとcronベースの変更検出が必要でした。一方のシステムで「ライブ」だったデータが、もう一方のシステムに表示されるまでに数分以上かかることがありました。また、独自のスケーリング、バックアップ、セキュリティの懸念を持つ別のデータベ ーススタックを管理する運用上のオーバーヘッドは、nOpsが最も得意とすること、つまりコミットメント自動化の構築からエンジニアリング時間を奪っていました。
nOpsが2026年初頭にAWSのみからGCPおよびAzure全体でのマルチクラウドカバレッジに拡大したとき、増加するワークロードはこのアーキテクチャに負担をかけました。チームはプラットフォームを再構築することを決定し、今回は専門分野に焦点を当て、機能するインフラストラクチャを選択しました。
nOpsは、Lakehouseに直接統合された完全に管理されたPostgreSQLデータベースであるDatabricks Lakebaseを、新しいプラットフォームのOLTPバックボーンとして選択しました。
nOpsのプロダクトディレクターであるJordan Steinは、Lakebaseが適切だった3つの要因を挙げています。
nOpsの新しいアーキテクチャは次のようになります。
Lakebaseは、フロントエンドアプリケーションとAIインフラストラクチャの両方の中央Postgresデータベースおよび単一の真実の源として機能します。
Databricks Lakehouseは、分析とメトリック計算のためにLakebaseから継続的にデータを消費します。
nOpsプラットフォームは、Databricks Metric Viewsを自動的に検出し、提示するため、Lakehouseで計算された標準化されたメトリックがフロントエンドに一貫して表示されます。
データは一方向に流れ、LakebaseからLakehouseへ分析のために流れ、直接書き戻す必要はありません。これにより、アーキテクチャがクリーンに保たれ、真実の源が曖昧になりません。
スタックの残りの部分は同じアプローチに従います。ホスティングとオブザーバビリティにはVercel、認証にはWorkOS、そしてデータ関連すべてにはDatabricksを使用します。
Jordan Steinは最近、パートナーのスポットライトプレゼンテーションで、nOpsの完全なLakebase移行ストーリーを詳しく説明しました。移行がどのように進んだか、パフォーマンスについて何が驚きだったか、そしてLakehouseの統合がデータエンジニアリングワークフローをどのように変えたかを聞くには、ビデオをご覧ください。
nOpsのストーリーはユニークではありません。Databricks上で構築するほぼすべてのISVは、同じOLTPと分析の緊張に直面しています。注目すべきは、Lakebaseがそれをどれほどクリーンに解決するかということです。
同期のコストを排除します。あらゆるISVのスタックで最もコストのかかるコードは、多くの場合、システム間でデータを移動するコードです。LakebaseのUnity Catalogとのネイティブ統合とワンクリックDelta Lake同期は、カスタムETLパイプラインをマネージドインフラストラクチャに置き換えます。これは取り戻せるエンジニアリング時間です。
1つのガバナンスモデル。OLTPデータベースがUnity Catalogアセットとして登録されると、運用データと分析データの両方で統合されたガバナンス、リネージ、アクセス制御が得られます。セキュリティポリシーを2か所で管理する必要はなくなります。
Postgres互換性により書き換えはゼロ。Lakebaseは完全に管理されたPostgreSQLです。既存のライブラリ、ORM、SQLツールはそのまま動作します。pgvectorやPostGISなどの拡張機能もサポートされています。クエリを書き直すのではなく、新しい接続文字 列にアプリケーションをポイントすることで移行できます。理にかなったスケールエコノミクス。スケールツーゼロの従量課金制により、アイドル状態の容量に対して料金を支払うことはありません。ワークロードが変動するISV（そしてワークロードが変動しないISVはありますか？）にとって、これはユニットエコノミクスに直接影響します。
より速く出荷。アプリケーションデータベースとデータウェアハウスが同じプラットフォームである場合、あるカテゴリの統合作業がなくなります。チームは配管を維持するのではなく、機能をリリースします。
nOpsは、革新的なBuilt Onパートナーがどのようなものかを示す良い例です。Lakebaseが複数のリリースサイクルを経て成熟するのを待つのではなく、彼らは早期にアーキテクチャの適合性を認識し、本番移行にコミットし、すでに結果を見ています。データパイプラインの高速化、運用オーバーヘッドの削減、そして顧客エクスペリエンスの向上です。
この早期に動く意欲は、戦略的にも賢明です。今Lakebase上に構築することで、nOpsは、まだ別々のデータベーススタックを継ぎ合わせている競合他社よりも、Databricksプラットフォームとの統合が強化されています。彼らのプラットフォームは運用が容易で、拡張も迅速です。
Lakebaseを探索する。Databricks上で構築している、または構築を検討しているISVの場合は、Lakebaseについて、そしてそれがどのようにアーキテクチャを簡素化できるかについて詳しく学んでください。
nOpsを探索する。AWS、GCP、またはAzure全体でコミットメントリスクなしにクラウドコストを削減したい組織の場合は、nOpsにアクセスして、Databricks Lakebaseによって強化された自動化された最適化プラットフォームがどのように役立つかを確認してください。
(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事
ブログを購読して、最新の投稿を受信トレイにお届けします。