クラウドの請求書にはそれぞれストーリーがありますが、それを読み解くには、多数のクラウドおよび AI プロバイダーからの数百万件もの明細行を、CFO、エンジニアリングリード、または FinOps チームが実際に行動に移せるものに翻訳する必要があります。nOps は、まさにその問題を解決します。同社のプラットフォームは、数百社のお客さまに向けて年間50億ドル以上のクラウド利用費を管 理しており、生データの請求および利用データをリアルタイムのダッシュボードに変換しています。これにより企業は、部門、コストセンター、カスタムタグ単位で、予算がどこに使われているかを正確に把握できます。
お客さまは、その可視性が即座に得られることを期待しています。コミットメントの推奨事項が変更されたとき、予期せぬアカウントで支出が急増したとき、あるいは新しい AI ワークロードがコストを押し上げ始めたとき、ダッシュボードにそれがリアルタイムで反映される必要があります。nOps はカスタマイズ可能なダッシュボードビューを提供しており、その背後にあるデータは、お客さま固有の構成全体で常に新鮮で応答性の高い状態を維持する必要があります。Built on Databricks パートナーである nOps は最近、 Apache Druid に代えて Lakehouse//RT を導入し、インフラストラクチャコストを削減しながらそのリアルタイムレイヤーを強化し、単一のガバナンスが効いたプラットフォームへとアーキテクチャを統合しました。
次世代のエンタープライズ顧客に向けたリアルタイムレイヤーの構築
長年、nOps の顧客ダッシュボードの背後にあるリアルタイムクエリレイヤーは Apache Druid で稼働していました。同社はセルフホスト型デプロイからスタートし、その後マネージド Druid サービスに移行しました。しかし、プラットフォームが成長し、エンタープライズ顧客からのレポート要件がますます複雑にな るにつれて、ビジネスのニーズと Druid が提供できる機能とのギャップが広がっていきました。
「必要なパフォーマンスが得られませんでした」と、nOps のエンジニアリングディレクターである Jordan Stein 氏は述べています。「また、そこから価値を引き出すのも本当に困難でした。」課題は速度だけではありませんでした。nOps では、お客さまが独自のマッピング、タグ、グループ化を定義できるため、同じダッシュボードを使っているお客さまは 2 つといません。それらのビューを動かすクエリは非常に複雑になる場合があり、数兆行にわたる文字列一致を含む 30,000 行もの長大な SQL もあります。nOps が、より多くの部門、より多くのコストセンター、より詳細なレポート要件を持つ大規模なエンタープライズ顧客を獲得するにつれて、クエリはさらに長く、より要求の厳しいものになっていきました。これらは nOps が最もサービスを提供したい顧客層でしたが、既存のリアルタイムレイヤーがプラットフォームの足かせとなっていました。
チームには、データを S3 から移動させることなく、それらのクエリの完全な複雑さを処理できるプラットフォームが必要でした。S3 に約 380TB のクラウドインフラストラクチャデータがあり、それが Delta テーブルを支えているため、それを別のサービングレイヤーに複製することは、チームが完全に排除したいと考えていたコスト、レイテンシ、および運用のオーバーヘッドを増やすことになっていました。
Lakehouse//RT: データ移動ゼロ、インスタントロールバック
Lakehouse//RT がリリースされた当時、nOps はすでにプロダクション環境で Databricks メトリックビューを使用しており、アプリケーションデータベースを Lakebase で実行していました。このタイミングは、チームが新しいリアルタイムエンジンを探していた時期と完全に一致していました。「これはまさに私たちが解決しようとしていた問題でした」と Stein 氏は述べています。「アクセス権を取得した瞬間から、Lakehouse//RT が Druid レイヤーの直接の置き換えになることは明らかでした。」
最も重要な要件は、データの移動がゼロであることでした。nOps は S3 に約 380TB のデータを保有しており、それを別のサービングレイヤーに複製するのは費用がかかり、運用の負担も大きかったのです。Lakehouse//RT は、コピーやインジェスョンパイプライン、セカンダリストレージを使用せず、同じ Delta テーブルを直接クエリします。「380テラバイトを超えるデータをさまざまなプラットフォームに移動しようとすることがいかに大変で、費用がかかるかは誰でもわかるでしょう」と Stein 氏は述べています。「Lakehouse//RT を使えば、基盤となるデータを変更する必要は一切ありませんでした。」
また、この移行により、テーブルバージョンの即時ロールバックも可能になりました。Druid では、テーブルバージョンのロールバックには新しいインジェスョンジョブを送信し、最大 3 時間待つ必要がありました。Lakehouse//RT なら Delta テーブルを直接読み取るため、ロールバックは即座に行わ れます。「これが私たちにとって最もインパクトのある変更の 1 つです」と Stein 氏は述べています。「お客さまが表示するデータは、私たちが書き込みを終えたばかりのテーブルと同じです。別の場所にあるそのデータの複製を追いかける必要はありません。」
6倍以上のコスト削減と統合データプラットフォーム
経済的インパクトは絶大です。nOps の以前のアーキテクチャは、常時稼働の Druid クラスターに依存していました。Lakehouse//RT のサーバーレスオートスケーリングにより、チームはリアルタイムインフラストラクチャのコストを以前の約 16% に削減し、6 分の 1 以下に抑えることができました。また、この移行により、セカンダリ Druid ストレージ層の S3 外に保存されていた、重複する 40TB のサービングデータも排除されました。
ダッシュボードにとどまらず、nOps は内部の AI エージェントや MCP (Model Context Protocol) アーキテクチャも Lakehouse//RT 経由でルーティングしています。これにより、応答時間が大幅に短縮され、お客さま向けの対話型チャット体験の品質が向上しました。「バックエンドで書き込んでいるデータとフロントエンドでお客さまが表示するデータの間で、基盤となるデータを同じにできることは非常に大きいです」と Stein 氏は述べています。「これら相互依存するアーキテクチャを 1 か所にまとめることには、多大な価値があります。」
Built on Databricks パートナーである nOps の経験は、データ集約型アプリケーションを構築する ISV パートナーにとって、Lakehouse//RT がなぜ最適であるかを示しています。観測可能性 (オブザーバビリティ) やクラウドコスト管理プラットフォームは、膨大なデータボリューム、複雑な顧客定義のクエリ、そしてリアルタイムの応答性に対する期待を扱います。Lakehouse//RT を使用することで、ISV は、別のリアルタイムデータベースを維持することなく、レイクハウス内のデータを直接クエリしてそれらのワークロードを処理でき、インフラストラクチャコストと運用の複雑さの両方を削減できます。ベータ版の期間中に nOps が Databricks のプロダクトチームと密接に協力したことで、移行がさらに加速しました。「このようなパートナーシップは、新しいテクノロジーを推進し、価値あるフィードバックを提供できるチームがある場合に非常に価値があります」と Stein 氏は述べています。
nOps は、マネージド Apache Druid のリアルタイムクエリレイヤーを、Reyden エンジンを搭載した Databricks Lakehouse//RT に置き換えました。Lakehouse//RT は S3 に保存されている同じ Delta テーブルを直接クエリするため、個別のサービングデータベース、データの重複、およびインジェスョンパイプラインが不要になります。