Azure Data Lake Storage Gen2

解決する課題

ペタバイト級の生データを一か所に集約し、複数の分析エンジンから高速かつ安全に読み書きしたい場面で使います。汎用のオブジェクトストレージはフラットな名前空間のため、ディレクトリの一覧やリネームが重く、ファイル単位の細かなアクセス制御も難しくなりがちです。Azure Data Lake Storage Gen2（以下 ADLS Gen2）は Blob Storage を土台に分析向けの機能を加え、これらを解消します。

• 生データから加工済みデータまでを単一のストレージに集約し、分析パイプラインの置き場にする
• 本物のディレクトリを持つため、フォルダ単位の一覧・リネーム・削除が単一操作で速い
• POSIX 風 ACL でディレクトリ／ファイル単位の細かいアクセス制御ができる
• Synapse、Databricks、HDInsight、Microsoft Fabric など主要な分析エンジンから直接読み書きできる

主要概念と用語

• 階層型名前空間（HNS / Hierarchical Namespace）: ストレージアカウントで有効化する機能。ファイルとディレクトリを本物の階層構造として扱えるようにする。ADLS Gen2 の核心
• ファイルシステム（コンテナ）: ADLS Gen2 のデータを入れる最上位の入れ物。Blob Storage のコンテナと同じものを分析文脈でこう呼ぶ
• ディレクトリ: HNS により実体を持つフォルダ。一覧やリネームがメタデータ操作として完結する
• POSIX 風 ACL: 所有者・グループ・その他のパーミッションに加え、ユーザーやグループ単位のアクセス制御リストを付与する仕組み。RBAC と組み合わせて使う
• DFS エンドポイント: 階層対応の API を提供するエンドポイント。account.dfs.core.windows.net の形式で、従来の Blob エンドポイントと併存する
• マルチプロトコルアクセス: 同じデータを Blob API と Data Lake API の双方から扱える性質。既存の Blob 向けツールやライフサイクル機能をそのまま活かせる
• ABFS ドライバー: Hadoop / Spark から ADLS Gen2 へアクセスするためのドライバー。abfss:// スキームでパスを指定する

仕様・制限・クォータ

• 階層型名前空間はストレージアカウント作成時に有効化するのが基本。後からの有効化や移行には手順と注意が伴い、有効化後にフラット名前空間へ戻すことはできない
• 容量・耐久性・冗長性オプション（LRS / ZRS / GRS / GZRS など）は基盤の Blob Storage に準じる
• アクセスは DFS エンドポイント（階層対応）と Blob エンドポイントの両方から可能。利用する API やツールによって使い分ける
• ACL はディレクトリとファイルに付与でき、親から子へ引き継ぐ既定 ACL も設定できる。1 つの項目に設定できる ACL エントリ数には上限がある
• HNS 有効時は SFTP や NFS 3.0 によるアクセスも構成可能（別途有効化が必要）

内部の仕組み

ADLS Gen2 は独立した製品ではなく、Blob Storage に階層型名前空間を重ねた構成です。HNS を有効にすると、data/2026/sales.parquet のようなパスは「区切り文字を含む単なるキー」ではなく、ディレクトリとファイルからなる実体のある木構造として管理されます。

この違いが分析ワークロードで効きます。フラット名前空間では「あるフォルダ配下のリネーム」はキーを 1 つずつ書き換える操作の集まりになりますが、HNS ではディレクトリのメタデータ更新だけで完結するため、巨大なフォルダのリネームや削除が単一のアトミックな操作になります。分析ジョブが中間結果を一時ディレクトリに書き、最後に本番ディレクトリへ差し替える、といったパターンが安全かつ高速になります。

アクセス制御は RBAC と POSIX 風 ACL の二層で評価されます。まずストレージアカウントやコンテナに対する RBAC ロールが確認され、続いて対象のディレクトリ／ファイルの ACL が評価されます。RBAC は粗い粒度で広く、ACL はパス単位で細かく、という役割分担です。

設計パターン / ベストプラクティス

• メダリオン構成: 生データ（ブロンズ）→ クレンジング済み（シルバー）→ 集計・分析用（ゴールド）をディレクトリ階層で分け、加工段階ごとにアクセス権を分離する
• パーティション設計: year/month/day などの階層でディレクトリを切り、分析エンジンが不要なパスを読み飛ばせる（プルーニング）ようにする
• 列指向フォーマット: Parquet や Delta / Iceberg などの形式で保存し、スキャン量と保存コストを抑える。小さなファイルの乱立は避け、適度なサイズに集約する
• アクセス制御の設計: 個々のユーザーではなく Entra ID のセキュリティグループに ACL を付与し、メンバー変更で運用する。新規ファイルに権限を伝播させたい階層には既定 ACLを設定する
• ネットワーク分離: 分析クラスターとストレージをプライベートエンドポイントで接続し、パブリック経路を遮断する

運用・監視

• Azure Monitor の Metrics で容量・トランザクション・レイテンシ・可用性を監視する
• 診断設定で読み取り／書き込み／削除のリソースログを Log Analytics などへ送り、誰がどのパスへアクセスしたかを監査する
• ライフサイクル管理ポリシーで、一定期間アクセスのないデータを Hot から Cool・Cold・Archive へ自動的に移行・削除し、保存コストを抑える
• AzCopy で大量データの移行・同期を高速に行う。オンプレや他クラウドからの初期ロードに使う
• 「403 / AuthorizationFailure」は RBAC ロール・ACL のいずれかが不足しているケースが多い。ADLS Gen2 では RBAC と ACL の二層を両方確認する

コスト

課金は基盤の Blob Storage と同じく、「保存量」「トランザクション数」「取り出し」「データ転送」に対して発生します。HNS 有効時はディレクトリ操作などでメタデータ寄りの操作が増える点に留意し、アクセス頻度に応じてアクセス層を使い分けます。具体的な単価や階層の最小保持期間は変動するため、最新の公式情報で確認してください。

セキュリティ

• アクセス制御は Entra ID + RBAC を基本に、パス単位の細かい制御を POSIX 風 ACL で補う二層構成にする
• アプリやサービスからはマネージド IDで接続し、アカウントキーの直書きを避ける。一時的な委譲には有効期限の短いユーザー委任 SASを使う
• 保存時暗号化は既定で常時有効（Microsoft マネージドキー）。要件に応じて **Key Vault のカスタマーマネージドキー（CMK）**を使う。転送時は TLS を強制する
• プライベートエンドポイントでストレージをプライベート IP 化し、パブリックインターネットからの到達を遮断する

関連サービス・比較

データレイク用途では、通常の Azure Blob Storage と比較してどちらを選ぶかが最初の判断になります。HNS の有無が両者を分ける最大の違いです。

ハンズオン / CLI例

# リソースグループを作成
az group create --name demo-rg --location japaneast

# 階層型名前空間を有効化したストレージアカウントを作成（ADLS Gen2）
az storage account create \
  --name mydatalake2026 \
  --resource-group demo-rg \
  --location japaneast \
  --sku Standard_GRS \
  --kind StorageV2 \
  --hierarchical-namespace true \
  --min-tls-version TLS1_2 \
  --allow-blob-public-access false

# ファイルシステム（コンテナ）を作成（Entra ID 認証を使用）
az storage fs create \
  --name analytics \
  --account-name mydatalake2026 \
  --auth-mode login

# ディレクトリを作成
az storage fs directory create \
  --name raw/2026 \
  --file-system analytics \
  --account-name mydatalake2026 \
  --auth-mode login

# 階層型名前空間が有効か確認
az storage account show \
  --name mydatalake2026 \
  --resource-group demo-rg \
  --query "isHnsEnabled" -o tsv