AWS 고성능 컴퓨팅 네트워크, 1부: AWS가 제공하는 고속 네트워크 인터페이스, EFA(Elastic Fabric Adaptor)

고성능 컴퓨팅(HPC)에 관심 있는 고객분들을 위해 AWS 클라우드 환경에서 엔지니어링 시뮬레이션이나 분산 트레이닝을 수행할 때 거의 필수적으로 사용되는  고성능 컴퓨팅 네트워크 기술에 대해 알기쉽게 설명드리고자 합니다.

오늘은 첫 번째로 고속 네트워크 인터페이스인 Elastic Fabric Adapter에 대해 소개하고자 합니다.

오늘날의 인터커넥트 기술 현황

엔지니어링 시뮬레이션의 복잡도가 증가하고 처리해야할 데이터가 많아질수록 다수의 노드를 활용한 분산 처리는 필수가 되어가고 있으며 그 규모도 비약적으로 확대되고 있습니다. 일례로 약 10여년 전만 하더라도 ML 모델 트레이닝을 수행하기 위해서는 2개의 GPU만 있어도 충분했으나, 최근의 초거대 모델(LLM)을 트레이닝 하기 위해서는 약 10,000여개의 GPU가 필요하다고 합니다. 이렇게 분산 처리 환경을 구축하기 위해서는 다수의 서버 노드들을 연결하는 클러스터 구축이 필수이며, 클러스터를 구성하는 서버들을 연결하는 고속 네트워크 기술은 HPC 클러스터의 성능을 결정짓는 매우 중요한 요소입니다.

지난 2023년 11월 SC 컨퍼런스에서 발표된 Top500 자료를 살펴보면, 현재 슈퍼컴퓨터 환경에서는 다양한 인터커넥트(Interconnect) 기술이 활용되고 있습니다. 인터커넥트는 서버 간을 고속으로 연결하는 통신 기술을 의미합니다.특히 기가비트 이더넷(Gigabit Ethernet)과 인피니밴드(Infiniband) 기술이 시장을 주도하며 경쟁하고 있는 상황입니다.

그림1. Top 500 인터커넥트(Interconnect) 기술 채택 현황 (2023년 11월 기준)

TCP/IP 기반의 이더넷 기술은 기업용 환경 뿐만 아니라 가정용 환경에서도 가장 널리 사용되는 표준 기술로서, 비용 및 관리적인 측면에서 가장 선호되는 기술입니다. 단, 지연 측면에서 RDMA(Remote Direct Memory Access)를 이용하는 인피니밴드에 비해 5~6배 정도 불리하며, 안정성 관점에서 이더넷은 일정 수준의 패킷 손실을 가정합니다.

인피니밴드의 경우, RDMA를 이용하여 저지연성을 보장하기 때문에 상대적으로 높은 네트워크 성능을 제공합니다. 따라서 노드간 고대역의 네트워크 대역폭을 필수적으로 요구하는 HPC 환경에서 많이 선호되는 대표적인 인터커넥트 기술입니다. 다수의 엔터프라이즈 기업에서 현재 HPC 클러스터 환경을 인피니밴드로 구축하고 있습니다. NVIDIA에서 인피니밴드 전문 기업인 멜라녹스(Mellanox)를 2020년에 인수한 것도 컴퓨팅과 인터커넥트 기술의 고도화를 통해, 초고속 컴퓨팅 시장 점유율을 확장하려는 고도의 전략이 숨어있다고 볼 수 있습니다. 다만, 인피니밴드의 경우 HPC와 같은 매우 제한적인 컴퓨팅 환경에서 사용되므로, 관련 전문 인력 확보가 어렵고 구축을 위해서는 상대적으로 높은 비용이 요구됩니다. 기술적 난이도 또한 상대적으로 이더넷보다 높습니다.

만약, 온프레미스 환경에 구축된 HPC 클러스터를 AWS 클라우드 환경으로 이전을 고민 중이라면, 어떠한 기술로 노드간 네트워크 환경을 구성해야 할까요? 인피니밴드나 이더넷과 같은 고전적 인터커넥트 기술이 여전히 유효할까요? 지금부터는 이번 블로그를 통해, 이 질문에 대한 대답을 제공하려 합니다.

AWS가 제공하는 가상 서버(EC2 인스턴스) 간의 네트워크 인터페이스

우리가 사용하는 PC 또는 데이터센터에서 사용되는 서버에는 디바이스간 통신을 제공하기 위해 NIC(Network Interface Card)이라고 불리우는 네트워크 카드가 탑재되어 있습니다. 이와 유사하게 AWS 클라우드 환경에서는 일종의 가상 서버인 EC2 인스턴스 간의 통신을 위해 ENI(Elastic Network Interface)라고 불리우는 가상 네트워크 인터페이스가 제공됩니다. 현재 AWS에서는 약 750 여개가 넘는 다양한 형태의 EC2 인스턴스를 제공하고 있으며, 이들 개별 인스턴스는 타입에 따라 적게는 5Gbps에서, 많게는 최대 3200Gbps(p5 인스턴스)까지의 다양한 네트워크 대역폭을 지원하고 있습니다. 그림2는 컴퓨팅에 특화된 인스턴스인 c5 및 c6in 인스턴스 별로 제공되는 다양한 네트워크 대역폭의 예시를 보여주고 있습니다.

그림2 . EC2 인스턴스 별 제공되는 다양한 네트워크 대역폭

일반적으로 AWS에서는 10Gbps 이하의 네트워크 성능을 제공하는 인터페이스를 앞서 언급한 ENI라고 부르며, 그 이상의 네트워크 속도를 제공하는 인터페이스는 다시 ENA(Elastic Network Adaptor)와 EFA(Elastic Fabric Adaptor)로 세분하여 표현합니다. 테이블1에서 이 세가지 네트워크 인터페이스를 다양한 관점에서 정리하였습니다.

ENA는 ENI와 마찬가지고 TCP/IP 기반의 네트워크 인터페이스이나, 하나의 물리적 네트워크 디바이스를 여러 개의 가상 디바이스로 구현해 네트워크 속도를 높일 수 있는 단일 루트 I/O 가상화(SR-IOV) 기능을 제공하여 상대적으로 ENI에 비해 고속의 대역폭(최대 100Gbps)을 지원합니다. 따라서 ENA를 지원하는 EC2 인스턴스를 사용하여 HPC 클러스터도 구현도 기본적으로 가능합니다만, 초저지연의 고속 네트워크 구현이 요구되는 환경에서는 일반적으로 권장하지는 않습니다. 따라서 대량의 엔지니어링 시뮬레이션이나 Gen AI와 같은 ML 트레이닝 환경을 구축하기 위해 AWS 클라우드 환경에서 고성능의HPC 인프라 구축을 고민 중이시라면, EFA가 탑재된 인스턴스 사용을 추천 드립니다. 지금부터는 EFA가 무엇인지에 대해 좀 더 구체적으로 설명을 해보도록 하겠습니다.

AWS가 제공하는 고속의 네트워크 인터페이스, EFA

EFA는 AWS에서 자체 개발한 네트워크 프로토콜인 SRD(Scalable Reliable Datagram)를 탑재하여, 일반적으로 100Gbps 이상의 네트워크 대역폭을 제공하는 가상의 네트워크 인터페이스 입니다. EFA는 단일 루트 I/O 가상화와 같은 ENA에서 제공하는 모든 기능들을 계승하였으며, 이외에 추가적으로 OS 커널을 바이패스(bypass)할 수 있다는 특징이 있습니다. EFA를 사용하면 15us 이하의 일관된 네트워크 지연을 제공함으로써 고성능의 네트워크 성능을 보장합니다.

그림3. 전통적인 HPC SW스택과 EFA가 탑재된 AWS HPC SW 스택 비교

그렇다면 어떻게 EFA는 고성능을 제공할 수 있을까요? 이에 앞서 HPC 애플리케이션이 클러스터내의 노드간 통신하는 방법에 대해 알아보겠습니다. TCP/IP 기반의 전통적인 HPC 클러스터에서는 그림3의 왼쪽과 같이, 개별 노드들이 MPI(Message Passing Interface)를 통해 OS 커널 내의 TCP/IP 스택과 ENA 드라이버 모두를 거쳐 ENA 디바이스에 연결됩니다

그러나, EFA를 적용한 노드들로 클러스터를 구성할 경우, HPC SW 스택이 사뭇 달라집니다. 이 경우 그림3의 오른쪽과 같이, 노드간 통신을 위해 MPI가 libfabric과 통신하며 libfabric이 직접 EFA 디바이스와 연결되는 구조입니다. OS를 바이패스하여 TCP/IP 스택이 제거되었기 때문에, EFA는 ENA에 비해 월등히 높은 네트워크 성능을 제공할 수 있습니다. 최근에는 ML 분산 트레이닝에 HPC 인프라를 활용하는 추세인데, 이 경우에도 EFA를 적용할 경우 NCCL(NVIDIA Collective Communication Library)이 동일하게 libfabric과 직접 연결됨으로써 매우 높은 네트워크 대역폭을 확보할 수 있습니다.

참고로 libfabric이란 EFA 하드웨어에 엑세스 하기 위한 일종의 MPI 및 NCCL을 위한 통신 라이브러리입니다. libfabric이 제공되지 않는다면, MPI/NCLL 개발자는 그림 4와 같이 TCP, 인피니밴드, EFA와 같은 다양한 네트워크 디바이스를 고려해서 프로그램을 개발해야 합니다.

그림4. libfabric이 제공되지 않는 전통적인 HPC SW 스택

그러나, libfabric이 적용될 경우에는 그림5와 같이 MPI/NCCL은 통신을 위해 오직 libfabric만 고려해면 되기 때문에 개발자가 다양한 네트워크 디바이스에 대해 신경쓰지 않아도 된다는 장점이 존재합니다. 물론 이 경우 MPI와 네트워크 디바이스 사이에 레이어가 하나 더 추가된다는 단점이 존재하나, libfabric를 사용하면 OS 바이패스가 가능하기 때문에 단점을 충분히 상쇄한다고 볼 수 있습니다. AWS에서는 여러 네트워크 인터페이스 중 EFA만이 libfabric을 지원합니다.

그림5. EFA와 같이 libfabric이 제공되는 HPC SW 스택

대표적인 엔지니어링 시뮬레이션 워크로드 중에 하나인 CFD(Computational Fluid Dynamics) 해석을 통해, 실제적으로 EFA가 어느 정도의 성능을 제공할 수 있는지 알아보도록 하겠습니다. 그림6에서 확인할 수 있는 것처럼, 이상적으로는 클러스터내의 코어 수가 증가함에 따라 비례해서 클러스터의 성능이 늘어날 것으로 예상됩니다(붉은색). 노드(코어) 수의 증가에 따라 컴퓨팅 파워가 늘어나기 때문에 클러스터의 성능이 높아질 것으로 예상할 수 있습니다. 그러나 실제적으로는 코어 수가 증가할 수록 노드간 통신 역시 비례하여 증가하므로, 일정 수준 이상으로 코어수가 증가하면 오히려 클러스터 성능이 감소하는 것이 일반적입니다. 즉, 코어수의 증가로 인해 컴퓨팅 성능은 지속적으로 증가될 수 있으나, 네트워크에서 병목이 발생하기 때문입니다. 그림6의 보라색 라인이 바로 이것을 의미하며, EFA를 사용하지 않는 경우에 해당됩니다. 이에 비해 EFA를 사용하여 클러스터를 구현한 경우, 코어의 수가 지속적으로 증가하더라도 어느 정도 성능이 선형적으로 성능이 유지되는 것을 확인할 수 있습니다. 물론 EFA를 사용한다 하더라도 코어의 수가 무한정으로 증가한다면, 성능이 더 이상 비례하여 증가하지 않습니다.

그림6. 코어 수 증가에 따른 EFA 성능 평가

다양한 인스턴스에서 제공되는 EFA 인스턴스

AWS는 2024년 기준으로 약 120여 종류의 인스턴스에서 EFA를 지원하고 있습니다. 만약 여러분께서 CFD 해석을 위한 HPC 클러스터 구축이 필요하다면, 코어 성능에 특화된 ‘c’ 타입 인스턴스를 선택하면 좋습니다. 분산 트레이닝을 위한 HPC 클러스터가 필요하다면 GPU가 탑재된 ‘g’ 또는 ‘p’ 타입 인스턴스를 고려 할 수 있습니다. 또한 인텔, AMD 및 AWS 자체 개발 ARM 기반 그래비톤(Graviton) 프로세서 기반 인스턴스에서도 EFA를 지원하므로, 다양한 워크로드에 최적화된 고성능 네트워크 환경을 구축할 수 있습니다. 일부에서는 EFA가 100Gbps 이상의 네트워크만 지원한다고 알고 계시지만, 그렇지는 않습니다. 예를 들어 컴퓨팅 특화 c6i.32xlarge 인스턴스는 50Gbps 네트워크 속도를 제공하지만 EFA를 지원합니다.

그림7. EFA를 지원하는 EC2 인스턴스

만약 특정 리전에서 EFA가 탑재된 EC2 인스턴스 리스트를 확인하고자 한다면 다음의 명령을 사용할 수 있습니다.

aws ec2 describe-instance-types --region [리전명] \
    --filters Name=network-info.efa-supported,Values=true \
    --query "InstanceTypes[*].[InstanceType]" --output text | sort

그림8은 EC2 인스턴스에서 제공하는 네트워크 대역폭을 군집하여 보여주고 있습니다. 2024년 5월 현재 AWS에서는 최대 6400Gpbs의 네트워크 대역폭(trn2인스턴스, 예정)을 지원하고 있습니다. 그림8에서 보이는 네트워크 최적화 및 하이 스케일용 워크로드를 위한 인스턴스들에는 EFA가 탑재되어 있다고 보시면 됩니다. 특히, 하이 스케일용 워크로드를 위한 인스턴스들은 모두 400Gpbs이상의 네트워크 성능을 제공하고 있으며, 이 영역에 속하는 인스턴스들은 trn1, p5와 같이 모두 머신러닝 용으로 출시된 인스턴스들입니다. 여러분의 회사에서 사용하고 있는 온프레미스 환경의 네트워크 대역폭과 비교해 보신다면, AWS가 얼마나 고성능의 네트워크 대역폭에 진심인지 쉽게 판단 하실 수 있습니다.

그림8. EC2 인스턴스가 제공하는 네트워크 속도 변천사

EFA의 제약 사항

지금까지 EFA가 무엇이고 어떤 장점을 제공하는지 설명하였습니다. 그러나 EFA 사용에 있어 몇 가지 제약 사항이 있습니다. 첫번째로, EFA에서 제공하는 OS 바이패스 기능은 리눅스 OS에서만 지원 가능합니다. EFA를 지원하는 구체적인 리눅스 OS 버전은 다음의 링크를 참고하시기 바랍니다.

윈도우 OS를 사용하는 노드들에 EFA 인터페이스를 적용할 경우, 일반적인 IP 트래픽으로 동작합니다. EFA가 IP 통신과 같은 ENA에서 제공하는 모든 기능들을 계승하고 있다고 이미 언급드린 바 있습니다. 두번째로, OS 바이패스를 지원하는 EFA를 사용하는 트래픽은 AWS 내의 서브넷 간 전송이 불가능합니다. AWS에서는 기본적으로 EFA를 이용하여 HPC 클러스터를 구성하는 모든 노드들은 단일 서브넷에서 구성하게 됩니다. 따라서 기본적으로 두개의 인스턴스가 각기 다른 서브넷에 존재할 경우 OS 바이패스를 지원하는 EFA 통신이 불가합니다. 따라서 이러한 경우에는 EFA의 일반 IP 트래픽으로 동작하여 다른 서브넷 간에 통신이 가능합니다.

EFA 성능 평가를 통한 EFA가 제공하는 네트워크 속도 확인

마지막으로 EFA의 성능 평가를 통해, 실제 EFA가 Spec. 만큼의 성능을 제대로 내고 있는지 알아보도록 하겠습니다. 성능 평가를 위해서 다양한 방법이 있겠습니다만, 이 블로그에서는 OSU Bandwidth Benchmark를 사용하였습니다. 우선 클러스터를 손쉽게 생성하고 관리해 주는 AWS ParallelCluster를 사용하여, 두개의 c5n.18xlarge 노드로 구성된 클러스터를 생성하였습니다. 이 후 인텔 MPI를 이용하여 노드간 통신을 발생시켜 노드를 연결하고 있는 네트워크를 포화 시킴으로써, 실제 c5n.18xlarge 노드에서 어느 정도의 네트워크 속도를 확보할 수 있을지 확인하였습니다.

테스트 결과는 그림9와 같습니다. 메시지의 사이즈가 증가할 수록 네트워크 스루풋(throughput, 그림 중간)이 비례하여 증가하는 것을 확인할 수 있습니다. 그러나 메시지 사이즈가 4K(4096) 이상이 되면 스루풋이 거의 포화 상태에 이르며, 메시지 사이즈가 8K 이상이 되면 스루풋은 더 이상 증가하지 않고 약 122,00MB/s를 유지하는 것을 확인할 수 있습니다. 이것을 GB/s로 환산하면 약 98Gb/s 로 치환되며, 공표한 100Gbps에 거의 근접한 성능을 제공하는 것을 확인할 수 있습니다.

그림9. C5n.18xlarge 인스턴스를 사용한 EFA 벤치마크 결과

맺음말

이번 블로그에서는 AWS에서 제공하는 고성능 네트워크 인터페이스인 EFA에 대해 소개하였습니다. 요약해서 정리하자면, 여러분께서 AWS 클라우드 환경에서 엔지니어링 시뮬레이션이나 분산 트레이닝을 위한 HPC 환경을 고민 중이시라면, 네트워크 관점에서 EFA는 필수적으로 고려해야 합니다. 만약 EFA를 처음 시작해보고자 한다면, 다음의 링크를 참고하실 것을 추천 드립니다.

EFA는 SRD라는 프로토콜을 탑재함으로써 온프레미스 환경에서의 기가비트 이더넷이나 인피니밴드와 같은 고성능의 네트워크 대역폭을 보장합니다. 그렇다면 SRD 프로토콜은 무엇이고 어떻게 고성능을 제공할 수 있는지 궁금하지 않으신가요? 다음의 추가 자료 영역에서 EFA를 구성하는 핵심 프로토콜인 SRD를 중심으로 EFA에 대해 보다 다양한 관점에서 소개하고 있습니다. 많은 참고 부탁 드립니다.

추가 자료
AWS 고성능 컴퓨팅 네크워크 시리즈의 다른 블로그 글

• AWS가 제공하는 고성능 네트워크 프로토콜, SRD(Scalable Reliable Datagram)