メインコンテンツまでスキップ

Databricks アプリの主要な概念

この記事では、アプリの構造、依存関係と状態の管理方法、アクセス許可のしくみ、アプリがプラットフォーム リソースと対話する方法など、Databricks アプリの背後にある主要な概念について説明します。これらの概念を理解しておくと、ワークスペースでアプリを開発、デプロイ、管理する際に役立ちます。

アプリ​

Databricks アプリは、Databricks サーバレス プラットフォーム上でコンテナ化されたサービスとして実行される Web アプリケーションです。開発者は、Streamlit、Dash、Gradioなどのサポートされているフレームワークを使用して、AI Databricksワークスペース内でインタラクティブなデータや エクスペリエンスを提供するアプリを構築します。

各アプリには、独自の構成、ID、分離されたランタイム環境が含まれています。アプリは特定のワークスペースに属しているため、 SQLウェアハウスなどのワークスペース レベルのリソースや、 Unity Catalogなどのアカウント レベルのリソースにアクセスできます。 開発者は、ワークスペースの外部にいるユーザーと同じ Databricks アカウント内のユーザーとアプリを共有することもできます。

アプリケーションコンテナは Databricks サーバレスインフラストラクチャ上で実行されますが、アプリケーション自体はサーバレスリソースと非サーバレスリソースの両方に接続できます。 概念的には、アプリは Web UI をホストし、利用可能な Databricks データ プレーン サービスにアクセスするコントロール プレーン サービスとして機能します。 詳細については、「 Databricks アーキテクチャの概要」を参照してください。

アプリを起動して管理するには、ワークスペースUIの [アプリ ]セクションに移動します。

テンプレート​

アプリ テンプレートは、開発者がサポートされているフレームワークを使用してアプリの構築をすばやく開始するのに役立つ、事前構築済みのスキャフォールドです。各テンプレートには、基本的なファイル構造、 app.yaml マニフェスト、Python アプリ用の requirements.txt ファイル、サンプルソースコードが含まれています。

app.yaml ファイルは、アプリを実行するコマンド (Streamlit アプリの場合は streamlit run <app-name> など) を定義し、ローカル環境変数を設定し、必要なリソースを宣言します。

  • requirements.txt を使用して、pipでインストールする追加の Python パッケージを一覧表示します。
  • package.json を使用して、npmでインストールするNode.jsパッケージを一覧表示します。

これらのファイルは、デフォルトのシステム環境とプリインストールされたパッケージを補完します。詳細については、「 Databricks Apps システム環境」を参照してください。

開発者は、Databricks UI または CLI を使用して、テンプレートから新しいアプリを生成できます。

システム環境とパッケージ​

Databricks アプリは、Databricks によって管理される事前構成済みのシステム環境で実行されます。詳細については、「 Databricks Apps システム環境」を参照してください。

各アプリには、依存関係の競合を防ぐために、独自の分離された環境があります。一貫性を確保するには、必要なパッケージとそのバージョンをアプリの適切なファイルに定義します。

  • Python の場合は、requirements.txt.
  • Node.js の場合は、package.jsonを使用します。

デプロイ中に、Databricks はこれらの依存関係をアプリの分離されたランタイム環境にインストールします。既にプレインストールされているパッケージを含めると、指定したバージョンがデフォルトを上書きします。

詳細については、「 Databricks アプリの依存関係の管理 」を参照してください。

アプリのリソース​

アプリ リソースは、DatabricksSQL ウェアハウス、モデルサービング エンドポイント、ジョブ、シークレット、ボリュームなど、アプリが依存する ネイティブ サービスです。これらの依存関係は、resources フィールドを使用して databricks.yml マニフェストで宣言します。Databricks では、次のリソースの種類がサポートされています。

  • SQLウェアハウス
  • ジョブ
  • モデルサービングエンドポイント
  • Genieスペース
  • シークレット
  • ボリューム

サポートされているリソースの種類がまだない Databricks サービスにアクセスするには、Unity Catalog で管理されるシークレットを使用して、資格情報を安全に挿入します。シークレット管理を参照してください。

アプリ リソースの構成には、次の 2 つの段階があります。

  • 宣言 (開発) - 必要な各リソースを databricks.yml マニフェストで宣言します。これにより、アプリに必要なリソースと必要なアクセス許可が定義されます。
  • 構成 (デプロイ) - デプロイ中に、 Databricks Apps UI を使用して、宣言されたリソースを実際のワークスペース固有のインスタンスで構成します (たとえば、特定の SQLウェアハウスを選択するなど)。

このように宣言と構成を分離することで、アプリを環境間で移植できます。たとえば、同じアプリ コードを開発ワークスペースにデプロイし、それを 1 つの SQLウェアハウスにリンクできます。 本番運用では、コードを変更せずに、コードを再利用して別のウェアハウスを構成することができます。 これをサポートするには、アプリでリソース ID や環境固有の値をハードコーディングしないようにします。

Databricks では、最小特権アクセスが適用されます。アプリは既存のリソースを使用する必要があり、新しいリソースを作成することはできません。デプロイ中、ワークスペース管理者は、リソースへのアプリの要求されたアクセスを確認して承認します。アプリのサービスプリンシパルは必要な権限を受け取り、アプリ開発者はそれらを付与する権限を持っている必要があります。

詳細については、「 Databricks アプリにリソースを追加する」を参照してください。

アプリのステータス​

アプリのステータスは、 実行中 、 停止 中、 デプロイ中 、 クラッシュ のいずれかです。

  • 実行中 - アプリはアクティブでアクセス可能です。Databricks アプリの実行中に使用されるコンピュート リソースの請求を行います。
  • 停止 - アプリにはアクセスできず、コストは発生しません。Databricks ではアプリの構成と環境が保持されるため、再構成せずにアプリを再起動できます。
  • デプロイ中 - アプリは起動しています。この段階ではまだアクセスできず、料金は発生しません。
  • クラッシュ - アプリの起動に失敗したか、予期せず停止しました。アクセスできず、料金もかかりません。ログを表示してトラブルシューティングを行い、問題が解決したらアプリを再起動できます。

アプリの状態​

アプリの状態には、ユーザーがセッションや操作をまたいでアプリが保持する必要があるデータやコンテキストが含まれます。アプリは再起動後にメモリ内の状態を保持しません。メモリに保持されているデータは、アプリがシャットダウンすると失われます。

セッション間または再起動間で状態を維持するには、開発者はその状態を外部に保存する必要があります。たとえば、アプリは Databricks SQL (Delta テーブルなど)、 ワークスペース ファイル、 または Unity Catalog ボリュームを使用して状態を保持できます。一般的な使用例には、クエリ結果のキャッシュ、ユーザー設定の保存、セッション間でのユーザーアクションのログ記録などがあります。

アプリの認証と承認​

Databricks Apps は、認証とアクセス制御に OAuth 2.0 を使用します。各アプリには、Databricks リソースへのアクセスを認証および承認する方法を決定する 2 つの補完的な ID ( アプリの承認 と ユーザー承認 ) があります。

  • アプリの承認 - Databricks は、アプリごとにサービスプリンシパルを自動的に作成します。 このサービスプリンシパルは、アプリの ID として機能し、アプリ開発者によってアクセス許可が付与されます。 アプリのすべてのユーザーは、この ID を共有し、同じアクセス許可のセットにアクセスできます。このモデルは、ログ記録やシステムレベルのアクションなど、個々のユーザーのコンテキストに依存しない操作に役立ちます。

  • ユーザー認証 - このモデルでは、アプリ ユーザーの ID を使用してアクセスを認証および承認します。ユーザーは、アプリがデプロイされている Databricks アカウントに属している必要があります。シングル サインオン (SSO) を使用してサインインした後、アプリはユーザーの資格情報を使用して、 SQLウェアハウスなどの管理されたリソースにアクセスできます。 これにより、アプリは、 Unity Catalog によって管理されるきめ細かな権限を尊重し、それらの権限をアプリのサービスプリンシパルに付与することができます。

OAuthアプリは、アクセスできるAPIs とリソースを制御するために、マニフェストで特定の スコープをリクエストします。この柔軟なモデルは、エンタープライズグレードのセキュリティをサポートし、きめ細かなアクセス制御を可能にします。

詳細については、「Databricksアプリで承認を構成する」を参照してください。

アプリユーザー​

デプロイ後、アプリ開発者は、アプリ インスタンスに対する CAN_USE または CAN_MANAGE アクセス許可を付与することで、アプリをユーザーまたはグループと共有できます。ユーザーは同じワークスペースに属している必要はありませんが、同じ Databricks アカウントの一部である必要があります。外部ユーザーと共有するには、まず ID プロバイダーを使用してアカウントに同期します。詳細については、「SCIMを使用して ID プロバイダーからユーザーとグループを同期する」を参照してください。

また、 CI/CD パイプラインと Infrastructure as Code を使用して、開発環境、ステージング環境、本番運用環境に同じアプリを配布することもできます。 一元化されたアプリ UI は、ユーザーが使用が許可されているアプリを見つけて起動するのに役立ちます。

に最終更新
この記事は役に立ちましたか?