Azure 仮想ネットワーク (VNet インジェクション) で Azure Databricks をデプロイする
この記事では、Azure 仮想ネットワークに Azure Databricks ワークスペースをデプロイする (VNet インジェクションとも呼ばれる) 方法について説明します。
VNet インジェクションを使用したネットワークのカスタマイズ
Azure Databricks の既定のデプロイは、Azure のフル マネージド サービスです。 Azure 仮想ネットワーク (VNet) は、ロックされたリソース グループにデプロイされます。 すべてのクラシック コンピューティング プレーン リソースは、その VNet に関連付けられます。 ネットワークのカスタマイズが必要な場合は、Azure Databricks クラシック コンピューティング プレーン リソースを独自の仮想ネットワーク内にデプロイできます。 これを使用すると、次のことができます。
- サービス エンドポイントまたは Azure プライベート エンドポイントを使用して、より安全な方法で Azure Databricks を (Azure Storage などの) 他の Azure サービスに接続する。
- ユーザー定義ルートを使用してオンプレミスのデータ ソースに接続する 「Azure Databricks のためのユーザー定義のルート設定」を参照してください。
- Azure Databricks をネットワーク仮想アプライアンスに接続してすべての送信トラフィックを検査し、許可および拒否の規則に従ってアクションを実行する。 「オプション: 仮想アプライアンスまたはファイアウォールを使用して Azure Databricks のトラフィックをルーティングする」を参照してください。
- カスタム DNS を使用するように Azure Databricks を構成する。 「オプション: カスタム DNS を構成する」を参照してください。
- ネットワーク セキュリティ グループ (NSG) 規則を構成して、エグレス トラフィック制約を指定する。
Azure Databricks クラシック コンピューティング プレーン リソースを独自の VNet にデプロイすると、柔軟な CIDR 範囲を利用することもできます。 VNet の場合は、CIDR 範囲サイズ /16-/24 を使用できます。 サブネットの場合は、/26 程度の小ささの IP 範囲を使います。
重要
VNet を既存のワークスペースに置き換えることはできません。 現在のワークスペースに、必要な数のアクティブ クラスター ノードを収めることができない場合は、より大きな VNet に別のワークスペースを作成することをお勧めします。 詳細な移行手順に従って、古いワークスペースから新しいワークスペースにリソース (ノートブック、クラスター構成、ジョブ) をコピーします。
仮想ネットワークの要件
Azure Databricks ワークスペースをデプロイする先の VNet は、次の要件を満たしている必要があります。
- リージョン: VNet は、Azure Databricks ワークスペースと同じリージョンおよびサブスクリプション内に存在する必要があります。
- サブスクリプション: VNet は、Azure Databricks ワークスペースと同じサブスクリプションに存在する必要があります。
- アドレス空間: VNet に対しては
/16から/24までの CIDR ブロック、2 つのサブネット (コンテナー サブネットとホスト サブネット) に対しては/26までの CIDR ブロック。 VNet とそのサブネットのサイズに基づいたクラスター ノードの最大数に関するガイダンスについては、「アドレス空間とクラスター ノードの最大数」を参照してください。 - サブネット: VNet には、Azure Databricks ワークスペース専用の 2 つのサブネットを含める必要があります。1 つは、コンテナー サブネット (別名: プライベート サブネット) で、もう 1 つは、ホスト サブネット (別名: パブリック サブネット) です。 セキュリティで保護されたクラスター接続を使用そてワークスペースをデプロイすると、コンテナー サブネットとホスト サブネットの両方でプライベート IP が使用されます。 ワークスペース間でサブネットを共有することや、Azure Databricks ワークスペースで使用されるサブネットに他の Azure リソースをデプロイすることはできません。 VNet とそのサブネットのサイズに基づいたクラスター ノードの最大数に関するガイダンスについては、「アドレス空間とクラスター ノードの最大数」を参照してください。
アドレス空間とクラスター ノードの最大数
小さい仮想ネットワークを使用するワークスペースは、大きい仮想ネットワークを使用するワークスペースよりも早く IP アドレス (ネットワーク空間) を使い切る可能性があります。 VNet に対して /16 から /24 までの CIDR ブロックを使用し、2 つのサブネット (コンテナー サブネットとホスト サブネット) に対して /26 までの CIDR ブロックを使用します。 サブネットに対して CIDR ブロックを /28 まで作成することはできますが、Databricks では、/26 より小さいサブネットは推奨されません。
VNet アドレス空間の CIDR 範囲は、ワークスペースで使用できるクラスター ノードの最大数に影響します。
Azure Databricks ワークスペースには、VNet 内に 2 つのサブネットが必要です。1 つはコンテナー サブネットで、もう 1 つはホスト サブネットです。 Azure では、各サブネットで 5 つの IP が予約されています。 Azure Databricks ではクラスター ノードごとに 2 つの IP が必要です。1 つは、ホスト サブネット内のホストの IP アドレスで、もう 1 つは、コンテナー サブネット内のコンテナーの IP アドレスです。
- VNet のすべてのアドレス空間を使用したくない場合があります。 たとえば、1 つの VNet に複数のワークスペースを作成する場合などです。 ワークスペース間でサブネットを共有できないため、VNet アドレス空間全体を使用しないサブネットが必要になる場合があります。
- VNet のアドレス空間内にあり、その VNet の現在または将来のサブネットのアドレス空間と重複しない 2 つの新しいサブネットに対してアドレス空間を割り当てる必要があります。
次の表は、ネットワーク サイズに基づいたサブネットの最大サイズを示しています。 この表は、アドレス空間を占有する追加のサブネットが存在しないことを前提とします。 既存のサブネットがある場合、または他のサブネットのアドレス空間を予約する場合は、小さいサブネットを使用します。
| VNet のアドレス空間 (CIDR) | 他のサブネットがないと仮定した場合の Azure Databricks の最大サブネット サイズ (CIDR) |
|---|---|
/16 |
/17 |
/17 |
/18 |
/18 |
/19 |
/20 |
/21 |
/21 |
/22 |
/22 |
/23 |
/23 |
/24 |
/24 |
/25 |
サブネット サイズに基づいてクラスター ノードの最大数を見つけるには、次の表を使用します。 "サブネットあたりの IP アドレス数" 列には、Azure で予約されている 5 つの IP アドレスが含まれます。 右端の列は、そのサイズのサブネットでプロビジョニングされるワークスペースで同時に実行できるクラスター ノードの数を示します。
| サブネットのサイズ (CIDR) | サブネットあたりの IP アドレス数 | Azure Databricks クラスター ノードの最大数 |
|---|---|---|
/17 |
32768 | 32763 |
/18 |
16384 | 16379 |
/19 |
8192 | 8187 |
/20 |
4096 | 4091 |
/21 |
2048 | 2043 |
/22 |
1024 | 1019 |
/23 |
512 | 507 |
/24 |
256 | 251 |
/25 |
128 | 123 |
/26 |
64 | 59 |
セキュリティで保護されたクラスター接続を使用する場合のエグレス IP アドレス
VNet インジェクションを使用するワークスペースでセキュリティで保護されたクラスター接続を有効にした場合、Databricks では、ワークスペースに安定したエグレス パブリック IP を設定することをお勧めします。
安定したエグレス パブリック IP アドレスは、外部許可リストに追加できるため便利です。 たとえば、安定した発信 IP アドレスを使用して Azure Databricks から Salesforce に接続する場合などです。 IP アクセス リストを構成する場合は、それらのパブリック IP アドレスを許可リストに追加する必要があります。 「ワークスペース向けの IP アクセス リストを構成する」をご覧ください。
警告
Microsoft は、2025 年 9 月 30 日に Azure における仮想マシンの既定の送信アクセス接続が廃止されることを発表しました。 このお知らせを参照してください。 つまり、安定したエグレス パブリック IP ではなく、既定の送信アクセスを使用する Azure Databricks ワークスペースは、その日付以降、機能しない可能性があります。 Databricks では、その日付より前にワークスペースの明示的な送信方法を追加することをお勧めします。
安定したエグレス パブリック IP を構成するには、「VNet インジェクションを使用したエグレス」を参照してください。
共有リソースとピアリング
DNS などの共有ネットワーク リソースが必要な場合、Databricks では、ハブおよびスポーク モデルの Azure ベスト プラクティスに従うことを強く推奨しています。 VNet ピアリングを使って、スポークを相互に分離したまま、ワークスペース VNet のプライベート IP 空間をハブに拡張します。
VNet 内に他のリソースがある場合、またはピアリングを使っている場合、Databricks では、同じ VNet 内にある、またはその VNet にピアリングされている他のネットワークおよびサブネットにアタッチされているネットワーク セキュリティ グループ (NSG) に拒否規則を追加することを強く推奨しています。 受信接続と送信接続の両方の接続に拒否規則を追加して、Azure Databricks コンピューティング リソースとの送信と受信の接続を制限します。 クラスターがネットワーク上のリソースにアクセスする必要がある場合は、要件を満たす必要最小限のアクセスのみを許可する規則を追加します。
関連情報については、「ネットワーク セキュリティ グループ規則」を参照してください。
Azure portal を使用して Azure Databricks ワークスペースを作成する
このセクションでは、Azure portal で Azure Databricks ワークスペースを作成し、独自の既存 VNet 内にデプロイする方法について説明します。 Azure Databricks は、ユーザーが指定した CIDR 範囲を使用して、2 つの新しいサブネットで VNet を更新します (それらがまだ存在しない場合)。 また、このサービスは、新しいネットワーク セキュリティ グループを使用してサブネットを更新し、インバウンドとアウトバウンド規則を構成して、最後に更新された VNet にワークスペースをデプロイします。 VNet の構成をより詳細に制御するには、ポータルではなく、Azure Databricks で提供されている Azure Resource Manager (ARM) テンプレートを使用します。 たとえば、既存のネットワーク セキュリティ グループを使用するか、独自のセキュリティ規則を作成します。 「Azure Resource Manager テンプレートを使用した詳細な構成」を参照してください。
ワークスペースを作成するユーザーには、対応する仮想ネットワークに対するネットワーク共同作成者ロール、または Microsoft.Network/virtualNetworks/subnets/join/action アクションと Microsoft.Network/virtualNetworks/subnets/write 権限が割り当てられたカスタム ロールを割り当てる必要があります。
Azure Databricks ワークスペースをデプロイする先の VNet を構成する必要があります。 既存の VNet を使用することも、新しく作成することもできますが、VNet は、作成する予定の Azure Databricks ワークスペースと同じリージョンおよびサブスクリプションに存在する必要があります。 VNet のサイズは、/16 から /24 までの CIDR 範囲である必要があります。 その他の要件については、「仮想ネットワークの要件」を参照してください。
ワークスペースを構成するときに、既存のサブネットを使用するか、新しいサブネットの名前と IP 範囲を指定します。
Azure portal で、[+ リソースの作成] > [Analytics] > [Azure Databricks] を選択するか、Azure Databricks を検索し、[作成] または [+ 追加] をクリックして [Azure Databricks サービス] ダイアログを起動します。
独自 VNet での Azure Databricks ワークスペースの作成に関するクイックスタートで説明されている構成手順に従います。
[ネットワーク] タブの [仮想ネットワーク] フィールドで、使用する VNet を選択します。
重要
ピッカーにネットワーク名が表示されない場合は、ワークスペースに対して指定した Azure リージョンが目的の VNet の Azure リージョンと一致していることを確認します。
サブネットに名前を付け、サイズが
/26までのブロックで CIDR 範囲を指定します。 VNet とそのサブネットのサイズに基づいたクラスター ノードの最大数に関するガイダンスについては、「アドレス空間とクラスター ノードの最大数」を参照してください。 ワークスペースのデプロイ後にサブネットの CIDR 範囲を変更することはできません。- 既存のサブネットを指定するには、既存のサブネットの正確な名前を指定します。 また、既存のサブネットを使用する場合は、ワークスペース作成フォーム内の IP 範囲が、既存のサブネットの IP 範囲と正確に一致するように設定します。
- 新しいサブネットを作成するには、その VNet にまだ存在しないサブネット名を指定します。 サブネットは、指定した IP 範囲を使用して作成されます。 VNet の IP 範囲内にある、既存のサブネットにまだ割り当てられていない IP 範囲を指定する必要があります。
Azure Databricks では、サブネット名は 80 文字以下にする必要があります。
サブネットには、クラスター内部通信を許可する規則を含む、ネットワーク セキュリティ グループ規則が関連付けられます。 Azure Databricks は、
Microsoft.Databricks/workspacesリソース プロバイダーを介して両方のサブネットを更新するための委任されたアクセス許可を所持しています。 これらのアクセス許可は、Azure Databricks で必要なネットワーク セキュリティ グループ規則にのみ適用されます。追加する他のネットワーク セキュリティ グループ規則や、すべてのネットワーク セキュリティ グループに含まれる既定のネットワーク セキュリティ グループ規則には適用されません。[作成] をクリックして、Azure Databricks ワークスペースを VNet にデプロイします。
Azure Resource Manager テンプレートを使用した詳細な構成
VNet の構成をより細かく制御するには、ポータル UI ベースの自動 VNet 構成とワークスペース デプロイの代わりに、次の Azure Resource Manager (ARM) テンプレートを使用します。 たとえば、既存のサブネット、既存のネットワーク セキュリティ グループを使用したり、独し自のセキュリティ規則を追加したりします。
カスタム Azure Resource Manager テンプレートまたは Azure Databricks VNet インジェクション用のワークスペース テンプレートを使用して、ワークスペースを "既存の VNet" にデプロイする場合、ワークスペースをデプロイする "前" に、ホストとコンテナーのサブネットを作成し、各サブネットにネットワーク セキュリティ グループをアタッチし、それらのサブネットを Microsoft.Databricks/workspaces リソース プロバイダーに委任する必要があります。 デプロイするワークスペースごとに、サブネットの個別ペアが必要です。
オールインワン テンプレート
1 つのテンプレートを使用して VNet と Azure Databricks ワークスペースを作成するには、Azure Databricks VNet で挿入されるワークスペース用のオールインワン テンプレートを使用します。
仮想ネットワーク テンプレート
テンプレートを使用して適切なサブネットを含む VNet を作成するには、Databricks VNet インジェクション用の VNet テンプレートを使用します。
Azure Databricks ワークスペース テンプレート
テンプレートを使用して既存の VNet に Azure Databricks ワークスペースをデプロイするには、Azure Databricks VNet インジェクション用のワークスペース テンプレートを使用します。
ワークスペース テンプレートを使用すると、既存の VNet を指定し、既存のサブネットを使用できます。
- デプロイするワークスペースごとに、ホストとコンテナーのサブネットの個別ペアが必要になります。 ワークスペース間でサブネットを共有することや、Azure Databricks ワークスペースで使用されるサブネットに他の Azure リソースをデプロイすることは "サポートされていません"。
- この Azure Resource Manager テンプレートを使用してワークスペースをデプロイする前に、VNet のホストおよびコンテナーのサブネットにネットワーク セキュリティ グループをアタッチし、
Microsoft.Databricks/workspacesサービスに委任する必要があります。 - サブネットが適切に委任された VNet を作成するには、Databricks VNet インジェクション用の VNet テンプレートを使用します。
- ホストおよびコンテナーのサブネットをまだ委任していない場合に既存の VNet を使用するには、「サブネットの委任を追加または削除する」を参照してください。
ネットワーク セキュリティ グループ規則
次の表に、Azure Databricks で現在使用されているネットワーク セキュリティ グループ規則を示します。 Azure Databricks で規則を追加する必要がある場合、またはこの一覧の既存の規則のスコープを変更する必要がある場合、事前通知を受け取ります。 この記事と表は、このような変更が発生するたびに更新されます。
Azure Databricks によるネットワーク セキュリティ グループ規則の管理方法
次のセクションに示す NSG 規則は、VNet のホストおよびコンテナーのサブネットを Microsoft.Databricks/workspaces サービスに委任することで、Azure Databricks によって NSG で自動的にプロビジョニングされ、管理される NSG 規則を表します。 これらの NSG 規則を更新または削除するアクセス許可はありません。そのような試行は、サブネット委任によってブロックされます。 Microsoft が VNet で Azure Databricks サービスを確実に運用し、サポートできるようにするために、Azure Databricks がこれらの規則を所有している必要があります。
これらの NSG 規則の一部には、ソースおよび宛先として、VirtualNetwork が割り当てられます。 これは、Azure にサブネット レベルのサービス タグがない場合の設計を簡略化するために実装されています。 クラスター A が同じワークスペース内のクラスター B に接続できないように、すべてのクラスターは、内部的に 2 番目のネットワーク ポリシーのレイヤーによって保護されます。 これは、複数のワークスペースが同じカスタマー マネージド VNet 内の異なるサブネット ペアにデプロイされている場合、それらのワークスペースにも適用されます。
重要
Databricks では、同じ VNet 内にある、またはその VNet にピアリングされている他のネットワークおよびサブネットにアタッチされているネットワーク セキュリティ グループ (NSG) に拒否規則を追加することを強く推奨しています。 受信接続と送信接続の両方の接続に拒否規則を追加して、Azure Databricks コンピューティング リソースとの "送信" と "受信" の接続を制限します。 クラスターがネットワーク上のリソースにアクセスする必要がある場合は、要件を満たす必要最小限のアクセスのみを許可する規則を追加します。
ワークスペースのネットワーク セキュリティ グループ規則
このセクションの情報は、2020 年 1 月 13 日より "後" に作成された Azure Databricks ワークスペースにのみ適用されます。 ワークスペースが、2020 年 1 月 13 日のセキュリティで保護されたクラスター接続 (SCC) のリリースよりも前に作成された場合は、次のセクションを参照してください。
この表には、ワークスペースのネットワーク セキュリティ グループ規則がリストされており、セキュリティで保護されたクラスター接続 (SCC) が無効になっている場合にのみ組み込まれる 2 つの受信セキュリティ グループ規則が含まれています。
| 方向 | Protocol | source | 発信元ポート | 宛先 | 宛先ポート | 使用済み |
|---|---|---|---|---|---|---|
| 受信 | Any | VirtualNetwork | Any | VirtualNetwork | Any | Default |
| 受信 | TCP | AzureDatabricks (サービス タグ) SCC が無効の場合のみ |
Any | VirtualNetwork | 22 | パブリック IP |
| 受信 | TCP | AzureDatabricks (サービス タグ) SCC が無効の場合のみ |
Any | VirtualNetwork | 5557 | パブリック IP |
| 送信 | TCP | VirtualNetwork | Any | AzureDatabricks (サービス タグ) | 443、3306、8443-8451 | 既定値 |
| 送信 | TCP | VirtualNetwork | Any | SQL | 3306 | Default |
| 送信 | TCP | VirtualNetwork | Any | 記憶域 | 443 | 既定 |
| 送信 | Any | VirtualNetwork | Any | VirtualNetwork | Any | Default |
| 送信 | TCP | VirtualNetwork | Any | EventHub | 9093 | 既定値 |
Note
アウトバウンド規則を制限する場合、Databricks では、特定のライブラリのインストールを有効にするためにポート 111 と 2049 を開くようお勧めします。
重要
Azure Databricks は、グローバル Azure パブリック クラウド インフラストラクチャにデプロイされる Microsoft Azure のファーストパーティ サービスです。 コントロール プレーンのパブリック IP とカスタマー コンピューティング プレーンのパブリック IP との間の通信を含め、サービスのコンポーネント間の通信はすべて、Microsoft Azure のネットワーク バックボーン内に維持されます。 「マイクロソフトのグローバル ネットワーク」も参照してください。
トラブルシューティング
ワークスペース作成のエラー
サブネット <subnet-id> では、サービス関連リンクを参照するために次のいずれかの委任 [Microsoft.Databricks/workspaces] が必要です
考えられる原因: ホストおよびコンテナーのサブネットが Microsoft.Databricks/workspaces サービスに委任されていない VNet でワークスペースを作成しようとしています。 各サブネットは、ネットワーク セキュリティ グループがアタッチされ、適切に委任されている必要があります。 詳細については、「仮想ネットワークの要件」を参照してください。
The subnet <subnet-id> is already in use by workspace <workspace-id> (サブネットは、ワークスペースで既に使用されています)
考えられる原因: 既存の Azure Databricks ワークスペースで既に使用されているホストおよびコンテナーのサブネットを使用して VNet でワークスペースを作成しようとしています。 1 つのサブネットで複数のワークスペースを共有することはできません。 デプロイするワークスペースごとに、ホストおよびコンテナーのサブネットの新しいペアが必要です。
トラブルシューティング
Instances Unreachable:Resources were not reachable via SSH. (インスタンスに到達できませんでした。SSH 経由でリソースに到達できません。)
考えられる原因: コントロール プレーンから worker へのトラフィックがブロックされています。 オンプレミス ネットワークに接続されている既存の VNet をデプロイ先にする場合、「Azure Databricks ワークスペースをオンプレミス ネットワークに接続する」の情報を使用して設定を確認しまてください。
予期しない起動エラー: クラスターの設定中に予期しないエラーが発生しました。 Please retry and contact Azure Databricks if the problem persists. 内部エラー メッセージ: Timeout while placing node。
考えられる原因: worker から Azure Storage エンドポイントへのトラフィックがブロックされています。 カスタム DNS サーバーを使用している場合は、VNet 内の DNS サーバーの状態も確認してください。
クラウド プロバイダーの起動エラー: クラスターの設定中にクラウド プロバイダーのエラーが発生しました。 See the Azure Databricks guide for more information. Azure エラー コード: AuthorizationFailed/InvalidResourceReference.
考えられる原因: VNet またはサブネットが存在していません。 VNet とサブネットが存在することを確認してください。
クラスターが終了しました。 理由: Spark スタートアップ エラー: Spark を時間内に起動できませんでした。 This issue can be caused by a malfunctioning Hive metastore, invalid Spark configurations, or malfunctioning init scripts. Spark ドライバー ログを参照して、この問題のトラブルシューティングを行います。問題が解決しない場合は、Databricks にお問い合わせください。 内部エラー メッセージ: Spark failed to start: Driver failed to start in time。
考えられる原因: コンテナーがホスティング インスタンス、または、ワークスペース ストレージ アカウントと通信できません。 ワークスペース ストレージ アカウントのサブネットにカスタム ルートを追加し、ネクスト ホップをインターネットにして、修正してください。