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

# ネットワーク
<a name="aiml-networking"></a>

**ヒント**  
 今後開催予定の Amazon EKS AI/ML ワークショップに[登録](https://events.eksworkshop.com/workshops/genai/)してください。

## ノード間通信が高いアプリケーションでは、ネットワーク帯域幅または Elastic Fabric Adapter を高くすることを検討する
<a name="_consider_higher_network_bandwidth_or_elastic_fabric_adapter_for_applications_with_high_inter_node_communication"></a>

ノード間通信の需要が高い Amazon EKS の分散トレーニングワークロードの場合は、ネットワーク帯域幅が高いインスタンスまたは [Elastic Fabric Adapter](https://docs.aws.amazon.com/eks/latest/userguide/node-efa.html) (EFA) を選択することを検討してください。ネットワークパフォーマンスが不十分な場合、データ転送がボトルネックになり、分散マルチ GPU トレーニングなどの機械学習タスクが遅くなる可能性があります。推論ワークロードでは通常、ノード間の通信は高くないことに注意してください。

コンテナイメージに NCCL と [aws-ofi-nccl プラグイン](https://github.com/aws/aws-ofi-nccl) (NCCL が libfabric 経由で EFA を使用できるようにする) が含まれていることを確認します。トレーニングフレームワークのランチャーによっては、MPI が必要になる場合もあります。

### EFA ワークロードのノードプロビジョニングに関する考慮事項
<a name="_node_provisioning_considerations_for_efa_workloads"></a>

EFA 対応ノードをプロビジョニングする場合、通信する必要があるインスタンスは同じアベイラビリティーゾーンにある必要があります (ハード要件）。さらに、AWS では、[クラスタープレイスメントグループ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html)内のすべての EFA 対応インスタンスを起動して、その単一の AZ 内のインスタンス間の物理的な距離を最小限に抑えることをお勧めします。これにより、レイテンシーを最小限に抑えることができます。EFA が機能するためにプレイスメントグループは必要ありませんが、最適なパフォーマンスを得るには強くお勧めします。

EKS での EFA ベースの分散トレーニングデプロイには、以下の考慮事項が適用されます。以下は Karpenter 注釈を例として参照しますが、マネージド型ノードグループとセルフマネージド型ノードグループの両方の実装にも同じ考慮事項を適用できます。
+  **AZ にピン留めします**。EFA では、すべての通信ノードが同じ AZ に存在する必要があるため、例えば、同じ分散トレーニングジョブに参加しているノードをゾーン間で分散してはいけません。これを強制するには、 で `nodeSelector`または ポッドアフィニティを使用して Pod を AZ に固定します`topology.kubernetes.io/zone`。ターゲットインスタンスタイプが最適な可用性を持つ AZ、またはキャパシティブロックが予約されている AZ を選択します。同じ AZ コロケーションはノード間のレイテンシーを改善しますが、AZ レベルの障害のブラスト半径も向上することに注意してください。長時間実行されるトレーニングワークロードの場合、1 回の AZ 停止または容量イベントにより、蓄積されたトレーニングの進行状況が何時間も枯渇する可能性があります。これはコストのかかる損失です。これをチェックポイント戦略とジョブ期間計画に組み込みます。
+  **クラスタープレイスメントグループを設定します (推奨)**。EC2NodeClass でプレイスメントグループを指定します。Karpenter は自動的にプロビジョニングされます。これは、最適なレイテンシーのために推奨されますが、EFA が機能するために厳密に必須ではありません。[ML のキャパシティブロックの場合](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html)、配置は UltraClusters を介して自動的に処理されるため、手動配置グループは必要ありません。この場合、AZ は既にロックされているため、追加の Pod レベルまたは NodePool レベルの AZ 制限は必要ありません。
+  **マルチノードトレーニングジョブの中断を防止**します。トレーニングポッドで PDBs または`karpenter.sh/do-not-disrupt: "true"`注釈を使用します。これを行わないと、Karpenter の統合によって EFA ワークロードの置き換えや移動がジョブの途中で試みられ、分散トレーニングの実行全体が中断される可能性があります。占有ノードの統合を防ぐには、NodePool `consolidationPolicy: WhenEmpty`で を設定します。これらのラベルと `terminationGracePeriod`および の相互作用を`expireAfter`[ここで](https://karpenter.sh/docs/concepts/disruption/)確認します。
+  **適切な有効期限を設定します**。NodePool `expireAfter`で、最長のトレーニングジョブよりも長い値に設定するか、NodePools を完全にトレーニングするために無効にします。トレーニング中に期限切れになるノードはジョブを終了します。
+  **正しい EFA デバイスプラグインバージョンを使用します**。[EFA デバイスプラグイン](https://github.com/aws/eks-charts/tree/master/stable/aws-efa-k8s-device-plugin)は、スケジュール可能なリソース`vpc.amazonaws.com/efa`として公開します。
+  **セキュリティグループを設定します**。すべての EFA インスタンスは、それ自体との間のすべてのトラフィックを許可する自己参照ルールを持つ同じセキュリティグループに存在する必要があります。これを行わないと、EFA トラフィックはサイレントに失敗します。

### EFA コロケーションによるスポットインスタンスのリスクを理解する
<a name="_understand_spot_instance_risks_with_efa_co_location"></a>

Amazon EC2 スポットインスタンスは、トレーニングワークロードの大幅なコスト削減を実現します (GPUs を使用したスポットの一般的なベストプラクティスについては[、このセクション](aiml-compute.md#spot-gpus-karpenter)を参照してください）。ただし、EFA ではすべての通信ノードが同じアベイラビリティーゾーンに存在する必要があり、AWS では最適なレイテンシーを実現するためにクラスタープレイスメントグループに配置することをお勧めします。このコロケーションは*、相関する中断リスク*をもたらします。インスタンスは基盤となる物理インフラストラクチャを同じ AZ 内 (さらにプレイスメントグループ内) で共有するため、1 つの容量再利用イベントが複数のインスタンスに同時に影響するため、1 つのノードではなく、マルチノードトレーニングジョブ全体を一度に中断する可能性があります。

これは、ノードを AZs に分散でき、中断が統計的に独立している EFA 制約のないスポット使用量とは根本的に異なります。EFA の同じ AZ 要件では、単一の容量イベントをトレーニングクラスター全体にカスケードできます。

GPU トレーニングワークロードのコスト削減を追求する場合は、スポットにコミットする前に、利用可能なすべての購入オプションを評価していることを確認してください。ML [のリザーブドインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-reserved-instances.html)、[オンデマンドキャパシティ予約](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) (ODCRs)、[Savings Plans](https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html)、[キャパシティブロック](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html)はすべて、キャパシティの可用性を確保しながら大幅な割引を提供し、EFA コロケーション制約によりスポットに固有の相関中断リスクを回避できます。

## 大規模な GPU インスタンスでの IP アドレス消費の計画
<a name="_planning_for_ip_address_consumption_on_large_gpu_instances"></a>

デフォルトでは、Amazon VPC CNI プラグインは IP アドレスを事前に割り当てて、ポッドを迅速にスケジュールできるようにし、1 つの完全な予備の ENI をアタッチして IPs を入力します。大規模なインスタンスでは、少数のポッドしか実行されていない場合でも、ノードごとに数十の IPs が予約される可能性があります。

この不一致は、ノードあたりのポッド密度が低いトレーニングワークロードと推論ワークロードで一般的です。クラスター規模では、特に多くの GPU ノードをスピンアップするオートスケーリングイベントでそれぞれポッドが少ない場合、実際の IP 使用率が低い場合でも、サブネット IP が枯渇する可能性があります。

これを軽減するには、`WARM_IP_TARGET`、`MINIMUM_IP_TARGET`、および `WARM_ENI_TARGET`変数を実際のポッド密度に合わせて調整します。詳細については、[「VPC CNI の ENI および IP ターゲット設定](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/eni-and-ip-target.md)」を参照してください。

IP 消費の最適化に関する詳細なガイドについては、[「IP アドレス使用率の最適化](https://docs.aws.amazon.com/eks/latest/best-practices/ip-opt.html)」を参照してください。