View a markdown version of this page

네트워킹 - Amazon EKS
노드 간 통신이 많은 애플리케이션의 경우 더 높은 네트워크 대역폭 또는 탄력적 패브릭 어댑터 고려대규모 GPU 인스턴스에서 IP 주소 소비 계획

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

네트워킹

작은 정보

향후 예정된 Amazon EKS AI/ML 워크숍에 등록합니다.

노드 간 통신이 많은 애플리케이션의 경우 더 높은 네트워크 대역폭 또는 탄력적 패브릭 어댑터 고려

노드 간 통신 요구가 높은 Amazon EKS의 분산 훈련 워크로드의 경우 네트워크 대역폭 또는 EFA(Elastic Fabric Adapter)가 더 높은 인스턴스를 선택하는 것이 좋습니다. 네트워크 성능이 충분하지 않으면 데이터 전송에 병목 현상이 발생하여 분산 다중 GPU 훈련과 같은 기계 학습 작업이 느려질 수 있습니다. 추론 워크로드는 일반적으로 노드 간 통신이 높지 않습니다.

컨테이너 이미지에 NCCL 및 aws-ofi-nccl 플러그인(NCCL이 libfabric을 통해 EFA를 사용할 수 있음)이 포함되어 있는지 확인합니다. 훈련 프레임워크의 시작 관리자에 따라 MPI가 필요할 수도 있습니다.

EFA 워크로드에 대한 노드 프로비저닝 고려 사항

EFA 지원 노드를 프로비저닝할 때 통신해야 하는 인스턴스는 동일한 가용 영역(하드 요구 사항)에 있어야 합니다. 또한 AWS는 클러스터 배치 그룹에서 모든 EFA 지원 인스턴스를 시작하여 단일 AZ 내에서 인스턴스 간의 물리적 거리를 최소화하여 지연 시간을 최소화할 것을 권장합니다. 배치 그룹은 EFA가 작동하는 데 필요하지 않지만 최적의 성능을 위해 적극 권장됩니다.

EKS의 모든 EFA 기반 분산 훈련 배포에는 다음 고려 사항이 적용됩니다. 아래에서 Karpenter 주석을 예로 들 수 있지만 관리형 노드 그룹 구현과 자체 관리형 노드 그룹 구현 모두에 동일한 고려 사항을 적용할 수 있습니다.

  • AZ에 고정합니다. EFA를 사용하려면 모든 통신 노드가 동일한 AZ에 있어야 합니다. 예를 들어 동일한 분산 훈련 작업에 참여하는 노드는 영역 간에 분산되어서는 안 됩니다. 에서 nodeSelector 또는 포드 선호도를 사용하여 포드를 AZ에 고정하여 이를 적용할 수 있습니다topology.kubernetes.io/zone. 대상 인스턴스 유형의 가용성이 가장 좋거나 용량 블록이 예약된 AZ를 선택합니다. 동일 AZ 코로케이션은 노드 간 지연 시간을 개선하지만 AZ 수준 장애의 블래스트 반경도 높입니다. 장기 실행 훈련 워크로드의 경우 단일 AZ 중단 또는 용량 이벤트로 누적된 훈련 진행 시간을 지울 수 있으므로 비용이 많이 드는 손실이 발생할 수 있습니다. 이를 체크포인트 전략 및 작업 기간 계획에 반영합니다.

  • 클러스터 배치 그룹을 구성합니다(권장). EC2NodeClass에서 배치 그룹을 지정합니다. Karpenter는 자동으로 프로비저닝합니다. 이는 최적의 지연 시간을 위해 권장되지만 EFA가 작동하는 데 반드시 필요한 것은 아닙니다. ML용 용량 블록의 경우 UltraClusters 통해 배치가 자동으로 처리되므로 수동 배치 그룹이 필요하지 않습니다. 이 경우 AZ는 이미 잠겨 있으므로 추가 포드 수준 또는 NodePool 수준 AZ 제한은 필요하지 않습니다.

  • 다중 노드 훈련 작업의 중단을 방지합니다. 훈련 포PDBs 또는 karpenter.sh/do-not-disrupt: "true" 주석을 사용합니다. 이렇게 하지 않으면 Karpenter의 통합이 작업 중 EFA 워크로드를 교체하거나 이동하려고 시도하여 전체 분산 훈련 실행을 방해할 수 있습니다. NodePoolconsolidationPolicy: WhenEmpty에서를 설정하여 점유된 노드의 통합을 방지합니다. expireAfter 여기에서 이러한 레이블과 terminationGracePeriod 및 간의 상호 작용을 검토합니다.

  • 적절한 만료를 설정합니다. NodePoolexpireAfter에서 가장 긴 훈련 작업보다 긴 값으로를 구성하거나 NodePools 훈련을 위해 완전히 비활성화합니다. 훈련 중 만료되는 노드는 작업을 종료합니다.

  • 올바른 EFA 디바이스 플러그인 버전을 사용합니다. EFA 디바이스 플러그인은를 예약 가능한 리소스vpc.amazonaws.com/efa로 노출합니다.

  • 보안 그룹을 구성합니다. 모든 EFA 인스턴스는 자체적으로 송수신되는 모든 트래픽을 허용하는 자체 참조 규칙이 있는 동일한 보안 그룹에 있어야 합니다. 이렇게 하지 않으면 EFA 트래픽이 자동으로 실패합니다.

EFA 코로케이션을 통한 스팟 인스턴스 위험 이해

Amazon EC2 스팟 인스턴스는 훈련 워크로드에 상당한 비용 절감 효과를 제공합니다(GPUs의 일반적인 스팟 모범 사례는 이 섹션 참조). 그러나 EFA에서는 모든 통신 노드가 동일한 가용 영역에 있어야 하며 AWS에서는 최적의 지연 시간을 위해 클러스터 배치 그룹에 배치할 것을 권장합니다. 이 코로케이션은 상관관계가 있는 중단 위험을 초래합니다. 인스턴스는 동일한 AZ 내에서(그리고 배치 그룹 내에서도) 기본 물리적 인프라를 공유하므로 단일 용량 재생성 이벤트가 여러 인스턴스에 동시에 영향을 미칠 수 있으므로 단일 노드가 아닌 전체 다중 노드 훈련 작업을 한 번에 중단할 수 있습니다.

이는 노드를 AZs에 분산할 수 있고 중단이 통계적으로 독립적인 EFA 제약이 없는 스팟 사용과 근본적으로 다릅니다. EFA의 동일 AZ 요구 사항을 사용하면 단일 용량 이벤트가 훈련 클러스터에서 캐스케이드될 수 있습니다.

GPU 훈련 워크로드에 대한 비용 절감을 원하는 경우 스팟에 커밋하기 전에 사용 가능한 모든 구매 옵션을 평가했는지 확인하세요. ML용 예약 인스턴스, 온디맨드 용량 예약(ODCRs), Savings Plans 및 용량 블록은 모두 용량 가용성을 보장하면서 상당한 할인을 제공할 수 있으므로 EFA 코로케이션 제약이 있는 스팟에 내재된 상관관계가 있는 중단 위험을 방지할 수 있습니다.

대규모 GPU 인스턴스에서 IP 주소 소비 계획

기본적으로 Amazon VPC CNI 플러그인은 IP 주소를 미리 할당하여 포드를 신속하게 예약할 수 있도록 하고, 하나의 전체 예비 ENIIPs로 채웁니다. 대규모 인스턴스에서는 몇 개의 포드만 실행 중인 경우에도 노드당 수십 개의 IPs가 예약될 수 있습니다.

이러한 불일치는 노드당 포드 밀도가 낮은 훈련 및 추론 워크로드에서 흔히 발생합니다. 클러스터 규모에서, 특히 포드가 거의 없는 많은 GPU 노드를 가동하는 오토 스케일링 이벤트에서는 실제 IP 사용률이 낮더라도 서브넷 IP가 고갈될 수 있습니다.

이를 완화하려면 실제 포드 밀도에 맞게 WARM_IP_TARGETMINIMUM_IP_TARGET, 및 WARM_ENI_TARGET 변수를 조정합니다. VPC CNI의 ENI 및 IP 대상 설정에 대한 자세한 정보입니다.

IP 소비 최적화에 대한 전체 가이드는 IP 주소 사용률 최적화를 참조하세요.