MENU

Azure BatchとADLS Gen2の対応状況まとめ｜階層型名前空間(HNS)の制限とベストプラクティス

Azure

Azure Batch を使っていると、「ストレージは ADLS Gen2（階層型名前空間あり）のままでよいのか？」という疑問に必ずぶつかります。特に、既存のデータレイクをそのままバッチ処理に使いたいケースでは、どこまで公式にサポートされているのかを正しく理解しておかないと、思わぬところで機能が動かない・プレビュー環境だけ失敗するといったトラブルになりがちです。本記事では、Azure Batch と ADLS Gen2（階層型名前空間）の対応状況を整理しつつ、現実的な構成パターンと設計のコツを詳しく解説します。

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

Azure Batch と ADLS Gen2（階層型名前空間）の基本整理

Azure Batch がストレージに求めているもの

Azure Batch は、内部にファイルシステムを持たず、以下の用途で Azure Storage（Blob / Files）に強く依存しています。

  • ジョブ・タスクの 入力データ（resourceFiles / inputFiles）
  • タスク終了後の 出力データ（outputFiles）
  • アプリケーション パッケージ（Application Packages）
  • Azure Storage ベースの 仮想ファイル システム マウント（mountConfigurations）
  • ログ、診断情報の退避

このうち「どの用途で ADLS Gen2（階層型名前空間＝HNS 有効）を使えるか」が本記事の焦点になります。

ADLS Gen2 と階層型名前空間（HNS）とは？

Azure Data Lake Storage Gen2（ADLS Gen2）は、Blob ストレージに階層型名前空間（Hierarchical Namespace, HNS）を追加したものです。HNS を有効にすると、ディレクトリ／サブディレクトリを持つファイルシステム的な構造が Blob ストレージ上に提供され、分析ワークロードに最適化された操作（ディレクトリ単位の移動・削除など）が可能になります。

つまり、ADLS Gen2 は「まったく別物のストレージ」ではなく、Blob ストレージ＋ファイルシステム機能という位置付けです。この「ファイルシステム機能」を有効にするフラグが HNS であり、一度有効にすると元には戻せません。

Azure Batch は ADLS Gen2 をサポートするか？結論

結論を整理すると次のとおりです。

  • ジョブ／タスクの入力・出力・リソースファイルの保管：ADLS Gen2（HNS 有効）でも 利用可能
  • アプリケーション パッケージ（Application Packages）：HNS 有効アカウントでは 利用不可
  • Azure Storage ベースの仮想ファイル システム マウント（Blob / Files マウント）：HNS 有効アカウントでは 利用不可

これは、公式ドキュメントでも明記されています。「階層型名前空間（Hierarchical namespace）を有効にしたストレージ アカウントでは、Application Packages と Azure Storage ベースの仮想ファイル システム マウント機能は利用できない」とされています。

また、Microsoft Q&A などでも、「Batch のリンク ストレージとして ADLS Gen2 を利用可能だが、上記 2 機能は動作しない」という形で繰り返し回答されています。

つまり、Azure Batch と ADLS Gen2 の関係は次のように覚えるとシンプルです。

  • 「データを置く」用途 → ADLS Gen2 で OK
  • 「アプリ配布とマウント」用途 → HNS 無効のストレージか別手段が必要

利用シナリオ別の可否早見表

まずはざっくりと、HNS 有効アカウント（ADLS Gen2）での可否を一覧にしておきます。

シナリオADLS Gen2（HNS 有効）補足・推奨代替
ジョブ／タスクの入力データ保管（resourceFiles / inputFiles）可SAS or マネージド ID でアクセス制御
タスク出力データ（outputFiles）可成果物、ログ、メトリック等の保存に利用
リソースファイル配布（スクリプト・設定ファイル等）可Blob API 経由で取得されるため問題なし
アプリケーション パッケージ（Application Packages）不可HNS 無効ストレージ or コンテナ イメージで代替
Azure Storage ベースの仮想ファイル システム マウント（Blob / Files）不可HNS 無効アカウントでマウント、もしくはローカル取得型に変更
ストレージ アカウントにファイアウォール／VNet 制限を設定要注意Application Packages とマウントはFirewall ありでも不可。Private Endpoint と DNS を正しく設計する必要あり。

なぜ「部分的サポート」になるのか

Blob API ベースの処理はおおむね動く

ADLS Gen2 は HNS を有効にしても、従来の Blob API でのアクセスをサポートしています。

Batch の「resourceFiles」「outputFiles」などは、いわゆる Blob のブロック Blob へのアップロード／ダウンロードの範囲で完結するため、HNS が有効でも基本的に問題ありません。

そのため、以下のような構成は ADLS Gen2 でもそのまま動作します。

  • 巨大な CSV / Parquet を ADLS Gen2 上に配置し、Batch タスクから読み込む
  • タスクの結果（集計結果、ログ、サマリーファイル）を ADLS Gen2 に書き戻す
  • スクリプトや設定ファイルを ADLS Gen2 に置いておき、resourceFiles として配布する

ストレージ側の追加機能を前提とする機能は非対応

一方で、Application Packages や Storage ベースのマウント機能は、Blob ストレージとの統合がより密で、アクセス方法や権限管理が HNS を前提としていない古い設計になっています。

公式ドキュメント上も、「ファイアウォールが有効なストレージ」および「HNS 有効なストレージ」では Application Packages と仮想ファイル システム マウントが使えないと明記されており、これは設定やネットワーク構成では回避できません。

そのため、ADLS Gen2 を Batch に紐づけること自体は可能だが、上記 2 機能は諦める必要がある、という「部分的サポート」という表現になります。

推奨アーキテクチャ：用途分離（二層ストレージ）

実運用で安定して使うためには、次のような二層ストレージ構成がもっともトラブルが少なくおすすめです。

構成イメージ

  • データ用ストレージ
    • アカウント種別：GPv2 + HNS 有効（ADLS Gen2）
    • 用途：入力データ、出力データ、ジョブログ、診断ログの保管
    • アクセス方法：SAS または マネージド ID（Azure AD 認証）
  • 機能用ストレージ
    • アカウント種別：GPv2（HNS 無効）
    • 用途：Application Packages、Azure Files / Blob のマウント専用
    • アクセス方法：通常の Blob / Files 認証

Batch アカウントに関連付ける「既定のストレージ アカウント」をどちらにするかはユースケース次第ですが、アプリケーション パッケージやマウントを使うなら、機能用ストレージをリンクする構成が運用上わかりやすくなります。

二層構成のメリット

  • ADLS Gen2 の ACL や階層構造を活かして、データを「データレイクらしく」管理できる
  • Batch 固有機能（Application Packages / マウント）を HNS 無効ストレージで安全に利用できる
  • 将来、Batch 以外のサービス（Synapse, Fabric, Databricks 等）からも同じデータレイクを共用しやすい
  • ファイアウォールや Private Endpoint の設定を用途ごとにチューニングできる

アプリケーション配布：Application Packages からコンテナへ

Application Packages の課題

Application Packages は、Batch ノードに配布したいアプリケーション一式を Zip 化して Blob に保管し、プール起動時に自動展開してくれる便利機能です。しかし、次の制限があります。

  • 階層型名前空間（HNS）を有効にしたストレージ アカウントでは 利用不可
  • ストレージ アカウントにファイアウォール／VNet 制限がある場合も 利用不可
  • Zip 作成・アップロード・バージョン管理が運用負荷になりがち

ADLS Gen2 をメインストレージにしたい場合、Application Packages にこだわると構成がかなり複雑になります。そこで、最近の Azure の推奨はコンテナ イメージによるアプリ配布です。

コンテナ イメージでの配布パターン

Batch の「poolConfiguration」でコンテナを指定すれば、プールノードごとに 同一バージョンの Docker イメージを展開できます。画像（イメージ）のホスト先は Azure Container Registry（ACR）が一般的です。

典型的な構成は次のとおりです。

  1. アプリケーションを Docker イメージ化し、ACR にプッシュ
  2. Batch プール作成時に、containerConfiguration でイメージとレジストリ資格情報を指定
  3. 各タスクの commandLine は、コンテナ内のエントリポイントを実行

イメージ更新も「タグを変えるだけ」「別タグを指定した新プールを作る」といった運用にできるため、CI/CD との相性も良好です。

コンテナプール設定の例（概略）

{
  "pool": {
    "vmSize": "Standard_D4as_v5",
    "virtualMachineConfiguration": {
      "imageReference": {
        "publisher": "microsoft-azure-batch",
        "offer": "ubuntu-server-container",
        "sku": "20-04-lts",
        "version": "latest"
      },
      "containerConfiguration": {
        "type": "dockerCompatible",
        "containerImageNames": [
          "myregistry.azurecr.io/my-batch-app:1.0.0"
        ],
        "registry": {
          "userName": "myregistry",
          "password": "<ACR のパスワード or マネージド ID>"
        }
      }
    }
  }
}

この構成であれば、ストレージが ADLS Gen2 かどうかに依存せずアプリ配布が完結するため、今から新規構成を作るのであればコンテナ方式を強くおすすめします。

マウント機能の代替パターン

なぜ Storage マウントが ADLS Gen2 では使えないのか

Batch の Azure Storage ベースのマウント機能は、mountConfigurations で Blob / Azure Files を VM のローカルパスとしてマウントできる機能です。しかし、前述のとおり、HNS 有効ストレージではこの機能はサポートされません。

これは、ADLS Gen2 の API が従来の Blob API とは異なる部分を持ち、内部実装の互換性がないためと考えられます（公式には「サポートされない」とだけ記載）。

パターンA：HNS 無効アカウントをマウント専用にする

どうしてもマウントが必要な場合は、マウント専用の HNS 無効ストレージ アカウントを用意するのが現実的です。

  • ADLS Gen2 側：データ保管・長期保存・分析用途
  • HNS 無効アカウント側：ジョブ実行時の一時領域／共有ディスクとして利用

ジョブの流れとしては、次のようなイメージになります。

  1. ジョブ開始時に、ADLS Gen2 <-> HNS 無効ストレージ間で必要なデータをコピー
  2. Batch ノードは HNS 無効ストレージをマウントして高速に読み書き
  3. ジョブ終了時に、成果物のみ ADLS Gen2 に戻す

パターンB：マウントを諦めて「取得型」に切り替える

マウントが「なんとなく便利だから」という理由で使われているだけなら、タスク起動時に AzCopy / SDK でローカルディスクに取得するパターンに置き換えた方が構成はシンプルになります。

  • タスク開始時：
    • AzCopy または Data Lake SDK を使って ADLS Gen2 から C:\batchdata などにデータをコピー
  • タスク実行：
    • アプリケーションはローカルパスを参照（I/O パフォーマンスも向上）
  • タスク終了時：
    • 結果を ADLS Gen2 にアップロードし、不要なローカルデータを削除

シェルスクリプトの例（Linux ノード）のイメージは次のようになります。

#!/bin/bash
set -e

# 1. 入力データ取得（SAS 付き URL 例）
azcopy copy \
  "https://mystorage.dfs.core.windows.net/input/&lt;path&gt;?&lt;SAS&gt;" \
  "/mnt/batch/tasks/workitems/input" \
  --recursive=true

# 2. アプリ実行
python main.py --input /mnt/batch/tasks/workitems/input --output ./output

# 3. 結果アップロード
azcopy copy \
  "./output" \
  "https://mystorage.dfs.core.windows.net/output/&lt;path&gt;?&lt;SAS&gt;" \
  --recursive=true

この方式であれば、Batch 側の機能に依存せず ADLS Gen2 をフル活用できます。

マウント vs 取得型の比較

項目マウント方式取得方式（AzCopy / SDK）
ADLS Gen2 での利用可否不可（HNS 有効アカウント）可
実装の複雑さBatch 設定だけで完結スクリプト実装が必要
I/O パフォーマンスネットワーク越しのアクセスローカルディスクのため高速
柔軟性Batch / Storage の機能制約に依存任意のコピー・変換ロジックを組み込める

ネットワーク・セキュリティ設計の注意点

Firewall / Private Endpoint と Batch の関係

ADLS Gen2 を本番運用する場合、多くの環境で ストレージ アカウントにファイアウォールや Private Endpoint を設定します。

このとき注意すべきポイントは次のとおりです。

  • Application Packages / Storage ベースのマウントは、
    • HNS 有効ストレージ
    • ファイアウォール有効ストレージ
    のどちらの場合も サポートされない（回避不可能な制限）
  • Batch プールを VNet 統合している場合、そのサブネットからストレージの Private Endpoint に到達できることを確認する
  • Private DNS ゾーン（privatelink.blob.core.windows.net / privatelink.dfs.core.windows.net 等）の名前解決設定を正しく行う
  • ユーザー割り当てマネージド ID でストレージにアクセスする場合は、ストレージ側に RBAC / ACL を正しく設定

Batch アカウントの配置モードにも注意

Batch には「Batch サービスモード」と「ユーザーサブスクリプションモード」があり、VNet や Private Endpoint を使う場合はどちらのモードでプールを作成しているかも重要になります。

  • Batch サービスモード：
    • 多くの場合、ストレージとの通信は Microsoft 管理のネットワーク経由
    • Private Endpoint を使う場合、特定の構成が必要になるケースあり
  • ユーザーサブスクリプションモード：
    • VM がユーザーのサブスクリプション上に作成されるため、VNet / NSG / Route Table をユーザー側で自由に制御可能
    • ただし管理コスト・責任範囲は増える

ADLS Gen2 の Private Endpoint と組み合わせる場合は、事前にネットワーク設計を図で書き出しておくとトラブルが減ります。

構成例：Azure Batch + ADLS Gen2 + VNet

典型的な「データレイク + バッチ処理」構成の一例を文章で整理します。

  • リソースグループ：
    • ADLS Gen2（データ用、HNS 有効、Private Endpoint 有）
    • GPv2（HNS 無効、Application Packages / マウント用、必要に応じて Private Endpoint）
    • Azure Batch アカウント（Batch サービスモード or ユーザーサブスクリプションモード）
    • VNet + サブネット（Batch プール用）
    • Azure Container Registry（コンテナ イメージ用）

処理フローのイメージは次のようになります。

  1. データ基盤側が ADLS Gen2 にデータを投入（ETL / ストリーミングなど）
  2. バッチ処理をトリガー（Logic Apps / Functions / ADF / Fabric などから）
  3. Batch ジョブが起動し、コンテナイメージを使ってプールノードを起動
  4. タスク開始時に ADLS Gen2 から入力を取得し、ローカルディスクで処理
  5. 結果・ログを ADLS Gen2 にアップロード
  6. 必要に応じて、集計結果を Synapse / Fabric / Power BI などに連携

この構成では、ADLS Gen2 は「データレイクとしての本来の役割」に集中し、Batch のアプリ配布・マウントはコンテナ＋HNS 無効ストレージで担保する形になります。

トラブルシューティング：動かないときのチェックリスト

既存構成で「急に動かなくなった」「一部の機能だけエラーになる」といったときに確認すべきポイントをまとめます。

症状よくある原因確認ポイント
Application Packages がデプロイに失敗するリンクストレージが HNS 有効 or ファイアウォール有効ストレージ アカウントの「階層型名前空間」と「ネットワーク」設定を確認
mountConfigurations でのマウントに失敗するマウント先が ADLS Gen2 アカウントマウント対象のストレージが HNS 有効になっていないか確認
resourceFiles でのダウンロードが 403 / 404SAS トークンの期限切れ、パスミス、ACL 不足SAS 有効期限と権限、Data Lake 側 ACL / RBAC を確認
VNet 統合環境で Storage へのアクセスがタイムアウトPrivate Endpoint へのルーティング or DNS が誤りVM から nslookup / curl で名前解決と疎通性を確認
特定の環境だけ ADLS Gen2 にアクセスできない環境ごとのネットワーク／ファイアウォール設定の差分ステージング／本番で NSG・ルートテーブル・Firewall 設定を比較

まずは 「HNS の有無」「Firewall / Private Endpoint の有無」「使おうとしている Batch 機能」の 3 点を切り分けると、原因候補をかなり早く絞り込めます。

よくある質問（FAQ）

Q1. Batch アカウントに紐付ける既定ストレージとして ADLS Gen2 を選んでもよい？

A. 可能ですが、Application Packages と Storage マウントを使わない前提であれば、という条件付きです。

リンクストレージとして ADLS Gen2 を使っても、ジョブ／タスクの入力・出力には問題なく利用できます。しかし、後から「Application Packages を使いたい」「マウントしたい」となったときに制限に引っかかるため、はじめから二層構成（データ用 ADLS Gen2 + 機能用 HNS 無効ストレージ）にしておく方が安全です。

Q2. ADLS Gen2 にすると Batch 処理のパフォーマンスは上がる？

A. ADLS Gen2 は分析系ワークロード向けに最適化されており、大量ファイルや階層構造を扱う場合にメリットがありますが、Batch の性能向上はワークロード次第です。

ADLS Gen2 の HNS は、ディレクトリ単位での操作や ACL、メタデータ管理などが効率化されるため、データレイクとしてのスループットや TCO 改善に寄与します。

一方で、Batch タスク側から見ると、実質的には「ネットワーク越しの Blob アクセス」であることに変わりはありません。I/O がボトルネックになるようなバッチ処理では、ストレージ種別よりも次のようなポイントの方が効きます。

  • ローカルディスクに一時展開してから処理する（AzCopy / SDK での取得型）
  • 複数タスクにデータを適切にシャーディングして並列度を上げる
  • 小さなファイルを大量に扱わないよう、事前にマージする

Q3. 既存の Blob ストレージを ADLS Gen2 にアップグレードしてもよい？

A. 可能ですが、「一度 HNS を有効にすると元に戻せない」点と Batch の制限を理解した上で行うべきです。

公式ドキュメントにもあるように、Blob ストレージを ADLS Gen2 にアップグレードすると、階層型名前空間が有効になり、ファイル／ディレクトリ単位の操作などの機能が利用可能になりますが、この変更は 不可逆です。

もしそのストレージを Batch の Application Packages / マウントで既に使っている場合、アップグレード後にこれらの機能が利用できなくなる可能性があります。アップグレード前に、Batch からの利用用途を棚卸しすることが必須です。

Q4. ADLS Gen2 へはどの認証方式でアクセスするのがよい？

Batch から ADLS Gen2 にアクセスする場合、主な選択肢は次の 2 つです。

  • SAS トークン
    • resourceFiles / outputFiles でよく使われる
    • 有効期限・権限を細かく制御可能
    • トークン管理の運用が必要（Key Vault + Managed Identity との組み合わせ推奨）
  • マネージド ID + Azure AD 認証
    • プールの VM（またはユーザー割り当て Managed Identity）にロールを付与
    • アプリケーションが Data Lake SDK 経由でアクセス
    • 長期的にはこちらが推奨される流れ

単純に「Batch の API 経由でファイルをアップロード／ダウンロードするだけ」であれば SAS の方が楽な場合もありますが、中長期的な運用やセキュリティを考えると、マネージド ID を前提とした実装を検討する価値は高いです。

まとめ：データは ADLS Gen2、アプリ配布とマウントは別ストレージ or コンテナ

本記事のポイントを最後に整理します。

  • Azure Batch は ADLS Gen2（HNS 有効）を 入出力データ・リソースファイル用途では問題なく利用可能
  • しかし、Application Packages と Azure Storage ベースのマウントは
    • HNS 有効ストレージ
    • ファイアウォール有効ストレージ
    ではサポートされない
  • そのため、実運用では
    • データ用：ADLS Gen2（HNS 有効）
    • 機能用：HNS 無効ストレージ（＋コンテナ イメージ）
    の用途分離（二層ストレージ）構成が安全
  • マウントが必須なら HNS 無効ストレージでマウントし、そうでなければ AzCopy / SDK による「取得型」に切り替えると構成がシンプルになる
  • ADLS Gen2 を本番で使う際は、Firewall / Private Endpoint / DNS / マネージド ID など、ネットワークと認証の設計もセットで検討する

これから Azure Batch と ADLS Gen2 を組み合わせたバッチ処理基盤を設計する場合は、「データレイクとしての ADLS Gen2」と「Batch のアプリ配布・マウント機能」を分離して考えることで、将来の拡張やサービス追加にも耐えられる構成にしやすくなります。

なお、本記事の内容は執筆時点の公式ドキュメントおよび Q&A をもとに整理したものであり、今後仕様が変わる可能性があります。必ず最新版の Azure 公式ドキュメントも合わせて確認してください。

Azure
Azure Storage ADLS Gen2 Azure Batch 階層型名前空間

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次