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

# ポリシー
<a name="sagemaker-hyperpod-eks-operate-console-ui-governance-policies"></a>

Amazon SageMaker HyperPod タスクガバナンスは、Amazon EKS クラスターリソースの割り当て方法とタスクの優先順位付け方法を簡素化します。以下では、HyperPod EKS クラスターポリシーについて説明します。データガバナンスをセットアップする方法については、「[タスクガバナンスの設定](sagemaker-hyperpod-eks-operate-console-ui-governance-setup-task-governance.md)」を参照してください。

ポリシーは、**[コンピューティングの優先順位付け]** と **[コンピューティング割り当て]** に分割されます。以下のポリシーの概念は、これらのポリシーに基づいて整理されています。

**[コンピューティングの優先順位付け]**、つまりクラスターポリシーは、アイドル状態のコンピューティングリソースをどのように借用し、チームごとにタスクをどのように優先順位付けするかを決定します。
+ **[アイドル状態のコンピューティング割り当て]** は、アイドル状態のコンピューティングリソースをチーム間でどのように割り当てるかを定義します。つまり、未使用のコンピューティングリソースをチームからどのように借用するかを定義します。**[アイドル状態のコンピューティング割り当て]** を選択する際は、次のいずれかを選択できます。
  + **先着順**: 適用すると、チーム間の優先順位付けは行われず、各タスクが割り当て超過リソースを取得する可能性は均等になります。タスクは送信順に優先順位付けされます。つまり、ユーザーが最初にリクエストすれば、アイドル状態のコンピューティングリソースを 100% 使用できる可能性があります。
  + **適性な共有**: 適用すると、チームは割り当てられた**適正な共有の加重**に基づいてアイドル状態のコンピューティングリソースを借りることができます。これらの重みは、**[コンピューティング割り当て]** で定義されます。使用方法の詳細については、「[アイドル状態のコンピューティングリソースを共有する例](#hp-eks-task-governance-policies-examples)」をご覧ください。
+ **[タスクの優先順位付け]** は、コンピューティングリソースが利用可能になった場合にタスクがどのようにキューに入れられるかを定義します。**[タスクの優先順位付け]** を選択する際は、次のいずれかを選択できます。
  + **先着順**:適用すると、タスクはリクエストした順にキューに入れられます。
  + **タスクの順位付け**: 適用すると、タスクは優先順位で定義された順序でキューに入れられます。このオプションを選択した場合は、優先クラスと、その優先度の加重を追加する必要があります。同じ優先クラスのタスクは、先着順で実行されます。コンピューティング割り当てで有効にすると、タスクはチーム内の優先度の高いタスクによって、優先度の低いタスクよりも優先されます。

    データサイエンティストがクラスターにジョブを送信する際は、YAML ファイルで優先クラス名を使用します。優先クラスは `{{priority-class-name}}-priority` の形式です。例については、[SageMaker AI マネージドキューと名前空間にジョブを送信する](sagemaker-hyperpod-eks-operate-console-ui-governance-cli.md#hp-eks-cli-start-job)を参照してください。
  + **優先クラス**: これらのクラスは、キャパシティを借用する際のタスクの相対的な優先度を設定します。借用クォータを使用してタスクが実行されている場合、タスクに利用可能なキャパシティが不足していると、そのタスクよりも優先度の高い別のタスクによってプリエンプトされる場合があります。**[コンピューティング割り当て]** で **[プリエンプション]** が有効になっている場合、優先度の高いタスクが自分のチーム内のタスクよりも優先される場合があります。
+ **未割り当てのリソース共有**により、チームはコンピューティングクォータを通じてどのチームにも割り当てられていないコンピューティングリソースを借用できます。有効にすると、チームが未割り当てのクラスター容量を自動的に借用できるようになります。詳細については、「[未割り当てのリソース共有の仕組み](#sagemaker-hyperpod-eks-operate-console-ui-governance-policies-idle-resource-sharing-how-it-works)」を参照してください。

**[コンピューティング割り当て]**、つまりコンピューティングクォータは、チームのコンピューティング割り当てと、適性な共有のアイドル状態のコンピューティング割り当てにおけるチームに割り当てられた加重 (優先度) を定義します。
+ **チーム名**: チームの名前です。対応する**名前空間** (`hyperpod-ns-{{team-name}}` 型) が作成されます。
+ **メンバー**: チーム名前空間のメンバー。Amazon EKS でオーケストレーションされた HyperPod クラスターでタスクを実行するには、このチームに参加させるデータサイエンティストユーザーに対して Kubernetes のロールベースのアクセスコントロール (RBAC) を設定する必要があります。Kubernetes RBAC を設定するには、「[チームロールの作成](https://github.com/aws/sagemaker-hyperpod-cli/tree/main/helm_chart#5-create-team-role)」の手順を使用します。
+ **適正な共有の加重**: これは、**[適正な共有]** が **[アイドル状態のコンピューティング割り当て]** に適用される場合にチームに割り当てられる優先順位付けのレベルです。最高優先度の加重は 100 で、最低優先度の加重は 0 です。加重が高いほど、チームは共有キャパシティ内の未使用のリソースにより早くアクセスできます。加重が 0 の場合、優先順位が最も低く、このチームが他のチームと比較して常に不利になることを意味します。

  適正な共有の加重は、利用可能なリソースを他のユーザーと競う際に、このチームに比較上の優位性を提供します。アドミッションは、加重が最も高く、借用が最も少ないチームからのタスクのスケジューリングを優先します。例えば、チーム A の加重が 10 で、チーム B の加重が 5 の場合、チーム A は未使用のリソースへのアクセスに関して優先権を持ち、チーム B よりも先にジョブがスケジュールされます。
+ **タスクのプリエンプション**: コンピューティングは、優先度に基づいてタスクから引き継がれます。デフォルトでは、アイドル状態のコンピューティングを貸すチームが、他のチームのタスクをプリエンプトします。
+ **貸借**: アイドル状態のコンピューティングがチームによってどのように貸し出されているか、また、チームが他のチームから借りることができるかどうか。
  + **パーセンテージベースの借用制限**: チームが借用できるアイドル状態のコンピューティングの制限。保証されたクォータに対するパーセンテージで表されます。チームは、割り当てられたコンピューティングの最大 10,000% を借用できます。ここで指定した値はパーセンテージとして解釈されます。例えば、500 の値は 500% と解釈されます。この割合は、チームのクォータ内のすべてのリソースタイプ (CPU、GPU、メモリ) とインスタンスタイプに均一に適用されます。
  + **絶対借用制限**: チームが借用できるアイドル状態のコンピューティングの制限。インスタンスタイプあたりの絶対リソース値として定義されます。これにより、特定のインスタンスタイプの借用動作をきめ細かく制御できます。インスタンス数、アクセラレーター、vCPU、メモリ、アクセラレーターパーティションなど、**コンピューティングクォータ**と同じスキーマを使用して絶対制限を指定する必要があります。チームのクォータで 1 つ以上のインスタンスタイプの絶対制限を指定できます。

優先クラスや名前空間など、これらの概念の使用方法については、「[HyperPod タスクガバナンス AWS CLI コマンドの例](sagemaker-hyperpod-eks-operate-console-ui-governance-cli.md)」を参照してください。

## アイドル状態のコンピューティングリソースを共有する例
<a name="hp-eks-task-governance-policies-examples"></a>

適切なクォータ管理を確保するため、予約済みクォータの合計は、クラスターでそのリソースに対して利用可能なキャパシティを超えることはできなりません。例えば、クラスターが 20 個の `ml.c5.2xlarge` インスタンスで設定されている場合、チームに割り当てられる累積クォータは 20 未満である必要があります。

チームの **[コンピューティング割り当て]** ポリシーで **[貸借]** または **[貸す]** が許可されている場合、アイドル状態のキャパシティはこれらのチーム間で共有されます。例えば、チーム A とチーム B では **[貸借]** が有効になっています。チーム A のクォータは 6 ですが、ジョブには 2 つのみを使用し、チーム B のクォータは 5 で、ジョブには 4 を使用しています。チーム B に 4 つのリソースを必要とするジョブが送信された場合、3 つがチーム A から借用されます。

チームの **[コンピューティング割り当て]** ポリシーが **[貸さないでください]** に設定されている場合、チームは独自の割り当てを超えて追加のキャパシティを借りることはできません。

## 未割り当てのリソース共有の仕組み
<a name="sagemaker-hyperpod-eks-operate-console-ui-governance-policies-idle-resource-sharing-how-it-works"></a>

未割り当てのリソース共有は、クラスター内のコンピューティングクォータに割り当てられていないリソースのプールを自動的に管理します。つまり、HyperPod はクラスターの状態を継続的にモニタリングし、時間の経過とともに自動的に正しい設定に更新します。

**初期セットアップ**
+ ClusterSchedulerConfig `Enabled`で `IdleResourceSharing`を に設定すると (デフォルトでは `Disabled`)、HyperPod タスクガバナンスはクラスターのモニタリングを開始し、合計ノード容量からチームクォータを差し引いて使用可能なアイドルリソースを計算します。
+ 未割り当てのリソース共有 ClusterQueues は、借用可能なリソースプールを表すために作成されます。
+ 割り当てられていないリソース共有を初めて有効にすると、インフラストラクチャのセットアップに数分かかります。ポリシー`Status`と ClusterSchedulerConfig `DetailedStatus` を使用して進行状況をモニタリングできます。

**継続的な調整**
+ HyperPod タスクガバナンスは、ノードの追加や削除、クラスターキュークォータの更新などの変更を継続的にモニタリングします。
+  変更が発生すると、未割り当てのリソース共有はクォータを再計算し、ClusterQueues を更新します。照合は通常、数秒以内に完了します。

**モニタリング**

 未割り当てのリソース共有が完全に設定されていることを確認するには、未割り当てのリソース共有 ClusterQueues を確認します。

```
kubectl get clusterqueue | grep hyperpod-ns-idle-resource-sharing
```

のような名前の ClusterQueues が表示されると`hyperpod-ns-idle-resource-sharing-cq-1`、未割り当てのリソース共有がアクティブになります。クラスター内のリソースフレーバーの数によっては、未割り当てのリソース共有 ClusterQueues が複数存在する場合があることに注意してください。

## 未割り当てリソース共有のノード適格性
<a name="sagemaker-hyperpod-eks-operate-console-ui-governance-policies-idle-resource-sharing-node-eligibility"></a>

未割り当ての Resource Sharing には、次の要件を満たすノードのみが含まれます。

1. **ノード準備完了ステータス**
   + 未割り当てのリソースプールに寄与する`Ready`には、ノードのステータスが である必要があります。
   + `NotReady` または他の準備ができていない状態のノードは、容量計算から除外されます。
   + ノードが になると`Ready`、次の調整サイクルに自動的に含まれます。

1. **ノードのスケジュール可能なステータス**
   + を持つノード`spec.unschedulable: true`は、未割り当てのリソース共有から除外されます。
   + ノードが再びスケジュール可能になると、次の調整サイクルに自動的に含まれます。

1. **MIG 設定 (GPU ノードのみ)**
   + MIG (マルチインスタンス GPU) パーティショニングを使用する GPU ノード`success`の場合、割り当てられていないリソース共有に MIG プロファイルを提供するには、 `nvidia.com/mig.config.state`ラベルに と表示する必要があります。
   + これらのノードは、MIG 設定が正常に完了すると自動的に再試行されます。

1. **サポートされているインスタンスタイプ**
   + インスタンスは、サポートされている SageMaker HyperPod インスタンスタイプである必要があります。
   + SageMaker HyperPod クラスターでサポートされているインスタンスタイプのリストを参照してください。

**Topics**
+ [アイドル状態のコンピューティングリソースを共有する例](#hp-eks-task-governance-policies-examples)
+ [未割り当てのリソース共有の仕組み](#sagemaker-hyperpod-eks-operate-console-ui-governance-policies-idle-resource-sharing-how-it-works)
+ [未割り当てリソース共有のノード適格性](#sagemaker-hyperpod-eks-operate-console-ui-governance-policies-idle-resource-sharing-node-eligibility)
+ [ポリシーの作成](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-create.md)
+ [ポリシーを編集する](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-edit.md)
+ [ポリシーを削除する](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-delete.md)
+ [Amazon SageMaker HyperPod タスクガバナンスでのコンピューティングクォータの割り当て](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-compute-allocation.md)