Amazon SageMaker HyperPod は、機械学習 (ML) チームに、モデルのトレーニングとファインチューニングのための大規模なアクセラレーテッドコンピューティングプールへのアクセスを提供します。複数のチームが 1 つのクラスタを共有する場合、技術的なセットアップは通常シンプルです。難しいのはガバナンスです。どのチームがクラスタを使用できるか、各チームにどれだけのキャパシティを割り当てるか、あるチームのワークロードが別のチームのワークロードと競合した場合にどうするか、そして利用がポリシーから逸脱した場合に誰が責任を負うかを決めなければなりません。 Amazon SageMaker Unified Studio は、もう 1 つの考慮点を加えます。SageMaker HyperPod クラスタをプロジェクトに接続することで、チームメンバーはプロジェクトのワークスペースからワークロードを起動できます。この利便性は価値がありますが、複数のチームが同じクラスタへの可視性を共有すると、誰が何を実行できるかを統制するコントロールがさらに重要になります。この記事では、基盤となるガバナンスコントロールを維持しながら、SageMaker Unified Studio を通じて SageMaker HyperPod を管理する方法を示します。組織、プロジェクト、クラスタ、ワークロードという 4 つのコントロールレイヤーを取り上げ、これら全体にわたってアイデンティティ、キャパシティ、オブザーバビリティのポリシーを設計する方法を説明します。最後には、インフラストラクチャチームがクラスタ運用を維持したまま、承認済みの SageMaker HyperPod コンピューティングをプロジェクトのコンテキストで ML チームに提供するための、再現可能なモデルを手にすることができます。
Amazon SageMaker HyperPod は、 Amazon SageMaker AIの機能です。Amazon SageMaker Unified Studio は、チームがデータとツールを使って開発を行うデータおよび AI 開発環境です。SageMaker Unified Studio を使用すると、プロジェクトを既存の SageMaker HyperPod クラスタに接続できます。その後、メンバーは機械学習ワークロードを起動したり、クラスタとタスクの情報を確認したり、JupyterLab ワークフローを開いたりできます。クラスタの管理は引き続き Amazon SageMaker AI のインターフェイスと API を通じて行います。
この分離により、インフラストラクチャチームには実用的な運用モデルがもたらされます。確立されたクラウド運用プロセスを通じてクラスタインフラストラクチャを管理できます。同時に、承認済みのコンピューティングをプロジェクトのコンテキストで機械学習チームに提供できます。この記事では、インフラストラクチャの境界を設計し、アクセスを統制し、共有キャパシティを割り当て、SageMaker Unified Studio を通じて一貫して SageMaker HyperPod を運用する方法を説明します。
管理境界を理解する
適切にガバナンスされた環境では、組織の管理、プロジェクトへのアクセス、クラスタの運用が分離されています。各レイヤーは異なる問いに答え、異なるコントロールを使用します。次の表は、各境界、その主要なコントロール、およびその管理上の目的をまとめたものです。
| 境界 | 主要なコントロール | 管理上の目的 |
| 組織 | SageMaker Unified Studio のドメイン、ドメインユニット、関連アカウント、プロジェクトプロファイル、認可ポリシー | 誰がプロジェクトを作成できるか、プロジェクトがどのアカウントとリージョンを使用できるか、どのツールが利用可能かを決定する |
| プロジェクト | プロジェクトメンバーシップ、プロジェクトロール、SageMaker HyperPod 接続 | コラボレーションのコンテキストと、プロジェクトメンバーがアクセスできる AWS リソースを定義する |
| クラスタ | SageMaker HyperPod クラスタ管理者ロール、Amazon EKS アクセスエントリ、ロールベースのアクセスコントロール (RBAC)、EKS Pod Identity、または Slurm コントロール | クラスタの設定、スケジューラへのアクセス、名前空間、タスク、インフラストラクチャの運用を統制する |
| ワークロード | コンピューティング割り当て、優先度クラス、レンディングおよびボローイングポリシー、タスクのアクセス許可 | 誰が作業を送信できるか、共有キャパシティがどのように割り当てられるかを制御する |
これらのコントロールをレイヤーとして扱ってください。SageMaker HyperPod 接続は、承認されたクラスタをプロジェクトに追加するものです。クラスタの AWS Identity and Access Management (IAM)、Amazon Elastic Kubernetes Service (Amazon EKS)、または Slurm のコントロールを置き換えるものではありません。プロジェクトロール、接続アクセスロール、EKS アクセスエントリと RBAC または Slurm コントロール、ワークロードアイデンティティ、データと AWS Key Management Service (AWS KMS) キー のポリシー、ネットワークポリシー、タスク表示の制限、スケジューラポリシーを総合的に見直してください。これらのコントロールが整合した後にのみクラスタを利用可能にしてください。
これらのコントロールは、次の図に示す 4 つのレイヤーを形成します。
図1: 4つの制御レイヤー: 組織、プロジェクト、クラスター、ワークロード。各レイヤーは異なる問いに答え、異なる制御を使用するため、それぞれをその境界において確認してください。
SageMaker Unified Studioのプロジェクトはコラボレーションの境界です。これらは強力なランタイムセキュリティ境界ではありません。SageMaker HyperPodクラスター、スケジューラ、そして希少なアクセラレーターのキャパシティは、指定された1つのキャパシティアカウントの下に置いてください。承認されたユーザーとデータセットは、同じアカウントに置くことも、コンシューマーアカウントとデータアカウントに分けて置くこともできます。AWSは、Amazon EKSクラスター上のSageMaker HyperPodタスクガバナンスに対するマルチアカウントサポートをドキュメントに記載しています。On-Demand Capacity Reservationsはアカウント間で共有できますが、SageMaker HyperPodクラスターの所有権とキャパシティ管理はキャパシティアカウントに一元化してください。各コンシューマーアカウントを独立したキャパシティ管理者にするのではなく、承認されたクロスアカウントアクセスを使用してください。
- Amazon EKS では、テナントごとの namespace を RBAC、テナント別のサービスアカウントと EKS Pod Identity ロール、デフォルト拒否のネットワークポリシー、テナント固有のストレージと AWS KMS の権限と併せて使用します。Slurm では、階層的なアカウントとアソシエーションを持つ Slurm アカウンティング、Quality of Service (QoS)、優先度および fair-share ポリシー、パーティションを使用します。さらに、OS の ID とファイル権限、ネットワーク制御、テナント固有のデータパスも使用します。
- Amazon Simple Storage Service (Amazon S3) バケット、AWS KMS キー、シークレット、コンテナレジストリ、その他のデータサービスへのアクセスを制御するには、プロジェクトメンバーシップだけではなく、IAM ロールとリソースポリシーを使用します。コラボレーションと委任には、プロジェクトおよびドメインユニットのポリシーを使用します。
- Amazon EKS クラスタでは、SageMaker HyperPod のタスクガバナンス(クォータ、優先度クラス、貸し出しと借り入れ、プリエンプションを含む)を使用して、中央のアクセラレータプールを公平に共有します。Slurm クラスタでは、ネイティブのパーティション、Quality of Service (QoS)、優先度、fair-share、プリエンプションの制御を使用します。Slurm は同じ貸し出しと借り入れのモデルを提供していません。これらのスケジューリング制御は、承認されたワークロードがいつコンピュートを受け取るかを決定します。namespace やデータアクセスを付与するものではありません。
クラスタ内でより強力な分離を行うには、必要に応じて専用ノードまたはノードグループとアドミッションコントロールを使用します。法的、規制、またはセキュリティ要件が強固なインフラストラクチャ分離を求める場合は、別のクラスタまたはアカウントを使用します。クロスアカウントのコンシューマーアクセスにより、中央の SageMaker HyperPod クラスタを複製することなく、アカウントレベルの所有権を維持できます。キャパシティアカウント内では、 プロジェクトプロファイル と ドメインユニット をプロジェクト認可ポリシーと共に使用し、プロジェクトの作成と所有権を委任します。
次の図は、テナント固有のワークロード、ID、データ、ネットワーク、可視性の制御を備えた中央集権型のキャパシティを示しています。
図 2: 中央集権型の SageMaker HyperPod キャパシティ。クラスタとスケジューラは 1 つのキャパシティアカウントに残ります。各テナントには、ワークロード、ID、データ、ネットワーク、タスク可視性の制御が提供されます。強固な分離が必要な場合は専用インフラストラクチャを使用します。
図 3 は、SageMaker Unified Studio が承認された SageMaker HyperPod コンピュートをプロジェクトメンバーに公開するときに、それらの境界がどのように接続されるかを示しています。
図 3: 推奨される SageMaker HyperPod 管理モデル。SageMaker Unified Studio がコラボレーションコンテキストを管理する一方で、クラスタ ID、ワークロード認可、スケジューラポリシー、運用制御は分離されたままです。
SageMaker Unified Studio が適切な管理エクスペリエンスとなる状況を判断する
SageMaker Unified Studio では、既にプロジェクトで作業している機械学習チームが、承認されたパスを通じて共有の SageMaker HyperPod コンピュートを利用できます。メンバーは、接続されたクラスタを検索し、ステータスやメタデータを確認し、サポートされているタスクやメトリクスを調べ、別個のインフラストラクチャ在庫管理を使わずに JupyterLab へ移行できます。
このエクスペリエンスはクラスタ管理の代替ではありません。次の表は、各ペルソナがサービス固有のインターフェイスと併せて SageMaker Unified Studio をどのように使用すべきかを示しています。
| ペルソナ | SageMaker Unified Studio を使用する用途 | 引き続きサービス固有のツールを使用する用途 |
| ドメインまたはインフラストラクチャ管理者 | ドメインユニット、プロジェクト作成ポリシー、プロジェクトプロファイル、メンバーシップポリシー、アカウント配置 | 組織レベルの制御、アカウントプロビジョニング、インフラストラクチャの自動化 |
| SageMaker HyperPod クラスタ管理者 | 承認されたクラスタ接続の提示、およびクラスタ、タスク、設定、メタデータビューの確認 | クラスタの作成、更新、レジリエンシー設定、アドオン、EKS または Slurm の管理、インシデント対応 |
| プロジェクトオーナー | プロジェクトメンバーシップの管理、および承認されたコンピュートに対する一貫したプロジェクトコンテキストのユーザーへの提供 | インフラストラクチャ変更の要求、およびビジネス固有のアクセス要件の承認 |
| ML エンジニアまたはデータサイエンティスト | 承認されたコンピュートの検索、ワークロードステータスの確認、JupyterLab ワークフローの起動 | SageMaker HyperPod CLI, kubectlや、必要に応じて Slurm ツールを通じた詳細なワークロードの送信と管理 |
プロジェクトのメンバーシップ、データアクセス、開発ツール、コンピュートに共通のコンテキストが必要な場合は、SageMaker Unified Studioを使用してください。クラスターの変更や再現可能な自動化については、引き続きSageMaker AI API、infrastructure as code、オーケストレーターツールを使用してください。リファレンス実装と統合については、次を参照してください： AI on SageMaker HyperPod サイト。
クラスターを接続する前にインフラストラクチャの決定を行う
接続を承認する前に、キャパシティアカウント、コンシューマーアカウントやデータアカウントの有無、AWSリージョン、ネットワークパス、アイデンティティ、オーナー、ワークロードの境界、分離要件を文書化してください。クラスターの作成に関するガイダンスが必要な場合は、 Amazon SageMaker HyperPod documentation または AI on SageMaker HyperPodサイトを参照してください.
管理用IDとワークロード用IDを分離してください。プロジェクト用ロールやアクセス用ロールを作成する際は、クラスター管理者とデータサイエンティストユーザーというSageMaker HyperPodの区別を維持してください。プロジェクト向けのロールが、そのユーザーがワークロードを実行しているという理由だけで、クラスターのライフサイクル権限を受け取るべきではありません。参照： SageMaker HyperPod 向けの AWS Identity and Access Management サポート対象の権限モデルについて。
ネットワーキングをエンドツーエンドの制御として扱ってください。Amazon EKS Kubernetes APIエンドポイントへのアクセスを承認された管理用ネットワーク経路に制限し、Podのイングレスとエグレスを管理し、プロジェクト、接続ロール、ワークロードロール、クラスタネットワークが意図されたデータ経路のみをサポートしていることを確認してください。オーケストレーター固有の設定については、以下を参照してください。 Amazon EKS による SageMaker HyperPod クラスターのオーケストレーション.
例えば、Amazon EKS APIエンドポイントへのプライベートアクセスを設定し、承認された管理者またはワークロードのサブネットからのみアクセスを許可します。Kubernetesのデフォルト拒否（default-deny）を適用します NetworkPolicy 必要なサービス間通信および送信(egress)経路を明示的に許可します。適切な場合には、Amazon S3、Amazon Elastic Container Registry(Amazon ECR)、Amazon CloudWatch などのサービスに対して仮想プライベートクラウド(VPC)エンドポイントを使用し、データアクセスのために各テナントに専用のワークロードロールを付与します。
接続契約を作成します。接続契約とは、Wikiページ、チケット、サービスカタログのレコード、infrastructure-as-codeリポジトリで管理されるファイルなど、顧客が管理するガバナンス記録です。これはプラットフォームの機能ではありません。承認されたすべてのプロジェクトとクラスター間の接続について、以下の情報を記録します。
- ビジネスオーナー、オペレーションオーナー、そしてコストオーナーです。
- SageMaker Unified Studio のドメインユニットとプロジェクト。
- クラスターアカウント、リージョン、名前、オーケストレーター。
- 接続で使用されるプロジェクトロールとアクセスロールの Amazon Resource Name (ARN)。
- 承認されたワークロードの種類とデータ分類。
- EKS のネームスペースまたは Slurm のアクセススコープ。
- スケジューリングポリシーおよび例外の担当者。
- 監視、サポート、および廃止に関する期待。
この契約は、レビュー担当者に対して、アクセス経路全体を評価・承認するための1つのレコードを提供します。
アイデンティティとタスクの可視性を統制する
行动と可視性の両方を制御します。タスク名、名前空間、リソースリクエスト、使用パターンの不適切な設定により、他チームの作業に関する情報が漏洩する可能性があります。
可能な限り、プロジェクトメンバーシップやクラスターアクセスには個別のグラントではなくグループを使用してください。ドメイン、プロジェクト、クラスター、ワークロードポリシーにまたがる1つの広範なロールを作成するのではなく、各ロールをそれぞれの境界で見直してください。
次のワークフローは、ユーザーが見ることのできるものと、ユーザーが実行できることを分離する方法を示しています。
図4:アイデンティティとタスクの可視性の統制。グループを通じてアクセスを割り当て、各ロールをその境界にスコープし、タスクの可視性を制限し、作業を見る能力と作業に対処する能力を分離する。
ユーザーのオンボーディングの前に、デフォルトのタスクの可視性を確認してください。この SageMaker AI StudioにおけるSageMaker HyperPodのドキュメント SageMaker AI Studioのユーザーは、デフォルトですべてのAmazon EKSクラスタータスクを表示できると説明しています。Slurmクラスターの場合、すべてのSageMaker AI Studioユーザーが利用可能なタスクを表示、管理、操作できます。複数のチームをオンボーディングする前に、タスク表示の制限を設定してください。以下を参照してください。 StudioでEKSクラスタ向けにタスクビューを制限する Amazon EKS および Slurmクラスター向けStudioでタスクビューを制限する Slurm 向け。プロジェクトのメンバーシップはクラスターレベルのセキュリティ境界ではありません。
Amazon EKS クラスターでは、各チームを承認された名前空間と RBAC 権限にマッピングし、各ワークロードのサービスアカウントをテナント専用の IAM ロールにマッピングします。アカウントをまたぐデータアクセスについては、サービスアカウントをキャパシティ(クラスター)アカウント内の EKS Pod Identity ロールに関連付け、その関連付けに対象の IAM ロールを設定します(targetRoleArn"). その後、EKS Pod Identity が自動的にクロスアカウントのロール引き受けを実行するため、アプリケーションコードで呼び出す必要はありません。 AssumeRole。ターゲットロールはコンシューマーアカウントまたはデータアカウントに属します。読み取り専用の可視性を、ワークロードの作成、更新、削除の権限から分離してください。Slurmクラスターの場合は、ユーザー、アカウント、パーティション、ファイルシステム、タスク可視性に関する同等の制御を定義します。
例えば、以下のKubernetes RBACロールは、チームに対して自身の名前空間内のジョブへの読み取り専用アクセスを付与します。ワークロードを作成または削除するには別のロールが必要であり、これにより「見る」ことと「実行する」ことが分離されます。
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: team-research
name: research-job-viewer
rules:
- apiGroups: ["batch"]
resources: ["jobs"]
verbs: ["get", "list", "watch"]
- apiGroups: ["kubeflow.org"]
resources: ["pytorchjobs"]
verbs: ["get", "list", "watch"]ビジネスの優先事項をスケジューリングポリシーに変換する
Amazon EKSクラスターでは、アイデンティティとワークロードのアクセス制御が整備された後に、タスクガバナンスを適用してください。
次の図は、これに伴う2つの決定を分けて示しています。
図5: 認可とスケジューリングポリシーを分離して維持する。EKS RBACまたはSlurm ACLが、ユーザーがワークロードを送信できるかどうかを決定します。Amazon EKS向けSageMaker HyperPodタスクガバナンスまたはネイティブのSlurmスケジューリング制御が、いつコンピュートを受け取るかを決定します。
ドキュメント化された保証容量と共有容量、優先クラス、そしてあるチームが別のチームのアイドル状態の割り当てを使用できるかどうかを管理します。すべての例外にオーナーを割り当てます。タスクガバナンスは SageMaker HyperPod spaces (クラスター上で直接実行される自己完結型の JupyterLab または Code Editor 環境)にも適用されるため、これらの対話型開発ワークロードも割り当てポリシーに含めてください。
たとえば、Amazon EKS クラスターでは、本番トレーニングチームに高い優先クラスで 60 パーセントの保証割り当てを与え、リサーチチームにはより低い優先度でアイドル容量を借りることを許可し、本番チームがジョブを投入したときにはその借入容量をプリエンプションできるようにすることが考えられます。このポリシーに対する例外を承認するオーナーを 1 名割り当て、一時的なリクエストが黙々と常態化しないようにしてください。
認可とスケジューリングポリシーは分けてください。EKS RBAC または Slurm ACL は、ユーザーがワークロードを投入できるかどうかを決定します。Amazon EKS 向け SageMaker HyperPod タスクガバナンス、またはネイティブの Slurm スケジューリング制御は、その承認されたワークロードがいつコンピュートを受け取るかを決定します。スケジューラのクォータをアクセス制御として使ったり、認可制御をスケジューリングポリシーとして使ったりすると、動作が不明瞭になり、インシデントの診断が難しくなります。
記事「 Best practices for Amazon SageMaker HyperPod task governance 」では、フェアシェアの重み、クォータ、レンディングとボロウィング、優先クラス、一般的な割り当てシナリオについて解説しています。Amazon EKS クラスターでは、割り当てポリシーを定義する際にこれらのパターンを使用してください。Slurm クラスターでは、前述のネイティブスケジューラ制御を使用してください。
オブザーバビリティをガバナンスのフィードバックループとして使用する
SageMaker Unified Studio を使用すると、タスク、メトリクス、設定、メタデータに関する SageMaker HyperPod クラスターの詳細を表示できます。Amazon EKS クラスターの場合、タスクガバナンスのメトリクスには、ハードウェア、チーム、タスクのビューが含まれます。これらのビューは、ポリシーの意図と実際の消費を比較するのに役立ちます。
オブザーバビリティを、次の図に示すようなループとして扱ってください。
図 6: ガバナンスのフィードバックループとしてのオブザーバビリティ。シグナルを監視し、ポリシーの意図と比較し、対応を決定し、ポリシーと割り当てを調整します。すべてのシグナルにオーナーと対応を割り当てます。
監視するすべてのシグナルについて、オーナーと対応を定義します。次の例は、ダッシュボードのデータを管理上の判断に変換するものです。
| シグナル | 管理上の判断 |
| クラスターの容量とアクセラレータの使用率 | 低使用率が一時的なものか、ポリシーに起因するものか、それともワークロードの制約によるものかを判断する |
| チームの割り当てと使用率 | 予約容量と共有容量が依然としてビジネス需要を反映しているかを確認する |
| タスクの実行時間と待機時間 | 優先ポリシー、ワークロードのサイジング、容量の取り合いを調査する |
| 保留中およびプリエンプションされたタスク | スケジューラの結果が承認済みの優先モデルと一致していることを確認する |
| ノードの健全性とリカバリイベント | クラスターのインシデントプロセスを実行し、リカバリ目標を検証する |
Amazon EKS クラスターの場合、タスクテーブルには Kubeflow タスク (PyTorch、MPI、TensorFlow) が表示され、デフォルトでは PyTorch タスクが表示されます。他のメカニズムを通じて投入されたワークロードはそこに表示されない場合があります。Slurm クラスターの場合、タスクテーブルには現在のスケジューラキュー内のジョブが表示され、Slurm アカウンティングは sacctなどのツールを通じて履歴ジョブデータを提供します。履歴タスクデータ、監査エビデンス、インシデントの詳細をどこから取得するかを定義してください。
ドキュメントに記載されているメトリクスビューには、Amazon CloudWatch Observability EKS アドオンが必要です。このアドオンには独自の前提条件があります。バージョン 2.4.0 以降であること、および Kubernetes ワーカーノードロールにアタッチされた CloudWatchAgentServerPolicy IAM ポリシーであることです。タスクガバナンスビューを提供する Kueue メトリクスは、無料利用枠を超えた場合に CloudWatch メトリクスの課金が発生する可能性があります。最新のセットアップと価格に関する考慮事項については、 SageMaker HyperPod ダッシュボードのドキュメント を参照してください。
接続をライフサイクル全体を通じてレビューする
すべての接続に対してレビュースケジュールを設定します。また、プロジェクトの所有権、アクセスロール、アカウントまたはリージョン、クラスターのキャパシティ、オーケストレーターのバージョン、データ分類、または監視カバレッジの変更に関するイベント駆動型のレビューも定義します。各決定は接続契約に記録します。
次の図はライフサイクルの各段階を示しています。
図7: 接続のライフサイクル。記録済みの接続契約に基づいて接続を承認し、運用と監視を行い、スケジュールおよび定義されたイベントに基づいてレビューした後、更新または取り消します。
手作業を削減できる範囲でインベントリとエビデンス収集を自動化しますが、承認は責任を持つ管理者が行うようにしてください。ビジネス上の目的や責任ある所有者がもはや存在しない接続は取り消します。
結論
Amazon SageMaker Unified Studio を使用すると、機械学習チームはプロジェクト中心のアプローチで承認済みの SageMaker HyperPod コンピュートを利用でき、インフラストラクチャチームは中央集権的なクラスターの管理権限を維持できます。まず、本番前のクラスター 1 つとテストプロジェクトから始めます。メンバーを追加する前に、Amazon EKS 向けにはワークロード ID、名前空間または Slurm スコープ、データ権限、ネットワークポリシー、タスクビューの制限、タスクガバナンスを構成し、Slurm 向けにはネイティブのスケジューリング制御を構成します。メトリクスビューが表示されるように Amazon CloudWatch Observability EKS アドオンをインストールし、承認の全内容を接続コントラクトに記録します。承認された利用者アカウントにはクロスアカウントロールを使用し、強力な分離が必要な場合には専用インフラストラクチャを使用してください。実装手順については、 SageMaker HyperPod 接続手順 に従ってください。