このページでは、Databricks Apps の開発と実行に関する重要なベスト プラクティスを示します。 これらのガイドラインは、セキュリティ、パフォーマンス、プラットフォームの要件に重点を置きます。
一般的なベスト プラクティス
データ処理には Azure Databricks ネイティブ機能を使用します。 アプリ コンピューティングは UI レンダリング用に最適化されています。 クエリとデータセットには Databricks SQL、バッチ処理には Lakeflow ジョブ、AI 推論ワークロードにはモデル サービスを使用します。 パフォーマンスの問題を回避するために、これらのサービスに大量のデータ処理をオフロードします。 予想される読み込み条件でアプリをテストし、要件を満たしていることを確認します。
グレースフル シャットダウン処理を実装します。 アプリは、
SIGTERM信号を受信してから 15 秒以内にシャットダウンするか、SIGKILLで強制的に終了する必要があります。特権操作は避けてください。 アプリは特権のないユーザーとして実行され、ルート アクセスなどの昇格されたアクセス許可を必要とするアクションを実行することはできません。
apt-get、yum、apkなどのパッケージ マネージャーを使用してシステム レベルのパッケージをインストールすることはできません。 代わりに、PyPI の Python パッケージや npm の Node.js パッケージを使ってアプリの依存関係を管理します。プラットフォームで管理されるネットワークについて説明します。 要求はリバース プロキシ経由で転送されるため、アプリは要求の配信元に依存できません。 Azure Databricks は TLS 終了を処理し、アプリで HTTP/2 クリア テキスト (H2C) をサポートする必要があります。 カスタム TLS 処理を実装しないでください。
適切なホストとポートにバインドします。 アプリは
0.0.0.0をリッスンし、DATABRICKS_APP_PORT環境変数で指定されたポートを使用する必要があります。 詳細については 、環境変数 を参照してください。コンテナーの起動時間を最小限に抑えます。 コールド スタートの待機時間を短縮するために、初期化ロジックを軽量に保ちます。 起動中に大規模な依存関係のインストールや外部 API 呼び出しなどの操作をブロックしないようにします。 必要な場合にのみ、負荷の高いリソースを読み込みます。
stdout と stderr にログを記録します。 Azure Databricks は、標準の出力ストリームとエラー ストリームからログをキャプチャします。 すべてのログ記録にこれらを使用して、Azure Databricks UI にログが確実に表示されるようにします。 ローカル ファイルにログを書き込むのは避けてください。
予期しないエラーを適切に処理します。 グローバル例外処理を実装して、キャッチされないエラーによるクラッシュを防ぎます。 スタック トレースや機密データを公開せずに、適切な HTTP エラー応答を返します。
依存関係のバージョンを固定します。
requirements.txtファイルで正確なバージョン番号を使用して、ビルド間で一貫性のある環境を確保します。 ピン留めされていないパッケージや最新バージョンのパッケージは使用しないでください。ユーザー入力を検証してサニタイズします。 常に受信データを検証し、それをサニタイズして、内部向けのアプリでも、インジェクション攻撃や不正な入力を防ぎます。
メモリ内キャッシュを使用して、コストの高い操作を行います。 待機時間を短縮し、冗長な処理を回避するために、クエリ結果や API 応答などの頻繁に使用されるデータをキャッシュします。
functools.lru_cache、cachetools、または同様のライブラリを使用し、マルチユーザー アプリでキャッシュのスコープを慎重に設定します。実行時間の長い操作には非同期要求パターンを使用します。 操作の完了を待機する同期要求は避けてください。この要求はタイムアウトする可能性があります。代わりに、操作を開始する最初の要求を行い、リソースの状態またはエンドポイントに定期的にクエリを実行して完了状態を確認します。
セキュリティのベスト プラクティス
最小特権の原則に従います。 各ユーザーまたはグループに必要なアクセス許可のみを付与します。 完全な制御が必要な場合を除き、
CAN USEの代わりにCAN MANAGEを使用します。 アクセス許可のベスト プラクティスを参照してください。認証方法は慎重に選択してください。 リソースとデータへのアクセスがアプリのすべてのユーザーで同じ場合は、サービス プリンシパルを使用します。 アプリが呼び出し元のユーザーのアクセス許可を尊重する必要がある場合は、信頼できるアプリ作成者とピア レビューされたアプリ コードを含むワークスペースでのみユーザー認証を実装します。
アプリごとに専用のサービス プリンシパルを使用します。 アプリまたはユーザー間でサービス プリンシパルの資格情報を共有しないでください。
CAN USEやCAN QUERYなど、必要な最小限のアクセス許可のみを付与します。 アプリ作成者が組織を離れるときに、サービス プリンシパルの資格情報をローテーションします。 「リソースへのアプリ アクセスの管理」を参照してください。アプリ環境を分離する。 異なるワークスペースを使用して、開発、ステージング、運用の各アプリを分離します。 これにより、開発とテスト中に運用環境のデータに誤ってアクセスするのを防ぐことができます。
適切なコンピューティングを使用してデータにアクセスします。 データに直接アクセスしたり処理したりするようにアプリを構成しないでください。 クエリには SQL ウェアハウス、AI 推論にはモデル サービス、バッチ処理には Lakeflow ジョブを使用します。
シークレットを管理します。 環境変数で生のシークレット値を公開しないでください。 アプリの構成で
valueFromを使用し、シークレットを定期的にローテーションします (特にチームロールが変更された場合)。 ベスト プラクティスを参照してください。スコープを最小限に抑え、ユーザー アクションをログに記録します。 ユーザー承認を使用する場合は、アプリに必要なスコープのみを要求し、構造化された監査レコードを使用してすべてのユーザー アクションをログに記録します。 ユーザー承認のベスト プラクティスを参照してください。
送信ネットワーク アクセスを制限します。 パッケージ リポジトリや外部 API など、アプリに必要なドメインのみを許可します。 ドライラン モードと拒否ログを使用して、構成を検証します。 ネットワーク ポリシーを構成するためのベスト プラクティスを参照してください。
セキュリティで保護されたコーディングプラクティスに従います。 SQL クエリをパラメーター化してインジェクション攻撃を防ぎ、入力の検証やエラー処理など、セキュリティで保護された一般的な開発ガイドラインを適用します。 「ステートメント実行 API: ウェアハウスで SQL を実行する」を参照してください。
疑わしいアクティビティを監視します。 通常とは異なるアクセス パターンや未承認のアクションがないか、監査ログを定期的に確認します。 重要なセキュリティ イベントのアラートを設定します。