AKSのDACS公開プレビュー：NVMe初期化・Blobフォールバック・監視の設計判断

結論（エンジニアリング判断・要点）

編集上の判断：DACSはモデルやデータセットの反復読み取りを検証する候補です。既存ストレージの置き換えとして一括導入せず、専用の検証用ノードプールから始めます。NVMeの所有権、Blob直読時の権限と帯域、キャッシュ実測の三条件を満たしてから適用範囲を決めます。

確認済み事実：Microsoft LearnはプレビューをSLAなしとし、運用環境のワークロードには推奨していません。個別環境の設計保証や法的助言を行う記事ではありません。実装適用には検証環境での事前テストと、導入・権限設定・監視・復旧を誰が担当するかという業務範囲の確認が必要です。

背景と技術的要因（機能拡張の経緯）

確認済み事実：Azure公式更新情報は、2026年11月10日にAKS向けDACSの公開プレビューを告知しました。ノード間のローカルNVMeを利用する分散リードスルーキャッシュにより、スケールアウトやノード置換で同じモデルを繰り返しBlobから取得する負荷の低減を狙います。性能効果はデータ再利用とキャッシュの温まり方に依存し、一定倍率の高速化は保証されていません。

確認済み事実：Azure Container StorageがDACSを管理しますが、DACSはStorageClass・PV・PVCを作る永続ボリューム機能とは別です。Blob Storageが正本であり、学習出力やチェックポイントの永続保存はDACSの役割に含まれません。編集上の提案：モデル入力と学習成果物の保存先を構成図で分けます。

具体的な日付・数値・対象リソース／APIバージョン

確認済み事実：告知のAdded to roadmapとLast modifiedはいずれも2026-11-10です。参照する日本語Learn各資料の表示上の最終更新日は2026-11-07、当記事の確認日は2026-11-12です。告知登録日を全環境の適用開始日と読み替えません。日単位の提供開始日、GA予定日、移行必須日、非推奨化期日は確認できず、それぞれnullです。

確認済み事実：対象はAzureパブリッククラウドのAKSで、Kubernetes 1.35以降、ローカルNVMeを備えるLinuxキャッシュノードが前提です。プレビューの規模は最大100ノードで、x64とArm64をサポートします。aks-previewは22.0.0b9以降が必要です。

確認済み事実：クイックスタートのCacheリソースはapiVersion: storage.azure.com/v1、kind: Cacheです。これはKubernetes CRDのバージョンで、ARMのapi-versionとは別です。導入用ARM APIの最小バージョンは当該資料では確認できずnullです。例のdacs-client==0.1.0はクライアント版であり、サーバー版は拡張のcurrentVersionを取得して記録します。

アーキテクチャ設計・実装上の確認事項（IaC・設定・依存関係）

確認済み事実：有効化はaz aks update --name <cluster-name> --resource-group <resource-group> --enable-azure-container-storage distributedAcceleratorで行います。大文字Aを含む値を単独指定し、永続ボリューム用オプションと混在させません。ノードプールには既存ラベルを保持してdacs.azure.com/processing-unit=cpuを設定します。管理DaemonSetが対象NVMeを検出・フォーマット・マウントするため、他の保存用途で使うディスクを対象にしないことが前提です。

確認済み事実：拡張導入だけではキャッシュサーバーは作成されません。コントローラーと全対象ノードのdacs-prereqがReadyになった後にCacheを作成します。spec.storage.hostPath.nodeCacheFolderPathは管理側のマウント先/var/lib/ssd/cacheserverと一致させます。編集上の提案：IaCではノードプール設定、拡張、Ready確認、Cache、クライアント設定を順序付きの工程として管理し、実際に使うプロバイダーの対応を検証します。

確認済み事実：公式クイックスタートはkubeletマネージドIDにコンテナ範囲のStorage Blob Data Readerを付与する例です。編集上の提案：その権限を全ワークロードへ無条件に横展開せず、共有するIDの範囲とBlobへの通信経路をレビューします。AKSの管理権限とBlobデータ読み取り権限を別々に棚卸しします。

運用・監視・フェイルオーバー・責任分界上の技術論点

確認済み事実：キャッシュが使えない場合、クライアントはBlobへ直接読み取れます。キャッシュデータは永続性のために複製されず、ノード喪失で失われ得ます。キャッシュは相互に信頼しないテナントの隔離機構ではありません。編集上の設計案：Blobへの到達性を維持し、信頼境界の異なる利用者を同じキャッシュへ集約しない方針を検討します。

確認済み事実：読み取り成功や所要時間の短縮だけではキャッシュ利用の証拠になりません。cache_client_download_cache_hitsとcache_client_download_cache_missesを確認し、全キャッシュサーバーのcache_server_request_counterについてrequest_type="Download"、status="Success"の増分を比較します。編集上の提案：Blob側の要求量と突き合わせ、成功率を保ったまま直読へ退行している状態も検知対象にします。

編集上の提案：試験はウォーム状態、空キャッシュ、ノード置換、キャッシュ停止、Blobアクセス拒否を分けて行い、モデル準備時間、起動失敗率、Blob要求量と費用を比較します。キャッシュへの切り替えをリージョンDRやBlobの冗長化と同一視せず、復旧先での権限・ネットワーク・モデル取得を別に試します。基盤担当はNVMeと拡張、アプリ担当はクライアント設定と整合性、運用担当は監視と復旧判定の責任を明文化します。