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

Databricks アプリのベスト プラクティス

このページでは、Databricks アプリの開発と実行に関する重要なベスト プラクティスの一覧を示します。これらのガイドラインは、セキュリティ、パフォーマンス、およびプラットフォームの要件に焦点を当てています。

一般的なベストプラクティス​

  • データ処理には Databricks ネイティブの機能を使用します 。App コンピュートは、UI レンダリング用に最適化されています。 クエリとデータセットには [ Databricks SQL ] を、バッチ処理には [ Lakeflow ジョブ] を、推論ワークロードの AI にはモデルサービングを使用します。

  • グレースフル シャットダウン処理を実装します 。アプリは、 SIGTERM シグナルを受信してから 15 秒以内にシャットダウンするか、 SIGKILLで強制的に終了する必要があります。

  • 特権操作は避けてください 。アプリは特権のないユーザーとして実行され、ルート アクセスなどの昇格されたアクセス許可を必要とするアクションを実行できません。

  • プラットフォーム管理型ネットワーキングを理解する 。リクエストはリバースプロキシ経由で転送されるため、アプリはリクエストの発信元に依存することはできません。Databricks は TLS ターミネーションを処理し、アプリは HTTP/2 クリアテキスト (H2C) をサポートする必要があります。カスタム TLS 処理を実装しないでください。

  • 正しいホストとポートにバインドします 。アプリは 0.0.0.0 でリッスンし、 DATABRICKS_APP_PORT 環境変数で指定されたポートを使用する必要があります。詳細については、 環境変数 を参照してください。

  • コンテナの起動時間を最小限に抑えます 。初期化ロジックを軽量にして、コールドスタートのレイテンシを短縮します。スタートアップ中に大きな依存関係のインストールや外部 API 呼び出しなどの操作をブロックしないようにします。必要な場合にのみ、重いリソースをロードします。

  • stdout と stderr にログを記録します 。Databricks は、標準出力ストリームとエラー ストリームからログをキャプチャします。これらをすべてのログに使用して、ログが Databricks UI に表示されるようにします。ローカルファイルへのログの書き込みは避けてください。

  • 予期しないエラーを適切に処理します 。グローバル例外処理を実装して、キャッチされないエラーによるクラッシュを防ぎます。スタックトレースや機密データを公開せずに、適切なHTTPエラー応答を返します。

  • ピン留め 依存関係のバージョン . requirements.txtファイルで正確なバージョン番号を使用して、ビルド間で一貫した環境を確保します。ピン留めされていないパッケージや最新バージョンのパッケージの使用は避けてください。

  • ユーザー入力を検証し、サニタイズします 。内部向けアプリであっても、常に受信データを検証し、サニタイズして、インジェクション攻撃や不正な形式の入力を防ぎます。

  • 負荷の高い操作には、メモリ内キャッシュを使用します 。クエリ結果や API 応答など、頻繁に使用されるデータをキャッシュして、レイテンシを減らし、冗長な処理を回避します。functools.lru_cache、cachetools、または同様のライブラリを使用し、マルチユーザー アプリではキャッシュのスコープを慎重に設定します。

セキュリティのベストプラクティス​

  • 最小特権の原則に従います 。ユーザーまたはグループごとに必要な権限のみを付与します。フルコントロールが必要な場合を除き、CAN MANAGEではなくCAN USEを使用してください。権限のベスト プラクティスを参照してください。

  • 認証方法は慎重に選択してください 。リソースとデータへのアクセスがアプリのすべてのユーザーで同じである場合は、サービスプリンシパルを使用します。 アプリが呼び出し元のユーザーの権限を尊重する必要がある場合、信頼できるアプリ作成者とピアレビュー済みのアプリ コードを持つワークスペースでのみ、ユーザー認証を実装します。

  • アプリごとに専用サービスプリンシパルをご利用ください 。 サービスプリンシパルの資格情報をアプリまたはユーザー間で共有しないでください。 CAN USEやCAN QUERYなど、必要最小限の権限のみを付与します。アプリ作成者が組織を離れる場合は、サービスプリンシパルの資格情報を更新します。 「リソースへのアプリのアクセスを管理する」を参照してください。

  • アプリ環境を分離します 。異なるワークスペースを使用して、開発、ステージング、本番運用アプリを分離します。 これにより、開発およびテスト中に本番運用データに誤ってアクセスすることが防止されます。

  • 適切なコンピュートを通じてデータにアクセスします 。 データに直接アクセスしたり、データを処理したりするようにアプリを構成しないでください。クエリにはSQL 、 AI推論にはモデルサービング、バッチ処理にはLakeFlow Jobs を使用します。

  • シークレットを管理します 。環境変数で生のシークレット値を公開しないでください。アプリ構成で valueFrom を使用し、特にチームの役割が変更された場合に、シークレットを定期的にローテーションします。「 ベスト プラクティス」を参照してください。

  • スコープを最小限に抑え、ユーザーアクションをログに記録します 。ユーザー認証を使用する場合は、アプリに必要なスコープのみをリクエストし、構造化された監査レコードを使用してすべてのユーザーアクションを記録します。ユーザー認証のベストプラクティスを参照してください。

  • 送信ネットワーク アクセスを制限します 。パッケージ リポジトリ や外部APIsなど、アプリに必要なドメインのみを許可します。 構成を検証するには、dry-実行モードと拒否ログを使用します。 ネットワーク ポリシーを構成するためのベスト プラクティスを参照してください。

  • 安全なコーディングプラクティスに従ってください 。SQL クエリをパラメーター化して、インジェクション攻撃を防ぎ、入力検証やエラー処理などの一般的な安全な開発ガイドラインを適用します。ステートメント実行 API: ウェアハウスで SQL を実行するを参照してください。

  • 不審なアクティビティを監視します 。監査ログを定期的に確認して、異常なアクセス パターンや不正なアクションがないか確認します。重大なセキュリティ イベントに関するアラートを設定します。

に最終更新