こちらの続編です。
前回の手順で接続自体はできましたが、西日本のストレージアカウントでストレージファイアウォールを設定すると(当たり前ですが)データにアクセスできなくなってしまいました。
弊社のAzureスーパーエキスパートの方の記事に助けられました。
こちらのNCCの設定の流れ：プライベートリンクで解決できました。
マニュアルはこちら。
NCC 内にプライベート エンドポイントを追加すると、Azure Databricks によって Azure リソースへのプライベート エンドポイント要求が作成されます。 リソース側で要求が受け入れられると、プライベート エンドポイントは、サーバーレス コンピューティング プレーンからリソースにアクセスするために使用されます。 プライベート エンドポイントはユーザーの Azure Databricks アカウント専用であり、認可されたワークスペースからのみアクセスできます。
Delta Sharingによるテーブルの共有
以前の記事の手順に従って、西日本のテーブルを東日本に共有してください。
NCCの追加
アカウントコンソールにログインし、東日本のAzure DatabricksワークスペースにNCCを追加します。
NCCの設定を進める前に、Azure Portalに移動します。
ストレージアカウントのリソースIDの取得
Azureリソース(ここではストレージアカウント)へのプライベートエンドポイント要求を作成するには、要求先のストレージアカウントのリソースIDが必要となります。
こちらにあるように、西日本で使用しているストレージアカウントにアクセスし、Essential(日本語だと要点) のJSON ビューをクリックします。リソースIDをコピーしておきます。また、使用しているストレージがBlog StorageなのかADLSなのかも確認しておきます。
再度、Databricksアカウントコンソールに移動します。
プライベートエンドポイントルールの追加
NCCにアクセスし、プライベートエンドポイントルールタブを開き、プライベートエンドポイントルールを追加をクリックします。
上でコピーしたストレージアカウントのリソースIDを適用先AzureリソースのIDに貼り付け、使用しているストレージに応じてサブリソース名を入力します。以下の例では、ADLSのdfsを指定しています。
追加をクリックすることで、ストレージアカウントへのプライベートエンドポイント要求が作成されます。この時点ではステータスはPENDINGです。承認するために再度Azure Portalに移動します。
プライベートエンドポイント要求の承認
Azure PortalのPrivate Linkセンター、あるいは、要求先のストレージアカウントの画面で承認を行うことができます。
Private Linkセンター
ストレージアカウント
承認されると、Azure Databricksアカウントコンソールでの表示がESTABLISHEDになります。
パブリックネットワークアクセスを禁止するようにストレージアカウントを設定する
このままではパブリックアクセスは許可された状態なので、適切にネットワークの設定を行います。
無効に設定した場合、サーバレスSQLウェアハウスからプライベートエンドポイント経由でストレージにはアクセスできますが、それ以外のクラスターや非サーバレスのウェアハウスからはアクセスできなくなっています。
こちらでも説明されているように、要件に応じてファイアウォールの設定を変更ください。
対象のストレージアカウントのファイアウォールについて、「すべてのネットワークから有効」から「選択した仮想ネットワークとIPアドレスから有効」に変更する場合、上記画面の「仮想ネットワーク」のセクションにAzure Databricksワークスペースの2つのサブネット（通称 public-subnet と private-subnet）のIDを追加してサービスエンドポイントを有効化してください。
上記を行わないと、非サーバーレスのクラスターやSQLウェアハウスから対象のストレージアカウントにアクセスできなくなります。
なお、サービスエンドポイントが利用できるのはVNetインジェクションされたAzure Databricksワークスペースである点に留意ください。
動作確認
設定が反映されるまで5分ほど待ち、東日本のサーバレスSQLウェアハウスを再起動して西日本のテーブルにアクセスします。
