はじめに
2026 年 5 月 1 日、AWS は Amazon EKS において Elastic Fabric Adapter（EFA）向けの Dynamic Resource Allocation（DRA）サポートを発表しました。AI/ML の分散学習や HPC ワークロードにおけるノード間高性能通信の設定を、Kubernetes ネイティブな方法で扱えるようにするアップデートです。
EKS 上で GPU ワークロードの分散学習や大規模 HPC を運用したことがある方なら、EFA まわりの設定がいかに手間だったかをご存知かと思います。どの NIC が GPU と物理的に近いかを把握してトポロジーを手動で合わせる、EFA インターフェースの割り当てを Kubernetes の標準的な仕組みの外で管理するといった運用上の課題は、クラスターのスケールが大きくなるほど顕在化します。
本記事では「EFA と DRA の基本」「何が変わったのか」「アーキテクチャ」「Device Plugin との使い分け」「実際のセットアップ手順」を中心に解説します。EKS 上で AI/ML・HPC ワークロードを運用している、または今後導入を検討しているエンジニアはぜひ参考にしてみてください。
EFA と DRA の基本
本章では、今回のアップデートを理解するうえで押さえておきたい 2 つのキーワードを整理します。すでにご存知の方は読み飛ばしていただいて構いません。
EFA とは
EFA（Elastic Fabric Adapter）は、Amazon EC2 インスタンス間の高速通信を実現するネットワークアダプターです。RDMA（Remote Direct Memory Access）に対応しており、CPU を介さずにノード間でデータを直接転送できるため、通信レイテンシを大きく削減できます。
LLM の分散学習における AllReduce 通信や、気象シミュレーション・分子動力学といった HPC ワークロードでは、ノード間通信の帯域幅とレイテンシがそのままスループットに直結します。EFA はこうした用途において、標準的な TCP/IP ネットワークでは得られないパフォーマンスを実現します。
DRA とは
DRA（Dynamic Resource Allocation）は、GPU や FPGA、ネットワークアダプターといった特殊なハードウェアを Kubernetes 上で管理するための新しいリソース管理フレームワークです。Kubernetes 1.26 でアルファとして導入され、1.32 でベータに昇格、Kubernetes 1.34 で GA（General Availability）に昇格しました。
従来の Device Plugin API では、デバイスを「個数」で要求するシンプルな仕組みのため、トポロジーを考慮した割り当てやデバイスの共有といった柔軟な管理が困難でした。DRA では ResourceClaim や DeviceClass といった Kubernetes オブジェクトを通じてリソースを宣言的に管理でき、スケジューラーがトポロジー情報を考慮した割り当てをネイティブに行えるようになっています。
今回の EFA DRA ドライバーは、Kubernetes コミュニティの upstream プロジェクトである DRANET をベースに構築されています。DRANET のベンチマーク結果では、トポロジー対応スケジューリングにより all_gather で最大 59.6%、all_reduce で最大 58.1% の帯域幅向上が確認されています。
| Device Plugin API | DRA | |
|---|---|---|
| デバイスの要求方法 | 個数指定（整数カウント） | 宣言的（ResourceClaim） |
| トポロジー対応 | AL2023 AMI 使用時のみ自動対応 | ネイティブサポート |
| デバイスの共有 | 非対応（Pod ごとに専有） | 対応（ResourceClaim の共有参照） |
| Kubernetes 対応バージョン | 全バージョン | 1.34 以降（GA） |
何が変わったのか
EKS 上で EFA を使った分散学習や HPC ワークロードを運用したことがある方なら、EFA デバイスの管理がいかに手間だったかをご存知かと思います。
| 項目 | Before | After |
|---|---|---|
| デバイスの割り当て方法 | 整数カウント（vpc.amazonaws.com/efa）で個数を指定 |
ResourceClaim による宣言的な割り当て |
| トポロジー対応 | EKS 最適化 AL2023 AMI 使用時のみ自動対応 | DRA ネイティブでトポロジー対応（AMI 依存なし） |
| デバイスの共有 | 非対応。1 つの EFA デバイスは 1 Pod に専有 | 複数 Pod 間で同一デバイスを共有可能 |
| デバイス情報の公開 | 整数カウントのみ |
ResourceSlice によりデバイスタイプ・PCIe 位置情報などリッチな属性を公開 |
従来の課題
EFA Device Plugin では、デバイスは vpc.amazonaws.com/efa というリソース名で「個数」として扱われます。Pod から見えるのは「EFA デバイスが何個あるか」だけであり、どのデバイスがどの GPU や Neuron と物理的に近い位置にあるかといったトポロジー情報は考慮されません。
トポロジー対応の自動割り当ては EKS 最適化 AL2023 AMI（NVIDIA・Neuron）を使用している場合に限り機能しますが、Bottlerocket やカスタム AMI を使用している環境では対応しておらず、最適なペアリングを実現するためには別途手動での調整が必要でした。
また、1 つの EFA デバイスは常に 1 つの Pod に専有されるため、同一ノード上で複数のワークロードが動作している場合でも EFA インターフェースを共有することができず、リソースの無駄が生じていました。
EFA DRA ドライバーによる解決
EFA DRA ドライバーでは、各 EFA デバイスがデバイスタイプ・PCIe トポロジー・接続グループといったリッチな属性を持つ ResourceSlice オブジェクトとして公開されます。スケジューラーはこの情報をもとに、GPU や Neuron デバイスと同一 PCIe ルートにある EFA インターフェースを自動的に選択して割り当てます（トポロジー対応割り当ての詳細はアーキテクチャ詳解の章で解説します）。
また、ResourceClaim を Pod 間で共有参照することで、同一ノード上の複数 Pod が同じ EFA デバイスにアクセスできるようになりました。これにより、1 デバイスあたりの利用効率が上がり、コスト面でも恩恵があります。
なお、EFA デバイスは dra.net というドライバー名と efa.networking.k8s.aws という DeviceClass 名で Kubernetes API に公開されます。
アーキテクチャ詳解
動作フロー
EFA DRA ドライバー（DRANET）は各ノード上に DaemonSet として動作し、EFA デバイスを自動検出します。検出されたデバイスは、デバイスタイプ・PCIe トポロジー・接続グループなどの属性情報を持つ ResourceSlice オブジェクトとして Kubernetes API に公開されます（ドライバー名：dra.net、DeviceClass 名：efa.networking.k8s.aws）。
ユーザーが ResourceClaim または ResourceClaimTemplate を作成すると、Kubernetes スケジューラーが ResourceSlice のデバイス情報を参照しながら割り当てをバインドし、Pod を対象ノードにスケジューリングします。
PCIe トポロジー対応割り当て
EFA DRA ドライバーの核心となる機能の一つが、PCIe トポロジーを考慮したデバイス割り当てです。
各 EFA デバイスの ResourceSlice には PCIe ルートやデバイスグループといった位置情報が含まれており、ResourceClaim の constraints フィールドに matchAttribute 制約を指定することで、同一 PCIe ルート上にある GPU または Neuron デバイスと EFA インターフェースを自動的にペアリングできます。
| アクセラレーター | matchAttribute |
|---|---|
| NVIDIA GPU | resource.kubernetes.io/pcieRoot |
| Neuron（1 デバイス） | resource.aws.com/devicegroup1_id |
| Neuron（4 デバイス構成） | resource.aws.com/devicegroup4_id |
| Neuron（8 デバイス構成） | resource.aws.com/devicegroup8_id |
| Neuron（16 デバイス構成） | resource.aws.com/devicegroup16_id |
Neuron の devicegroup 属性名は、割り当てたい Neuron デバイス数と一致する番号を選択します。たとえば 4 台を確保したい場合は devicegroup4_id を指定します。
また allocationMode: All を指定すると、1 GPU に対して同一 PCIe ルート上のすべての EFA インターフェースをまとめて確保できます。p5.48xlarge のように GPU あたり複数の EFA デバイスが存在するインスタンスで有効です。具体的な YAML 設定例はセットアップ手順の章で紹介します。
デバイス共有の仕組み
EFA DRA ドライバーでは、複数の Pod が同一の EFA デバイスを共有できます。
ResourceClaimTemplate は各 Pod に対して個別の ResourceClaim を生成しますが、独立して作成した ResourceClaim オブジェクトを複数の Pod から resourceClaimName で参照することで、同一 EFA デバイスの共有が実現します。共有を参照するすべての Pod は、該当デバイスが利用可能なノードにスケジューリングされます。
どちらを使うべきか
EFA DRA ドライバーと EFA Device Plugin はどちらも EKS 上で EFA デバイスを管理する手段ですが、対応環境や機能に明確な違いがあります。本章では判断基準を整理します。
判断フロー
制約事項
最初に確認すべき重要な制約として、EFA DRA ドライバーは Karpenter および EKS Auto Mode では非対応です。「推奨」ではなく「非サポート」であるため、これらの環境では EFA Device Plugin を使用してください。
また、EFA DRA ドライバーと EFA Device Plugin は同一ノード上での共存ができません。片方が動作しているノードにもう片方をインストールしないよう注意が必要です。
| EKS コンピュート環境 | EFA DRA ドライバー | EFA Device Plugin |
|---|---|---|
| EKS Managed Node Groups | ✅ 対応（推奨） | ✅ 対応 |
| Self-managed Nodes | ✅ 対応（推奨） | ✅ 対応 |
| Karpenter | ❌ 非対応 | ✅ 対応 |
| EKS Auto Mode | ❌ 非対応 | ✅ 対応 |
既存環境からの移行
現在 EFA Device Plugin を使用しているクラスターで EFA DRA ドライバーへの移行を検討する場合のポイントは以下の通りです。
まず、EFA DRA ドライバーは Kubernetes 1.34 以降が前提です。既存クラスターが 1.34 未満の場合は、バージョンアップが移行の前提条件となります。
同一ノード上での共存はできないため、移行はノードグループ単位で段階的に行うのが現実的です。新規ノードグループに EFA DRA ドライバーを導入し、既存ノードグループは Device Plugin のまま運用しながら徐々に切り替えるアプローチが低リスクです。
なお、EKS 最適化 AL2023 AMI（NVIDIA・Neuron）および Bottlerocket AMI には、EFA DRA ドライバーも EFA Device Plugin もいずれも含まれていません。どちらを選択する場合でも、クラスターへの別途インストールが必要です。
セットアップ手順
前提条件
EFA DRA ドライバーを使用するには、以下の条件を満たしている必要があります。
| 条件 | 内容 |
|---|---|
| ① EKS クラスター | Kubernetes 1.34 以降、EKS Managed Node Groups または Self-managed Nodes |
| ② EC2 インスタンスタイプ | EFA 対応インスタンスタイプ（p5、p4d、trn1 等） |
| ③ ホストコンポーネント | EFA ホストレベルコンポーネントがインストール済み（EKS 最適化 AL2023 NVIDIA・Neuron AMI および Bottlerocket AMI には含まれる） |
| ④ Helm | コマンドライン環境にインストール済み |
| ⑤ kubectl | クラスターと通信できる状態 |
注意： EFA DRA ドライバーと EFA Device Plugin は同一ノード上に共存できません。すでに EFA Device Plugin が動作しているノードには導入しないでください。
EFA DRA ドライバーのインストール
EKS の Helm チャートリポジトリを追加し、aws-dranet をインストールします。
# リポジトリの追加
helm repo add eks https://aws.github.io/eks-charts
# リポジトリの更新
helm repo update
# EFA DRA ドライバーのインストール
helm install aws-dranet eks/aws-dranet --namespace kube-system
インストールの確認
DaemonSet の起動、DeviceClass の作成、ResourceSlice の公開を順に確認します。
# DaemonSet の確認
kubectl get daemonset -n kube-system aws-dranet
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
aws-dranet 2 2 2 2 2 <none> 60s
# DeviceClass の確認
kubectl get deviceclass
NAME AGE
efa.networking.k8s.aws 60s
# ResourceSlice の確認（ノードごとに EFA デバイス情報が公開される）
kubectl get resourceslices --field-selector spec.driver=dra.net
エラーが発生する場合は、DRANET のログで原因を確認できます。
kubectl logs -n kube-system -l app=aws-dranet
EFA デバイスのリクエスト（基本）
ResourceClaimTemplate を作成し、Pod スペックから参照します。以下は EFA デバイスを 1 つリクエストするシンプルな例です。
apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
name: single-efa-claim
spec:
spec:
devices:
requests:
- name: efa
exactly:
deviceClassName: efa.networking.k8s.aws
count: 1
---
apiVersion: v1
kind: Pod
metadata:
name: efa-workload
spec:
containers:
- name: app
image: <your-image>
resources:
claims:
- name: efa-device
resourceClaims:
- name: efa-device
resourceClaimTemplateName: single-efa-claim
トポロジー対応割り当て
matchAttribute 制約を使うことで、GPU または Neuron デバイスと同一 PCIe ルート上の EFA インターフェースを自動的にペアリングできます。
NVIDIA GPU との組み合わせ（EFA 1 つ・GPU 1 つ）
apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
name: aligned-efa-nvidia
spec:
spec:
devices:
requests:
- name: 1-efa
exactly:
deviceClassName: efa.networking.k8s.aws
count: 1
- name: 1-gpu
exactly:
deviceClassName: gpu.nvidia.com
count: 1
constraints:
- requests: ["1-gpu", "1-efa"]
matchAttribute: "resource.kubernetes.io/pcieRoot"
p5.48xlarge のように GPU あたり EFA が複数ある場合（allocationMode: All）
EFA デバイスの正確な数を指定せずに、1 GPU と同じ PCIe ルート上のすべての EFA を確保したい場合は allocationMode: All を使用します。
apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
name: aligned-all-efa-one-nvidia
spec:
spec:
devices:
requests:
- name: all-efas
exactly:
deviceClassName: efa.networking.k8s.aws
allocationMode: All
- name: one-gpu
exactly:
deviceClassName: gpu.nvidia.com
allocationMode: ExactCount
count: 1
constraints:
- requests: ["all-efas", "one-gpu"]
matchAttribute: "resource.kubernetes.io/pcieRoot"
AWS Neuron との組み合わせ（EFA 4 つ・Neuron 4 デバイス）
Neuron の場合は matchAttribute に devicegroupN_id を指定します。N は確保したい Neuron デバイス数（1・4・8・16）と一致させます。
apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
name: aligned-efa-neuron
spec:
spec:
devices:
requests:
- name: 4-neurons
exactly:
deviceClassName: neuron.aws.com
count: 4
- name: 4-efas
exactly:
deviceClassName: efa.networking.k8s.aws
count: 4
constraints:
- requests: ["4-neurons", "4-efas"]
matchAttribute: "resource.aws.com/devicegroup4_id"
デバイス共有の設定
複数の Pod で同一の EFA デバイスを共有する場合は、ResourceClaimTemplate ではなく ResourceClaim を独立して作成し、各 Pod から resourceClaimName で参照します。
# 共有用 ResourceClaim の作成
apiVersion: resource.k8s.io/v1
kind: ResourceClaim
metadata:
name: shared-efa
spec:
devices:
requests:
- name: efa
exactly:
deviceClassName: efa.networking.k8s.aws
count: 4
# Pod 1（training-worker）
apiVersion: v1
kind: Pod
metadata:
name: training-worker
spec:
containers:
- name: worker
image: <your-training-image>
resources:
claims:
- name: efa-devices
resourceClaims:
- name: efa-devices
resourceClaimName: shared-efa # resourceClaimTemplateName ではなく resourceClaimName
---
# Pod 2（training-monitor）
apiVersion: v1
kind: Pod
metadata:
name: training-monitor
spec:
containers:
- name: monitor
image: <your-monitor-image>
resources:
claims:
- name: efa-devices
resourceClaims:
- name: efa-devices
resourceClaimName: shared-efa
両 Pod は同じ shared-efa を参照するため、同一ノードの同一 EFA デバイスにスケジューリングされます。ResourceClaim は Pod のライフサイクルとは独立しており、明示的に削除するまで保持されます。
まとめ
EKS における EFA 向け DRA サポートの追加により、AI/ML・HPC ワークロードのノード間通信管理が Kubernetes ネイティブな方法で扱えるようになりました。Kubernetes 1.34 での DRA GA 昇格に合わせたリリースです。
トポロジー対応割り当ての汎用性が、今回の最大の改善点です。従来の EFA Device Plugin では EKS 最適化 AL2023 AMI を使用している場合のみ自動でトポロジーが考慮されていましたが、EFA DRA ドライバーでは AMI に依存せず DRA ネイティブで GPU・Neuron と EFA のペアリングが実現されます。デバイス共有と合わせて、運用上の選択肢が広がります。
一方で、現時点では Karpenter および EKS Auto Mode には対応しておらず、これらの環境では EFA Device Plugin が引き続き必要です。