--- title: "Azure Databricksのサーバーレスコンピューティング｜種類・NCCとネットワーク・コスト管理" url: "https://www.issoh.co.jp/tech/details/4362/" published: 2024-12-02 updated: 2026-09-27 categories: ["Azure"] publisher: "株式会社一創" --- # Azure Databricksのサーバーレスコンピューティング｜種類・NCCとネットワーク・コスト管理 Azure Databricksのサーバーレスコンピューティングは、クラスタを自分でプロビジョニングせずにノートブックやジョブを実行できるマネージドサービスです。ただし「サーバーレス」と呼ばれる機能はワークロードごとに分かれており、構成の入口も課金も別々です。加えてネットワーク許可の方式が2026年に切り替わり、以前の手順書が使えなくなっています。この記事では対象となるワークロードの区別、ストレージ接続の現行方式、コストの見方までを公式ドキュメントの記述で整理します。サーバーレスという方式そのものの仕組みは[サーバーレスとは？仕組み・メリットとコンテナとの使い分けを解説](/column/details/13005/)で扱っています。 ## まとめ：押さえるべき4点 先に要点を挙げます。 - **対象は3つ**：サーバーレスコンピューティングとして構成するのはノートブック、ワークフロー（ジョブ）、Lakeflowパイプラインです。サーバーレスSQLウェアハウスやモデルサービングは同じ基盤で動きますが、**別に構成・管理されます**。 - **Unity Catalogが必須**：有効化されたワークスペースであれば既定で使え、手動の有効化手順はありません。逆にUnity Catalogに対応していないレガシワークスペースはアクセスできません。 - **ネットワーク許可の方式が変わった**：同一リージョンのAzure Storageはネットワークセキュリティ境界（NSP）とサービスタグ、それ以外は公開された送信IPを使います。**NCCからコピーした安定IPなどのレガシIPリストは2026年5月25日で使用停止**です。 - **コストは事後に見る**：料金の見積もりは代表的なワークロードを実行してから`system.billing.usage`を分析する方法が推奨されています。課金の反映には最大24時間の遅延があります。 ## サーバーレスコンピューティングの対象になるワークロード 混乱の元は、Azure Databricksに「サーバーレス」と名の付く機能が複数あることです。公式ドキュメントが「サーバーレスコンピューティング」として扱うのは次の3つです。 | ワークロード | 構成の入口 | 用途 | | -------------------- | ------------------ | ---------- | | サーバーレスノートブック | ノートブックのコンピューティング選択 | 対話的な分析・開発 | | サーバーレスジョブ | ジョブのコンピューティング設定 | 定期実行・バッチ処理 | | サーバーレスLakeflowパイプライン | パイプライン設定 | 宣言的なETL | 一方、サーバーレスSQLウェアハウス、モデルサービング、AI機能もサーバーレス基盤の上で動きますが、**これらは独自の構成パスを持ち、上の3つとは別に管理されます。**「サーバーレスを有効にしたのにSQLウェアハウスの設定が見当たらない」という混乱は、この区別が原因です。 ### 利用の要件は2つだけ 必要なのは、ワークスペースでUnity Catalogが有効になっていること、そしてサーバーレスがサポートされているリージョンにあることです。この2つを満たしていれば**既定で利用可能で、有効化の手続きはありません**。逆に、Unity Catalogに移行していないレガシワークスペースはサーバーレスコンピューティングを使えません。この場合はまずUnity Catalogへのアップグレードが前提になります。 ### ランタイムはバージョンレス サーバーレスコンピューティングは「バージョンレス製品」と位置づけられており、ランタイムはDatabricksが自動でアップグレードします。ワークロードは常に最新のランタイムで実行されるため、**Databricks Runtimeの版を固定して長期運用する、という運用はできません。**ライブラリの互換性を版で固定したい要件があるなら、クラシックコンピュートを選ぶ判断になります。 ## ストレージへの接続｜NSPとサービスタグ ファイアウォールで保護されたリソースにサーバーレスから接続する場合、方式はリソースの種類で分かれます。 **ワークスペースと同一リージョンのAzure Storage**では、ストレージアカウントをネットワークセキュリティ境界（NSP）に関連付け、受信規則でサービスタグ`AzureDatabricksServerless`を許可します。推奨されているのはリージョン付きのタグ（例：`AzureDatabricksServerless.EastUS2`）で、グローバルタグを許可すると全リージョンのDatabricksからのアクセスを通してしまいます。 注意が必要なのは移行期限です。**サーバーレスのサブネットIDを許可リストに持っていた既存のストレージアカウントは、2026年6月9日までにNSPへ参加し、サービスタグを許可する必要がありました。**この期限は既に過ぎています。旧方式のまま残っている環境があれば、接続の可否を確認してください。 ### 「境界で保護」にすると壊れる 設定でつまずきやすい点があります。リソースをNSPに関連付けたあと、Azureポータルは境界内のリソースに対して「境界で保護」を推奨してきますが、**この設定にしてはいけません。**公式ドキュメントは、パブリックネットワークアクセスを「選択したネットワークから有効」のままにするよう明記しています。 「境界で保護」にすると、サーバーレスコンピューティングは外部ロケーションへ到達できなくなり、`PERMISSION_DENIED`や「Request for user delegation key is not authorized」といったエラーで失敗します。アクセスモードも**移行モードを無期限で維持することが推奨**されており、強制モードはほとんどのケースで推奨されていません。強制モードはDatabricks以外のサービスにも影響するためです。 ### 東日本ワークスペースはタグが1つでは足りない リージョン付きのサービスタグを使う場合、ワークスペースのリージョンだけでは不足することがあります。公式ドキュメントは**東日本のワークスペースには西日本にセカンダリの成果物ストレージがある**と明記しており、この場合はセカンダリリージョンのサービスタグも追加する必要があります。国内リージョンを使う環境では、ここが見落としやすい落とし穴です。 ## NCCと送信IP｜2026年に方式が切り替わった 同一リージョンのストレージ以外のリソース（他リージョンのストレージ、データベース、外部API）へは、サーバーレスがパブリックIPで到達します。そのため、リソース側のファイアウォールにDatabricksの送信IPを許可リスト登録する必要があります。 **ここが2026年に変わった部分です。**2026年2月中旬以降、送信IPはパブリックエンドポイントでJSON形式（`ip-ranges.json`）で公開される方式になりました。そして**パブリックプレビューの安定IPや、アカウントコンソールのネットワーク接続構成（NCC）からコピーしたレガシIPリストは、2026年5月25日で使用停止**になっています。NCCから安定IPをコピーする手順を書いた記事や社内手順書は、この時点で使えません。 ### 許可リストの更新は自動化が前提 送信IPは固定ではありません。公式は次のように運用条件を示しています。 - IPの更新は**30日に1回程度**発行される。 - 新しいIPは**発行の60日後にアクティブ**になる。 - 新しいリージョンも定期的に追加される。 つまり**一度コピーして貼るだけの運用では、いずれ接続が切れます。**公式が示す手順は、定期的に`ip-ranges.json`を取得し、`timestampSeconds`を保存済みのコピーと比較して変更を検知し、自分の`platform`と`region`に該当する`ipv4Prefixes`でファイアウォールを更新する、というものです。フィルタ条件は`service`が`Databricks`、`type`が`outbound`、`platform`が`azure`、そして`region`がワークスペースのリージョンと一致するエントリです。 なお、専用のプライベート接続が必要なら、IP許可の代わりにアウトバウンドPrivate Link接続を使う選択肢があります。 ## コストの見方｜見積もりより実測が推奨されている サーバーレスのコスト把握について、公式が推奨しているのは事前の理論計算ではありません。**代表的なワークロードあるいは特定のワークロードを実際に実行してベンチマークし、その後に課金システムテーブルを分析する**という順序です。 分析先は`system.billing.usage`システムテーブルで、ワークロード単位のDBU使用量を確認できます。ここで注意すべきは**反映の遅延**です。ワークロードを実行してから使用状況がテーブルに反映されるまで、最大24時間かかることがあります。実行直後に数字が出ないからといって課金されていないわけではありません。 ### 身に覚えのない課金レコードの正体 サーバーレスジョブを実行していないのに、サーバーレスジョブの課金レコードが現れることがあります。これは異常ではありません。**データ品質の監視と予測最適化がサーバーレス基盤で動作し、サーバーレスジョブSKUで課金される**ためです。これらの機能はノートブックやジョブのサーバーレスコンピューティングとは別に管理されているため、こちらを止めても課金は止まりません。原因を追う際は、まずこの2機能の有効状態を確認してください。 ## 実装前に確認すべき制限 採用判断に直結する制限があります。 - **カスタムデータソースには接続できない**。サポートされるのはLakehouse Federationを使うソースのみです。独自コネクタで外部システムへ直接つなぐ設計は成立しません。 - **認証が必要なリポジトリには事前署名URLが要る**。プライベートリポジトリの利用自体は可能ですが、セキュリティ上の理由で事前に署名されたURLが必要になります。 - **ランタイムの版を固定できない**。バージョンレス製品のため自動でアップグレードされます。 - **ファイアウォール設定はクラシックコンピュートにも影響する**。サーバーレス向けに許可リストを変更すると、クラシックコンピュートからの接続にも影響が出るため、両方の経路を同時に確認する必要があります。 ライブラリの管理については、ジョブタスクごとに個別インストールするのではなく、環境（environment）を利用する方法が推奨されています。ローカル環境から実行したい場合はDatabricks Connectを使います。 ## よくある質問 ### Azure Databricksのサーバーレスコンピューティングにはどんな種類がありますか？ サーバーレスコンピューティングとして構成するのは、ノートブック、ワークフロー（ジョブ）、Lakeflowパイプラインの3つです。サーバーレスSQLウェアハウスやモデルサービング、AI機能も同じサーバーレス基盤で動作しますが、これらは別に構成・管理される機能で、上の3つとは設定の入口が異なります。 ### サーバーレスを使うのに有効化の手続きは必要ですか？ 不要です。ワークスペースでUnity Catalogが有効になっており、サーバーレスがサポートされているリージョンにあれば、既定で利用できます。逆にUnity Catalogに対応していないレガシワークスペースは利用できないため、その場合はUnity Catalogへのアップグレードが先になります。 ### NCCからコピーした安定IPは今も使えますか？ 使えません。2026年5月25日でレガシIPリストは使用停止になりました。現在の方法は、Databricksが公開する`ip-ranges.json`を取得し、service・type・platform・regionで絞り込んだ`ipv4Prefixes`をファイアウォールに登録する方式です。IPは30日に1回程度更新され、新しいIPは発行の60日後に有効になるため、許可リストの更新は自動化してください。 ### ストレージへの接続でNSPを「境界で保護」にしてもよいですか？ してはいけません。公式ドキュメントは、リソースのパブリックネットワークアクセスを「選択したネットワークから有効」のままにするよう明記しています。「境界で保護」にすると、サーバーレスコンピューティングが外部ロケーションへ到達できず、PERMISSION\_DENIEDなどのエラーで失敗します。アクセスモードも移行モードの維持が推奨されています。 ### サーバーレスのコストはどう見積もればよいですか？ 公式が推奨しているのは、代表的なワークロードを実際に実行してベンチマークし、`system.billing.usage`システムテーブルでDBU使用量を分析する方法です。事前の理論値ではなく実測を前提としています。課金の反映には最大24時間の遅延があるため、実行直後に数字が出ないことを異常と判断しないでください。 ## 関連記事 - [サーバーレスとは？仕組み・メリットとコンテナとの使い分けを解説](/column/details/13005/) - [サーバーレスアーキテクチャとは？構成パターン・AWS実装・採用判断を実装者目線で解説](/tech/details/13125/) --- 出典: [Azure Databricksのサーバーレスコンピューティング｜種類・NCCとネットワーク・コスト管理]()（株式会社一創）