サーバー管理不要でフルスタック開発：Databricks AppsとLakebaseで本番運用レベルのデータ＆AIアプリを構築する

本番運用データ・アプリケーションへの挑戦

本番運用対応のデータ・アプリケーションの構築は複雑です。アプリのホスティング、データベースの管理、システム間のデータ移動には、別々のツールが必要になることが多く、各レイヤーは、セットアップ、メンテナンス、デプロイでオーバーヘッドが発生します。

リアルタイムのstate管理が必要なGenAIアプリを構築するための最適なエンタープライズプラットフォームとして、Databricks Data + AI Platformが挙げられます。Databricksは、すべてを単一のプラットフォームであるDatabricks Data + AI Platformに統合することで、これを簡素化します。Databricks Appsはserverlessコンピュートでウェブアプリケーションを実行します。LakebaseはUnity Catalogと同期するマネージドPostgresデータベースを提供し、アプリが管理されたデータに高速アクセスできるようにします。また、Declarative Automation Bundles（DABs）を使用すると、コード、インフラストラクチャ、データパイプラインをまとめてパッケージ化し、1つのコマンドでデプロイできます。

このブログでは、Unity CatalogデータのLakebaseへの同期から、Databricks上でのウェブ・アプリケーションの実行、Asset Bundlesを使ったデプロイの自動化まで、実際のデータ・アプリケーションを構築しデプロイするために、これら3つのピースがどのように連携するかを紹介します。

アーキテクチャと仕組み

このパターン全体を示すタクシー旅行アプリケーションを紹介しよう。ReactとFastAPIを使ったアプリケーションで、Lakebaseの同期テーブルからデータを読み込み、Unity Catalog Deltaテーブルから数秒以内にデータを自動更新します。

次の図に、ソリューション アーキテクチャの簡略図を示します。

Databricks Appsは、ユーザーがデータを探索および可視化するためのフロントエンドとして機能します。Lakebaseは、アプリがクエリーを実行するPostgresデータベースを提供し、同期されたテーブルによってそれをUnity Catalogからのライブデータに近い状態に保ちます。Declarative Automation Bundlesは、アプリ、データベース、データ同期といったすべてのリソースを、バージョン管理された1つのユニットとして定義、デプロイすることで全体をまとめます。

主なソリューション コンポーネント:

• Databricks App: ユーザーは、React、TypeScript、Vite、FastAPI を使用して構築されたウェブ アプリケーションを操作します。このアプリは、Lakebase Postgres データベースに保存されている Unity Catalog の同期テーブルからデータを読み取ります。
• Unity Catalog同期テーブル: マネージド同期パイプラインを介してUnity Catalogテーブルと自動的に同期される、読み取り専用のPostgresテーブルです。Lakebaseデータベース インスタンス上でランされます。
• Lakebase データベース インスタンス: Lakebase のストレージとコンピュートを管理し、Databricks アプリが接続するための Postgres Endpoint を提供します。
• Unity Catalogテーブル ： すべてのデータベース・workspaceで利用可能な samples.nyctaxi.trips サンプル・テーブルから クローンされた、ニューヨークのタクシー乗車に関するデータを含むDeltaテーブルです 。
• Declarative Automation Bundles (DABs): アーキテクチャの主要な要素はすべて、DABs バンドルを使ってコードで定義されます。

このサンプル アプリは、最近のタクシー乗車履歴をテーブル形式とグラフ形式の両方で表示し、新しい乗車を自動的にポーリングします。Unity Catalog の Delta テーブルをミラーリングした Lakebase 同期テーブルからデータを読み取ります。 

同期されたテーブルは自動的に更新されるため、Unity Catalogテーブルの変更は数秒以内にアプリに反映されます。カスタムETLは不要です。

ソース Delta テーブルに新しいデータを挿入し、同期されたテーブルをリフレッシュすることで、これをテストすることができます：

次に、同期済みの trips_synced テーブルの refresh を trigger します。

同期を実行するマネージドパイプラインは、ソースDeltaテーブルからターゲットPostgresテーブルへのスナップショットコピーを実行します。

数秒のうちに、新しい記録がダッシュボードに表示されます。このアプリは、更新をポーリングし、ユーザーがオンデマンドでrefreshできるようにするもので、Lakebaseが余分なエンジニアリングなしに運用データを最新に保つ方法を示しています。

Lakebase の同期テーブルが、カスタム ETL コードやチーム間の調整を必要とせずに、すべての同期を自動的に処理するため、このようなシームレスなデータフローが実現します。

Databricksアプリの解剖学

Databricks アプリ内で、ソリューションのさまざまな要素がどのように連携するのかを見てみましょう。

認証とデータベース接続

各 Databricks アプリには、作成時に一意の service principal ID が割り当てられます。アプリは、この ID を使用して Lakebase などの他の Databricks リソースとやり取りします。

Lakebase は、OAuth machine-to-machine (M2M) 認証をサポートしています。アプリは、Databricks SDK for Python の WorkspaceClient とその service principal の認証情報を使用して、有効なトークンを取得できます。WorkspaceClient は、有効期間の短い（1 時間）OAuth トークンを更新します。

このアプリは、トークンを使用して、Psycopg Python Postgres アダプターで Lakebase への接続を確立します:

Postgres のホストとデータベース名は、 アプリ用の Lakebase リソース を使用すると、Databricks アプリの環境変数として自動的に設定されます。

Postgres ユーザーは、アプリの service principal（Databricks アプリにデプロイされた場合）、またはアプリをローカルで実行しているユーザーの Databricks ユーザー名のいずれかです。

RESTful FastAPI バックエンド

アプリのFastAPIバックエンドは、この接続を使用してLakebaseにクエリーを実行し、同期されたテーブルから最新のトリップデータを取得します：

API Endpoint を提供するだけでなく、FastAPI は StaticFiles クラス を使用して静的ファイルを提供することもできます。Vite のビルドプロセスで React フロントエンド (app/frontend) をバンドルすることで、FastAPI で提供可能な一連の静的ファイルを生成できます。

リアクト・フロントエンド

リアクト・フロントエンドは、FastAPI endpoint を呼び出してデータを表示します:

サンプル・アプリケーションは、可視化のためにag-gridとag-chartsを使用し、数秒ごとに新しいデータを自動的にチェックします：

Declarative Automation Bundles（DABs）リソースを定義する

上記に示したすべての Databricks リソースとアプリケーション コードは、1 つのソースコード リポジトリで DABs バンドルとして維持できます。これはまた、すべてのリソースを単一のコマンドで Databricks workspace にデプロイできることも意味します。デプロイの詳細な手順については、GitHub リポジトリ を参照してください。

これによりソフトウェア開発ライフサイクルが簡素化され、CI/CD のベストプラクティスを用いて、開発、ステージング、本番運用環境にデプロイできるようになります。

以下のセクションでは、バンドルファイルについて詳しく説明します。

バンドル構成

databricks.yml には、バンドル設定と含まれるリソースという形式で DABs バンドル構成が記述されています。

この例では、開発環境とステージング環境のみを定義しています。本番運用で使用する場合は、環境の追加を検討することをお勧めします。 より高度な設定例については、databricks-dab-examples repository と DABs ドキュメントをご参照ください 。

LakebaseのセットアップとUnityカタログとの同期

DABでLakebaseインスタンスを定義するには、 database_instances リソースを使用します。最低限、インスタンスの容量フィールドを定義する必要があります。

さらに、Unity Catalog テーブルと Postgres テーブルの間に管理された同期パイプラインをセットアップする synced_database_tables リソースを定義します。

そのためには、source_table_full_nameでソース・テーブルを定義します。primary_key_columnsフィールドで定義された更新を処理するには、Unity Catalogのソーステーブルに一意の (複合) 主キーが必要です。

Lakebaseにおけるターゲットテーブルの位置は、logical_database_nameとして指定されたターゲットデータベースオブジェクトと、nameとして定義されたテーブル名によって決定されます。

同期テーブルも Unity Catalog オブジェクトです。このリソース定義では、databricks.yml で定義された DABs 変数を使用して、ソーステーブルと同じカタログとスキーマに同期テーブルを配置します。これらのdefaultは、異なる変数値を設定することで上書きできます。

今回の使用例では、SNAPSHOP同期モードを使用します。利用可能なオプションについては、考察とベストプラクティスのセクションをご参照ください。

Databricks Apps リソース

DABs を使用すると、Databricks Apps のコンピュートリソースを apps リソースとして、またアプリケーションのソースコードも 1 つのバンドルで定義できます。これにより、Databricks のリソース定義とソースコードの両方を単一のリポジトリで管理できます。この例では、FastAPI と Vite に基づくアプリのソースコードは、プロジェクトのトップレベルの app ディレクトリに格納されます。

設定は、database.ymlリソース定義で定義されたdatabase_nameとinstance_nameを動的に参照します。

データベースは、 DABで定義できる アプリリソースとしてサポートされています。 データベースをアプリリソースとして 定義することで 、アプサービスの主体がLakebaseインスタンスとやり取りする際に使用するPostgresロールが自動的に作成されます。

考察とベストプラクティス

モジュール式で再利用可能なバンドルを作成

この例では開発環境とステージング環境にデプロイしていますが、DABsでは開発ライフサイクルに合わせて複数の環境を簡単に定義できます。Azure DevOps、GitHub Actions、またはその他のDevOpsプラットフォームでCI/CDパイプラインを設定することで、これらの環境間でのデプロイを自動化できます。

DABs の 置換と変数を 使用して、環境固有の設定を定義します。例えば、開発用と本番運用で異なるLakebaseインスタンスキャパシティ構成を定義し、コストを削減することができます。同様に、環境固有のデータレイテンシー要件に対応するために、同期するテーブルに対して異なる Lakebase 同期モードを定義することができます。

レイクベースの同期モードを選択し、パフォーマンスを最適化する

適切な Lakebase の sync mode を選択することは、コストとデータの鮮度のバランスを取る上で重要です。 

マネージド同期パイプラインに通知を設定し、障害が発生した場合にアラートを出します。

クエリーのパフォーマンスを向上させるには、適切な インスタンス容量 を選択して、Lakebase データベース インスタンスのサイズを適正化します。クエリー パターンに一致する インデックス を Postgres の同期テーブルに作成することを検討してください。プリインストールされている pg_stat_statements 拡張機能 を使用すると、クエリーのパフォーマンスを調査できます。

アプリの本番運用に向けた準備

このサンプル アプリケーションでは、ポーリングベースのアプローチを実装して Lakebase から最新のデータを取得します。要件に応じて、サーバーリソースをより効率的に使用し、データ更新の適時性を高めるために、WebSockets や Server-Sent-Events に基づくプッシュベースのアプローチを実装することもできます。

FastAPIバックエンドがデータベース操作をtriggerする必要性を減らすことで、より多くのアプリ・ユーザーにスケールするには、例えば、 クエリー結果をインメモリでキャッシュするfastapi-cacheの使用など、キャッシュの実装を検討しましょう。

認証と認可

認証と認可には OAuth 2.0 を使用します。ローカルマシンでの開発時には、Databricks CLI を使用して OAuth U2M 認証を設定し、Lakebase のようなライブ Databricks リソースとシームレスにやり取りできるようにします。

同様に、デプロイされたアプリは、 他の Databricks サービスとの OAuth M2M 認証および認可のために、関連するサービスプリンシパルを使用します 。あるいは、 アプリユーザに代わって Databricks リソース上でアクションを実行するために、アプリのユーザ認証を 設定します 。

一般的なベストプラクティスとセキュリティのベストプラクティスについては、Databricks AppsドキュメントのBest practices for appsをご参照ください 。

まとめ

本番向けのデータアプリケーションを構築するために、デプロイ、データ同期、インフラ管理といった複数のツールを行き来する必要はもうありません。
Databricks Apps を使えば、Python や Node.js アプリケーションをインフラ管理なしで実行できるサーバーレスコンピュートが手に入ります。
Lakebase の同期テーブル は、Unity Catalog の Delta テーブルから Postgres へ低レイテンシでデータを自動連携し、カスタム ETL パイプラインを不要にします。
さらに Declarative Automation Bundles (DABs) によって、アプリケーションコード、インフラ定義、データ同期設定をひとつのバージョン管理されたパッケージとしてまとめ、環境間で一貫したデプロイが可能になります。

複雑なデプロイは開発の速度を落とします。
変更をすぐに、そして自信を持ってリリースできなければ、反復開発は滞り、環境ごとの差異が発生し、チーム間の調整にも時間が浪費されます。

しかし DABs によってアプリケーションスタック全体を「コード」として扱うことで、CI/CD の自動化を実現し、開発・ステージング・本番のどの環境でも一貫したデプロイが行えます。
つまり、面倒なデプロイパイプラインと戦うのではなく、チームは本来の価値である“機能開発”に集中できるようになります。
これが、プロトタイプから本番運用へスムーズに移行するための新しいアプローチです。

この一連のサンプルは、GitHub repositoryで公開されており、段階的なデプロイ手順も確認できます。

無料トライアル

Lakebase 、 Databricks Apps 、 Declarative Automation Bundles の詳細については、Databricksドキュメントをご参照ください。Databricks Appsに関する開発者向けリソースについては、 Databricks Apps Cookbook および Cookbook Resource Collection をご参照ください。