翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# HyperPod のインタラクティブスペースのタスクガバナンス
<a name="task-governance"></a>

このセクションでは、共有 Amazon SageMaker HyperPod EKS クラスターをインタラクティブスペースワークロード用に最適化する方法について説明します。クォータ管理、優先度スケジューリング、リソース共有ポリシーなど、Kueue のタスクガバナンス機能を設定して、開発ワークロードを中断することなく実行し、チームのトレーニング、評価、バッチ処理アクティビティ全体で公平な配分を維持する方法について説明します。

## インタラクティブスペース管理の仕組み
<a name="task-governance-how"></a>

共有 HyperPod EKS クラスターでインタラクティブスペースを効果的に管理するには、Kueue の既存の機能を使用して次のタスクガバナンス戦略を実装します。

**優先クラス設定**

重みが高いインタラクティブスペース (100 など) の専用優先度クラスを定義して、開発ポッドが他のタスクタイプより先に許可およびスケジュールされるようにします。この設定により、インタラクティブスペースはクラスターのロード中に優先度の低いジョブを優先できます。これは、中断のない開発ワークフローを維持する上で重要です。

**クォータのサイジングと割り当て**

予想される開発ワークロードを処理するのに十分なコンピューティングリソースをチームの ClusterQueue に予約します。開発リソースがアイドル状態の期間中は、未使用のクォータリソースを他のチームのタスクに一時的に割り当てることができます。開発需要が増加すると、これらの借用リソースを再利用して、保留中のインタラクティブスペースポッドに優先順位を付けることができます。

**リソース共有戦略**

要件に基づいて、以下の 2 つのクォータ共有アプローチから選択します。

*厳格なリソースコントロール*: クォータの貸借を無効にして、リザーブドコンピューティング容量がインタラクティブスペースで常に使用可能であることを確認します。このアプローチでは、ピーク時の開発需要を個別に処理するのに十分な大きさのサイジングクォータが必要であり、使用頻度が低い期間にアイドルノードが発生する可能性があります。

*Flexible Resource Sharing*: クォータローンを有効にして、他のチームが必要に応じてアイドル状態の開発リソースを利用できるようにします。ただし、借用を無効にして、予期しないエビクションにつながる可能性のある借用された再利用可能なリソースで Interactive Spaces が実行されないようにします。

**チーム内プリエンプション**

同じクォータで混合ワークロード (トレーニング、評価、インタラクティブスペース) を実行する場合、チーム内プリエンプションを有効にします。これにより、Kueue はチーム内の優先度の低いジョブを優先して優先度の高いインタラクティブスペースポッドに対応できるため、外部クォータの借用に応じて開発作業を続行できます。

## インタラクティブスペースの設定例
<a name="task-governance-space-setup"></a>

次の例は、Kueue が共有 Amazon SageMaker HyperPod クラスター内のインタラクティブスペースのコンピューティングリソースを管理する方法を示しています。

**クラスター設定とポリシー設定**

このクラスターの設定は、以下のとおりです。
+ *チームアルファ (開発チーム)*: インタラクティブスペースの 8 CPU クォータ
+ *チームベータ (ML チーム)*: トレーニングと評価のための 16 CPU クォータ
+ *チームガンマ (研究)*: 実験用の 6 CPU クォータ
+ *静的プロビジョニング*: オートスケーリングなし
+ *合計容量*: 30 CPUs

共有 CPU プールはこの優先度ポリシーを使用します。
+ *インタラクティブスペース*: Priority 100
+ *トレーニング*: 優先度 75
+ *評価*: 優先度 50
+ *バッチ処理*: Priority 25

Kueue はチームのクォータと優先度クラスを適用し、開発チームに対してプリエンプションが有効になり、借用が無効になります。

**初期状態: 通常のクラスター使用率**

通常運用:
+ *Team Alpha*: 6 つの CPUs を使用して 6 つのインタラクティブスペースを実行し、2 つの CPUsアイドル状態にします
+ *チームベータ*: トレーニングジョブ (12 CPUs) と評価 (4 CPU) を 16 CPUs クォータ内で実行します
+ *チームガンマ*: 6 つの CPUs
+ *リソース共有*: Team Beta が追加のトレーニングのために Team Alpha の 2 つのアイドル CPUs を借りる

**開発スパイク: Team Alpha には追加のリソースが必要です**

Team Alpha の開発者が開発作業をスケールアップする必要がある場合、追加のインタラクティブスペースポッドにはさらに 4 つの CPUsが必要です。Kueue は、新しいポッドが以下であることを検出します。
+ Team Alpha の名前空間内
+ Priority 100 (インタラクティブスペース)
+ クォータの制約によりアドミッション保留中

**Kueue の応答プロセス**

Kueue は 3 ステップのプロセスに従ってリソースを割り当てます。

1. **クォータチェック**

   質問: Team Alpha には未使用のクォータがありますか?
   + *現在の使用状況*: 6 CPUs が使用され、2 つの CPUsが利用可能
   + *新しい要件*: 4 CPUs が必要
   + *結果*: クォータが不十分 → ステップ 2 に進む

1. **Team Alpha 内のセルフプリエンプション**

   質問: 優先度の低い Team Alpha ジョブを優先できますか?
   + *使用可能なターゲット*: Team Alpha に優先度の低いジョブがない
   + *結果*: プリエンプション不可 → ステップ 3 に進む

1. **借用リソースの再利用**

   質問: Team Alpha リソースは他のチームによって借用されていますか?
   + *借用リソース*: Team Alpha の 2 つの CPUs を使用する Team Beta
   + *アクション*: Kueue は Team Beta の借用トレーニングポッドを削除し、2 CPU CPUs解放
   + *残りのニーズ*: まだ 2 つの CPUsが必要 → インタラクティブスペースは、リソースが利用可能になるまで NotAdmitted 状態のままです

このアプローチでは、インタラクティブスペースを優先しながら、チームのクォータの境界を維持し、開発作業が不安定な借用リソースで実行されないようにします。