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

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

**ヒント**  
 Amazon EKS [https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el)ワークショップを通じてベストプラクティスをご覧ください。

## ノード間通信が高いアプリケーションでは、より高いネットワーク帯域幅または 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 トレーニングなどの機械学習タスクが遅くなる可能性があります。推論ワークロードでは通常、ノード間の通信は高くないことに注意してください。

 **例** 

たとえば、Karpenter を使用します。

```
apiVersion: v1
kind: Pod
metadata:
  name: ml-workload
spec:
  nodeSelector:
    karpenter.k8s.aws/instance-network-bandwidth: "100000"  # 100 Gbps in Mbps
    node.kubernetes.io/instance-type: p5.48xlarge  # EFA-enabled instance
  containers:
  - name: training-job
    image: `763104351884.dkr.ecr.us-west-2.amazonaws.com/pytorch-inference:2.6.0-gpu-py312-cu124-ubuntu22.04-ec2-v1.6`
    resources:
      limits:
        vpc.amazonaws.com/efa: 1  # Requires EFA device plugin
```

トレーニングジョブに EFA を活用するために、MPI や NCCL などのツールがコンテナイメージにインストールされていることを確認します。

## ポッドの起動時間を短縮するために使用可能な IP アドレスの数を増やす
<a name="_increase_the_number_of_ip_addresses_available_to_enable_faster_pod_launch_times"></a>

EKS では、各ポッドに VPC CIDR ブロックの IP アドレスが必要です。クラスターがより多くのノードやポッドでスケールすると、IP アドレスの枯渇やパフォーマンスの低下のリスクがありますが、プレフィックスの委任を有効にすると、IP 範囲を事前に割り当てて EC2 API コールを減らすことで、これらの問題を軽減できるため、ポッドの起動時間が短縮され、スケーラビリティが向上します。

クラスターの作成後にプレフィックスの委任を有効にすると、VPC コンテナネットワークインターフェイス (CNI) は EC2 インスタンスのネットワークインターフェイスに IP プレフィックス (/28、それぞれ 16 個の IP アドレスを付与) を割り当てることができます。つまり、各ノードはより多くのポッドをサポートできるため、IP 不足のリスクが軽減されます。たとえば、`c5.4xlarge`インスタンスでは、プレフィックス委任を使用して最大 110 個のポッドをサポートできます。

多数の小さなポッドがある環境で IP 使用率を最適化するにはプレフィックスの委任が不可欠ですが、AI/ML ワークロードでは多くの場合、使用するポッドが少なくて大きなポッド (GPU ごとに 1 つのポッドなど) を使用します。プレフィックス委任を有効にすると、VPC CNI はウォームプールを維持することで、ポッドの起動を高速化するためにプレフィックスを事前に割り当てることができます。つまり、IP アドレスがすぐに使用可能になり、非プレフィックスモードでのオンデマンド割り当てと比較して、ポッドの初期化に必要な時間が短縮されます。このような場合、プレフィックス委任を有効にすることで IP を節約することで、AI/ML ワークロードのパフォーマンス上の利点が得られます。IP アドレス設定と IP 範囲の事前割り当てに必要な EC2 API コールの数を減らすことで、プレフィックス委任を使用するとポッドの起動時間が短縮され、AI/ML ワークロードを迅速にスケーリングするために特に役立ちます。

プレフィックスの委任を有効にするには:

```
kubectl set env daemonset/aws-node -n kube-system ENABLE_PREFIX_DELEGATION=true
```

特に大規模なデプロイでは、IP アドレスの枯渇を避けるために VPC サブネットを適切に計画し、VPCs 間での重複を避けるために CIDR ブロックを管理します。詳細については、[「IP アドレス使用率の最適化](ip-opt.md)」および[「プレフィックス付きの Amazon EKS ノードへの IP アドレスの割り当て](https://docs.aws.amazon.com/eks/latest/best-practices/ip-opt.html#_plan_for_growth)」を参照してください。