

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

# Amazon SageMaker HyperPod タスクガバナンスでのトポロジー認識スケジューリングの使用
<a name="sagemaker-hyperpod-eks-operate-console-ui-governance-tasks-scheduling"></a>

Amazon SageMaker HyperPod タスクガバナンスでのトポロジー認識スケジューリングは、Amazon EC2 インスタンスの物理ネットワークトポロジーに基づいてポッドを配置することで、分散機械学習ワークロードのトレーニング効率を最適化します。アベイラビリティーゾーン、ネットワークブロック、物理ラックなどの AWS インフラストラクチャの階層構造を考慮すると、トポロジ対応のスケジューリングにより、頻繁な通信を必要とするポッドがネットワークレイテンシーを最小限に抑えるために近接してスケジュールされます。このインテリジェントな配置は、ポッド間の集中的な通信を伴う大規模な機械学習トレーニングジョブで特に効果的であり、トレーニング時間の短縮とクラスター全体にわたるリソース利用効率の向上につながります。

**注記**  
トポロジー認識スケジューリングを使用するには、HyperPod タスクガバナンスのバージョンが v1.2.2-eksbuild.1 以降であることを確認する必要があります。

トポロジー認識スケジューリングでは、次のインスタンスタイプがサポートされています。
+ ml.p3dn.24xlarge
+ ml.p4d.24xlarge
+ ml.p4de.24xlarge
+ ml.p5.48xlarge
+ ml.p5e.48xlarge
+ ml.p5en.48xlarge
+ ml.p6e-gb200.36xlarge
+ ml.p6-b300.48xlarge
+ ml.trn1.2xlarge
+ ml.trn1.32xlarge
+ ml.trn1n.32xlarge
+ ml.trn2.48xlarge
+ ml.trn2u.48xlarge

トポロジー認識スケジューリングは、既存の HyperPod ワークフローと統合され、kubectl YAML ファイルと HyperPod CLI の両方を通じて柔軟なトポロジー設定を提供します。HyperPod タスクガバナンスは、トポロジーラベルを使用してクラスタノードを自動的に設定し、HyperPod タスクガバナンスポリシーおよびリソース借用メカニズムと組み合わせて使用することで、トポロジー認識スケジューリングが現在の運用プロセスを中断することを防ぎます。優先トポロジー仕様と必須トポロジー仕様の両方が組み込まれているため、トポロジー制約を満たせない場合に標準スケジューリングにフォールバックする柔軟性を維持しながら、特定のパフォーマンス要件に合わせてワークロードの配置を微調整できます。

HyperPod のトポロジー認識ラベルを活用することで、物理ネットワークインフラストラクチャを考慮したインテリジェントなポッド配置を介して、機械学習ワークロードを強化できます。HyperPod タスクガバナンスは、階層型データセンタートポロジーに基づいてポッドスケジューリングを自動的に最適化します。これは、分散 ML タスクのネットワークレイテンシーの短縮とトレーニングパフォーマンスの向上に直接つながります。このトポロジー認識機能は、関連するポッドをネットワーク階層内で戦略的に近接配置することで通信オーバーヘッドを最小限に抑えるため、特に大規模な機械学習ワークロードで役に立ちます。その結果、ポッド間の通信ネットワークレイテンシーが最適化され、リソース利用効率が向上し、コンピューティング集約型の AI/ML アプリケーションの全体的なパフォーマンスが向上します。これらはすべて、複雑なネットワークトポロジー構成を手動で管理する必要なく実現できます。

以下は、HyperPodタスクガバナンスがポッドをスケジュールできる利用可能なトポロジーネットワークレイヤーのラベルです。
+ topology.k8s.aws/network-node-layer-1
+ topology.k8s.aws/network-node-layer-2
+ topology.k8s.aws/network-node-layer-3
+ topology.k8s.aws/ultraserver-id

トポロジー認識スケジューリングを使用するには、YAML ファイルに次のラベルを含めます。
+ kueue.x-k8s.io/podset-required-topology - このジョブに必要なポッドが必要であり、ノード内のすべてのポッドが同じトポロジレイヤー内でスケジュールされる必要があることを示します。
+ kueue.x-k8s.io/podset-preferred-topology - このジョブに必要なポッドが必要であり、同じトポロジレイヤー内でのポッドのスケジュールが推奨されるものの、必須ではないことを示します。HyperPod タスクガバナンスは、次のトポロジレイヤーを試す前に、単一のレイヤー内でポッドのスケジュールを試行します。

リソースが同じトポロジラベルを共有していない場合、ジョブは中断され、待機リストに登録されます。Kueue が十分なリソースがあることを認識すると、ジョブを承認して実行します。

次の例は、YAML ファイルでラベルを使用する方法を説明しています。

```
apiVersion: batch/v1
kind: Job
metadata:
  name: test-tas-job
  namespace: hyperpod-ns-{{team-name}}
  labels:
    kueue.x-k8s.io/queue-name: hyperpod-ns-{{team-name}}-localqueue
    kueue.x-k8s.io/priority-class: {{PRIORITY_CLASS}}-priority
spec:
  parallelism: 10
  completions: 10
  suspend: true
  template:
    metadata:
      labels:
        kueue.x-k8s.io/queue-name: hyperpod-ns-{{team-name}}-localqueue
      annotations:
        kueue.x-k8s.io/podset-required-topology: "topology.k8s.aws/network-node-layer-3"
        or
        kueue.x-k8s.io/podset-preferred-topology: "topology.k8s.aws/network-node-layer-3"
    spec:
      nodeSelector:
        topology.k8s.aws/network-node-layer-3: {{TOPOLOGY_LABEL_VALUE}}
      containers:
        - name: dummy-job
          image: gcr.io/k8s-staging-perf-tests/sleep:v0.1.0
          args: ["3600s"]
          resources:
            requests:
              cpu: "100"
      restartPolicy: Never
```

次の表は、kubectl YAML ファイルで使用できる新しいパラメータを説明しています。


| パラメータ | 説明 | 
| --- | --- | 
| kueue.x-k8s.io/queue-name | ジョブの実行に使用するキューの名前。この queue-name の形式は hyperpod-ns-{{team-name}}-localqueue である必要があります。 | 
| kueue.x-k8s.io/priority-class | ポッドのスケジューリングの優先度を指定できます。この仕様はオプションです。 | 
| annotations | ジョブにアタッチするトポロジーの注釈が含まれます。利用可能なトポロジーは、kueue.x-k8s.io/podset-required-topology と kueue.x-k8s.io/podset-preferred-topology です。注釈または nodeSelector のどちらかを使用できますが、両方を同時に使用することはできません。 | 
| nodeSelector | Amazon EC2 インスタンスの配置レイヤーを表すネットワークレイヤーを指定します。このフィールドまたは注釈のどちらかを使用しますが、両方を同時に使用することはできません。YAML ファイルでは、nodeSelector パラメータを使用してポッドの正確なレイヤーを選択することもできます。ラベルの値を取得するには、[DescribeInstanceTopology](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstanceTopology.html) API オペレーションを使用します。 | 

HyperPod CLI を使用してジョブを実行し、トポロジー認識スケジューリングを使用することもできます。HyperPod CLI の詳細については、「[SageMaker HyperPod CLI コマンド](sagemaker-hyperpod-eks-hyperpod-cli-reference.md)」を参照してください。

```
hyp create hyp-pytorch-job \                                            
  --version 1.1 \
  --job-name sample-pytorch-job \
  --image 123456789012.dkr.ecr.us-west-2.amazonaws.com/ptjob:latest \
  --pull-policy "Always" \
  --tasks-per-node 1 \
  --max-retry 1 \
  --priority high-priority \
  --namespace hyperpod-ns-{{team-name}} \
  --queue-name hyperpod-ns-{{team-name}}-localqueue \
  --preferred-topology-label topology.k8s.aws/network-node-layer-1
```

トポロジーラベルを使用して PytorchJob を実行するために使用できる設定ファイルの例は、次のとおりです。MPI ジョブと Tensorflow ジョブを実行する場合、ファイルはほぼ同様です。代わりにこれらのジョブを実行したい場合は、PyTorchJob の代わりに適切なイメージを使用するなど、設定ファイルを適宜変更します。PyTorchJob を実行する場合は、プライマリノードとワーカーノードに異なるトポロジを割り当てることができます。PyTorchJob には常に単一のプライマリノードが存在するため、ワーカーポッドをサポートするにはトポロジーを使用することをお勧めします。

```
apiVersion: kubeflow.org/v1
kind: PyTorchJob
metadata:
  annotations: {}
  labels:
    kueue.x-k8s.io/queue-name: hyperpod-ns-{{team-name}}-localqueue
  name: tas-test-pytorch-job
  namespace: hyperpod-ns-team-name
spec:
  pytorchReplicaSpecs:
    Master:
      replicas: 1
      restartPolicy: OnFailure
      template:
        metadata:
          labels:
            kueue.x-k8s.io/queue-name: hyperpod-ns-{{team-name}}-localqueue
        spec:
          containers:
          - command:
            - python3
            - /opt/pytorch-mnist/mnist.py
            - --epochs=1
            image: docker.io/kubeflowkatib/pytorch-mnist:v1beta1-45c5727
            imagePullPolicy: Always
            name: pytorch
    Worker:
      replicas: 10
      restartPolicy: OnFailure
      template:
        metadata:
          # annotations:
            # kueue.x-k8s.io/podset-required-topology: "topology.k8s.aws/network-node-layer-3"
          labels:
            kueue.x-k8s.io/queue-name: hyperpod-ns-{{team-name}}-localqueue
        spec:
          containers:
          - command:
            - python3
            - /opt/pytorch-mnist/mnist.py
            - --epochs=1
            image: docker.io/kubeflowkatib/pytorch-mnist:v1beta1-45c5727
            imagePullPolicy: Always
            name: pytorch
            resources:
              limits:
                cpu: 1
              requests:
                memory: 200Mi
                cpu: 1
          #nodeSelector:
          #  topology.k8s.aws/network-node-layer-3: xxxxxxxxxxx
```

クラスターのトポロジーを確認するには、[DescribeInstanceTopology](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstanceTopology.html) API オペレーションを使用します。デフォルトでは、トポロジは AWS マネジメントコンソール および Amazon SageMaker Studio では非表示になっています。使用しているインターフェイスでこれらを表示するには、以下の手順を実行します。

**SageMaker Studio**

1. SageMaker Studio で、使用するクラスターに移動します。

1. タスクビューで、名前列のオプションメニューを選択し、**[列の管理]** をクリックします。

1. **[リクエストされたトポロジー]** と **[トポロジーの制約]** を選択して列を追加し、Kubernetes ポッドのリストでトポロジー情報を表示します。

**AWS マネジメントコンソール**

1. Amazon SageMaker AI コンソール ([https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/)) を開きます。

1. **[HyperPod クラスター]** で、**[クラスターの管理]** をクリックします。

1. **[タスク]** タブをクリックしてから歯車アイコンをクリックします。

1. インスタンス属性で、**[リクエストされたトポロジー]** と **[トポロジの制約]** を切り替えます。

1. **[確認]** をクリックして、テーブルでトポロジー情報を表示します。