概要
これまでの「オンプレ編」では、Azure の仮想マシン（IaaS）を使って、社員番号から名前を検索できるシンプルな社内システムを構築してきました。Active Directory、SQL Server、ADFS などを組み合わせ、オンプレミスの構成を仮想的に再現しています。
※全体構成の詳細は、【第0回】Azureで社内システム再現（オンプレ編）｜構成図と動作の流れ をご参照ください。
クラウド編では、これまでの構成をベースにしつつ、Azure のマネージドサービス（PaaS）を中心とした構成へ段階的に移行していきます。
※クラウド移行全体の設計方針については、【第10.5回】Azureで社内システム再現（クラウド編）｜オンプレ構成をどうクラウドに移行するか？ にまとめています。
システム構成（今回の対象範囲）
今回のテーマは、Azure Data Factory（ADF）を使って、Blob Storage に保存された社員情報の CSV ファイルを Azure SQL Database にコピーする構成を実現することです。
まず、下図は「クラウド編」におけるシステム全体の構成を示したものです。
このうち、赤枠で示している「ADF → Blob Storage → SQL Database」間のデータ転送構成が、今回の対象範囲です。
次に、下図がその詳細構成図です。
Azure Data Factory（ADF）は、クラウド上のデータ連携や加工をノーコードで構築できる データ統合サービスです。
GUI上の操作でコピー処理や条件分岐などのパイプライン（処理の流れ）を作成でき、さまざまなデータソース間の接続や処理を自動化できます。
今回は、Blob Storage に保存された CSV ファイルを ADF で読み取り、SQL Database に転送する構成を構築しました。
今回は以下の作業を行いました。
- Azure Data Factory を作成し、マネージドIDを有効化
- Blob Storage 側にアクセス権限（ストレージ関連ロール）を付与
- SQL Database 側にもマネージドIDを SQLユーザーとして登録し、
db_datawriter権限を付与 - ADF Studio 上で「データのコピー」アクティビティを作成し、Blob Storage と SQL Database を接続
- ストレージやSQLのネットワーク設定（ファイアウォール・アクセス許可）を調整して接続できるよう構成
Azure Data Factory を使って Blob Storage の CSV を SQL Database にコピーする
今回は、Azure Data Factory（以下 ADF）を使って、Blob Storage に格納された社員情報の CSV ファイルを Azure SQL Database にコピーする構成を実装します。
データファクトリの作成
Azure ポータルから「データファクトリ」を選択し、新しいインスタンスを作成します。
今回は adf-employee という名前で作成しました。
スタジオを起動
作成したデータファクトリのページにある「スタジオの起動」をクリックして、ADF Studio を開きます。
コピーアクティビティの作成
スタジオが起動したら、「移動と変換」カテゴリから データのコピー アクティビティをキャンバス上にドラッグ＆ドロップします。
今回は、Blob Storage にある CSV を SQL Database にコピーする構成のため、アクティビティ名を Copy_EmployeeBlobToSql としました。
Azure Data Factory を使って Blob Storage の CSV を SQL Database にコピーする
今回は、Azure Data Factory（以下 ADF）を使って、Blob Storage に格納された社員情報の CSV ファイルを Azure SQL Database にコピーする構成を実装します。
ADF（データファクトリ）の作成
Azure ポータルから「データファクトリ」を選択し、新しいインスタンスを作成します。
今回は adf-employee という名前で作成しました。
スタジオを起動
作成したデータファクトリのブレードにある「スタジオの起動」をクリックして、ADF Studio を開きます。
コピーアクティビティの作成
スタジオが起動したら、「移動と変換」カテゴリから データのコピー アクティビティをキャンバス上にドラッグ＆ドロップします。
今回は、Blob Storage にある CSV を SQL Database にコピーする構成のため、アクティビティ名を Copy_EmployeeBlobToSql としました。
コピー元（Blob Storage）の設定
コピーアクティビティの「ソース」設定から、新しいデータセットを作成します。
今回は、Automation によって保存された CSV形式の社員情報ファイル をコピー対象とするため、Blob Storage を選択します。
ソースデータセットの新規作成
「新規」をクリックして、コピー元となる BLOB への接続を設定します。
BLOB を選択
データストアの種類として「Azure Blob Storage」を選択します。
CSV 形式のデータセットを選択
保存されているファイルは CSV形式 なので、フォーマットとして「DelimitedText（CSV）」を選択します。
リンクサービスの作成
Blob Storage への接続を表すリンクサービスを新規作成します。
ここでは EmpBlobStorage_LS という名前を付けました。
接続方法として「統合ランタイム」を使用します。
これは ADF がどこで処理を実行するかを決めるもので、以下のような種類があります：
-
Azure 統合ランタイム（デフォルト）：Azure のマネージド環境で実行され、Blob などのクラウドサービスに直接アクセス可能。
※ 通信は パブリックネットワーク経由 で行われます（対象ストレージがパブリックアクセス可能である必要あり）。 -
セルフホステッド統合ランタイム：オンプレやVNetにあるリソースにアクセスする際に使用（Automation や Hybrid Worker に近い考え方）。
本当は ADF もセルフホステッド統合ランタイムを使って、全体を閉域構成で統一したかったのですが、
Azure のファイアウォール機能との連携も試してみたかったため、今回は Azure 統合ランタイムを採用しました。
マネージドIDの有効化とストレージアクセス権の付与
接続テストを実行すると、以下の「マネージドIDが設定されていない」といった内容のエラーが表示され接続に失敗しました。
マネージドIDの有効化とストレージアクセス権の付与
接続テストを実行すると、「マネージドIDが設定されていない」といった内容のエラーが表示されました。
そのため、Azure Data Factory にマネージドIDを有効化し、Blob Storage 側で必要なアクセス権を付与します。
マネージドIDを有効化する
ADFの「ID」メニューから、システム割り当てを「有効」に設定します。
ストレージアカウントにロールを付与
Blob Storage にアクセスできるように、マネージドIDに対して以下のロールを割り当てました。
-
ストレージアカウント共同作成者（Storage Account Contributor）
→ ストレージアカウント自体に対する操作権限
-
ストレージ BLOB データ共同作成者（Storage Blob Data Contributor）
→ BLOB データの読み書き・削除が可能
ADF 統合ランタイム経由での接続とパブリックアクセス設定
今回、ADF は 統合ランタイム を使ってストレージアカウントに接続しています。
この構成では、パブリックネットワーク経由でのアクセスとなるため、ストレージ側で パブリックアクセスの許可設定 が必要です。
ストレージアカウントのネットワーク設定を変更
以下のように、パブリックアクセスを最小限に許可する形でネットワーク設定を行いました。
- 「選択した仮想ネットワークと IP アドレス」
- 「信頼された Azure サービスからのアクセスを許可する」
この「信頼されたサービス」の一覧には ADF も含まれており、有効にすることでアクセスが許可されます。
参考：公式ドキュメント
https://learn.microsoft.com/ja-jp/azure/storage/common/storage-network-security?tabs=azure-portal#exceptions
宛先コンテナの接続テスト
ネットワーク設定を変更したあと、コピー元となる BLOB ファイルのパス（コンテナ）を指定して接続テストを実施。
無事に成功しました。
コンテナ内のファイルパスを指定
最後に、ソースデータとして読み取るファイルのパスを指定します。
今回のコンテナ名は empdata です。
これで、ソース（コピー元）の設定は完了です。
Sink（Azure SQL Database）の設定
次に、コピー先（Sink）として Azure SQL Database を設定していきます。
データベース接続の構成
シンクに Azure SQL Database を選択し、CSVファイルの内容をこのDBにコピーする構成とします。
接続方法の指定
接続には、ソースと同様に 統合ランタイム を使用します。
認証方式の選択
認証には マネージドID を選択しました。
必要なロールの付与
マネージドIDが SQL Server にアクセスできるよう、以下のロールを付与します：
- SQL Server 共同作成者
- SQL Database 共同作成者
接続テストとFWの設定
接続テストを実施すると、ファイアウォールのルールに関するエラーが表示されました。
これは、ADF が 統合ランタイムを通じてパブリック経由で SQL に接続しており、SQL Server 側ではパブリックアクセスが無効化されていたため、接続が拒否されていました。
ファイアウォールルールの追加
SQL Server の「ネットワーク」設定から、パブリックアクセスを有効化したうえで、
接続エラー時に表示された IP アドレスを許可するファイアウォールルールを追加しました。
マネージドIDでのSQL接続に失敗する理由と対処
再度接続テストを実施したら、以下のエラーが発生しました。
Login failed for user ''
⇒ ADF（マネージドID）による接続は試みられましたが、SQL側でこのIDを認識・許可できていない状態です。
なぜエラーになるのか？
ここでポイントとなるのが、「マネージドIDもSQL上では“ユーザー”として登録されていないといけない」という点です。
Azureのリソースに対しては、Azureポータル上の「ロール（例：SQL DB 共同作成者）」を付与すれば操作できますが、
SQL Database にログインするためには、SQL内部にユーザーが存在している必要があります。
AzureのロールとSQL内部ユーザーの違い
| 種類 | 役割 | 設定する場所 | 今回必要か |
|---|---|---|---|
| SQL Server 共同作成者 / SQL DB 共同作成者 | Azure上のSQLリソースの作成・構成・削除 | Azure ポータル（IAM） | 不要（今回は関係なし） |
| SQLユーザー（EXTERNAL PROVIDER） | DBへのログインやデータ操作（SELECT, INSERT など） | SSMSやT-SQLで作成 | 必要（これがないとログイン不可） |
どうやってSQLにマネージドIDのユーザーを作るのか？
SQLにユーザーを追加するには CREATE USER FROM EXTERNAL PROVIDER を使いますが、
この操作はEntra ID（旧Azure AD）で認証されたアカウントでないと実行できません。
今回、SQL認証ユーザー（例：sqladmin）で試しましたが、実行権限がなく失敗しました。
マネージドIDをSQLユーザーとして登録する
Microsoft Entra ID 認証で SQL Server にログインし、マネージドIDのユーザーを作成します。
以下は実際に実行したときの画面です。
CREATE USER [<マネージドID名>] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [<マネージドID名>];
ALTER ROLE db_datawriter ADD MEMBER [<マネージドID名>];
今回のADFのパイプラインでは、SQL Database に対して以下の操作を行っています。
-
テーブル内の既存データをすべて削除(DELETE)
-
Blob StorageのCSVファイルの内容を全件挿入(INSERT)
このため、付与するロールは db_datawriter だけで十分でした。
db_datareader（SELECT権限）は今回は不要ですが、将来的にSQL側の中身を読み取る処理が発生する可能性があれば、その際に追加すれば問題ありません。
接続テストの再実行と設定完了
マネージドIDのユーザー作成とロール付与を行ったあと、再度接続テストを実行しました。
結果、無事に接続が成功。
これで、Azure SQL Database 側の接続設定は完了しました。