Azure Managed Lustre

解決する課題

数百〜数千の計算ノードから巨大データへ同時に読み書きする HPC や AI/ML 学習では、汎用の共有ファイルやオブジェクトストレージだけではスループットが足りません。Azure Managed Lustre は、HPC で広く使われる Lustre 並列ファイルシステムをマネージドで提供し、クラスタ構築・運用なしに高い集約スループットを得られるようにします。

• HPC シミュレーションや解析パイプラインで、多数のノードから単一の名前空間へ並列 I/O したい
• AI/ML の学習で、大量の学習データを高スループットでフィードし GPU を遊ばせたくない
• オンプレの Lustre クラスタをクラウドへ移行し、運用負荷を下げたい
• Blob Storage 上のデータセットを高速ファイルシステムとして展開し、ジョブ後に結果を書き戻したい

主要概念と用語

• Lustre: 多数のクライアントから単一の名前空間へ並列アクセスできるオープンソースの並列ファイルシステム。HPC で広く使われる
• 並列ファイルシステム: データを複数のサーバーへ分散配置し、クライアントが並列に I/O することで集約スループットを稼ぐ方式
• MDS / MDT（メタデータ）: ファイル名やディレクトリ構造などのメタデータを扱うサーバーとそのターゲット
• OSS / OST（オブジェクトストレージ）: 実データを格納するサーバーとそのターゲット。台数に応じてスループット上限が伸びる
• HSM 連携 / Blob 統合: Azure Blob Storage をアーカイブ層とみなし、ファイルシステムへの取り込み（ハイドレーション）と書き戻しを行う仕組み
• インポート / エクスポート: Blob のデータをファイルシステムへ取り込む処理と、ファイルシステムの変更を Blob へ書き戻す処理
• クライアント（lustre client）: 計算ノード側に入れる Lustre クライアント。VNet 経由でファイルシステムをマウントする

仕様・制限・クォータ

• ファイルシステムは POSIX 互換で、Lustre クライアント経由で多数のノードからマウントする
• スループットは 容量とパフォーマンス階層に連動し、容量を増やすほど集約スループット上限が伸びる傾向にある
• ファイルシステムは VNet 内の専用サブネットに配置し、クライアントは同一 VNet からプライベートに接続する
• Azure Blob Storage との連携により、データの取り込み（インポート）と書き戻し（エクスポート）を自動化できる
• 提供されるパフォーマンス階層は要件に応じて選択し、容量あたりのスループット単価が階層で変わる
• 対応リージョン・容量の最小単位・上限値・クォータはサービス更新で変わるため、最新の公式ドキュメントで確認する

内部の仕組み

Azure Managed Lustre は、メタデータを扱う MDS / MDT と実データを扱う OSS / OST から成る Lustre のアーキテクチャを、マイクロソフトがマネージドで構築・運用します。利用者はサーバー個別を意識せず、容量とパフォーマンス階層を指定するだけでクラスタが用意されます。

• クライアント（計算ノード）は VNet 内の専用サブネット経由でファイルシステムをマウントし、単一の名前空間として読み書きする
• 実データは複数の OST に分散ストライプされ、多数のクライアントから並列に I/O することで集約スループットを稼ぐ
• メタデータ操作は MDT が処理し、データ I/O とは別経路で扱われる
• Blob Storage との連携では、ジョブ開始時に必要なデータをファイルシステムへ取り込み（ハイドレーション）、ジョブ完了後に結果を Blob へ書き戻すことで、長期保管は安価な Blob、計算時は高速 Lustre という役割分担ができる

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

• HPC スクラッチ領域: シミュレーションの中間データや並列出力先として Lustre を使い、最終結果だけを Blob へエクスポートする
• AI/ML 学習のデータフィード: 学習データセットを Blob からインポートし、多数の GPU ノードへ高スループットで供給する
• ジョブ単位のライフサイクル: 必要なときだけファイルシステムを作成し、終了後に結果を書き戻して削除する使い捨て運用でコストを最適化する
• 容量を性能から逆算: スループット要件を満たす容量・パフォーマンス階層を先に見積もり、I/O ボトルネックを避ける
• ストライプ設計を意識: 大きなファイルは複数 OST にまたがるよう配置し、並列 I/O の効果を引き出す
• 専用サブネットを最初に確保: VNet 設計時に Managed Lustre 用のサブネットと IP レンジを確保しておく

運用・監視

• Azure Monitor のメトリクスで、スループット・IOPS・容量使用率などを監視し、性能上限への接近を検知する
• 性能が頭打ちなら、容量の増加やパフォーマンス階層の引き上げで対処する。容量と性能が連動する点に注意する
• 容量使用率にアラートを設定し、ファイルシステムの空き枯渇でジョブが失敗する事態を防ぐ
• Blob 連携では、インポート / エクスポートの進捗と整合性を確認し、書き戻し完了前の削除を避ける
• マウントできないときは、専用サブネットの設定・VNet 到達性・クライアントのバージョン・名前解決を順に切り分ける

コスト

課金は基本的に確保したファイルシステム容量とパフォーマンス階層に対して発生します。実使用量ではなく確保量が基準になるため、常時確保しっぱなしにすると割高になりやすいサービスです。

• パフォーマンス階層が高いほど、確保容量あたりの単価が上がる
• 長期保管は安価な Blob に寄せ、計算時だけ Managed Lustre を立てる使い捨て運用がコスト効率に直結する
• 使い終わったファイルシステムは、結果を Blob へ書き戻したうえで速やかに削除して確保コストを止める
• Blob とのデータ転送やエクスポートに伴うコストも、必要分だけに抑える

セキュリティ

• ファイルシステムは専用サブネット経由でプライベートにアクセスし、VNet 外へ公開エンドポイントを持たない
• 保存時暗号化が有効で、要件に応じてカスタマー管理キー（CMK）を利用できる構成がある
• 暗号鍵は Azure Key Vault で管理し、ローテーションを運用する
• ネットワークは VNet・サブネット・NSG・ルーティングで閉域化し、クライアントの到達範囲を限定する
• 連携先の Blob Storage 側のアクセス制御（RBAC・ネットワーク制限） も併せて設計し、データ経路全体を保護する
• 管理操作は Microsoft Entra ID + RBAC で最小権限に制御する

関連サービス・比較

同じ高性能ストレージでも、Managed Lustre は並列ファイルシステムによる大規模 I/O、Azure NetApp Files は低レイテンシのエンタープライズ NAS という位置づけです。AWS では FSx for Lustre が相当します。

ハンズオン / CLI例

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

# プロバイダーを登録（初回のみ）
az provider register --namespace Microsoft.StorageCache

# Azure Managed Lustre ファイルシステムを作成
# 容量とパフォーマンス階層、専用サブネットを指定する
az amlfs create \
  --resource-group aml-rg \
  --name aml-fs \
  --location eastus \
  --sku AMLFS-Durable-Premium-250 \
  --storage-capacity 16 \
  --zones 1 \
  --filesystem-subnet "/subscriptions/<sub-id>/resourceGroups/aml-rg/providers/Microsoft.Network/virtualNetworks/aml-vnet/subnets/aml-subnet" \
  --maintenance-window '{"dayOfWeek":"Saturday","timeOfDayUTC":"22:00"}'

# 作成したファイルシステムの情報（マウント情報など）を確認
az amlfs show \
  --resource-group aml-rg \
  --name aml-fs