AKS上での大規模Ray実行
MicrosoftのAKSチームは、AnyscaleのRayマネージドサービスを大規模運用するための技術ガイダンスを公開し、GPU容量制限や分散ストレージの問題に対処するマルチリージョン構成とBlobFuse2を活用したデータ管理手法を提案している。
キーポイント
GPU容量制限の克服
マルチクラスター・マルチリージョン構成でAzure内のGPUクォータを統合し、障害時や容量不足時のワークロード自動リダイレクトを実現する。
分散MLストレージの最適化
Azure BlobFuse2を用いてBlob StorageをPOSIX互換ファイルシステムとしてマウントし、GPUストールを防ぐローカルキャッシュと計算/ストレージの分離を実現する。
Anyscaleランタイム統合
Rayオープンソースフレームワークを基盤に、AnyscaleのRayTurboが提供するスマート自動スケーリングと耐障害性トレーニング機能をAKS上で運用可能にする。
認証・設定の簡素化
Workload Identityを用いたStorageClassとReadWriteMany PVCの設定により、マルチノードからの並列データアクセスとコードのポータビリティを確保する。
AzureストレージとReadWriteMany PVCの活用
Blob CSIドライバーとワークロードアイデンティティを用いたStorageClass、ReadWriteMany PVCの設定により、複数ノードでの同時データアクセスが可能になり、RayコードのポータビリティとAzureネイティブストレージの耐久性・スケーラビリティが実現される。
ワークロードアイデンティティによる認証の信頼性向上
Microsoft EntraとAKSワークロードアイデンティティを用いた自動短期トークン発行により、手動ローテーションが不要になり、マルチクラスター環境での運用負荷軽減と監査ログの取得が可能となる。
クラウドベンダー間の競争焦点の移行
AWS、GCP、AzureがAnyscaleとの統合を進めており、競争の焦点はランタイム自体から、AIワークロードに最適化された周辺インフラストラクチャの統合と効率化へと移行している。
重要な引用
GPU scarcity is one of the most significant operational challenges in large-scale ML.
Distributing Ray clusters across different AKS instances in various Azure regions allows teams to: Aggregate GPU quota beyond regional limits, automatically reroute workloads during outages or capacity issues...
Local caching prevents GPU stalls during large training runs, and because data is decoupled from compute, Ray clusters can scale up and down without data loss.
This shows the industry prefers Kubernetes-plus-Ray for AI workloads. Now, the competition is less about the runtime and more about which cloud can streamline the surrounding infrastructure best.
影響分析・編集コメントを表示
影響分析
このガイダンスは、Azure環境での大規模AI/MLトレーニングにおけるインフラ制約を具体的なアーキテクチャで解決する実用的な枠組みを提供する。企業はリージョンを跨ぐリソース統合とストレージ分離設計を採用することで、スケーラビリティと運用コストの最適化を両立でき、ハイブリッド分散ML基盤の標準化が進むと期待される。
編集コメント
GPUリソースの地理的分散とストレージ分離設計は、大規模AIトレーニングのコスト効率を劇的に改善する実務的な指針である。今後はAzure Arcを活用したハイブリッド展開が標準化し、オンプレとクラウドの境界を曖昧にする基盤技術として注目されるだろう。
Microsoft の Azure Kubernetes Service (AKS) チームは、Anyscale が提供するマネージド Ray サービスを大規模に実行するためのガイダンスを共有しました。彼らは GPU 容量の制限、散在する ML ストレージ、および認証情報の有効期限切れという 3 つの主要な課題に焦点を当てています。
この投稿では、AKS 上のオープンソース KubeRay に関する以前の概要について補足しています。今回は、以前 RayTurbo と呼ばれていた Anyscale の改善されたランタイム（runtime）を取り上げています。このランタイムは、スマートな自動スケーリング、監視機能の向上、および耐障害性のあるトレーニング機能を備えています。これらすべてはオープンソースの Ray フレームワークに基づいています。
Ray は、単一のラップトップから数千ノードにわたるクラスターまで AI および ML ワークロードをスケールできるように設計された、Python ネイティブの分散コンピューティングフレームワークです。Anyscale のマネージドプラットフォームは、本番環境での使用に向けた機能を Ray に追加しています。新しいガイダンスは、Microsoft と Anyscale が Azure 統合を改善するためのパートナーシップを示すものです。
GPU の不足は、大規模な ML における最も重要な運用課題の一つです。NVIDIA GPU のような需要の高いアクセラレーターは、Azure リージョンにおいてクォータや利用可能性の問題に直面することが多く、これによりクラスターのセットアップやジョブのスケジューリングが遅れる可能性があります。
Microsoft が提案する解決策は、マルチクラスター・マルチリージョン構成です。異なる Azure リージョン内のさまざまな AKS インスタンスに Ray クラスターを分散配置することで、チームは以下のことが可能になります：リージョンごとの制限を超えて GPU のクォータを集約する、障害や容量の問題が発生した際にワークロードを自動的にリルートする、Azure Arc を使用して AKS と連携し、オンプレミスシステムや他のクラウドプロバイダーへ計算プールを拡張する。
Anyscale コンソールでは、登録されたクラスターを一つのビューで確認できます。Anyscale Workspaces は、利用可能なキャパシティに基づいて、手動または自動でワークロードのスケジューリングを管理します。新しいリージョンを追加するには、cloud_resource.yaml マニフェストを作成し、その後 Anyscale CLI を使用して適用します。この設定ファーストのアプローチにより、マルチリージョンへの拡張が容易に管理できます。
ML 運用における一般的な課題は、パイプラインの各ステージ間でトレーニングデータ、モデルチェックポイント、およびアーティファクトを転送することです。これには、事前学習から微調整、そして推論へとデータを移動させることが含まれます。この課題への対応策として Azure BlobFuse2 が提案されており、これは Ray ワーカーポッドに POSIX 互換のファイルシステムとして Azure Blob Storage をマウントします。
Ray の観点からは、マウントポイントは単なるローカルディレクトリです。タスクとアクターは標準的なファイル I/O を使用してデータセットを読み込み、チェックポイントを書き出します。BlobFuse2 はその後、データを Azure Blob Storage に保存します。これにより、ポッド間およびノードプール間でデータが利用可能になります。ローカルキャッシングは大規模なトレーニング実行中の GPU のストールを防ぎ、データと計算リソースが分離されているため、Ray クラスターはデータ損失を伴うことなくスケールアップ・ダウンできます。
セットアップには、クラスター作成時に Blob CSI ドライバーを有効化します。次に、ワークロードアイデンティティを使用して認証を行う StorageClass を定義してください。最後に、ReadWriteMany アクセス権を持つ PersistentVolumeClaim を作成します。これにより、異なるノード上の複数の Ray ワーカーが同時に共有データにアクセスできるようになります。このアプローチにより、Ray コードの移植性が向上し、インフラストラクチャ層に Azure ネイティブストレージの耐久性とスケーラビリティが付加されます。
もう一つの重要なトピックは認証の信頼性です。Anyscale と Azure は以前、30 日ごとに期限切れとなる CLI トークンまたは API キーとの統合を行っており、これにより手動でのローテーションが必要となり、サービス停止のリスクがありました。
新しい手法では、Microsoft Entra サービスプリンシパルと AKS ワークロードアイデンティティを使用し、短期間のトークンを自動的に発行します。Anyscale Kubernetes Operator ポッドはユーザー割り当てマネージドアイデンティティを使用しており、このアイデンティティが Entra ID から Anyscale サービスプリンシパルのアクセストークンを要求します。Azure はトークンの更新を透過的に処理するため、クラスター内に長期有効な認証情報を保存する必要がなく、手動でのローテーションも不要です。
著者らは、これはマルチクラスター環境において特に重要であると述べています。ここでは多数のクラスター間で認証情報を手動で管理することは運用負荷を増大させます。ワークロードアイデンティティモデルは、Azure リソースアクセスに対する細粒度の RBAC を提供し、副産物として Azure Activity Logs を通じて完全な監査証跡を生成します。
Anyscale の AKS 統合機能は現在、クローズドベータ版として提供されています。アクセスを希望するチームは、担当の Microsoft アカウントチームまでお問い合わせください。また、AKS の GitHub リポジトリにてリクエストを提出することも可能です。その際は、Ray ワークロードの詳細と対象リージョンを含めて記載してください。GitHub 上の Azure-Samples/aks-anyscale リポジトリでは、DeepSpeed や LLaMA-Factory を用いたファインチューニングのための例セットアップやワークロードを確認できます。これには大規模言語モデル（LLM）の推論エンドポイントも含まれています。
Microsoft がこの賭けを単独で行っているわけではありません。AWS は Ray Summit 2024 で Anyscale とのパートナーシップを発表しました。これにより、E クラスターが RayTurbo ランタイムと接続されます。これは、NVIDIA GPU に AWS の Trainium や Inferentia アクセラレータを組み合わせてハードウェアの柔軟性を強調するものです。さらに、SageMaker HyperPod は、ノードレベルでの耐障害性が必要な長時間実行型のトレーニングジョブに対するデプロイ先として新たに追加されました。Google Cloud はオープンソースへの貢献においてリードしています。
GKE チームは Anyscale のエンジニアと協力し、ラベルベースのスケジューリングを Ray v2.49 へアップストリームしました。また、マルチチップ TPU セットアップにおけるリソースの断片化を削減するため、ray.util.tpu レイヤーも作成されました。さらに、新しい GB200 ベースのインスタンス向けに動的リソース割り当て（Dynamic Resource Allocation）が追加されています。
3 つの主要クラウドプロバイダーはすべて同じマネージド Ray オペレーターを採用し、それぞれが独自のインフラストラクチャを追加しました。これは、業界が AI ワークロードに対して Kubernetes と Ray の組み合わせを好んでいることを示しています。現在、競争の焦点はランタイムそのものではなく、どのクラウドが周辺インフラストラクチャを最も効率的に最適化できるかという点に移っています。
著者について
Claudio Masolo
Claudio は Nearform のシニア DevOps エンジニアです。
余暇には、ランニング、読書、そして昔のビデオゲームを遊ぶことが好きです。
原文を表示
The Azure Kubernetes Service (AKS) team at Microsoft has shared guidance for running Anyscale's managed Ray service at scale. They focus on three key issues: GPU capacity limits, scattered ML storage, and problems with credential expiry.
This post expands on a previous overview of open-source KubeRay on AKS. Now, it highlights Anyscale's improved runtime, previously known as RayTurbo. This runtime offers smart autoscaling, improved monitoring, and fault-tolerant training features. They are all based on the open-source Ray framework.
Ray is a Python-native distributed compute framework designed to scale AI and ML workloads from a single laptop to clusters spanning thousands of nodes. Anyscale's managed platform enhances Ray with features for production use. The new guidance shows a partnership between Microsoft and Anyscale to improve Azure integration.
GPU scarcity is one of the most significant operational challenges in large-scale ML. High-demand accelerators, such as NVIDIA GPUs, often have quota and availability issues in Azure regions. This can delay cluster setup and job scheduling.
Microsoft's proposed solution uses a multi-cluster, multi-region setup. Distributing Ray clusters across different AKS instances in various Azure regions allows teams to: Aggregate GPU quota beyond regional limits, automatically reroute workloads during outages or capacity issues, and extend the compute pool to on-premises systems or other cloud providers using Azure Arc with AKS.
The Anyscale console shows these registered clusters in one view. Anyscale Workspaces manages workload scheduling using available capacity, either manually or automatically. You can add new regions by creating a cloud_resource.yaml manifest. Then, apply it using the Anyscale CLI. This configuration-first approach makes multi-region expansion easy to manage.
A common issue in ML operations is transferring training data, model checkpoints, and artifacts between pipeline stages. This includes moving them from pre-training to fine-tuning and then to inference. The guidance addresses this with Azure BlobFuse2, which mounts Azure Blob Storage into Ray worker pods as a POSIX-compatible filesystem.
From Ray's perspective, the mount point is just a local directory. Tasks and actors read datasets and write checkpoints using standard file I/O. BlobFuse2 then saves data to Azure Blob Storage. This makes data available across pods and node pools. Local caching prevents GPU stalls during large training runs, and because data is decoupled from compute, Ray clusters can scale up and down without data loss.
To set up, enable the blob CSI driver when creating the cluster. Then, define a StorageClass that uses workload identity for authentication. Finally, create a PersistentVolumeClaim with ReadWriteMany access. This allows multiple Ray workers on different nodes to access shared data at the same time. This approach makes Ray code portable. It also adds the durability and scalability of Azure-native storage to the infrastructure layer.
Another important topic is the authentication reliability. Anyscale and Azure used to integrate with CLI tokens or API keys that expired every 30 days. This meant manual rotation was needed, which risked service disruption.
The new method uses Microsoft Entra service principals and AKS workload identity. It issues short-lived tokens automatically. The Anyscale Kubernetes Operator pod uses a user-assigned managed identity. This identity requests an access token for the Anyscale service principal from Entra ID. Azure handles token refresh transparently, meaning no long-lived credentials are stored in the cluster and no manual rotation is required.
The authors say this is especially important in multi-cluster environments. Here, managing credentials by hand across many clusters adds to the operational burden. The workload identity model provides fine-grained RBAC for Azure resource access and produces full audit trails through Azure Activity Logs as a byproduct.
The Anyscale on AKS integration is currently in private preview. Teams wanting access should reach out to their Microsoft account team. They can also file a request on the AKS GitHub repository. Include details about Ray workloads and target regions. You can check out example setups and workloads for fine-tuning with DeepSpeed and LLaMA-Factory in the Azure-Samples/aks-anyscale repository on GitHub. This also includes LLM inference endpoints.
Microsoft is not the sole entity making this wager. AWS announced its Anyscale partnership at Ray Summit 2024. This connects EKS clusters to the RayTurbo runtime. It highlights hardware flexibility by combining NVIDIA GPUs with AWS's Trainium and Inferentia accelerators. Additionally, SageMaker HyperPod is now a deployment target for long-running training jobs that need node-level resilience. Google Cloud leads in open-source contributions.
The GKE team worked with Anyscale engineers to upstream label-based scheduling into Ray v2.49. They also created a ray.util.tpu layer to reduce resource fragmentation in multi-chip TPU setups. Additionally, they added Dynamic Resource Allocation for the new GB200-backed instances.
All three hyperscalers have chosen the same managed Ray operator, and each has added its infrastructure. This shows the industry prefers Kubernetes-plus-Ray for AI workloads. Now, the competition is less about the runtime and more about which cloud can streamline the surrounding infrastructure best.
About the Author
Claudio Masolo
Claudio is a Senior DevOps Engineer at Nearform.
In his spare time, he likes running, reading, and playing old video games.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み