Azure HPC Cache

解決する課題

HPC のスケールアウト計算では、多数のノードが同じデータセットを読むため、正本との距離や帯域がボトルネックになります。旧 Azure HPC Cache は、NFS や Blob の手前にキャッシュと集約名前空間を置いてこの問題を緩和していました。移行では製品名を置き換えるのではなく、旧キャッシュが担っていた次の責任を分解します。

• 計算ノードが参照する NFS マウントパスと集約名前空間を特定する
• 各パスの正本が NFS と Blob のどちらか、書き込みがいつ正本へ反映されるかを確認する
• 作業集合、ヒット率、読み書き比率、帯域、待ち時間を測り、キャッシュが吸収していた負荷を数値化する
• アプリケーションが必要とする POSIX 操作、NFS / SMB、オブジェクトAPIを分けて移行先を選ぶ

旧構成の主要概念

• キャッシュ: 旧 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つのツリーに束ね、計算側には単一のマウントポイントとして見せていた
• 読み取りはキャッシュヒットで高速化され、書き込みは 使用モデルに従ってバックエンドへ反映された

横にスクロール

移行設計 / ベストプラクティス

• 依存関係を棚卸し: マウントパス、ストレージターゲット、利用モデル、クライアント、認証、ネットワーク経路を一覧化する
• 基準性能を保存: ピーク帯域、p95待ち時間、IOPS、作業集合、ファイルサイズ分布、同時クライアント数を移行前に測る
• 正本を検証: 未反映の書き込みを排出し、件数・容量・検査値を記録する。キャッシュ上だけに残るデータを作らない
• 要件ごとに候補を比較: 大規模な並列I/O、低遅延NFS／SMB、汎用共有、オブジェクト分析を分け、複数サービスを評価する
• 段階的に切り替え: 代表ジョブで互換性と性能を確認し、読み取り専用期間、差分同期、最終切り替えの順に進める
• 切り戻し条件を決める: 待ち時間、エラー率、データ不一致のしきい値と、旧マウントへ戻す期限を事前に定義する

移行時の運用・監視

• 旧構成の監視記録が残っていれば、ヒット率、スループット、待ち時間、ストレージターゲット障害を移行後の基準値とする
• 新旧の代表ジョブで、処理時間だけでなく メタデータ操作、小ファイル処理、同時実行時のp95待ち時間を比較する
• 名前解決、NFS エクスポート、ID／ACL、サブネット、経路MTUを切り分け、性能低下をストレージだけの問題と決めつけない
• 最終同期後は、正本の件数・容量・検査値を照合し、アプリケーションの書き込み先が新構成だけになったことを確認する
• 監視、バックアップ、障害復旧手順の移管を完了してから、旧構成に関係するネットワーク規則や資格情報を撤去する

コスト

サービスは廃止済みなので、旧 HPC Cache の料金を新規設計へ当てはめません。移行先の費用は、保存容量だけでなく、必要帯域、操作回数、データ移行、二重稼働、ネットワーク転送、検証ジョブまで含めて比較します。

• 移行期間の 新旧二重保存と二重転送を一時費用として見積もる
• 実測したピーク帯域と待ち時間から性能階層を選び、平均負荷だけで過小構成にしない
• Blob／ADLS Gen2 へ寄せる場合は、要求回数、階層移行、再水和、アプリケーション改修も含める
• ファイルサービスを選ぶ場合は、確保容量に連動する帯域、スナップショット、地域間複製の費用を分ける

セキュリティ

• 旧構成の NFS エクスポート規則、クライアント範囲、VNet経路を棚卸しし、新構成で同等以上に制限する
• Azure Blob を正本としていた場合は、Microsoft Entra ID、RBAC、ネットワーク境界、暗号鍵の責任者を確認する
• オンプレ NAS が正本なら、VPN / ExpressRoute の経路、名前解決、ファイアウォール、遅延を移行試験へ含める
• 移行用アカウントには読み取り元と書き込み先の最小権限だけを与え、検査後に資格情報を失効させる
• 旧サービス向けの規則や資格情報は、切り戻し期限と監査記録を確認してから削除する

関連サービス・比較

Azure HPC Cache に一対一で対応する移行先を決め打ちしません。旧構成が担っていた責任を分け、ワークロードが実際に必要とするI/Oとプロトコルから候補を比較します。

ハンズオン / CLI例

# 旧HPC Cacheリソースの記録が残っていないか読み取り専用で棚卸し
az resource list \
  --resource-type Microsoft.StorageCache/caches \
  --query '[].{name:name,resourceGroup:resourceGroup,location:location,id:id}' \
  --output table

# 各計算ノードで現在のNFSマウント元・方式を記録
nfsstat --mounts
findmnt -t nfs,nfs4 -o TARGET,SOURCE,FSTYPE,OPTIONS

# 正本側の総容量とファイル数を、同一ファイルシステム内で読み取り専用集計
du -sx --block-size=1 /mnt/source
find /mnt/source -xdev -type f -printf '.' | wc -c

廃止済みサービスを作成するコマンドは掲載しません。上の結果に加え、監視履歴、構成管理、ジョブ定義から旧マウントパスと正本を突き合わせ、候補サービスごとの検証環境で性能と互換性を確認します。