Amazon SageMaker HyperPod を使用して、分離と公平性を備えた GPU クラスターをチーム間で共有する

同じ企業内の複数チームが、分離の境界、リソースの公平性、運用の独立性を維持しながら、生成 AI 操作のために高価な GPU クラスターへの共有アクセスをますます必要としています。大規模言語モデルをトレーニングするデータサイエンスチーム、推論ワークロードを実行するコンピュータビジョングループ、新しいモデルアーキテクチャを試す研究チームを考えてみてください。これらすべてのチームが同じクラスターへのアクセスを必要とする可能性があります。適切に設計されたマルチテナント(マルチチーム)アーキテクチャがないと、組織は制御されていないリソース消費、チーム間の弱い分離、発生した共有 GPU コストをそのチームに帰属させることの不可能性、イノベーションを遅らせる管理オーバーヘッドに直面します。

Amazon SageMaker HyperPod は、生成 AI ワークロード向けの大規模コンピュートクラスターの管理を簡素化する専用設計の AI サービスです。Amazon Elastic Kubernetes Service (Amazon EKS) または Slurm によってオーケストレーションされた、回復力のある最適化されたクラスターを提供し、組織は大規模な分散トレーニング、インタラクティブな開発、モデル推論を実行できます。同時に、ノードのヘルスモニタリング、障害復旧、クラスターのライフサイクル管理を自動的に処理します。

この記事では、EKS を備えた Amazon SageMaker HyperPod 上にマルチテナント環境を構築するためのリファレンスアーキテクチャを紹介します。このアーキテクチャは、一元化された認証に AWS IAM Identity Center を、テーラリングされたユーザーエクスペリエンスのためにチームごとの SageMaker AI ドメインを、ワークロードの分離のために Kubernetes 名前空間を、公平なリソース割り当てのために HyperPod Task Governance を、チームごとの支出の可視性とチャージバックのために名前空間レベルのコスト配分を使用します。この記事を読み終える頃には、複数チームが単一の HyperPod EKS クラスターを効率的に共有するための明確な青写真を手にしているでしょう。

アーキテクチャの概要

次の図は、マルチテナントの HyperPod EKS デプロイの高レベルアーキテクチャを示しています。この例では、2 つのチーム(Team A と Team B)が単一の HyperPod EKS クラスターを共有し、それぞれが独自に分離された名前空間内で動作します。

図 1: 1 つの HyperPod EKS クラスターを共有する 2 チームのための高レベルマルチテナントアーキテクチャ

アーキテクチャは左から右への階層化されたフローとして構成されており、ユーザーアイデンティティを認可コントロールを通じてクラスター上の分離されたワークロード名前空間へと接続します。

ユーザーと認証

最も左側では、各チームの個々のユーザー(Team A の User 1、Team B の User 2)が 2 つの経路を通じてシステムとやり取りします。どちらの経路も、左下に示されている外部 ID プロバイダー(Microsoft Entra ID など)とフェデレーションする AWS IAM Identity Center ポータルを通じて認証します。

最初の経路は CLI アクセスです。ユーザーは aws sso loginで認証し、Identity Center ポータルにリダイレクトされた後、チームのアクセス許可セットから一時的な認証情報を取得して、 kubectlを使って EKS クラスターに直接タスクを送信します。図では、ピンク色の矢印が CLI ターミナルから上部を横切って HyperPod EKS クラスターに直接流れています。

2 番目の経路は Identity Center ポータルを直接通るもので、ユーザーは SageMaker Studio アプリケーションを選択して、チーム固有の SageMaker AI ドメインにサインインします。

各チームには、CLI ワークフローに必要な AWS Identity and Access Management (IAM) ポリシーを保持する対応するアクセス許可セット(TeamA permission set、TeamB permission set)があります。Identity Center は各アクセス許可セットの IAM ロールを自動的にプロビジョニングし、図では TeamA-permissionset-role および TeamB-permissionset-role (「CLI/Console role」と表示)として示されています。このロールは、ユーザーが aws sso login.

SageMaker AI ドメイン

Identity Center ポータルから、ユーザーはチーム固有の SageMaker AI ドメインにルーティングされます。各ドメイン(SageMaker AI domain Team A と SageMaker AI domain Team B)は専用の Amazon SageMaker Studio GUI を提供し、チーム固有の実行ロール(それぞれTeamA-role と TeamB-role )で設定されています。これらのドメインは主要なワークスペースインターフェイスとして機能し、ユーザーは GUI からタスクを送信できます(EKS に向かって流れるピンク色の矢印で示されています)。

EKS アクセスコントロール

EKS の境界では、アクセスエントリが IAM ロールを Kubernetes アクセス許可にマッピングします。図には、 TeamA-role および TeamB-role (Studio の実行ロール)のアクセスエントリが示されており、SageMaker Studio GUI から発信されるリクエストを認可します。TeamA-permissionset-role を通じて到着するリクエストを認可するために、Identity Center によってプロビジョニングされた CLI/Console ロール( TeamB-permissionset-roleおよび kubectl)に対してもアクセスエントリを設定する必要があります。すべてのアクセスエントリは、マネージドまたはカスタムのロールベースアクセスコントロール (RBAC) ポリシー(鍵のアイコンで表現)に関連付けられ、チームの指定された名前空間にスコープされます。その結果、Studio からであれ CLI からであれ、アクセスの発信元に関わらず、ユーザーは自分の名前空間内のリソースのみとやり取りできます。

HyperPod EKS クラスター

クラスター自体は、上部に2つの横断的なプラットフォーム層を持つ形で描かれています。HyperPod Observability(モニタリングとダッシュボード用)と HyperPod Task Governance(コンピュートクォータ管理とスケジューリング優先度用)です。これらの層の下には、クラスターが Namespace A(Team A)と Namespace B(Team B)に分割されています。各名前空間内で、チームはそれぞれの HyperPod Spaces(インタラクティブ開発環境)、HyperPod PyTorch ジョブ(分散トレーニングワークロード)、HyperPod Inference エンドポイント(モデルサービング)を実行できます。

ストレージ

クラスターの下には、2つのストレージ階層がアーキテクチャに含まれています。第1は、チームごとの共有ディレクトリ(/fsx/TeamA, /fsx/TeamB)とユーザーごとのホームディレクトリ(/home/User1, /home/User2)に整理された POSIX 準拠のファイルシステム(Amazon FSx for Lustre または Amazon FSx for OpenZFS)です。第2は、オブジェクトストレージ用のチームごとの、または共有の Amazon Simple Storage Service(Amazon S3)バケットで、チームの IAM 実行ロールによって管理されます。

このアーキテクチャは、認証から認可、ワークロード実行に至るまで各チームを分離しながら、高価な GPU インフラを効率的に共有します。

認証とアクセス制御

マルチテナントシステムの基盤となるのは堅牢な認証、つまりユーザーがリソースを操作する前にそのユーザーが誰であるかを検証することです。このアーキテクチャでは、AWS IAM Identity Center が一元化された認証層として機能し、外部 ID プロバイダーとフェデレーションしてユーザーアイデンティティとグループメンバーシップを管理します。

なぜ AWS IAM Identity Center なのか

AWS IAM Identity Center(AWS Single Sign-On の後継)は、AWS アカウントとアプリケーションにわたるワークフォースアイデンティティを管理するための一元的な場所を提供します。マルチテナントの HyperPod デプロイにおいて、以下のような主要な機能を提供します:

• 一元化されたアイデンティティ管理 – AWS サービスごとに個別のユーザーデータベースを維持するのではなく、Identity Center はすべてのユーザーアイデンティティとそのグループメンバーシップの信頼できる単一の情報源を提供します。
• 既存の ID プロバイダーとのフェデレーション – ほとんどの企業は、Microsoft Entra ID(旧 Azure AD)、Okta、Ping Identity などのシステムでワークフォースアイデンティティをすでに管理しています。Identity Center はこれらのプロバイダーと統合できるため、ユーザーアカウントを複製することなく既存の ID インフラを再利用できます。
• SageMaker AI とのネイティブ統合 – SageMaker AI のドメインは Identity Center 認証をサポートしているため、ユーザーは企業の ID プロバイダーを通じてシングルサインオン(SSO)で SageMaker Studio にサインインできます。
• AWS アカウントへのアクセス – Identity Center は、特定の権限セットを用いて基盤となる AWS アカウントへのアクセスをユーザーに付与することもでき、Studio の GUI 体験に加えて CLI ワークフローもサポートします。
• Amazon Managed Grafana に必要 – Amazon Managed Grafana は、ワークフォースユーザーの認証メカニズムとして Identity Center を使用するため、チームがワークロードをモニタリングするためのオブザーバビリティダッシュボードへのアクセスも必要とする場合には、自然な選択となります。

詳細については以下を参照してください: IAM Identity Center とは

外部 ID プロバイダーとの Identity Center の設定

このリファレンスアーキテクチャでは、外部 ID プロバイダーとして Microsoft Entra ID を使用していますが、同じパターンはほとんどの標準的な Security Assertion Markup Language(SAML)2.0 プロバイダーに適用できます。

設定には以下が含まれます:

1. ID プロバイダーにおけるグループ構造 – Entra ID で、組織のチームに対応するグループを作成します。この例では、3つのグループを定義します: TeamA, TeamB、および Admin。各グループにはそのチームに属するユーザーが含まれます(例えば、 user1-teamA@example.com グループ内の TeamA )。
2. SCIM プロビジョニング – Entra ID と AWS IAM Identity Center 間の SCIM(System for Cross-domain Identity Management)同期を有効にします。SCIM により、ユーザーとグループの自動プロビジョニングおよびプロビジョニング解除が可能になります。新しいユーザーが TeamA Entra IDのグループに追加されると、自動的にIdentity Centerへ同期され、手動の操作なしで適切なアクセス権を取得します。
3. SAMLベースの認証 「– SAML 2.0フェデレーションを設定し、ユーザーが認証する際にEntra IDに対して認証を行うようにします。Identity Centerはサービスプロバイダーとして機能し、Entra IDテナントからのアサーションを信頼します。」

この構成では、チームメンバーシップ(すべての後続の認可判断の基盤となります)を既存の企業ディレクトリで管理でき、それが自動的にAWSへ伝播されます。

次の画像は、Microsoft Entra ID において組織のチームをどのように表現できるかの例を示しています。ここでは、専用のグループが TeamA, TeamB,および Admin.

図2:Microsoft Entra IDのグループとして表現された組織チーム

次の画像は、Entra IDからSCIM同期を通じて自動的にプロビジョニングされた、AWS IAM Identity Centerにおける対応するグループを示しています。

図3:SCIMを通じてプロビジョニングされた、AWS IAM Identity Center 内の対応するグループ

詳しくは: 外部IDプロバイダーを接続する · SCIMプロファイルおよびSAML 2.0実装

認可

認証が確立されたら、次の層は認可です。認可とは、各チームがAWSサービスおよびKubernetesクラスター全体で実行できるアクションを制御することです。このアーキテクチャにおける認可は、2つのレベルで機能します。サービスレベルのアクセスにはIAM、クラスターレベルのアクセスにはKubernetes RBACを使用します。

チームごとのIAMロール

各チームには、AIおよび機械学習(ML)ワークフローに必要なAWSレベルの権限をまとめた専用のIAMロールが必要です。これらのロールはSageMaker AIドメイン実行ロールとして機能し、チームがアクセスできるAWSサービスを定義します。

典型的なチームのIAMロールには、以下へのアクセスを許可するポリシーを含める必要があります。

• Amazon SageMaker AI – HyperPod クラスター、MLflow トラッキングサーバー、およびその他の SageMaker AI リソースを SageMaker AI API を通じて管理する場合。
• Amazon S3 – トレーニングデータセットの読み取り、およびモデルアーティファクト、チェックポイント、ログの書き込み用です。これらの権限はチーム固有のバケットプレフィックスに限定してください。
• Amazon CloudWatch – チームのワークロードに関連するログおよびメトリクスを表示するため。
• Amazon EKS – 具体的には、 eks:AccessKubernetesApi および eks:MutateViaKubernetesApi Kubernetes API 呼び出しをユーザーの代理で実行するために SageMaker Studio の GUI が必要とする権限(たとえば、Spaces の一覧表示やジョブの送信など)です。

各IAMロールの信頼ポリシーには以下を含める必要があります sagemaker.amazonaws.com 信頼されたプリンシパルとして設定し、ユーザーが Studio を通じて操作する際に SageMaker AI がユーザーに代わってロールを引き受けられるようにします。後の Amazon S3 ストレージのセクションで説明するように、クラスター内のワークロード向けに同じ実行ロールを EKS Pod Identity の関連付けとして再利用する予定がある場合は、信頼ポリシーに次の内容も含める必要があります pods.eks.amazonaws.com 信頼されるプリンシパルとして扱われます。Identity Center 経由の CLI アクセスは、独自のポリシーを持つ別のアクセス許可セットを使用します(「Identity Center を経由した AWS アカウントアクセス」のセクションを参照)ので、CLI のアクセス許可は独立して範囲設定できます。

詳しくは: SageMaker AI 実行ロールの使用方法

Identity Center を通じた AWS アカウントアクセス

SageMaker Studio 以外にも、チームは実行などの CLI 操作のために AWS アカウントへの直接アクセスを必要とすることがよくあります kubectl 「コマンド、スクリプトによるワークフロー、またはプログラムによるリソースへのアクセスです。Identity Center のアクセス許可セットがこの機能を提供します。」

以下の点について 管理者 グループには、会社のポリシーに従って管理アクセス権限を持つアクセス権限セットを割り当て、クラスタ管理および管理操作に必要なアカウントアクセスを付与してください。

For チームA および Bチーム、CLI ワークフローに必要な権限を直接付与するインラインポリシーまたはマネージドポリシーを含む権限セットを作成します。典型的なチーム権限セットには、以下の権限が含まれます。 eks:AccessKubernetesApi （AWS コンソールから Kubernetes リソースを表示する場合）、チームのデータに対するスコープ付き S3 アクセス、およびモニタリング用の CloudWatch 読み取りアクセスです。これらのポリシーは Studio 実行ロールとは独立して定義されるため、管理者はチームがコマンドラインから実行する特定の操作に合わせて CLI の権限を調整できます。

ユーザーはAWS Command Line Interface（AWS CLI）を使用して一時的な認証情報を取得します。 aws sso loginその後、それを使って設定することができます kubectl EKSクラスターと直接やり取りするためのものです。

次の画像は、AWS IAM Identity Center のチームごとのアクセス許可セットを示しています。EKS クラスターに対する kubectl や aws sso login の実行といった CLI ワークフロー向けに、範囲を限定した AWS アカウントアクセスを提供します。

図 4: CLI ワークフロー向けの AWS IAM Identity Center のチームごとのアクセス許可セット

詳細: アクセス許可セットによる AWS アカウントの管理

AWS CLI の設定

チームメンバーは aws configure ssoを実行することで、Identity Center を経由して認証するように AWS CLI を設定します。これにより、適切な Identity Center セッションとアクセス許可セットを参照するプロファイルが ~/.aws/config に作成されます。各チームメンバーは、コマンドラインからクラスターを操作する際にチーム固有のプロファイルを使用し、アクセスが Studio からであってもローカルターミナルからであっても、認可の境界を維持します。

結果として得られる設定では、Identity Center ポータル用の共有 sso-session ブロックと、チームごとに 1 つの名前付きプロファイルが定義され、それぞれがそのチームのアクセス許可セットを指します。その後、チームメンバーは aws sso login --profile <team> を実行して、自分のアクセス許可セットの範囲に限定された一時的な認証情報を取得します:

[sso-session my-sso]
sso_start_url = https://d-xxxxxxxxxx.awsapps.com/start
sso_region = us-west-2
sso_registration_scopes = sso:account:access

[default]
sso_session = my-sso
sso_account_id = 123456789012
sso_role_name = OpsAdmin
region = us-west-2

[profile team-a]
sso_session = my-sso
sso_account_id = 123456789012
sso_role_name = TeamA-permission-set
region = us-west-2

[profile team-b]
sso_session = my-sso
sso_account_id = 123456789012
sso_role_name = TeamB-permission-set
region = us-west-2

詳細: AWS CLI を使用した IAM Identity Center 認証の設定

SageMaker AI ドメイン

SageMaker AI ドメインは各チームのワークスペース境界を提供し、チームに合わせたユーザーエクスペリエンス、事前設定された実行ロール、Identity Center 認証との組み込みの統合を提供します。

SageMaker AI ドメインを採用する理由

チームごとに 1 つの SageMaker AI ドメインを使用することは、マルチチーム環境を整理するための確立されたパターンです。このアプローチには次のような利点があります:

• 確立されたマルチチームパターン – AWS は、複数のドメインを使用して事業部門やチームを分離するこのアプローチについて広範にドキュメント化しており、実績がありサポート対象の構成です。
• ネイティブな Identity Center 認証 – 各ドメインは Identity Center 認証を使用するように設定でき、ユーザーは企業の ID プロバイダーを通じて 1 回サインインするだけで、チームの Studio 環境に直接移動します。
• 組み込みのチーム設定 – ドメインには、追加のカスタムエンティティを必要とせずに、ユーザーやチームの設定を指定するためのメカニズムがすでに備わっています。たとえば、チームの実行ロールなどの設定はドメインレベルで指定でき、最大限の柔軟性を得るためにユーザープロファイルレベルで上書きできます。
• ナビゲーションのカスタマイズ – ドメイン設定により、管理者はチームのワークフローに関係のないナビゲーション項目を非表示にでき、HyperPod のユースケースに合わせた集中型のインターフェイスを表示できます。

詳細については以下を参照してください: SageMaker AI ドメインのエンティティとステータス · 複数ドメインの概要

チームごとのドメインのセットアップ

Identity Center 認証を使用して、チームごとに 1 つの SageMaker AI ドメインを作成します。この例では、 TeamA-domain と TeamB-domainを作成します。各ドメインは次のように設定します。

1. デフォルト実行ロール – ドメインのデフォルト実行ロールを、認可ステップで作成したチーム固有の IAM ロールに設定します。これにより、Studio を通じて実行されるすべてのアクションが適切な権限を継承します。
2. Identity Center グループの割り当て – 対応する Identity Center グループ (例: TeamA グループ) をドメインに追加します。これにより、そのグループのすべてのメンバーに対して SageMaker Studio アプリケーションが有効化され、Studio インターフェイスへのアクセスが許可されます。
3. アプリケーション割り当ての確認 – グループアクセスを設定した後、Identity Center でアプリケーションの割り当てを確認し、正しいグループが正しいドメインにマッピングされていることを確認します。
4. ナビゲーションのカスタマイズ – 各ドメインのデフォルトのナビゲーション設定を構成し、関連する機能のみを表示します。たとえば、HyperPod のワークフローに関係のない項目を非表示にすることで、HyperPod リソースのみを扱うチームメンバーの認知的負荷を軽減する、合理化された HyperPod に焦点を絞った ユーザーエクスペリエンスを提供できます。

次の画像は、チームごとに 1 つのドメイン (TeamA-domain と TeamB-domain) を持つ SageMaker AI コンソールを示しており、それぞれが分離されたワークスペース境界を提供しています。

図 5: SageMaker コンソールでのチームごとの 1 つの SageMaker ドメイン

次の画像は、割り当てられた Identity Center グループを含む TeamA-domainの詳細を示しています。

図 6: 割り当てられた Identity Center グループを含む TeamA-domain の構成

HyperPod EKS クラスターの構成

HyperPod EKS クラスターは、ワークロードが実行される場所です。クラスターレベルのマルチテナンシーは、分離のための Kubernetes 名前空間と、認可のための EKS アクセスエントリによって実現されます。

名前空間の分離

各チームに専用の Kubernetes 名前空間を作成します。例: hyperpod-ns-team-a と hyperpod-ns-team-b". Namespaceはクラスター内に論理的な境界を提供し、各チームのワークロード(Spaces、トレーニングジョブ、推論エンドポイント)を互いに分離します。"]

注意: 名前空間は分離の境界であり、厳密なセキュリティ境界ではありません。 このアーキテクチャは次を対象としています。 単一の組織内における複数チーム: 共通の管理ドメインと基本的な相互信頼を共有するチーム。これは次の用途向けには設計されていない マルチカスタマー 互いに信頼していないテナント間の分離。

Namespace、RBAC、そしてクォータは次のことを防ぎます 偶発的 干渉(チームが互いのリソースを上書きしたり、コンピュート割り当てを超過したりすること)は防げますが、悪意のある決意したテナントに対する防御にはなりません。namespace内のPodは同じノードとカーネルを共有し、クラスタスコープのリソース(ノード、 PersistentVolumes、CRD、一部のoperatorコンポーネント)は、どのnamespaceの外に存在します。

信頼できないテナントや厳格な規制上の分離が求められる場合には、別々のクラスターまたはアカウント、専用のノードプール、ランタイムサンドボックス化といったより強固な境界を使用してください。ここでの複数チームのシナリオでは、名前空間の分離にRBAC、Task Governanceのクォータ、後述のPOSIXアイデンティティ制御を組み合わせることで、分離性と運用の簡便さの適切なバランスが得られます。

名前空間は手動で作成できます。作成には kubectl create namespace または、HyperPod Task Governanceを通じて自動的にプロビジョニングされます。HyperPod Task Governanceは、名前空間をクォータおよびスケジューリング設定の一部として管理します。

以下の画像は、クラスタのネームスペース(HyperPod Task Governanceで管理)を示したもので、チームごとに専用のネームスペースが1つ割り当てられています(hyperpod-ns-team-a および hyperpod-ns-team-b) によりワークロードの分離を提供します。

図7: ワークロード分離のためのチームごとの専用Kubernetesネームスペース

詳しくは: Kubernetesのネームスペース

ネットワーク分離

Namespace はネットワークトラフィックを制限しません。デフォルトでは、Kubernetes のネットワーキングはフラットです。すべての Pod が、すべての namespace にわたって他のあらゆる Pod に到達できます。その結果、 hyperpod-ns-team-a 内の Pod への接続を開くことができます hyperpod-ns-team-b コントロールを追加しない限り異なります。チーム境界に沿った pod 間の到達性をスコープ設定するには、Kubernetes を使用します。 NetworkPolicy リソース。

推奨されるパターンは default-deny ネームスペースごとに、まずすべてのingress(およびオプションでegress)を拒否し、その後、各チームが必要とするトラフィック、通常はネームスペース内通信に加えて、DNS、ストレージエンドポイント、AWS APIなどの必要なegressを明示的に許可します。次の例では、チームのネームスペース内のすべてのingressを拒否し、その後、同じネームスペース内のPodからのトラフィックのみを許可しています:

# 1. Default-deny all ingress in the team's namespace.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: hyperpod-ns-team-a
spec:
  podSelector: {}  # applies to all pods in the namespace
  policyTypes:
  - Ingress
---
# 2. Allow ingress only from pods within the same namespace.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-same-namespace
  namespace: hyperpod-ns-team-a
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector: {}  # any pod in this namespace

NetworkPolicy その強制には、対応するContainer Network Interface(CNI)が必要です。EKSでは、Amazon Virtual Private Cloud(Amazon VPC)CNIでネットワークポリシー機能を有効にできます。

名前空間の場合と同様に、 NetworkPolicies 削減する 偶然の チーム間の到達可能性を狭めて影響範囲を縮小できますが、それ自体は共有ノード上での敵対的なセキュリティ境界にはなりません。より強力な分離が必要な場合は、前述のとおり、チームごとに専用のノードプールを用意するか、別のクラスタを検討してください。

詳しくは: Kubernetesネットワークポリシー · Amazon VPC CNI ネットワークポリシー

EKSアクセスエントリー

EKSアクセスエントリは、IAMプリンシパルをKubernetes RBACの権限に接続します。各チームについて、2つのアクセスエントリを作成します。

• スタジオアクセスエントリー 「– IAM プリンシパルは、チームの SageMaker AI ドメイン実行ロールです。このエントリは、アクションが SageMaker Studio の GUI から発信される場合に使用されます。」
• CLIアクセスエントリ – IAMプリンシパルは、Identity Centerがチームのアクセス許可セットに対して作成したSSOプロビジョニング済みロールです(次のパターンに従います AWSReservedSSO_<permission-set-name>_<unique-id>)。このエントリは、ユーザーがクラスタと次を介してやり取りする際に使用されます: kubectl.

両エントリは、管理ポリシーまたはカスタムKubernetesポリシーにより、チームの名前空間にスコープ設定されています。たとえば、Team Aの両エントリは、次の範囲内でのみ権限を付与します。 hyperpod-ns-team-a。必要に応じて、この2つのエントリに異なるRBACポリシーを持たせることもできます。たとえば、CLIのエントリでは特定のリソースタイプへの書き込みアクセスを制限し、Studioのエントリではフルアクセスを許可するといった設定が可能です。

このスコーピングにより、Studio からのアクセスであれ CLI からのアクセスであれ、ユーザーは自分自身の namespace 内のリソースのみを操作できます。他のチームの namespace 内のリソースを一覧表示または変更しようとすると、Kubernetes Forbidden エラー。

より高度なシナリオでは、アクセスエントリ内のKubernetesグループを使用して、ユーザーを標準のマネージドポリシーを超えたきめ細かい権限を提供するカスタムのClusterRoleやRoleにマッピングできます。

以下の画像は、Team B のロールに対する EKS アクセスエントリを示しています。hyperpod-ns-team-b 名前空間にスコープダウンされているため、その権限は Team B の名前空間内でのみ適用されます。

Figure 8: Team BのnamespaceにスコープされたEKSアクセスエントリ

詳しくは: EKSアクセスエントリを使用してKubernetesへのIAMユーザーのアクセスを付与する

HyperPodタスクガバナンス

クラスタでタスクガバナンスが有効になると、リソース管理に追加のレイヤーが提供されます。

• コンピュートクォータ – 各チームが消費できるGPUおよびCPUの容量を定義します。これにより、トレーニング実行中に単一のチームが共有ハードウェアを独占することを防ぎます。
• 優先度 – 各チームまたはワークロードタイプにスケジューリングの優先度を割り当て、リソースが制約されている場合に、重要な本番推論ワークロードが実験的なトレーニングジョブをプリエンプト(横取り)できるようにします。
• フェアスケジューリング – タスクガバナンスを使用すると、複数のチームがリソースを競合する場合、先着順モデルではなく、設定されたポリシーに従って割り当てが行われます。

チームの名前空間ごとに適切なクォータと優先度でタスクガバナンスを構成し、保証された最低割り当てと、バースト的なワークロード向けのバースト容量とのバランスを取ります。

次の画像は、2つのチームのタスクガバナンスのコンピュート割り当てを示しています。各チームの名前空間には、クラスタのコンピュート容量の独自のクォータが割り当てられています。

図9: チームの名前空間ごとのタスクガバナンスのコンピュート割り当て

詳細はこちら: SageMaker HyperPodタスクガバナンス

ストレージ

ストレージは、チーム間で共有される人工知能および機械学習（AI/ML）環境の重要なコンポーネントです。チームは、トレーニングデータ、チェックポイント、モデルアーティファクトのために高性能なファイルシステムを必要とすると同時に、チーム間の適切なアクセス境界を維持する必要があります。

POSIX準拠のファイルシステム

共有された高性能なPOSIXファイルシステムを必要とするワークロード（複数のノードが同じデータセットを読み取ったりチェックポイントを書き込んだりする分散トレーニングで一般的）には、以下のオプションを検討してください：

• Amazon FSx for Lustre – 高スループットで低レイテンシーの並列ファイルシステムアクセスを提供し、大規模なデータセットを高速に読み取る必要がある大規模トレーニングワークロードに理想的です。
• Amazon FSx for OpenZFS – 強力なPOSIXセマンティクス、スナップショット、圧縮を備えた汎用ファイルシステムを提供します。従来のファイルシステム機能と高性能を兼ね備えたワークロードに適しています。
• Amazon Elastic File System (Amazon EFS) – 完全マネージドの伸縮自在なネットワークファイルシステム（NFS）ストレージを提供します。EFSはアクセスポイントもサポートしており、異なるマウントポイントをUIDとGIDを強制した異なるディレクトリにマッピングすることで、チームごとのディレクトリ分離を簡素化できます。

ストレージのレイアウトは通常、次のような構造に従います：

• チームごとの共有ディレクトリ – 各チームには、チームメンバー全員がアクセスする必要のあるデータセット、モデル、アーティファクト用の共有ディレクトリ（例： /fsx/TeamA, /fsx/TeamB）があります。
• ユーザーごとのホームディレクトリ – 各ユーザーには、個々の作業、実験、ノートブック用の個人ホームディレクトリ（例： /home/User1, /home/User2）があります。

これらのファイルシステム上のPOSIX権限モデルは、UID、GID、および補助グループに依存してアクセス境界を強制します。ユーザーがHyperPod Spaceを起動したりトレーニングジョブを送信したりする際には、これらのPOSIX IDをPodのセキュリティコンテキストに伝播し、ファイルシステムへのアクセスが設定された所有権と権限を尊重するようにする必要があります。アイデンティティストアからPOSIX ID情報を取得するために、Kubernetesのmutating admission webhookの使用をお勧めします。ワークロードが送信されると、webhookが実行時にIDを検索し、それに応じてPodのセキュリティコンテキストを変更します。

# 1. Extract the caller's session identity from the admission request.
# On EKS, requests from IAM-assumed roles (including IAM Identity Center)
# surface the STS session name in userInfo.extra["sessionName"]. Its format
# depends on how the session is created (e.g., an SSO short name, an email,
# or a role-session-name); align your identity mapping with this value.
def extract_username(admission_request):
    extra = admission_request["userInfo"]["extra"]
    ...
    return extra["sessionName"][0]

# 2. Look up the POSIX identity from a mapping table (e.g. DynamoDB).
def lookup_posix_identity(username):
    item = posix_table.get_item(Key={"username": username})["Item"]
    ...
    return {
        "uid": int(item["uid"]),
        "gid": int(item["gid"]),
        "supplementalGroups": [int(g) for g in item["supplementalGroups"]],
    }

# 3. Patch the Pod security context with the resolved POSIX identity.
def build_security_context_patch(pod, posix):
    ...
    return [{
        "op": "add",
        "path": "/spec/securityContext",
        "value": {
            "runAsUser": posix["uid"],
            "runAsGroup": posix["gid"],
            "fsGroup": posix["gid"],
            "supplementalGroups": posix["supplementalGroups"],
        },
    }]

詳細は以下をご覧ください: FSx for Lustre · FSx for OpenZFS · Amazon EFS

Amazon S3 ストレージ

オブジェクトストレージについては、S3 バケットへのアクセスはチームの IAM 実行ロールによって管理されます。チームごとのバケットを作成するか、チームごとのプレフィックスを持つ共有バケットを使用し、IAM ポリシーによって分離を強制することができます。クラスター内の Pod が S3 に対して認証を行うには、Service Accounts 向け IAM ロール（IRSA）または Pod Identity を設定した適切なサービスアカウントが必要です。簡単に行うには、SageMaker AI ドメインに設定済みの同じ実行ロールを、チームの namespace 内の Kubernetes サービスアカウントに関連付けることで、Studio とクラスターの両方のワークロードから一貫した S3 アクセスを実現できます。

詳細は以下をご覧ください: Service Accounts 向け IAM ロール（IRSA） · EKS Pod Identity

HyperPod Spaces

HyperPod Spaces は、クラスターノード上で直接動作するインタラクティブな開発環境（IDE）を提供します。共有クラスターでは、Spaces が各チームの namespace に適切にスコープされ、適切なリソーステンプレートで設定されている必要があります。

Space テンプレート

各チーム向けに namespace スコープの Space テンプレートを作成します。これらのテンプレートは、チームメンバーが Spaces を作成する際に利用できるリソース設定（インスタンスタイプ、ストレージボリューム、環境変数）を定義します。テンプレートを namespace にスコープすることで、各チームが指定された境界内でのみ Spaces を起動できるようにします。

HyperPod Task Governance が有効になっている場合、テンプレートにはガバナンスシステムが要求するデフォルトのラベル（チーム識別子や優先度ラベルなど）を含める必要があります。これらのラベルはクラスタ管理者が事前に設定するため、チームメンバーが Spaces を起動する際に手動で指定する必要はありません。

次の例は、Team A にスコープされた JupyterLab Space テンプレートを示しています。チーム固有の部分は metadata.namespace、 baseLabelsの下の Task Governance キューラベル、およびチームの共有ファイルシステムとユーザーのホームディレクトリをマウントする defaultVolumes です:

apiVersion: workspace.jupyter.org/v1alpha1
kind: WorkspaceTemplate
metadata:
  name: jl-smd-custom
  namespace: hyperpod-ns-team-a  # scopes the template to Team A's namespace
spec:
  displayName: "JupyterLab (team-a)"
  description: "SageMaker Distribution"
  appType: jupyterlab
  baseLabels:
  - key: kueue.x-k8s.io/queue-name  # Task Governance (Kueue) local queue for Team A
    value: hyperpod-ns-team-a-localqueue
  ...
  # container command, default CPU/memory resources, security context, access type, etc.
  ...
  defaultVolumes:
  - name: home-dir  # per-user home directory
    mountPath: /home
    persistentVolumeClaimName: fsx-openzfs-claim
  - name: shared-data  # Team A's shared directory
    mountPath: /fsx
    persistentVolumeClaimName: fsx-lustre-claim
  ...
  # primary (EBS) storage defaults and limits
  ...

Persistent Volume Claim

各チームの namespace 内に、共有ファイルシステムを参照する適切な Persistent Volume Claim（PVC）を作成します。これらの PVC は、チームの共有ディレクトリとユーザーのホームディレクトリを Space にマウントし、トレーニングデータ、チェックポイント、個人ワークスペースへのアクセスを提供します。

オーナー専用 Space と共有 Space

組織の Space 共有に関する要件を検討してください:

• オーナー専用 Space – 各 Space は、作成したユーザーのみがアクセスできます。これはデフォルトの設定であり、チームが機密性の高いプロジェクトや独立したプロジェクトに取り組む場合に適しています。
• 共有 Space – 複数のチームメンバーが同じ Space にアクセスできます。ペアプログラミング、共同デバッグ、共有開発環境に便利です。共有 Space を有効にする際は、Space 内で作成されたファイルへの適切なアクセスを許可するよう、POSIX 権限と補助グループが設定されていることを確認してください。

詳細は以下をご覧ください: Amazon SageMaker HyperPod EKS クラスター上のインタラクティブな開発環境

Studio エクスペリエンス

チームは kubectlを使用して完全に CLI からクラスターとやり取りできますが、SageMaker Studio は、マネージド型の GUI 主導のワークフローを好むユーザーに対して、クラスターへのグラフィカルなエントリーポイントを提供します。このアーキテクチャでは、各チームはそれぞれの SageMaker AI ドメイン（前述のとおり）を通じて Studio にアクセスし、同じ Identity Center の認証情報でサインインし、チームの namespace の境界内で作業します。

次の画像は、ユーザーが企業の認証情報でサインインした後にアクセスする IAM Identity Center アクスポータルを示しています。このポータルにより、割り当てられた SageMaker Studio アプリケーションと Amazon Managed Grafana アプリケーションへのシングルサインオンアクセスが提供されます。

図10: 割り当てられたアプリケーションへのシングルサインオンを備えたIAM Identity Centerアクセスポータル

Studio UIから、チームメンバーは以下のことができます:

• HyperPodスペースの管理 – 管理者が構成した名前空間スコープのスペーステンプレートから、Kubernetesマニフェストを書いたりTask Governanceラベルを手動で指定したりすることなく、インタラクティブな開発環境を起動できます。チームメンバーは、実行中のスペースの起動、停止、接続を行うこともでき、関連するIDE(JupyterLabなど)をブラウザーで直接開くことができます。
• Rayワークロードの管理 – Rayクラスターの作成と監視、JupyterLabまたはCode Editorワークスペースのクラスターへの接続、分散ジョブの送信、Ray DashboardとAmazon Managed Grafanaのオブザーバビリティダッシュボードのオープンを、Kubernetesマニフェストを書いたり kubectl コマンドを実行したりすることなく、すべて行えます。

StudioはチームのDomain実行ロールと対応するEKSアクセスエントリを通じて動作するため、すべてのアクションはチームの名前空間にスコープされます。StudioからスペースやRayクラスターを起動するユーザーは、自分のチームの境界内でのみ作成でき、これはCLIアクセスに対して強制される分離モデルと一致しています。

次の画像は、SageMaker Studio UIからHyperPodスペースを作成する方法を示しています。チームメンバーが、Kubernetesマニフェストを書いたりTask Governanceラベルを手動で指定したりすることなく、名前空間スコープのスペーステンプレートを選択します。

図11: SageMaker Studioで名前空間スコープのテンプレートからHyperPodスペースを作成する

詳細はこちら： Amazon SageMaker HyperPod EKS クラスター上のインタラクティブ開発環境 · SageMaker HyperPod の新しい Ray 機能のご紹介

HyperPod Training Operator

HyperPod Training Operator により、チームは分散トレーニングジョブを Kubernetes カスタムリソース（例： HyperPodPyTorchJob）として送信できます。マルチテナントアーキテクチャでは、トレーニングジョブは namespace スコープであり、チームの分離境界を自動的に継承します。

チームは CLI から、適切なジョブマニフェストを指定して kubectl apply を使用し、トレーニングジョブを送信できます。ジョブはチームの namespace で実行され、チームのコンピューティングクォータ（Task Governance が有効な場合）を使用し、チームのストレージボリュームにアクセスできます。

Task Governance が有効な場合、トレーニングジョブはチームに割り当てられたクォータと優先度設定の対象となります。チームが保証された割り当てを消費し尽くした場合、リソースが利用可能になるまで、または優先度の低いワークロードがプリエンプトされるまで、ジョブがキューに入れられることがあります。

ジョブをチームに紐付ける 2 つの要素は、 metadata.namespace （ジョブをチームの分離境界にスコープするもの）と Task Governance のラベルです。Task Governance は Kueueの上に構築されているため、ジョブは kueue.x-k8s.io/queue-nameを通じてチームのローカルキューにルーティングされます。スケジューリング優先度は kueue.x-k8s.io/priority-classを通じて割り当てられ、その値はクラスター上で定義された WorkloadPriorityClass の名前です：

apiVersion: sagemaker.amazonaws.com/v1
kind: HyperPodPyTorchJob
metadata:
  name: team-a-training-job
  namespace: hyperpod-ns-team-a  # scopes the job to Team A's namespace
  labels:
    kueue.x-k8s.io/queue-name: hyperpod-ns-team-a-localqueue  # Task Governance (Kueue) local queue
    kueue.x-k8s.io/priority-class: training-priority  # name of a WorkloadPriorityClass
spec:
  ...
  # replicaSpecs, container image, command, resources, volumes, etc.
  ...

詳細はこちら： HyperPod トレーニングオペレーターの使用

HyperPod Inference Operator

HyperPod Inference Operator により、チームはモデルを推論エンドポイントとしてクラスター上に直接デプロイできます。トレーニングジョブと同様に、推論エンドポイントは namespace スコープであり、チームの RBAC ポリシーと Task Governance クォータの対象となります。

チームは、自分の namespace に推論エンドポイントのカスタムリソースを作成することで、CLI からモデルをデプロイできます。エンドポイントは namespace ごとに分離されるため、チーム A がチーム B の推論エンドポイントにアクセスしたり干渉したりすることはできません。

高可用性が必要な本番推論ワークロードについては、バッチトレーニングワークロードによってモデルサービングが中断されないよう、トレーニングジョブよりも推論エンドポイントに高いスケジューリング優先度を割り当てることを検討してください。

トレーニングジョブと同様に、推論エンドポイントはチームの metadata.namespace に配置され、Task Governance のラベルを持ちます。ここでは、 kueue.x-k8s.io/priority-class がより高い優先度の WorkloadPriorityClass を参照しているため、チームのリソースが制約されている場合に、モデルサービングがバッチトレーニングをプリエンプトできます：

apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: InferenceEndpointConfig
metadata:
  name: team-a-inference-endpoint
  namespace: hyperpod-ns-team-a  # scopes the endpoint to Team A's namespace
  labels:
    kueue.x-k8s.io/queue-name: hyperpod-ns-team-a-localqueue  # Task Governance (Kueue) local queue
    kueue.x-k8s.io/priority-class: inference-priority  # higher-priority WorkloadPriorityClass
spec:
  ...
  # model source, instance type, replica count, autoscaling, etc.
  ...

詳細はこちら： Amazon SageMaker HyperPod へのモデルのデプロイ

HyperPod Observability

クラスターの健全性、ワークロードのパフォーマンス、リソース使用率を可視化することは、すべてのチームにとって不可欠です。HyperPod Observability は、Amazon Managed Grafana を通じて組み込みのモニタリングおよびダッシュボード機能を提供します。

Grafana へのチームアクセスの設定

チームは、ワークロードの監視、パフォーマンス問題のトラブルシューティング、リソース消費の把握のために、オブザーバビリティダッシュボードへのアクセスを必要とします。ただし、マルチテナント環境では、このアクセスは通常読み取り専用であるべきです：

1. Amazon Managed Grafana の Identity Center 認証の設定 – Amazon Managed Grafana コンソールで、[Authentication] に移動し、AWS IAM Identity Center を有効にします。これにより、ユーザーは SageMaker Studio で使用しているのと同じ企業認証情報で Grafana にサインインできます。
2. チームグループを Viewer として割り当てる – Identity Center のグループ（TeamA, TeamB）を Grafana の Viewer ロールにマッピングします。これにより、チームメンバーはダッシュボードやデータソースを変更することなく、ダッシュボードとメトリクスへの読み取り専用アクセスを granted されます。
3. Admin アクセス – Admin グループを Grafana の Admin または Editor ロールに割り当てます。これにより、ダッシュボードの作成と変更、アラートの設定、データソースの管理ができるようになります。
4. チーム固有のダッシュボード – namespace でデータをフィルタリングする専用のダッシュボードを作成することを検討してください。そうすることで、各チームは自分たちのワークロードのメトリクスのみを表示できます。Amazon Managed Grafana は Grafana Teams（Grafana ネイティブの RBAC の概念であり、このアーキテクチャにおける組織のチームとは別のもの）をサポートしており、Identity Center グループからマッピングすることで、ダッシュボードの表示を制限し、データ分離の追加レイヤーを提供できます。

次の画像は、Amazon Managed Grafana における Grafana ロールの割り当てを示しています。チームグループ（TeamA, TeamB）には、ダッシュボードとメトリクスへの読み取り専用アクセスのために Viewer ロールが割り当てられ、管理者グループには Admin ロールが割り当てられ、ダッシュボードの作成と変更、アラートの設定、データソースの管理が可能になっています。

図 12: チームに読み取り専用の Viewer アクセスを付与する Grafana ロールの割り当て

詳細情報： Amazon EKS でオーケストレーションされた Amazon SageMaker HyperPod クラスターのオブザーバビリティ

コスト配賦とチャージバック

高価なGPUインフラをチームで共有するマルチテナント環境では、誰が何を消費しているかを把握することが、アカウンタビリティ、予算管理、チャージバックのために不可欠です。 Kubecost は、クラスター内の支出をKubernetesのネイティブな概念( namespace、label、deployment、service )ごとに内訳し、それをチーム、プロジェクト、環境といった組織的な概念にマッピングすることで、このニーズに応えます。

このアーキテクチャでは各チームがすでに専用のnamespaceに分離されているため(hyperpod-ns-team-a, hyperpod-ns-team-b)、namespaceレベルのコスト配分がチームの境界と直接一致します。これにより、プラットフォーム管理者は、追加のワークロードタグ付けを行わなくても、チームごとのGPU、CPU、メモリ、ストレージ、ネットワークの消費量を明確に把握できます。HyperPodクラスターにKubecostをデプロイおよび設定する手順については、以下を参照してください。 Kubecost on SageMaker HyperPod.

チームの可視性の有効化

Kubecostがデータの収集を開始したら、Allocationsダッシュボードでコストをnamespaceごとにグループ化して、チームごとの支出を確認します。各チームが1つのnamespaceを所有しているため、コンピュート、メモリ、ストレージ、ネットワークを網羅するチームごとのコスト内訳が直接得られます。オブザーバビリティダッシュボードと同様に、チームは自身のコストデータを可視化できることで恩恵を受けます。

• ビューを各チームのnamespaceにスコープする – Kubecostはnamespaceによるフィルタリングと保存済みレポートをサポートしているため、各チームは他のチームのデータを見ることなく、自身の消費量と傾向を確認できます。
• 予算とアラートの設定 – namespaceごとの予算しきい値とアラートを設定することで、支出が定義された上限に近づいたときにチームとプラットフォーム管理者に通知され、HyperPod Task Governanceと同じリソースの公平性の目標をサポートします。
• チャージバックとショーバックのサポート – namespaceレベルの配分レポートは、内部チャージバック(利用量に応じたチームへの課金)やショーバック(課金を伴わない利用量の報告)のプロセスに活用でき、財務チームとプラットフォームチームが共有GPUコストを公平に配分するために必要なデータを提供します。

次の画像は、namespaceごとにグループ化されたKubecostのAllocationsダッシュボードを示しており、各チームのnamespaceの過去7日間の累積コストが表示されています。

図13: チームごとのコストを表示する、namespaceでグループ化されたKubecost Allocationsダッシュボード

詳細については、以下を参照してください: Kubecost on SageMaker HyperPod · Kubecost

まとめ

この記事では、EKSを使用するAmazon SageMaker HyperPod上でマルチテナント環境を構築するためのリファレンスアーキテクチャを紹介しました。認証にAWS IAM Identity Center、AWSレベルの認可にチームごとのIAMロール、カスタマイズされたワークスペース体験にSageMaker AIドメイン、ワークロードの分離にKubernetes namespace、公平なリソース配分にHyperPod Task Governance、チームごとの支出の可視性にnamespaceレベルのコスト配分を組み合わせることで、複数のチームが単一のHyperPod EKSクラスターを効率的に共有できます。

これは、複数の構成要素を一貫性のあるソリューションに組み合わせた、柔軟で構成可能なアプローチです。このアーキテクチャは、さまざまなユースケースや組織構造に対応できます。例えば、組織はこのパターンを拡張して、EKSに加えてHyperPod Slurmクラスターにチームを接続し、異なるオーケストレーションバックエンド間で統一されたマルチテナント体験を提供できます。

このアプローチでは複数のコンポーネントを組み立てて設定する必要がありますが、その結果として、各組織固有の分離、コンプライアンス、運用要件に合わせて調整できる高い制御性とカスタマイズ性が得られます。基盤となるパターン( IDフェデレーション、namespace分離、RBAC、クォータベースのガバナンス、コスト配分 )は引き続き適用可能です。

始めるには、ご自身のAmazon SageMaker HyperPod EKSクラスターでこのマルチテナント構成を構築してみて、組織の分離、ガバナンス、コスト配分の要件に合わせて構成要素を適宜調整してください。

著者について