Azure HPC Cache

解決する課題

HPC のスケールアウト計算では、数百から数千の計算ノードが同じデータセットを同時に読み込みます。バックエンドがオンプレミスの NAS や遠隔リージョンのストレージだと、レイテンシと帯域がボトルネックになり、計算ノードを増やしても処理が頭打ちになります。Azure HPC Cache は計算ノードのそばに高速なキャッシュ層を置き、初回アクセス後はキャッシュから配信することで、バックエンドの場所や速度に左右されにくいファイルアクセスを実現します。

• オンプレの NAS にあるデータを、Azure の計算ノードから低レイテンシで読みたい（ハイブリッド HPC）
• EDA・レンダリング・解析・ゲノムなど、同じデータを多数のノードが繰り返し読む読み取り中心のワークロード
• 複数の NFS バックエンドや Blob を 1つの名前空間にまとめて計算ノードへ見せたい
• バックエンドのストレージを増強せずに、読み取り性能だけをスケールさせたい

主要概念と用語

• キャッシュ: HPC Cache 本体のリソース。計算ノードからのマウント先となり、バックエンドの内容をキャッシュして低レイテンシで配信する
• ストレージターゲット: キャッシュの背後にある実データの所在。オンプレや Azure 上の NFS サーバー、または Azure Blob を登録する
• キャッシュサイズ / スループット: キャッシュに割り当てる容量と、提供できるスループットの規模。需要に合わせて選ぶ
• 集約名前空間（アグリゲーテッドネームスペース）: 複数のストレージターゲットを1つのディレクトリツリーに束ね、計算ノードからは単一のマウントポイントとして見せる仕組み
• キャッシュポリシー / 使用モデル: 書き込みの扱いやキャッシュの保持方針を決める設定。読み取り中心か、書き戻しを行うかなどで選ぶ
• NFS Blob（ADLS / Blob ターゲット）: Azure Blob をバックエンドにする構成。オブジェクトをファイルのように扱って計算へ供給する

仕様・制限・クォータ

• 計算ノードからのアクセスは NFS（v3 など） が中心で、Linux ベースの HPC クラスターに向く
• バックエンドのストレージターゲットは NFS サーバー と Azure Blob に対応する
• 読み取り中心ワークロード向けに最適化されたキャッシュであり、永続的なプライマリストレージそのものではない。実体はストレージターゲット側にある
• キャッシュは VNet 内のサブネットにデプロイし、計算ノードと同じネットワークから到達できるようにする
• キャッシュサイズとスループットは デプロイ時に規模を選択し、ワークロードに合わせてスケールする
• 提供リージョン・上限・対応構成はサービス更新で変わるため、最新の公式ドキュメントで確認する

内部の仕組み

Azure HPC Cache は、計算ノードとバックエンドストレージの間に位置するキャッシュ層です。計算ノードはキャッシュをマウントし、初回アクセスでバックエンドから取得した内容をキャッシュが保持します。以降の同一データへのアクセスはキャッシュから配信されるため、バックエンドのレイテンシや距離の影響を受けにくくなります。

• 計算ノードは NFS でキャッシュをマウントし、バックエンドの所在を意識せずに読み書きする
• バックエンドの NFS サーバーや Azure Blob はストレージターゲットとして登録され、キャッシュのミス時に参照される
• 複数のストレージターゲットを 集約名前空間で1つのツリーに束ね、計算側からは単一のマウントポイントに見せられる
• 読み取りはキャッシュヒットで高速化され、書き込みは 使用モデルに従ってバックエンドへ反映される

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

• ハイブリッド HPC（クラウドバースティング）: オンプレ NAS をストレージターゲットにし、Azure 側の計算ノードへ低レイテンシで供給する
• 集約名前空間で複数拠点を統合: 散在する NFS / Blob を1つのツリーにまとめ、計算ジョブのマウント構成を簡素化する
• 読み取り中心ワークロードに適用: EDA・レンダリング・解析など、同一データの繰り返し読み取りが多いほどキャッシュ効果が大きい
• キャッシュ規模を読み取り性能から逆算: 必要なスループットとワーキングセットの大きさからキャッシュサイズを見積もる
• 計算と同じ VNet / 近いリージョンに配置: ノードとキャッシュのネットワーク経路を短くしてレイテンシを抑える
• 永続性はバックエンドで確保: 重要データのバックアップ・冗長はストレージターゲット側に設計する

運用・監視

• Azure Monitor のメトリクスで、キャッシュのスループット・レイテンシ・ヒット状況やストレージターゲットの状態を監視する
• ワーキングセットに対してキャッシュが小さいと ヒット率が下がり性能が出ないため、規模を見直す
• ストレージターゲットの 到達性・名前解決・NFS エクスポート設定を定期確認し、ミス時のバックエンド遅延を抑える
• 計算ジョブの増減に合わせてキャッシュの スループット規模をスケールし、使わない期間は停止してコストを抑える
• マウントできないときは、VNet の到達性・サブネット・NFS の権限・ストレージターゲット設定を順に切り分ける

コスト

課金は主に、デプロイした キャッシュの規模（スループットとサイズ）と稼働時間に対して発生します。計算がアイドルでもキャッシュを起動している限り費用がかかるため、ジョブのライフサイクルに合わせた起動・停止が重要です。

• 必要なスループットに対して 過剰な規模を確保しない。読み取り要件から逆算してサイズを選ぶ
• ジョブが走らない期間はキャッシュを 停止・削除して稼働コストを抑える
• バックエンドが Azure Blob の場合、ストレージとトランザクションの費用が別途かかる点を見込む
• キャッシュはあくまで高速化層であり、永続容量のコストはストレージターゲット側で発生する

セキュリティ

• キャッシュは VNet 内のサブネットに配置し、計算ノードからプライベートに到達させる。パブリックに晒さない
• 保存時暗号化が利用でき、要件に応じてカスタマー管理キーを使える構成もある
• バックエンドの NFS は エクスポートポリシーとネットワーク制御でアクセス元を限定する
• Azure Blob をターゲットにする場合は Microsoft Entra ID / RBAC とネットワーク制御でアクセスを絞る
• オンプレ NAS をターゲットにする場合は、VPN / ExpressRoute で閉域接続し、経路を保護する

関連サービス・比較

同じ高性能ファイルでも、Azure NetApp Files は永続のプライマリ共有ストレージ、HPC Cache は読み取りを高速化するキャッシュ層という違いがあります。AWS では読み取り中心のファイルキャッシュとして Amazon File Cache が近い位置づけです。

ハンズオン / CLI例

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

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

# HPC Cache を作成（VNet 内のサブネットにデプロイし、規模を指定）
az hpc-cache create \
  --resource-group hpc-rg \
  --name demo-cache \
  --location japaneast \
  --cache-size-gb 3072 \
  --subnet "/subscriptions/<sub-id>/resourceGroups/hpc-rg/providers/Microsoft.Network/virtualNetworks/hpc-vnet/subnets/cache-subnet" \
  --sku-name "Standard_2G"

# NFS バックエンドをストレージターゲットとして登録
az hpc-cache nfs-storage-target add \
  --resource-group hpc-rg \
  --cache-name demo-cache \
  --name nfs-target \
  --nfs3-target 10.0.1.10 \
  --nfs3-usage-model READ_HEAVY_INFREQ \
  --junction namespace-path="/data" nfs-export="/export/data"

# 作成したキャッシュの状態とマウントアドレスを確認
az hpc-cache show \
  --resource-group hpc-rg \
  --name demo-cache