【NCCディープダイブ】Azure Databricksのサーバーレスのネットワークセキュリティ

はじめに

本記事では、Azure Databricksのサーバーレスのネットワーク接続を管理するための機能「ネットワーク接続構成（略称NCC）」の概要とともに、アカウントコンソールやAzureポータルの設定画面のキャプチャを交えながら具体的な挙動について紹介していきます。

まずは、Azure Databricksのサーバーレス機能のリリース状況とメリットについて軽く振り返った後、サーバーレスコンピューティングのネットワーク面の概要について触れたいと思います。それから本題であるNCCにディープダイブしていきましょう。

本記事のカバー範囲について

本記事ではAzure DatabricksのNCCにフォーカスして記載します。Databricks on AWSおよびDatabricks on Google Cloudについては本記事ではカバーしません。両クラウド向けにNCC相当の機能の開発が進んでおり、そちらがリリースされたタイミングで別記事にまとめたいと思います。

主な更新情報

本記事の内容に関連する主な更新情報をお知らせします。

NCCファイアウォールが対応するサーバーレスの種類が拡大（2024年5月）

2024年5月31日のリリースノートで、NCCファイアウォールが、SQLに加えて以下のサーバーレスコンピュートタイプをサポートすることが発表されました。

• SQL（従前からサポート）
• ノートブック
• ジョブ
• Delta Live Tables (DLT)
• モデルサービング

NCCプライベートリンクが対応するAzureサービスの種類が拡大（2024年11月）

2024年11月21日に、NCCプライベートリンクのアップデートが発表され、以下のサーバーレスコンピュートから、Azure Private Linkに対応する60以上のAzureの1stパーティサービスへの接続が可能になりました。

• SQL
• ノートブック
• ジョブ
• Delta Live Tables (DLT)
• モデルサービング

サーバーレスのリリース状況

2023年から、Azure Databricksのサーバーレス機能がどんどん強化されています。本記事を執筆している2024年4月時点で、Databricks SQLサーバーレス（略してDBSQLサーバーレス）と、ノートブックおよびワークフロー向けのサーバーレスの2つがリリースされています。

DBSQLサーバーレスは既に一般提供済みで、東日本リージョンにおいて2023年11月より利用可能になっています。ノートブック & ワークフローのサーバーレスは米国などの一部のリージョンでパブリックプレビュー機能として利用できます。東日本リージョンでも今後利用可能になる見通しです。

各リージョンへの最新の展開状況は、以下のページをご覧ください（日本語版に反映されるのに若干のタイムラグがあるため英語版をご覧頂くのがおすすめです）。

サーバーレスのメリット

DBSQLサーバーレスのメリットについて、以下のデータブリックス新井さんの記事に分かりやすくまとまっています。端的には、圧倒的な起動時間の短さ、性能およびコストパフォーマンスの高さが、DBSQLサーバーレスのメリットです。これらは、ノートブックやワークフローのサーバーレスにも共通するメリットと言えるでしょう。

サーバーレスはAzure Databricksがコンピューティングを完全に管理

サーバーレスの特徴の一つとして、クラスターやウェアハウスといった「コンピュート（計算資源）」の実行される場所が従来とは異なる点が挙げられます。従来型（クラシックコンピューティングプレーン）では、ユーザーのAzureサブスクリプションのVNet内でコンピュートが実行されます。一方サーバーレスは、Azure Databricksによって管理されるサーバーレスコンピューティングプレーンでコンピュートが実行されます。

出典：サーバーレス コンピューティング プレーン ネットワーキング - Azure Databricks | Microsoft Learn

上記の図の2番：サーバーレスコンピュートとAzure Storageなどのユーザーリソース間のネットワークセキュリティを管理するために使用するのが、ネットワーク接続構成です。Network Connectivity Configurationの頭文字をとってNCCと略します。

なお、上記の図の1番：ユーザー & アプリとコントロールプレーン間のネットワークセキュリティは、IPアクセスリストやPrivate Linkで保護できます。本記事では詳しく触れませんが、以下のDatabricksブログや私が以前作成したスライドに詳細がまとまっていますので、ご興味ある方はご覧ください。

Databricksセキュリティ & トラストセンター

サーバーレス全般のセキュリティについてご興味がある方は以下のDatabricksセキュリティ & トラストセンターをご覧ください。サーバーレスのページについて日本語でサマリーしたスライドも合わせてご覧頂くと良いと思います。

NCCの概要

ここからNCCの深掘りをしていきます。まずは、NCCの概要について見ていきましょう。正確な定義については以下のドキュメントに譲るとして、本記事では誤解を恐れずに分かりやすさを優先して記載します。

本記事の情報は古くなる可能性があります

なるべく最新化に努めたいとは思っていますが、本記事の情報が公式よりも古くなる可能性があります。特に制限周りの各種の数字について変更されるかもしれません。NCCを利用の際には必ず公式のドキュメントも合わせてチェックしてください。

NCCとは？

ネットワーク接続構成（NCC）は、複数のAzure DatabricksワークスペースのサーバーレスコンピュートからユーザーのAzureサブスクリプションにあるAzure Storageなどのリソースへのネットワークセキュリティをアカウントレベルで一元的に管理するための機能です。

NCCで何ができる？

NCCを用いることでユーザーが管理するAzureリソースに以下2つのネットワークセキュリティを適用できます。

1. ストレージアカウントのファイアウォール

サーバーレスコンピュートが経由する仮想ネットワークサービスエンドポイントの静的なサブネットID群をストレージアカウントのファイアウォールで許可し、接続元を制限します。以下のサーバーレスコンピュートタイプをサポートしています。

• SQL
• ワークフロー
• ノートブック
• Delta Live Tables (DLT)
• モデルサービング

2. プライベートリンク

以下のサーバーレスコンピュートから、Azure Private Linkに対応する60以上のAzureサービスに接続できます。

• SQL
• ジョブ
• ノートブック
• Delta Live Tables (DLT)
• モデルサービング

主な接続先サービスには以下が含まれます。

• Azure Storage（Blob Storage、ADLS Gen2）
• Azure SQL Database
• Azure OpenAI
• Azure Key Vault
• Azure Event Hubs
• Azure Service Bus
• その他のAzure Private Link対応サービス

両者の違いについては以下の図をご覧ください。

NCCの概念図（本記事のために作成）

以前から何が変わったの？

プライベートリンクのサポートは2024年4月に新しく始まったものです。ストレージアカウントのファイアウォールについては「静的な」サブネットID群になったのがポイントです。

2023年10月以前は、DBSQLサーバーレスが経由するサービスエンドポイントのサブネットID群をドキュメントで公開しており、それらのサブネットID群をストレージアカウントのファイアウォールに追加する方式でした。ただ、この方式だと、将来的にサブネットIDの追加や変更が発生した場合に、ユーザーがドキュメントを見て、ストレージアカウントのファイアウォールに反映するという作業が必要になってしまいます（そもそもどうやってユーザーが変更に気付くのかという問題もあります）。

以前のドキュメントで公開していたサブネットID群（以下の永田さんのQiita記事より）

現在は、NCC作成時に、そのNCCにサーバーレスコンピューティングが経由するサービスエンドポイントの「静的な」サブネットID群が設定されます。サーバーレスコンピューティングは、その中の一つのサブネットIDのサービスエンドポイントを経由してストレージアカウントにアクセスします。ユーザーは、それらのサブネットID群を一度だけストレージアカウントのファイアウォールに追加すれば良くなり、ユーザーの利便性が向上しています。

NCCへのアクセス方法

GUIとREST APIによるアクセスが可能です。今後Databricks CLIや各種SDK、Terraformなどもサポートされるはずです。

GUIアクセス

Azure Databricksのアカウントコンソール (https://accounts.azuredatabricks.net) の[クラウドリソース] > [ネットワーク接続構成]でNCCの編集・閲覧ができます。

REST APIアクセス

以下のAPIリファレンスを参照ください。

NCCに必要な権限

NCCに関する操作を行うユーザーは以下の権限を持っている必要があります。

• Azure Databricksアカウントのアカウント管理者ロール
  • NCCはアカウントレベルのリソースのため、ユーザーはアカウント管理者ロールを持っている必要があります
• 対象のストレージアカウントのファイアウォールの編集権限
  • NCCファイアウォールの編集を行う場合に必要です
  • Azure RBACの組み込みのロールの場合、ストレージアカウント共同作成者や共同作成者などのロールに必要な権限が含まれます
• 対象のAzureリソースのプライベートエンドポイントの編集権限
  • NCCプライベートエンドポイントの編集を行う場合に必要です

Azure Databricksのアカウントコンソールを有効化しておらず、アカウント管理者ロールが存在しない場合は、以下のドキュメントを参考に設定してください。

NCCの制限

NCCの制限は以下の通りです。

• NCCをアタッチするワークスペースはPremiumプランの必要があります
• 1つのNCCは最大で50個のワークスペースにアタッチできます
• 1つのAzure Databricksアカウントはリージョンごとに最大で10個のNCCを持つことができます
• 1つのAzure Databricksアカウントはリージョンごとに最大で100個のプライベートエンドポイントを作成でき、必要に応じて1から10個のNCCに分散できます

NCCの料金

NCCの料金体系は2024年12月4日に変更されました。

2024年12月4日以前

NCCは無料でご利用頂けました。ストレージアカウントのファイアウォール、プライベートリンクどちらのオプションを利用する場合も追加料金は発生しませんでした。

2024年12月4日以降

外部リソースに接続するサーバーレスワークロードのネットワークコストの課金が開始されます。以下の点に注意が必要です：

• 課金は段階的に実施され、2024年12月4日以降も一定期間は課金されない場合があります
• 課金が有効になる前の使用量に対して、さかのぼっての課金は発生しません
• 課金が有効になった後は、以下の料金が発生する可能性があります：

1. Private Link経由でのリソースへのプライベート接続

   • データ処理料金は無期限に免除
   • 時間単位の料金が適用

2. NATゲートウェイ経由のリソースへのパブリック接続

   • 接続時の料金が発生

3. リージョン間データ転送料金

   • サーバーレスコンピューティングとターゲットリソースが異なるリージョンにある場合など

NCCの設定の流れ：ストレージアカウントのファイアウォール

ここから実際にGUIを使ったNCCの設定の流れをウォークスルーしていきます。まずはストレージアカウントのファイアウォールから見ていきましょう。

1. NCCを追加（アカウントコンソール）

アカウントコンソール (https://accounts.azuredatabricks.net/) にアクセスし、左サイドバーの [クラウドリソース] > [ネットワーク接続構成] をクリックします。すると以下のような画面が表示されます。

画面右上にある [ネットワーク接続構成を追加] ボタンをクリックします。

任意の名前を入力、アタッチしたいワークスペースが存在するリージョンを選択し、[追加] をクリックします。

指定した名前でNCCが作成されます。

2. NCCの静的サブネットID群をコピー（アカウントコンソール）

作成したNCCをクリック、[デフォルトルール] タブにアクセスし [すべて表示]　リンクをクリックします。

静的なサブネットIDの一覧が表示されるので [サブネットをコピー] をクリックします。

以下がクリップボードにコピーされたサブネットIDの一覧の例です（あくまで例であり、NCCによってサブネットIDは異なる可能性があります）。各サブネットIDがカンマと半角スペースで区切られています。

この後、このサブネットID群をストレージアカウントのファイアウォールにスクリプトで追加していくのですが、その際にカンマがあるとエラーになりますので、テキストエディタなどに貼り付けてカンマを除去した上で、適当な名前で手元のPCに保存しておきましょう。

クリップボードにコピーされたサブネットIDの一覧の例（カンマと半角スペース区切り）

/subscriptions/23a8c420-c354-43f9-91f5-59d08c6b3dff/resourceGroups/prod-japaneast-snp-1-compute-4/providers/Microsoft.Network/virtualNetworks/prod-japaneast-snp-1-compute-4/subnets/worker-subnet, /subscriptions/31ef391b-7908-48ec-8c74-e432113b607b/resourceGroups/prod-japaneast-snp-1-compute-2/providers/Microsoft.Network/virtualNetworks/prod-japaneast-snp-1-compute-2/subnets/worker-subnet, /subscriptions/56beece1-dbc8-40ca-8520-e1d514fb2ccc/resourceGroups/prod-japaneast-snp-1-compute-8/providers/Microsoft.Network/virtualNetworks/prod-japaneast-snp-1-compute-8/subnets/worker-subnet, /subscriptions/653c13e3-a85b-449b-9d14-e3e9c4b0d391/resourceGroups/prod-japaneast-snp-1-compute-6/providers/Microsoft.Network/virtualNetworks/prod-japaneast-snp-1-compute-6/subnets/worker-subnet, /subscriptions/6c0d042c-6733-4420-a3cc-4175d0439b29/resourceGroups/prod-japaneast-snp-1-compute-3/providers/Microsoft.Network/virtualNetworks/prod-japaneast-snp-1-compute-3/subnets/worker-subnet, /subscriptions/8453a5d5-9e9e-40c7-87a4-0ab4cc197f48/resourceGroups/prod-japaneast-snp-1-compute-1/providers/Microsoft.Network/virtualNetworks/prod-japaneast-snp-1-compute-1/subnets/worker-subnet, /subscriptions/9d5fffc7-7640-44a1-ba2b-f77ada7731d4/resourceGroups/prod-japaneast-snp-1-compute-5/providers/Microsoft.Network/virtualNetworks/prod-japaneast-snp-1-compute-5/subnets/worker-subnet, /subscriptions/b4f59749-ad17-4573-95ef-cc4c63a45bdf/resourceGroups/prod-japaneast-snp-1-compute-10/providers/Microsoft.Network/virtualNetworks/prod-japaneast-snp-1-compute-10/subnets/worker-subnet, /subscriptions/b96a1dc5-559f-4249-a30c-5b5a98023c45/resourceGroups/prod-japaneast-snp-1-compute-7/providers/Microsoft.Network/virtualNetworks/prod-japaneast-snp-1-compute-7/subnets/worker-subnet, /subscriptions/d31d7397-093d-4cc4-abd6-28b426c0c882/resourceGroups/prod-japaneast-snp-1-compute-9/providers/Microsoft.Network/virtualNetworks/prod-japaneast-snp-1-compute-9/subnets/worker-subnet

3. NCCをワークスペースにアタッチ（アカウントコンソール）

アカウントコンソールの左サイドバーの [ワークスペース] をクリックし、NCCをアタッチするワークスペースの名前をクリックします。

[構成] タブが表示されるので右上の [ワークスペースを更新] ボタンをクリックします。

[ネットワーク接続構成] 欄に作成したNCCを設定し [更新] ボタンをクリックします。

以上でNCCのワークスペースへのアタッチは完了です。

（ドキュメントに以下の記述がありますので、念のため本記事にも転記しておきます）

• 変更が有効になるまで10分待ちます
• ワークスペースで実行中のサーバーレスのSQLウェアハウスをすべて再起動します

4. ストレージアカウントのファイアウォールを有効化（Azureポータル）

• Azureポータル (https://portal.azure.com) にアクセスし、対象ストレージアカウントを選択し、[ネットワーク] をクリックします
• [ファイアウォールと仮想ネットワーク] > [パブリックネットワーク アクセス]について [選択した仮想ネットワークとIPアドレスから有効] にチェックし [保存] をクリックします

非サーバーレスのクラスターやSQLウェアハウスからのアクセス許可について

対象のストレージアカウントのファイアウォールについて、「すべてのネットワークから有効」から「選択した仮想ネットワークとIPアドレスから有効」に変更する場合、上記画面の「仮想ネットワーク」のセクションにAzure Databricksワークスペースの2つのサブネット（通称 public-subnet と private-subnet）のIDを追加してサービスエンドポイントを有効化してください。

上記を行わないと、非サーバーレスのクラスターやSQLウェアハウスから対象のストレージアカウントにアクセスできなくなります。

なお、サービスエンドポイントが利用できるのはVNetインジェクションされたAzure Databricksワークスペースである点に留意ください。

5. ストレージアカウントのファイアウォールにNCCのサブネットID群を追加（Azure CLIなど）

Azure CLIやPowerShell、Terraform、または他のツールを使って、ストレージアカウントのファイアウォールにNCCのサブネットID群を追加します。

以下はAzure CLIを使って複数のサブネットID群をループして追加するスクリプトです。スクリプトを実行する前に以下の文字列を置き換える必要があります。

• SUBNETSの値をカンマを除去したサブネットID群で置き換えます
• --subscriptionの値を自身のAzureサブスクリプションIDに置き換えます
• --resource-groupの値を対象のストレージアカウントが存在するリソースグループ名に置き換えます
• --account-nameの値を対象のストレージアカウント名に置き換えます

スクリプト例

#!/bin/bash
SUBNETS=(/subscriptions/8453a5d5-9e9e-40c7-87a4-0ab4cc197f48/resourceGroups/prod-azure-eastusc3-nephos2/providers/Microsoft.Network/virtualNetworks/kaas-vnet/subnets/worker-subnet /subscriptions/8453a5d5-9e9e-40c7-87a4-0ab4cc197f48/resourceGroups/prod-azure-eastusc3-nephos3/providers/Microsoft.Network/virtualNetworks/kaas-vnet/subnets/worker-subnet)
for SUBNET in ${SUBNETS[@]}
do
  az storage account network-rule add --subscription 9999999-1ff3-43f4-b91e-d0ceb97111111 --resource-group mystorage-rg --account-name myaccount --subnet ${SUBNET}
done

カンマを含むサブネットID群で上記スクリプトを実行した場合
以下のようなエラーメッセージが表示され、サブネットIDの追加に失敗します。

エラーメッセージ例

(NetworkAclsValidationFailure) Validation of network acls failure: SubnetsDoNotExist:Virtual network /subscriptions/23a8c420-c354-43f9-91f5-59d08c6b3dff/resourceGroups/prod-japaneast-snp-1-compute-4/providers/Microsoft.Network/virtualNetworks/prod-japaneast-snp-1-compute-4 does not have subnets with names worker-subnet,..
Code: NetworkAclsValidationFailure
Message: Validation of network acls failure: SubnetsDoNotExist:Virtual network /subscriptions/23a8c420-c354-43f9-91f5-59d08c6b3dff/resourceGroups/prod-japaneast-snp-1-compute-4/providers/Microsoft.Network/virtualNetworks/prod-japaneast-snp-1-compute-4 does not have subnets with names worker-subnet,..
(NetworkAclsValidationFailure) Validation of network acls failure: SubnetsDoNotExist:Virtual network /subscriptions/31ef391b-7908-48ec-8c74-e432113b607b/resourceGroups/prod-japaneast-snp-1-compute-2/providers/Microsoft.Network/virtualNetworks/prod-japaneast-snp-1-compute-2 does not have subnets with names worker-subnet,..
Code: NetworkAclsValidationFailure
Message: Validation of network acls failure: SubnetsDoNotExist:Virtual network /subscriptions/31ef391b-7908-48ec-8c74-e432113b607b/resourceGroups/prod-japaneast-snp-1-compute-2/providers/Microsoft.Network/virtualNetworks/prod-japaneast-snp-1-compute-2 does not have subnets with names worker-subnet,..

Azure CLIが手元のPCにインストールされていない場合は、AzureポータルからCloudShellを使うのがお手軽です。

コマンドの実行が完了したら、Azureポータルから対象のストレージアカウントの [ネットワーク] > [仮想ネットワーク] を確認します。以下のようにサブネットID群が追加されていればOKです。

なお、エンドポイント状態列の「アクセス許可が不十分です」という表示や、ネットワーク一覧の下の警告は無視してOKです。これらは、ユーザーがNCCのサブネットID群の読み取りアクセス許可を持っていないことを示しているだけであり、サーバーレスコンピュートからストレージアカウントへの接続を妨げるものではありません。

6. DBSQLサーバーレスからストレージアカウントへの接続確認（ワークスペース）

NCCをアタッチしたワークスペースにアクセスします。

タイプがサーバーレスのSQLウェアハウスがない場合、左サイドメニューの [SQLウェアハウス] > [SQLウェアハウスを作成]をクリックして作成します。接続確認が目的なので、クラスターサイズはXXSなどの小さなサイズでOKです。

左サイドメニューの [SQLエディタ] にアクセスし、対象のストレージアカウントにデータがあるテーブルに対してSELECTをクエリを実行します。結果が表示されれば接続確認は問題ありません。

ストレージアカウント側のネットワーク設定が上手く行えていない場合、以下のエラーメッセージが出力されます。その場合は前の手順に戻って見落としやミスがないかを確認してみてください。

エラーメッセージ例

This Azure storage request is not authorized. The storage account's 'Firewalls and virtual networks' settings may be blocking access to storage services. Please verify your Azure storage credentials or firewall exception settings.

NCCの設定の流れ：プライベートリンク

続いてNCCのプライベートリンクの設定手順をウォークスルーしていきます。ストレージアカウントのファイアウォールと手順的に被る部分についてはキャプチャを省略してサクサクいきたいと思います。

1. NCCを追加（アカウントコンソール）

• アカウントコンソール (https://accounts.azuredatabricks.net/) にアクセスし、左サイドバーの [クラウドリソース] > [ネットワーク接続構成] をクリックします
• 画面右上にある [ネットワーク接続構成を追加] ボタンをクリックします
• 任意の名前を入力、アタッチしたいワークスペースが存在するリージョンを選択し、[追加] をクリックします

2. NCCをワークスペースにアタッチ（アカウントコンソール）

• アカウントコンソールの左サイドバーの [ワークスペース] をクリックし、NCCをアタッチするワークスペースの名前をクリックします
• [構成] タブが表示されるので右上の [ワークスペースを更新] ボタンをクリックします
• [ネットワーク接続構成] 欄に作成したNCCを設定し [更新] ボタンをクリックします

（ドキュメントに以下の記述がありますので、念のため本記事にも転記しておきます）

• 変更が有効になるまで10分待ちます
• ワークスペースで実行中のサーバーレスのSQLウェアハウスをすべて再起動します

3. 対象のストレージアカウントのリソースIDをコピー（Azureポータル）

Azureポータル (https://portal.azure.com) にアクセスし、対象ストレージアカウントの [概要] ページの右上にある [JSONビュー] をクリックします。

上部にリソースIDが表示されるので、枠で囲んだアイコンをクリックしてリソースIDをコピーします。

4. プライベートエンドポイントルールを追加（アカウントコンソール）

• アカウントコンソールの左サイドバーの [クラウドリソース] > [ネットワーク接続構成] にアクセスし、追加したNCCをクリックします
• [プライベートエンドポイントルール] タブを開き、[プライベートエンドポイントルールを追加] ボタンをクリックします

[適用先AzureリソースのID] に先ほどコピーしたストレージアカウントのリソースIDを貼り付けます。Azureサブリソース名については、以下の表を参考に、対象のストレージアカウントの種類に応じて blob か dfs を入力します。

対象のストレージアカウント	使用するサブリソース名
Blob Storage (= 階層型名前空間が有効でないストレージアカウント)	blob
ADLS Gen2 (= 階層型名前空間が有効なストレージアカウント)	dfs
ワークスペースルートストレージ（ルートDBFS）	1つのリソースIDに対して blob と dfs の2つのプライベートエンドポイントルールを作成する必要がある

ここではADLS Gen2を対象にしています。入力が完了したら [追加] をクリックします。

[追加] ボタンが処理中を表す表示に変わるので、しばらく待ちます。（数十秒〜1分程度）

自動的に表示が切り替わり、プライベートエンドポイントルールが1件追加されます。ステータスが PENDING になっているはずです。

補足: Azureのサブリソース名

上記以外のAzureサービスのサブリソース名については、Azure Private Linkのドキュメントをご確認ください。

5. プライベートエンドポイント接続を承認（Azureポータル）

Azureポータルで対象のストレージアカウントにアクセスし、[ネットワーク] > [プライベート エンドポイント接続] タブを開きます。接続状態が 保留中 のプライベートエンドポイント接続が1件表示されるので、チェックボックスにチェックを入れて [承認] をクリックします。

必要に応じて説明を入力し（ブランクでもOK）、[はい] をクリックします。

しばらく待機し、接続状態が 承認済み になることを確認します。

アカウントコンソールのプライベートエンドポイントルールのステータスが ESTABLISHED になっていることを確認します。

6. （オプション）ストレージアカウントのパブリックネットワークアクセスを無効化（Azureポータル）

省略可能な手順です。対象のストレージアカウントへのアクセスについてプライベートエンドポイントに限定したい場合は、パブリックネットワークを 無効 に変更して保存します。

7. DBSQLサーバーレスからストレージアカウントへの接続確認（ワークスペース）

• NCCをアタッチしたワークスペースにアクセスします
• タイプがサーバーレスのSQLウェアハウスがない場合、左サイドメニューの [SQLウェアハウス] > [SQLウェアハウスを作成]をクリックして作成します。接続確認が目的なので、クラスターサイズはXXSなどの小さなサイズでOKです
• 左サイドメニューの [SQLエディタ] にアクセスし、対象のストレージアカウントにデータがあるテーブルに対してSELECTをクエリを実行します。結果が表示されれば接続確認は問題ありません

NCCのウォークスルーは以上です。

Appendix

ここからは付録的な内容です。

NCCの分け方

NCCをどのように分けるかについて、ドキュメントでは以下のようにガイドされています。少なくとも、ストレージアカウントのファイアウォールに使うNCCと、プライベートリンクを使うNCCを分けるところから始めるのが良さそうです。

Databricks では、同じ部署内で同じリージョン接続プロパティを共有するワークスペース間では、NCC を共有することを推奨しています。 たとえば、一部のワークスペースが Private Link を使い、他のワークスペースはファイアウォールの有効化を使う場合、それらのユース ケースには個別の NCC を使います。

上記のガイドでは、複数のパラメーター（ビジネスユニットの数、ワークスペースの数とリージョン、ストレージアカウントの数と接続方式）が言及されています。大規模にAzure Databricksを活用している組織では、前述のNCCの制限を念頭に置きつつ、組織の実情に合わせてしっかりと設計するのが良いでしょう。

NCCアタッチ、未アタッチのワークスペース間での動作の違い

NCCをアタッチしていないワークスペースのサーバーレスコンピュートも、サービスエンドポイントを経由してストレージアカウントにアクセスします。NCCアタッチ、未アタッチのワークスペース間での動作の違いは以下の通りです。

1. NCCをアタッチしたワークスペース

   • サービスエンドポイントのサブネットID群が静的になります
   • このサブネットID群は、ファイアウォールのルールに追加することができます

2. NCCをアタッチしていないワークスペース

   • サービスエンドポイントのサブネットID群は静的ではありません
   • ただし、NCCをアタッチしたワークスペースと同一のサブネットのサービスエンドポイントを利用する可能性があります

つまり、NCCをアタッチしたワークスペースのサブネットID群をファイアウォールのルールに追加したストレージアカウントに対して、NCCをアタッチしていないワークスペースのサーバーレスコンピュートからの接続が成功する場合があります。これは、両方のワークスペースが同一のサブネットのサービスエンドポイントを利用する可能性があるためです。

NCCがアタッチされているかどうかを問わず、サーバーレスコンピュートからストレージアカウントへの通信は、認証や1時間の短命なトークンを使ったアクセス、暗号化などによって安全に保護されています。NCCをアタッチすることで、静的なVNetサブネットID群をストレージアカウントのファイアウォールに設定し、接続元を限定することができます。

特定のNCCがアタッチされたワークスペースのサーバーレスコンピュートからのネットワークアクセスのみを許可する必要がある場合には、NCCのプライベートリンクの利用を検討する必要があります。

まとめ

本記事では、Azure Databricksのサーバーレスコンピュートと、Azure StorageやAzure SQL Databaseなどの各種Azureサービス間のセキュアなネットワーク接続を管理するための機能である「ネットワーク接続構成（NCC）」について、概要と設定手順を紹介しました。

NCCを用いることで、以下の2つの方法でサーバーレスコンピュートからAzureサービスへのネットワークアクセスを制御できます：

1. ストレージアカウントのファイアウォールを使って、NCCに設定された静的なサブネットID群からの接続のみを許可する
2. NCCのプライベートエンドポイントルールを使って、プライベートリンク経由でAzureサービスに接続する

NCCはアカウントレベルのリソースであり、複数のワークスペースに対して一元的にネットワーク設定を管理できるメリットがあります。NCCの制限事項を理解した上で、組織の要件に合わせて適切に設計、活用していきましょう。