[ ENI ]
- 앱이 메시지를 보내면 커널 TCP/IP 스택을 거치고, 하이퍼바이저를 거쳐서, Physical NIC에
도달함. 모든 레이어를 전부 통과하는 가장 기본적인 ㅂ아식
[ ENA ]
- 이건 "NitroCard for VPC"에 해당하는 얘기
- 앱이 메시지를 보내면 커널 TCP/IP 스택을 거치지만, SR-IOV가 만든 VF를 통해 하이퍼바이저를
건너뛰고 DMA로 Physical NIC 메모리에 직접 접근
- MPI를 써도 전송 경로는 TCPI/IP 기반으로 커널은 반드시 거침
[ EFA ]
- 앱이 MPI로 메시지를 전송하면 Libfabric이 커널 네트워크 스택을 건너뛰고, TCP/IP 대신 SRD
프로토콜로 SR-IOV VF를 통해 DMA로 Physical NIC에 직접 접근
- 하이퍼바이저도 커널도 안거치고 프로토콜까지 경량화 된게 EFA
EFA Detail
[ 흐름 ]
App → MPI (통신 API)
→ Libfabric (커널 우회해서 NIC 직접 제어)
→ SRD 프로토콜 (TCP/IP 대체, 경량 전송)
→ SR-IOV VF + DMA → Physical NIC
[ 설명 ]
- MPI
- 앱이 쓰는 통신 API "이 데이터를 저 노드로 보내"
- Libfabric
- MPI 밑에서 커널 네트워크 스택을 우회하고 NIC에 직접 명령을 내리는 프레임워크
- OS bypass의 핵심
- SRD
- TPC/IP 대신 쓰는 경량 프로토콜, "핸드셰이크 없고 멀티패스 지원"
- DMA
- NIC이 CPU 안 거치고 메모리에 직접 접근
[ SRD 사용 위치 ]
노드A 네트워크 노드B
App → MPI → Libfabric → VF → NIC ──── SRD로 전송 ────→ NIC → VF → Libfabric → MPI → App
↑ 여기서 SRD
EC2 인스턴스에 제공되는 다양한 네트워크 대역폭
[ 설명 ]
- 우리가 흔히 사용하는 PC 또는 데이터센터에서 사용되는 서버에는 디바이스간 통신을 제공하기
위해 "NIC(Network Interface Card)"가 탑재되어 있음
- 이와 유사하게 AWS에서 EC2 인스턴스 간의 통신을 위해 "ENI(Elastic Network Interface)라고 불리는 가상 네트워크 인터페이스"가 존재
- 일반적으로 AWS에서는 10Gbps 이하의 성능을 가지면 ENI라고 부르고, 그 이상의 네트워크 속도를
제공하는 인터페이스는 "ENA(Elastic Network Adaptor)와 EFA(Elastic Fabric Adaptor)"로
세분하여 표현
[ 설명 ]
- ENA는 ENI와 마찬가지로 "TCP/IP 기반의 네트워크 인터페이스"이나, 하나의 물리적 네트워크
디바이스를 "여러 개의 가상 디바이스로 구현해" 네트워크 속도를 높일 수 있는 "단일 루트 I/O 가상화(SR-IOV)" 기능을 제공하여 상대적으로 ENI에 비해 고속 대역폭(최대 100Gbps)을 지원
- ENA를 지원하는 EC2 인스턴스를 사용하여 HPC 클러스터도 구현도 기본적으로 가능하다만,
초저지연의 고속 네트워크 구현이 요규되는 환경에서는 일반적으로 "권장되지 않음"
- 만약 AI/ML 환경을 구축하기 위해서라면 "EFA가 탑재된 인스턴스 사용을 추천"
[ 추가. ENA가 빠른 이유 ]
- SR-IOV가 ENA를 빠르게 만드는 이유는, 패킷이 TCP/IP 커널 스택을 거치더라도, 그 이후의
가상화 네트워크 경로를 소프트웨어 에뮬레이션 대신 NIC의 VF와 DMA 기반 하드웨어 경로로
처리해서 중간 오버헤드를 크게 줄이기 때문
=> 즉, 가상화 때문에 "중간 소프트웨어 경로를 많이 줄여줌"
DMA로 게스트 "메모리의 패킷 버퍼를 직접 읽고/써서"
[ SR-IOV 유무 통신 차이 ]
없을시
------
앱
→ 게스트 OS TCP/IP
→ 가상 NIC 드라이버
→ 하이퍼바이저의 가상 스위치/에뮬레이션 계층
→ 호스트 NIC 드라이버
→ 물리 NIC
→ 네트워크
있을시
------
앱
→ 게스트 OS TCP/IP
→ 게스트 ENA 드라이버
→ VF의 TX/RX 큐
→ NIC/Nitro 하드웨어가 DMA로 게스트 메모리 접근
→ 네트워크
=> 가상화 계층이 줄어
[ 추가. ENA 통신 방식 ]
- ENA는 "EC2가 패킷을 보내고 받을 때 그 네트워크 I/O 경로를 더 빠르게 처리해주는 고성능 네트워크 어댑터/드라이버"
=> 즉 본질은 "패킷 처리 성능 가속"
- 그래서 "EC2 <-> EC2", "EC2 <-> 인터넷" 통신에서 사용
왼쪽. ENA 기반 HPA 오른쪽. EFA 기반 HPA
[ 설명 ]
- EFA는 AWS에서 자체 개발한 네트워크 프로토콜인 "SRD(Scalable Reliable Datagrame)"를
탑재하여, 일반적으로 100Gbps 이상의 네트워크 대역폭을 제공하는 가상의 네트워크 인터페이스
- EFA는 "단일 루트 I/O 가상화와 같은 ENA에서 제공하는 기능들을 계승했으며", 이외의 추가로
"OS 커널을 bypass"가 가능하다는 특징이 존재
[ 어떻게 EFA는 고성능을 제공할까? ]
- 기존 HPA 애플리케이션이 클러스터 내의 노드간 통신하는 방법은 왼쪽에 보다시피, 개별 노드들이
"MPI(Message Passing Interface)를 통해 OS 커널 내의 TCP/IP 스택과 ENA 드라이버 모두를 거쳐 ENA 드라이스에 연결"
- 그러나 EFA를 적용한 노드들로 클러스터를 구성할 경우, "MPI가 libfabic과 통신하며 직접 EFA 디바이스에 연결되는 구조"
- 이 구조로 인하여 OS를 bypass하여 "TCP/IP 스택이 제거"되었기 때문에 더 높은 네트워크 성능을
제공