ライフスタイル

AWS:SageMaker StudioからHyperPod Spacesを直接管理可能に、日常操作にコマンドライン不要

AWSは2026年10月6日、データサイエンティストがSageMaker StudioのWebインターフェースから、HyperPodクラスター上のSpaces(インタラクティブな開発環境)を直接作成・起動・停止でき、コマンド入力が不要になったと発表した。本記事では、AWSが説明する機能、管理者が事前に行う必要がある設定、起動時間と費用をまとめる。

読了目安 10 分

AWS:SageMaker StudioからHyperPod Spacesを直接管理可能に、日常操作にコマンドライン不要
画像:Mokaair (Original editorial artwork)

AWSが発表した内容

AWSが2026年10月6日に公開したブログ記事によると、同社は最近、Amazon SageMaker Studioのインターフェースから、SageMaker HyperPod EKSクラスター上のSageMaker Spacesを直接作成・管理できる新機能を提供した。Spacesとは、クラスター上で直接実行されるインタラクティブな開発環境で、JupyterLabノートブックやCode Editorなどを指す。AWSによれば、データサイエンティストはStudio上でSpacesを作成、設定、起動、停止、オープンでき、HyperPodクラスターの詳細ページに新設された「IDE and Notebooks」タブで完全な管理インターフェースが提供される。

AWSの説明では、SageMaker HyperPodは基盤モデルの大規模な学習と推論(学習済みモデルを動かして結果を出すこと)のために構築されたインフラで、Amazon EKS(Amazon Elastic Kubernetes Service)によるオーケストレーションと組み合わせることで、数百のアクセラレーター上で分散学習を実行でき、耐障害性と自動障害復旧を備える。AWSはまた、今年初めにSageMaker Spaces for HyperPodアドオンを提供し、インタラクティブな開発作業を学習ジョブやモデルのデプロイと同じインフラで共有できるようにしたこと、さらにGPUの一部だけを特定の環境に割り当てる部分的なGPU割り当てにも対応したことに触れている。

  • AWSによれば、ガイド付きフォームで、コンピューティング、名前空間(クラスター内でチームや用途ごとに区切る単位)、ストレージ、イメージ、そして計算クォータを管理するHyperPod Task Governanceを設定できる。
  • 検索可能なテーブルで、すべてのSpacesの名前、アプリケーションの種類、ステータス、アクセスタイプ、ストレージ、GPUとvCPUの割り当てを一覧できる。
  • Spacesを起動・停止し、使用していないときは計算リソースを解放できる。
  • ブラウザでJupyterLabやCode Editorを開くか、VS CodeなどのリモートIDE(自分のコンピューターにインストールした開発ツール)から接続できる。

利用者への実際の影響

AWSによれば、これまでSpacesの作成と管理は主にHyperPod CLIやkubectlといったコマンドラインに依存しており、この方法はインフラ管理者にきめ細かな制御を提供していた。AWSの説明では、視覚的なインターフェースを好むデータサイエンティストは、このStudioの機能を使うことでコマンドラインツールを使わずにモデル開発に集中できる。AWSは記事の結論で、チームはクラスターへのアクセス権を得てから数分以内に実行中のJupyterLabやCode Editor環境に到達でき、CLIツールやKubernetesの概念を学ぶ必要はないとしている。

HyperPodクラスターを共有するチームにとって、日常的に開発環境を開く手順は、一般的なWeb操作に近いものになる可能性がある。AWSはまた、作業内容はマウントされたAmazon EBSボリュームに保存されるため、Spaceを停止して再起動しても進捗は失われないと説明している。リモート接続については、「Open in VS Code」は内部でSSH-over-SSMトンネル(AWS Systems Managerを経由する安全な接続方式)を使用しており、SSHキーの管理やポート22の開放は不要だとしている。

管理者が事前に行う必要がある設定

この機能はすぐに使えるわけではない。AWSによれば、設定は2つの役割に分かれ、管理者がクラスターを準備し、データサイエンティストがSpacesを作成して開く。管理者が行う一度限りの設定は以下のとおり。

  1. SageMaker Spacesアドオンのインストール:AWSによれば、Quick installとCustom installを選択でき、Webブラウザからのアクセスを有効にするにはCustom installが必須となる。
  2. EKS access entries(クラスターへのアクセス権限)の設定:AWSによれば、AmazonSagemakerHyperpodSpacePolicy、AmazonSagemakerHyperpodUserClusterPolicy、AmazonSagemakerHyperpodSpaceTemplatePolicyの3つのマネージドポリシーを、データサイエンティストが使用するIAM(AWS Identity and Access Management)ロールにアタッチする必要がある。
  3. ユーザーごとのID伝播の有効化:AWSによれば、Studioドメインがこの統合の提供開始前に作成されている場合はこの設定を有効にする必要がある。これにより、各ユーザーのクラスター上の操作がEKS access entriesとAWS CloudTrailにおけるそのユーザープロファイルに帰属し、Spaceの所有権、つまり各Spaceを誰が作成し、プライベートか共有かが記録・適用される。

AWSによれば、ドメイン設定を更新しても実行中の既存アプリケーションには影響せず、新しい設定はユーザーが次回ログインした時点で適用される。さらにAWSは複数のオプション機能を挙げている。管理者が設定を事前定義するSpaceテンプレート、Kueueを通じたTask Governanceのクォータとキュー、Spaceの需要に応じてノードを動的に増減するKarpenterの自動スケーリング、アイドル時の自動シャットダウン、A100/H100ハードウェア向けのNVIDIA MIGによる部分的なGPU割り当て、EFS/FSxの永続ボリューム、Amazon ECRでホストするカスタムイメージなどである。

起動時間と費用

AWSによれば、Karpenterの自動スケーリングを使い、ゼロまでスケールダウン(待機ノードがない状態)したクラスターでは、初回のSpace作成時にデフォルトで5〜7分のコールドスタート遅延が発生する。主な要因はAmazon EC2インスタンスの起動、Kubernetesノードの登録、SageMaker Distributionイメージのプルである。AWSが紹介するオーバープロビジョニングの手法は、一定数のノードをあらかじめ起動してイメージをダウンロードしておくもので、低優先度のプレースホルダーDeploymentによって各ウォームノードに「プレースホルダーPod」を配置し、ユーザーがSpaceを作成するとスケジューラーがSpaceにプレースホルダーPodを置き換え(プリエンプト)させる。これにより起動時間を約30〜40秒まで短縮できるとされる。

AWSが公表した起動遅延。テスト条件はml.m5.12xlargeと約3.5 GBのCPU版SageMaker Distributionイメージ
起動パスAWSが公表した遅延
SpaceとプレースホルダーPodが同一ノードに共存約14秒
SpaceがプレースホルダーPodをプリエンプト約35秒
コールドスタート(ウォームプールなし)5〜7分

費用面について、AWSはSageMaker Spacesアドオンの設定には追加料金はかからないとしているが、利用者はSpacesが消費するHyperPodクラスターの計算リソースと、SSH-over-SSMリモート接続に使用するAWS Systems Manager Advanced On-Premises Instanceの時間単位の料金を支払う必要がある。

よくある質問

この機能は以前と何が違うのですか?

AWSによれば、従来Spacesの作成と管理は主にHyperPod CLIやkubectlコマンドに依存していました。現在は、データサイエンティストがSageMaker Studioの「IDE and Notebooks」タブから直接Spacesを作成、設定、起動、停止、オープンできます。

データサイエンティストはすぐに使えますか?

必ずしもそうではありません。AWSによれば、管理者が先にHyperPod EKSクラスターにSageMaker Spacesアドオンをインストールし、3つのマネージドポリシーを関連するIAMロールにアタッチする必要があります。Studioドメインがこの統合の提供開始前に作成されている場合は、ユーザーごとのID伝播も有効にする必要があります。

Spaceの起動にはどのくらい時間がかかりますか?

AWSによれば、ゼロまでスケールダウンしたクラスターではコールドスタートに約5〜7分かかり、オーバープロビジョニングでノードを事前にウォームアップすれば約30〜40秒になります。AWSは、これらの数値はCPUにのみ適用され、GPU Spacesには別途設定が必要だと明記しています。

この機能を使うと追加料金がかかりますか?

AWSによれば、アドオンの設定自体に追加料金はかかりませんが、Spacesが消費するHyperPodクラスターの計算リソースと、SSH-over-SSMリモート接続に使用するAWS Systems Manager Advanced On-Premises Instanceの時間単位の料金がかかります。オーバープロビジョニングを採用する場合、ウォームノードにも追加コストが発生します。

このトピックの最新ニュースを見る

出典

ライフスタイル