2026年11月5日

Databricks Apps のスケーリングに関するビルダーズガイド

利用増加に伴いアプリの速度と信頼性を維持する方法

Databricks Appsのスケールは、コードを書く前から始まります。アプリの応答速度やピーク時の想定ユーザー数を決めた上で、重い処理を適切なサービスに割り当てます。アプリのコンピュートはUIの提供と呼び出しの調整を行います。
スケールするコードは、サービスの応答を待つ間もアプリを応答可能な状態に保ち、ユーザーごとのキャッシュを使用し、状態を復元できるようにします。ソフトな状態は再構築できますが、ハードな状態はLakebaseまたはUnity Catalogのテーブルに保存されるため、どのインスタンスでもセッションを再構築できます。
負荷テストとテレメトリーを使用して、インスタンスのサイズ、ワーカー数、インスタンス数を決定します。Lakebaseの接続数を管理し、測定された需要と可用性の目標に合わせてコンピュートを追加します。

おめでとうございます。Databricks Appsでアプリを構築し、数人のユーザーから組織全体で数百人、数千人規模へと利用が拡大しました。ユーザーは高速な応答と安定稼働を求めています。また、上長は、多数のインスタンスにまたがる大規模（XLarge）なコンピュートのコスト支払いに頭を悩ませているかもしれません。

高速に動作し、停止せず、増大する需要を処理できるアプリをどのように作成すればよいでしょうか？直感的な答えはコンピュートを増やすことですが、それでは不十分です。リクエストがどこで時間を消費しているか、アプリがスケールするように構築されているか（フレームワーク、非同期コード、複数のインスタンスで実行する能力など）を把握し、プラットフォームが容易にスケールアップまたはスケールアウトできるようにすることが重要です。

このガイドでは、Databricks Appsを4つの段階（設計、構築、テストとデプロイ、運用）にわたってスケールする方法について説明します（図1）。

このガイドの焦点は主に大規模なアプリケーションのパフォーマンスとレジリエンスであり、デプロイの自動化や、アプリと連携する他のDatabricksサービスのパフォーマンス最適化およびスケーリングについてはカバーしていません。

図1: Databricks Appのスケーリングの4つの段階。

優れたスケーリングの決定は、コードが書かれる前から始まります。アプリにユーザーが何を求めているのか合意し、ワークがどこで実行され、データがどこに保存されるかを決定します。

目標から始める：ピークユーザー数とレイテンシ

アーキテクチャを選択する前に、アプリがどれだけの負荷を処理する必要があるか、そして良好なエクスペリエンスとはどのようなものかを明確にすることが役立ちます。主に2つの目標に合意することをお勧めします。

パフォーマンス：主要なアクションはどれくらい素早く応答しなければならないか？平均値では見えない遅いエクスペリエンスを捉える、p95などのパーセンタイルに基づいたエンドツーエンドのレイテンシ目標をお勧めします。UIのレンダリングを含め、コールドスタートは別個に扱ってください。ストリーミングAI応答の場合は、最初のトークンまでの時間（time to first token）も重要です。
スケーラビリティ：ピーク時に何人のユーザーがアクティブか、どれくらいの頻度で利用するか、そしてアプリはどれくらいの成長をサポートすべきか？月末などの忙しい時期は、レイテンシとエラー率の目標内でアプリが処理しなければならない負荷であるため、この見積もりに含めてください。

これらと並行して、どのワークが再起動を生き延びなければならないかを決定し、クリティカルな依存関係がそれをサポートできることを確認します。これにより、ステートの分割方法や実行するインスタンス数が決まります。

次に、ダッシュボードを開く、質問を送信するなど、いくつかのユーザーの操作フローをスケッチします。各アクションについて、呼び出すサービス、呼び出しの概算回数、相互依存関係、完了すべき速度、およびキャッシュされたデータの許容可能な古さをメモします。これらの前提条件がアーキテクチャと最初のテスト目標を形作ります。プロトタイプが実行されたら、実際の呼び出しを測定して修正できます。

ある小売企業が2,000人の店長に在庫確認用のアプリを提供しており、Lakebaseによって支えられていると仮定します。ブラックフライデーの最も忙しい時間帯には、そのうち200人が同時に使用しています。それぞれが平均して1分あたり2回の在庫確認を行う場合、それは1分あたり400回の確認になります。各確認がLakebaseに対して3つのSQL文を実行する場合、その時間帯の平均で1分あたり1,200文、つまり1秒あたり20文の実行が予想されます。

これは同時実行数ではなく、クエリレートを見積もるものです。バーストと成長をテストし、ライブの利用状況に対して検証し、接続を別個に予算化してください（「Lakebaseへの接続の予算化」を参照）。

設計：アーキテクチャの計画

アプリのコンピュートはアプリのサービング用に維持する

アプリのコンピュートは、UIのサービングと呼び出しの調整を行うためのものであり、重い処理を行うためのものではありません。各種類のワークを、それに適した専用のサービスに送信することをお勧めします（図2）。長時間の呼び出しについては、完了まで1つのリクエストを開いたままにするのではなく、例えばジョブとしてバックグラウンドでワークを実行し、UIにステータスをポーリングさせたり、ストリーミングされた更新を受信させたりします。

ユーザーが書いたコードやエージェントによって生成されたコードなど、制御していないコードをアプリで実行する必要がある場合は、アプリ内で実行しないでください。Databricks Sandboxで実行してください。これはカスタムイメージから起動できる、CPUとメモリの使用量をユーザーにサービスを提供するインスタンスから切り離すことができる独立した環境です。

図2: 各種のワークが実行される場所とステートが保存される場所。

スケールの計画とフレームワークの選択

アプリを使用する人が増えた場合、容量を追加する方法は2つあります。1つは、より大きなコンピュートサイズに変更して各インスタンスのCPUとメモリを増やすスケールアップ（垂直スケーリング）であり、もう1つは、インスタンスを追加してリクエストの負荷を分散するスケールアウト（水平スケーリング）です。重いワークがアプリの外で実行されている場合、通常は一度に処理できるリクエスト数が制限要因になります。

例えば、ブラックフライデーのケースでは、個々の在庫確認は軽いものですが、200人の店長からの確認がバーストとして同時に到着する可能性があります。インスタンスを増やすことでそれらのリクエストが分散され、アプリが追加のコア（通常はより多くのワーカーを実行することによる）を使用できる場合は、より大きなインスタンスが役立ちます。大きな参照データセットやモデルをメモリに保持するアプリは、異なる制限にヒットします。より大きなインスタンスは必要なメモリを提供しますが、各インスタンスが独自のコピーを読み込むため、インスタンスを追加しても役立ちません。Mediumから開始し、このガイドの後半にある負荷テストによって必要なものを明らかにすることができます。

フレームワークは後から変更することが難しいため、ここで選択する価値があります。Databricks AppsはPythonまたはNode.jsで構築されたアプリを実行し、以下のフレームワークに限定されません。ほとんどの新しいアプリに対しては、databricks apps initおよびDatabricksエージェントのスキルがデフォルトで使用するTypeScript SDKであるAppKitをお勧めします。キャッシング、テレメトリー、リトライロジック、エラーハンドリングが組み込まれており、このガイドのいくつかのプラクティスを開始するための基盤を提供します。AppKitはデフォルトでインスタンスごとに1つのNode.jsプロセスを実行するため、最も簡単なスケーリング方法はインスタンスを追加することです。

すでにアプリをお持ちの場合、またはバックエンドにPythonが必要な場合：

APIバックエンドを備えたJavaScriptフロントエンド（FastAPI、Flask、またはExpress）：UIステートをブラウザに保持し、サーバー側のステートをワーカーおよびインスタンス間で復元可能にします。Pythonバックエンドは、UvicornやGunicornなどを使用して、インスタンスごとに複数のワーカーを実行できます。Node.jsバックエンドはデフォルトでインスタンスごとに1つのプロセスを実行するため、インスタンスを追加してスケールさせます。
StreamlitまたはGratioフレームワーク：Pythonで素早く構築されたデータおよびAIツールに適しています。Streamlitは単一プロセスとして実行され、どちらもインスタンスローカルのセッション処理に依存しているため、再起動やスケーリング中のセッションの継続性をテストしてください。インスタンス間でシームレスな復元を伴ってスケールする必要があるアプリの場合、これらのフレームワークは推奨されないため、上記のいずれかのアプローチを優先してください。

どれを選択する場合でも、サーバーメモリにセッションステートを保持する場合は、スケールアウトする前に、セッションが別のインスタンスに移動したときに何が起こるかをテストする価値があります。

再起動や再スケーリングを生き延びるアプリケーションステートの計画

ほとんどのDatabricks Appsはメモリ内に何らかのステートを保持しますが、どの部分を失っても問題ないかを把握している限り、それは問題ありません。有用な第一歩は、各セッションが保持しているものと再起動を生き延びなければならないものをリストアップし、それをソフトステートとハードステートに分割することです。

項目ソフトステートハードステート項目速度やコンテキストのために保持される一時的な作業データ耐久性をもって保持される信頼できる情報源（ソースオブトゥルース）例インメモリコンテキスト、キャッシュ、進行中の作業ビジネスレコード、チェックポイント、保存された設定保存場所通常はインスタンスメモリまたはローカルディスク（1つのインスタンスに紐付く）LakebaseまたはUnity Catalogのテーブル（すべてのインスタンスから利用可能）失われた場合可能な限りハードステートから再構築される復元要件の範囲内で、再起動や障害を生き延びなければならない

その分割がどのように機能するかは、アプリの種類によって異なります。

AIエージェント：ループの実行中は会話コンテキスト、ツール出力、プランをソフトステートに保持し、意味のあるステップごとにチェックポイントを保存します。
ワークフローアプリ：進行中のステータスをUIにストリーミングまたはポーリングし、完了した各ステップを保存します。
ダッシュボード：フィルター値、参照リスト、小さなデータセットをメモリに保持し、ユーザー設定や保存されたフィルターをハードステートとして保存します。

図3: セッションが移動した際、別のインスタンスがハードステートからそれを再構築できる。

Databricks Appsはベストエフォートベースで各ユーザーを同じインスタンスに維持し（セッションアフィニティ）、必要に応じてセッションを再バランスするため、アプリがローカルに保持するユーザーごとのキャッシュは通常利用可能な状態を維持します。それでも、再起動、障害、スケーリングの変更によってセッションが移動する可能性があるため、別のインスタンスがハードステートからそれを再構築できなければなりません（図3）。

構築：スケールし、再起動を生き延びるコードを書く

目標とアーキテクチャが整ったら、次のステップは、セッションが移動したりインスタンスが停止したりした場合を含め、負荷の下で耐えうるコードを書くことです。

必要になる前にアプリを計装する

最初からテレメトリーを有効にしておくことをおすすめします。そうすることで、必要なときにすぐにデータを利用できるようになります。アプリのテレメトリーは、OpenTelemetryを介してUnity Catalogのテーブルにログ、トレース、メトリクスを書き込みます。アプリで有効にするとログは自動的に届きますが、トレースとメトリクスには計装（インストルメンテーション）が必要です。

SQL、データベース、モデル、APIの呼び出しの前後にカスタムスパンを作成し、処理にどのくらいの時間がかかっているかを確認できるようにする必要があります。また、キャッチした例外もスパンに記録しておくと、トレースに表示されるようになります。トレースIDとリクエストIDを使用すると、1人のユーザーのリクエストを複数のインスタンスにわたって追跡できるようになります。たとえば、SQL呼び出しの前後のスパンは次のようになります。

非同期コードを使用して無駄な呼び出しを減らす

ほとんどのアプリは、SQLクエリ、モデルの呼び出し、外部APIなどの別のサービスの応答を待つことに時間を費やしています。ブロッキング呼び出しの場合、待機するたびに呼び出し全体の間実行スロットが占有されます。少数の遅い呼び出しが発生するだけで、その容量が枯渇してしまう可能性があります。そのため、I/O集約型の処理では非同期ハンドラーが重要になります。ハンドラーがモデルやデータベースの呼び出しを待機している間、それらの呼び出しが非ブロッキングであれば、1つのワーカーが待機中も他のリクエストの処理を継続できます。トレースやシステムメトリクスを確認すると、これがいつ該当するかがわかります。リクエストの大部分の時間がSQL、モデル、またはAPIのスパンで費やされていて、CPU使用率が低いままで同時ユーザー数に応じてレイテンシーが上昇する場合、リクエストはブロッキング呼び出しの背後でキューイングされている可能性が高くなります。

非同期を使用している場合でも、クエリを1つずつ順番に実行すると、1つのリクエストが遅くなることがあります。独立したクエリを同時に開始する（たとえば、asyncio.gatherやPromise.allを使用する）ことで、リクエストの処理時間を最も遅いクエリの処理時間に近い長さに抑えることができます。また、並列実行する数を制限することも価値があります。これにより、1つのリクエストがウェアハウスやデータベースを圧迫するのを防ぐことができます。多くの場合、N+1クエリを実行するよりもクエリをまとめる方が優れています。N+1クエリでは、アプリがリストを取得した後にアイテムごとにさらに1つのクエリを実行しますが、joinやINの句を使用すると、1つまたは2つのクエリで同じ処理を行うことができます。

デフォルトでユーザーごとにデータをキャッシュする

キャッシュはアプリを高速化しますが、データの漏洩につながる可能性もあります。アプリレベルのキャッシュではUnity Catalogの権限が適用されないため、共有キャッシュによってあるユーザーのデータが別のユーザーに表示されてしまう可能性があります。キャッシュキーは、ユーザーの検証済みIDとクエリパラメータ、および必要に応じてセッションによってスコープを設定します。クライアントが検証せずに送信したIDをキーにすることは絶対に行わないでください。キャッシュされたデータは、全員にとって同一である場合にのみ共有してください。多くのユーザーが同時に読み取る共有エントリの場合、1つのリクエストに期限切れのエントリを更新させ、他のリクエストはそれを待機させるようにします。これにより、すべてのリクエストが一斉にウェアハウスにアクセスするのを防ぐことができます。たとえば、AppKitのキャッシュは、各インスタンス内で同時に発生したキャッシュミスを重複排除します。

アプリコンテナーの再起動時やセッションの移動時

ソフトステートとハードステートの設計を実践するには、いくつかの推奨事項に従うことになります。

再起動やデプロイメントを生き延びる必要があるものはすべて永続化します。メモリのみでも使い捨てのキャッシュには問題ありませんが、ユーザーが失うことのできない作業には適していません。
作業をやり直したくない箇所には必ずチェックポイントを設定し、再試行が安全に行えるようにステップをべき等にします。
セッションをポータブルにし、どのインスタンスでもハードステートからセッションを再構築できるようにします（図3）。必要なものだけを再読み込みし、繰り返し読み込みを避けるためにキャッシュします。
ブラウザアプリではセッションアフィニティが自動的に取得されます。ステートフルなAPIクライアントの場合は、安定したX-Routing-Keyヘッダーを送信し、ソフトステートを所有するものをキーにします。テナントIDではなく、会話IDやユーザーIDなど、負荷を分散するのに十分な固有性を持つキーを選択してください。クライアントがヘッダーを設定するため、ルーティング目的にのみ使用し、ユーザーが誰であるかを判断するためには決して使用しないでください。
データベース接続が切断されることも想定してください。接続は、データベースの再起動時やフェイルオーバー時に切断されます。インスタンスが一斉に再接続して接続の嵐を引き起こさないように、制限付きのバックオフとジッターを使用して再接続します。書き込みを再試行する前に、データベースを確認して書き込みがすでに実行されていないことを確認してください。
起動時は軽量に保ちます。再起動、デプロイメント、新しいインスタンスの作成のたびに、トラフィックの処理を開始する前に、モデルやデータセットの読み込み、キャッシュのウォームアップ、プールのオープンにコストがかかります。起動時の大規模なインストールやブロッキングを伴う外部呼び出しは避け、重いリソースは必要なときにのみ読み込みます。

正常にシャットダウンする

アプリを再デプロイすると、DatabricksはSIGTERMを送信し、アプリが15秒以内に終了しない場合はSIGKILLを送信します。その猶予期間は最終的なチェックポイントのためのものです。重要な作業は、通常の運用中にすでに保存されている必要があります。

たとえば、FastAPIの場合、Uvicornはライフスパンのクリーンアップを実行する前にオープンなリクエストを完了させます。save_in_progress_sessions()は、未完了の作業を保存する独自の関数の代わりになります。

これは非同期プール（たとえば、psycopgのAsyncConnectionPool）を前提としています。Apps-to-Lakebaseチュートリアルでは同期プールを使用しており、これはawaitなしでクローズします。

長時間の実行を伴うリクエストがチェックポイントの時間を消費しないように、Uvicornの--timeout-graceful-shutdownを15秒未満（たとえば10秒）に設定し、独自ワークロードでシャットダウンをテストしてください。AppKitのLakebaseプラグインはシャットダウン時にプールをクローズしますが、カスタムのチェックポイント処理は同じ猶予期間内に収める必要があります。

テストとデプロイ：負荷テストとピークに向けたサイジング

図4：段階的負荷テスト中のシステムメトリクス：CPUと制限値を下回ったまま推移する一方、最後のステップでレイテンシーが跳ね上がっています。

ローンチ前に負荷テストを実施すると、見積もりを現実により近い決定（インスタンスサイズ、インスタンスあたりのワーカー数、インスタンス数）に変えるのに役立ちます。

Databricks Appsの負荷テストの方法

予想されるピーク時の実際のユーザーの動きを使用して、本番環境の前に負荷テストを実施することをおすすめします。Locustなどのツールは、秒間リクエスト数、レイテンシーのパーセンタイル、各ステップでのエラー率をレポートし、テストは主要なアクションについて合意したレイテンシーとエラー率のターゲットに基づいて合格または不合格になります。テストの実行中、アプリの組み込みのシステムメトリクスには、制限値に対する分間リクエスト数、レイテンシー、CPU、メモリが表示されるため、アプリがどの制限に最初に達するかを確認できます（図4）。

スループットの増加が停止するか、レイテンシーとエラー率がターゲットを超えるまで、同時ユーザー数を段階的に増やします。大きな構成が常に高速であるとは限らないため、いくつかのインスタンスサイズとワーカー数を試してみる価値があります。また、テスト環境でのリカバリのテストも推奨します。実行中に単なる再デプロイやインスタンス数の変更ではなく、アプリの停止と開始を行い、ユーザーが続行できるか、リカバリにどれくらいの時間がかかるか、作業が失われていないかを確認します。エージェントアプリの場合は、負荷テストガイドの手順に従って、まずモック化されたLLMで1回テストしてアプリ独自のスループットを測定し、次に実際のモデルでエンドツーエンドのレイテンシーを測定します。

負荷ジェネレーター自体がボトルネックになる可能性があります。CPUや接続が最初に枯渇する可能性があり、認証エラーやレート制限の応答が速度低下のように見えることがあります。重要なのは、短いスパイクではなく、レイテンシーターゲット内での持続的な成功リクエストです。

また、負荷テストでは、アプリの背後にあるサービスが追いついているかどうかも確認する必要があります。ウェアハウスのキューイングが開始されたり、モデルのエンドポイントがスロットリングされたりする場合は、アプリではなくそのサービスをスケールさせてください。

インスタンスサイズの選択

Databricks Appsには、Medium（デフォルト、最大2 vCPUおよび6 GB）、Large（最大4 vCPU、12 GB）、XLarge（最大12 vCPU、48 GB）の3つのサイズが用意されています。適切なサイズはアプリが最初にどの制限に達するかによって異なるため、Mediumから開始し、負荷テストで確認してください。

負荷テストでわかること	考えられる原因	対処方法
アプリのCPU使用率が低いのにリクエストが遅い	アプリがバックエンドの処理を待っているか、またはブロック呼び出しによってワーカーが占有されている	サイズを維持します。クエリ、ウェアハウス、コネクションプール、またはブロック呼び出しを先に修正し、プロセスごとのCPUも確認してください。1つのコアが100%に達していても、全体としてはCPU使用率が低く見えることがあります
CPUが上限に近く、サーバーが複数のワーカーを実行している（例: FastAPIとUvicorn）	アプリがさらに多くのコアを使用できる	Largeに変更する
CPUが上限に近く、シングルプロセスアプリ（Streamlit、またはデフォルトのAppKit）	プロファイルによると、処理が1つのコアに集中している	インスタンスを追加します。サイズを大きくしても、ワーカースレッドやネイティブライブラリなどを通じてアプリが追加のコアを使用できる場合のみ効果があります
メモリが上限に近い	大きなデータセットやモデルがメモリに保持されている	メモリのサイズを上げる: LargeはMediumの2倍、XLargeは1つのインスタンスで48 GBを提供します
リカバリテスト: 唯一のインスタンスが再起動するとアプリが停止する	引き継ぐための予備インスタンスがない	サイズを大きくするのではなく、インスタンスを追加する

各インスタンスで実行するワーカー数はいくつにすべきですか？

ワーカーは各インスタンス内のサーバープロセスです。このモデルをサポートするPythonサーバーの場合、起動時に数値を設定し（例: uvicorn --workers 2）、それがインスタンスごとに適用されます。

1つのワーカーではCPUがアイドル状態になることがありますが、ワーカーを増やしすぎるとCPUとメモリを競合することにもなります。負荷テストガイドのベンチマークでは、Mediumは4ワーカーよりも2ワーカーの方がパフォーマンスが良く、LargeはMediumのおよそ2.2倍のスループットを実現しました。Mediumで2ワーカー、Largeで8ワーカーというドキュメント上の開始点は、あくまで初期の目安として扱ってください。ベンチマークではLLMをモック化しておりCPUバウンドでしたが、モデルの呼び出し待ちが大部分を占める実際のアプリでは、ワーカーを増やすことでより高い効果が得られる場合があります。実際のモデルを使用した独自の負荷テストに基づいて数値を決定してください。

アプリで実行するインスタンス数はいくつにすべきですか？

水平スケーリングを使用すると、インスタンス数を自分で設定できます。デフォルトの上限はアプリあたり5インスタンスですが、負荷テストでより多くのインスタンスが必要であることが示された場合は、Databricks担当者に連絡して引き上げることができます。予想されるピークと成長に合わせてインスタンス数を設定してください。インスタンス数の変更中もアプリはサービスの提供を続け、コンピューティングコストはインスタンス数に比例して増加します。既存のアプリを移行する場合は、まず複製した環境でお試しください。

高可用性を確保するために、ピーク時の負荷を処理できる十分なキャパシティを持たせた上で、少なくとも2つのインスタンスを実行することをお勧めします。ピーク時に2つのインスタンスが必要な場合は、3つ実行してください。インスタンスを追加することでインスタンス障害からは保護できますが、アプリのバックエンドにあるサービスのトラブルを防ぐことはできません。

Lakebaseへの接続数を予算化する

OAuthを使用してLakebaseに接続するDatabricks Appの場合は、データベースの標準（PgBouncer以外の）接続文字列に対して、アプリ側のコネクションプールから始めることをお勧めします。Apps-to-Lakebaseチュートリアル（Python向け）に示されているように、接続を再利用し、新しい接続を開く際に最新のOAuth資格情報を取得します。リクエストの期限が切れる前にクエリ自体の十分な時間を確保できるように、プールのタイムアウトを設定してください。

これらの接続は積み重なるため、インスタンスやワーカーを追加する前に予算を見積もってください。ワーカーごとに1つのプールを使用する場合の上限は、インスタンス数 × インスタンスあたりのワーカー数 × プールの最大サイズとなります。5つのインスタンス、8つのワーカー、プールの最大サイズが10の場合、最大400の接続を開くことができます。他のクライアントや、アプリがユーザーの代わりに開く接続を追加し、新旧のバージョンが並行して稼働するデプロイメントのための余裕（ヘッドルーム）を残した上で、合計数とデータベースのドキュメントに記載されている上限を比較してください。

ユーザー代行（OBO）クエリには、IDキャパシティが必要です。つまり、Lakebaseに対してユーザー自身としてクエリを実行する各ユーザーには、独自のPostgresロールが必要であり、Lakebaseでは1つのブランチあたり500のロールが許可されます。ユーザーベースが大きい場合は、どのクエリに本当に行ごとのユーザーアクセスが必要かを早い段階で決定してください。インスタンスを追加してもこの上限は変わりません。グループ単位の権限で十分な場合は、Databricksグループ用のPostgresロールを使用することで、メンバーが自身のOAuthトークンで接続できるようになり、1つのロールでグループ全体をカバーできます。

ダウンタイムなしのロールアウトと安全なロールバック

水平スケーリングされたアプリの場合、Databricksは最初に1つのインスタンスを更新し、それが成功した後に残りのインスタンスを更新するため、アプリはサービスを継続して提供できます。デプロイメントのたびに、アプリが正常であり、セッションが復旧していることを確認することをお勧めします。コードをGitで管理していれば、検証済みの良好なタグやコミットを再デプロイすることでロールバックできます。ロールアウト中には新旧のバージョンが並行して稼働するため、データベースとチェックポイントのフォーマットは両方のバージョンで読み取り可能に保ち、ロールバックしないと確信するまでは、前のバージョンが必要とするフィールドを削除しないでください。

運用: データに基づいたモニタリング、診断、および修正

ローンチ後、作業は「最も遅いステップを見つけて修正し、再度測定する」というループになります。そのため、本番環境ではテレメトリを有効に維持します。水平スケーリングされたアプリでは、「ログ」タブの「ライブ」ビューに一度に1つのインスタンスが表示されますが、テレメトリを有効にすると「App Telemetry Logs」にすべてのインスタンスが表示されます。

処理が遅い場合は、リクエストを最初から最後までトレースします（図5）。

図5: リクエストが時間を費やしている箇所と主なボトルネック。

兆候から始める

これらは最もよく見られる兆候と、それらが通常指し示す場所です。

兆候	確認場所	考えられる原因	対処方法
アイドル期間やデプロイ後の最初のリクエストが遅い	「Insights」タブのシステムメトリクスおよびアプリテレメトリ内のトレース	コールドスタート: アプリの起動、またはアイドル状態から復帰するサービス	アプリの起動時間や、LakebaseまたはSQLウェアハウスがアイドル時に停止するかどうかを確認し、起動処理を軽量に保つ
アプリのCPU使用率が低いのにリクエストが遅い	「Insights」タブのシステムメトリクスおよびアプリテレメトリ内のトレース	アプリがバックエンドの処理を待っているか、またはブロック呼び出しによってワーカーが占有されている	アプリのコンピューティングを追加する前に、クエリ、ウェアハウス、またはコネクションプールの遅延に関するトレースを確認するシングルプロセスアプリの場合、全体のCPU使用率が低く見えても、1つのコアが100%に達している可能性があることを考慮する
アプリのCPUまたはメモリが上限に近い	「Insights」タブのシステムメトリクス	アプリ自体がボトルネックになっている、またはメモリ内に保持しているデータが多すぎる	CPU負荷の高い処理をプロファイルし、大きな状態をメモリ外に移動してから、「インスタンスサイズを選択する」のガイダンスを参照する
データベース接続待ちのタイムアウト	アプリログとLakebaseのメトリクス	プールの競合、長時間のトランザクション、またはデータベース接続数の上限	接続の使用状況とトランザクションのデュレーションを調査し、接続予算の範囲内でプールまたはデータベースのキャパシティを調整する
デプロイやスケーリングの変更時にユーザーが作業内容を失う、またはエラーが発生する	「Insights」タブのシステムメトリクス	再構築できないソフトステート、または15秒以内に終了しないシャットダウン	重要な作業をチェックポイントに保存し、どのインスタンスでもセッションを再構築できるようにし、実際の現実的なリクエストやストリームを使用してシャットダウンをテストする

ヘルスアラートを設定する

セットアップの一環としてアラートを計画することをお勧めします。アプリがダウンしたときに誰に通知するかを決定し、Apps APIからの app_status.state および compute_status.state をモニタリングツールにフィードします。アプリのステータスだけではユーザーが作業できる証明にはならないため、レイテンシーやエラー率も含めて、代表的なユーザーのジャーニーも確認してください。しきい値を設定する際は、デプロイ中の一時的な状態の変化を考慮に入れてください。

まとめ

Databricks Appsのスケーリングとは、単なるアプリサーバーではなくリクエストパス全体をサイジングすることを意味します。レイテンシーとピーク時の負荷目標を設定し、負荷の高い処理はそれに適したサービスに送り、状態を復元可能な状態に保ち、負荷テストとテレメトリに基づいてキャパシティの割り当て先を決定します。最初の反射的な対応としてではなく、測定によって必要性が示されたときにコンピューティングを追加してください。

詳細については、Databricks AppsとLakebaseを使用して本番環境対応のデータおよびAIアプリを構築する方法をご覧ください。詳細については、ドキュメントのDatabricks AppsのベストプラクティスとDatabricks Appsのロギングとモニタリングを参照してください。内部ツール、AIコパイロット、エージェント型ワークフローなど、アプリのタイプ別のアーキテクチャパターンについては、Data + AI Summit 2026のBuilding Better AppsおよびStateful Apps for Thousands of Usersをご覧ください。

よくある質問

Databricks Appをスケールするにはどうすればよいですか？

設計、構築、テストとデプロイ、運用の4つの段階でスケールします。最初にレイテンシーとピーク時の負荷目標を設定し、アプリのコンピューティングはUIの提供用に温存し、復元可能な状態を持つ非同期コードを記述します。その後、負荷テストとテレメトリに基づいて、より大きなインスタンスにスケールアップするか、より多くのインスタンスにスケールアウトするかを決定します。

Databricks Appはスケールアップとスケールアウトのどちらを行うべきですか？

アプリがどの制限に最初に達するかによって異なります。リクエストが急増する場合や、シングルプロセスのアプリが1つのコアに制限されている場合は、インスタンスを追加してスケールアウトします。アプリにより多くのメモリが必要な場合や、追加のコアを使用できる複数のワーカーを実行する場合は、LargeまたはXLargeにスケールアップします。

Databricks Appsではどのようなインスタンスサイズを提供していますか？

Databricks Appsでは、Medium（デフォルト、最大2 vCPU、6 GB）、Large（最大4 vCPU、12 GB）、XLarge（最大12 vCPU、48 GB）を提供しています。まずはMediumから始めて、負荷テストを実施してアプリに必要なサイズを確認してください。

アプリが再起動またはスケールするときに、ユーザーセッションを維持するにはどうすればよいですか？

セッション状態を、再構築可能なソフトステートと、LakebaseまたはUnity Catalogのテーブルに永続的に保存されるハードステートに分割します。Databricks Appsはベストエフォート方式で各ユーザーを同じインスタンスに維持しますが、再起動やスケーリングによってセッションが移動する可能性があるため、どのインスタンスでもハードステートからセッションを再構築できる必要があります。

スケールされたアプリは、いくつのLakebase接続を開くことができますか？

ワーカーごとに1つのプールを使用する場合の上限は、「インスタンス数 × インスタンスあたりのワーカー数 × 最大プールサイズ」となります。たとえば、8つのワーカーを持つ5つのインスタンスがあり、プールの最大サイズが10の場合、最大400の接続を開くことができます。その合計とデータベースの公式ドキュメントに記載されている制限を比較し、デプロイ用に余裕を持たせておいてください。

少数のユーザー向けのアプリを数千人のユーザー向けにスケールアップする準備はできましたか？ドキュメントの「Databricks Appsのベストプラクティス」および「Databricks Appsの水平スケーリング」をご覧ください。

"Databricks Appsを探求する" →

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