30秒サマリー
- AWSがSageMaker HyperPodとRayを統合する新機能を発表、YAML記述やkubectl操作なしでクラスター管理が可能に
- ハングジョブの自動検出・ノード障害時の自動回復・階層型チェックポイントの3層耐障害性を提供
- 既存のRayスクリプトやワークフローはコード変更なしでそのまま動作するとされる
何が起きたか
AWSは公式ブログで、Amazon SageMaker HyperPodにおけるRayの新機能群を発表した。これまでKubernetes上でRayを動かすにはYAMLマニフェストの記述、Dockerイメージの再ビルド、kubectl port-forwardの設定、PrometheusやGrafanaの手動設定が必要だったが、今回の統合によりこれらの作業をSageMaker Studioのコンソール操作に集約できるとしている。
データサイエンティストはSageMaker StudioからRayクラスターの作成・管理・モニタリングを行えるほか、JupyterLabやCode Editorのワークスペースをクラスターにアタッチしてインタラクティブな開発が可能になる。ノートブック上でray.init(address=”auto”)を呼び出すだけでクラスターに接続でき、コンテナイメージを再ビルドせずにPython依存関係をランタイムで注入できる機能も提供される。また、toolkit-for-ray-on-sagemaker-ai Pythonパッケージを用いてCI/CDパイプラインやローカルPCからリモートでジョブを投入することもできる。
耐障害性の面では、ノード障害時の自動回復、学習のハング（停止状態）を自動検出するJob Monitoring Agent、そしてローカルディスクへの書き込みとS3への非同期アップロードを組み合わせた階層型チェックポイントの3機能を提供する。ブログでは、階層型チェックポイントによりS3から直接リストアする場合と比べて大規模モデルの回復時間を短縮できると説明している（具体的な数値は原文では明示されていない）。観測性についても、HyperPod Observability EKS アドオンがRay Core・Data・Train・Serveの4種類のGrafanaダッシュボードを自動でプロビジョニングする。
推論面では、Ray ServeをSageMaker HyperPod上のEKSで動作させることができ、SageMaker JumpStartとの統合によってモデルの重みをRay Serveエンドポイントに直接ロードする機能も含まれる。これらの機能はオープンソースのKubeRayおよび標準RayAPIと互換性を持ち、既存スクリプトの変更は不要だとしている。
原典ハイライト
原文では「Until now, running Ray on Kubernetes required data scientists to write YAML manifests, manage Docker image rebuilds for every dependency change（中略）configure Prometheus and Grafana manually」と従来の煩雑さを明示したうえで、今回の統合でこれらをすべてSageMaker Studioに集約できると説明。また、ハングジョブについて「GPUs stay allocated with memory loaded but produce no useful compute（GPUはメモリを占有したまま有効な計算をしない）」「a few hours of undetected hang time across dozens of GPUs represents significant wasted cost（数十基のGPUで数時間のハングが検知されないだけで相当なコスト無駄が発生する）」と問題の深刻さを指摘している。
出典: AWS Machine Learning Blog（公式ブログ）
So What?（なぜ重要か）
大規模言語モデル（LLM）のファインチューニングや推論基盤の構築において、GPU障害・学習ハング・チェックポイント管理は運用コストを押し上げる主要因だった。今回の機能群はこれらをインフラ側で自動処理することで、データサイエンティストが本来の研究・開発業務に集中できる環境を整えるものだ。特にハングジョブの自動検出は、数十～数百基規模のGPUクラスターで発生していた「気づかないうちの浪費」を防ぐ実務的なインパクトが大きい。YAML記述や監視設定の内製化に割いていたMLOpsエンジニアの工数削減にもつながるとみられる。
日本企業への示唆
国内で生成AIの分散学習基盤をAWS上に構築している企業は、まずハングジョブ検出と階層型チェックポイントの導入可否を確認することを推奨したい。GPU単価が高騰する現在、数時間のハングを見逃すだけで数十万円規模のコストが無駄になりうる。一方、SageMaker HyperPodとEKSを前提とした機能のため、オンプレミスGPUやGCP・Azure環境では直接利用できない点は留意が必要だ。既存のRayコードが変更不要で動作するとされるため、すでにRayベースのMLパイプラインを持つ企業にとっては移行コストが低い可能性がある。導入検討時はKubeRay・SageMaker Spaces・HyperPod Observabilityの各EKSアドオンのセットアップが前提条件となる点も事前に確認されたい。
背景・経緯
SageMaker HyperPodは大規模ML向けにAWSが提供する専用インフラで、Amazon EKSと組み合わせてノードのヘルス監視・自動回復機能を備える。Rayはデータサイエンスコミュニティで広く使われるオープンソースの分散Python実行フレームワークであり、KubeRayはKubernetes上でのRayクラスター管理を担うオープンソースオペレーターとして普及している。原文によれば、今回の発表はこれら既存コンポーネントをSageMaker Studioのコンソールに統合し、運用上の手間を削減することを主眼とした機能拡張に位置づけられる。
