AWS 기술 블로그
AWS 고성능 컴퓨팅 네트워크, 2부: AWS가 제공하는 고성능 네트워크 프로토콜, SRD(Scalable Reliable Datagram)
지난 블로그에서는 AWS에서 제공하는 고속 네트워크 인터페이스인 EFA(Elastic Fabric Adaptor)에 대해 설명하였습니다. 또한 EFA에는 SRD(Scalable Reliable Datagram)라는 프로토콜이 탑재되어 있다고 소개하였습니다. 이번 블로그에서는 SRD란 무엇인지에 대해 좀 더 구체적으로 설명드리겠습니다.
일반적인 데이터센터의 네트워크 토폴로지 vs AWS 데이터센터 네트워크 토폴로지
본격적인 SRD 프로토콜에 대한 소개에 앞서, 일반적인 데이터센터의 네트워크 환경에 대해 알아보도록 하겠습니다. 전형적인 온프레미스 환경의 데이터센터 네트워크는 그림1과 같이 오버서브스크립션(oversubscription) 형태를 지니고 있습니다. 즉 맨 하단의 서버로부터 발생하는 트래픽이 상위 계층의 네트워크 장비를 통해 수용되는 방식입니다. 트래픽이 많이 몰릴수록 상위 계층에서 부담이 가중되며, 패킷 손실이나 딜레이와 같은 문제가 발생할 수 있습니다.
<그림1. 전통적 데이터센터의 네트워크 토폴로지>
이러한 문제점을 탈피하고자 AWS의 데이터센터 네트워크는 그림2와 같이, 이러한 전통적 방식이 아닌 수평적 구조를 가지는 ‘densely connected multipath’ 방식을 선택하였습니다. 이러한 방식은 보다 수평적이기 때문에 오버서브스크립션이 상대적으로 적으며, 서버 간 상대적으로 많은 네트워크 경로를 확보할 수 있다는 장점이 존재합니다.
<그림2. AWS 데이터센터 네트워크 토폴로지>
그러나 문제는, TCP와 같은 전통적인 네트워크 프로토콜은 이와 같은 새로운 네트워크의 장점을 완전히 이용하지 못하도록 설계되어 있다는 점입니다.
AWS 데이터센터에 최적화된 네트워크 프로토콜, SRD(Scalable Reliable Datagram)
TCP(Transmission Control Protocol)는 1972년에 세상에 처음 공개되어 50년이 넘은 네트워크 프로토콜로서, 일반 인터넷뿐만 아니라 온프레미스 데이터센터에서도 사용되는 업계의 실질적인 표준(defacto) 프로토콜입니다. TCP의 장점은 프로그램이 쉬울 뿐 아니라, 이미 성능 면에서도 검증이 완료된 프로토콜입니다. TCP의 명제는 간단합니다. 바로 패킷이 순서대로 도착하는 것을 보장하도록 설계되어 있습니다. 이러한 목표를 달성하기 위해 그림3과 같이 데이터 소스와 목적지 간에 여러 경로가 존재함에도 불구하고 5 tuple(Source IP, Destination IP, Protocol No, Source Port, Destination Port) 정보를 이용하여 하나의 경로만을 선택하여 데이터를 전송하게 됩니다. 이렇게 되면 데이터가 목적지에 in-order 방식으로 전달되기는 하나, 소스와 목적지 간에 여러 경로가 존재하더라도 사용할 수 없습니다. 당연히 성능적인 관점에서 비효율이 발생하며, 경로에 문제가 생기거나 트래픽이 몰리더라도 우회하기가 어렵습니다. 예를 들어, 집에서 부산역까지 가는데 무조건 하나의 경로만을 사용해서 갈 수 있는 상황이라고 생각해 볼 수 있습니다.
<그림3. TCP/IP 프로토콜을 사용한 전통적인 트래픽 전송 경로 >
SRD는, 기존의 TCP의 한계점을 극복하기 위해 AWS에서 자체 개발한 클라우드 데이터센터 전용 네트워크 프로토콜입니다. SRD는 TCP와 같은 기존 프로토콜 대비 다음과 같은 3가지 장점을 제공합니다.
우선 SRD는 그림4와 같이 ECMP(Equal Cost Multi-Path) 알고리즘을 통해 멀티패스를 기본적으로 사용하기 때문에 네트워크 스루풋(throughput)을 증가시킬 수 있으며, 전송 경로에 문제가 발생하더라도 다른 경로로 우회가 가능합니다. 단 이러한 경우에 전송되는 패킷들이 서로 다른 경로를 통해 전달되기 때문에 도착지에서 순서를 보장할 수 없습니다. 그래서 목적지에서 수신되는 패킷을 in order로 바꾸는 기능을 SRD에서 제공하고 있습니다.
<그림4. SRD 프로토콜을 사용한 트래픽 전송경로 >
또한 SRD는 AWS 클라우드 데이터센터에 최적화된 전용 프로토콜이므로, AWS 데이터센터 내에서 패킷이 드랍(drop) 되거나 지연이 발생할 경우, 범용 프로토콜인 TCP보다 훨씬 빠르게 감지할 수 있습니다. 보통 SRD는 문제가 발생한 경우 패킷을 재전송하는데 마이크로 세컨드(microsecond)의 시간대가 소요됩니다. TCP의 경우 밀리 세컨드(millisecond) 대의 시간이 필요한 것으로 알려져 있습니다.
마지막 SRD의 장점은, TCP는 OS 스택에서 동작하지만 SRD는 AWS의 차세대 EC2 인스턴스의 기본 플랫폼인 나이트로(nitro) 컨트롤러에서 동작하기 때문에, OS를 바이패스 할 수 있다는 장점이 있다는 점입니다. 관련된 자세한 내용은 지난 블로그에서 언급한 바 있습니다.
따라서 SRD는 성능이 매우 우선시 되는 HPC 및 머신러닝 트레이닝에 특화된 인스턴스(p5, g4dn, hpc7g, hpc7a 등)의 EFA 인터페이스에서 사용되고 있습니다. 참고로 이러한 인스턴스들은 대부분 100Gbps 이상의 속도를 낼 수 있으며, 200Gbps이상의 속도를 내는 인스턴스들은 100Gbps를 제공하는 EFA를 여러 개 묶어서 제공한다고 이해하시면 됩니다. 하나의 EC2 인스턴스에서는 그림5와 같이 여러 개의 네트워크 카드가 지원되며, 하나의 네트워크 카드당 최대 한 개의 EFA가 할당됩니다. 예를 들어, 그림5와 같이 3200Gbps의 네트워크 대역폭을 제공하는 GPU가 탑재된 p5.48xlarge 인스턴스의 경우, 32개의 네트워크 카드를 제공합니다.
<그림5. EC2 인스턴스 유형에 따른 네트워크 카드 개수 >
TCP, 인피니밴드(Infiniband), SRD 비교
앞서 TCP/IP 기반의 온프레미스 데이터센터 네트워크의 제약 사항에 대해 언급하였습니다. 이를 개선하기 위해 발전된 인터커넥트(interconnect) 기술이 바로 앞선 블로그에서도 소개한 인피니밴드(Infiniband)입니다. 인피니밴드는 이미 소개한 것처럼 RDMA(Remote Direct Memory Access) 기술을 사용하여, 매우 낮은 저지연성을 보장합니다. 그러나 인피니밴드 역시 트래픽 전송을 위해 기본적으로 단일 경로(single path)만을 사용하기 때문에, AWS 클라우드 데이터센터의 네트워크 토폴로지에는 적합하지 않습니다. 그림6에서, 기존의 데이터센터에서 사용되는 대표적인 인터커넥터 기술인 1) TCP 및 2) 인피니밴드와 3) SRD와의 차이점에 대해 설명하고 있습니다.
<그림6. TCP, 인피니밴드, SRD의 차이점>
SRD 프로토콜을 ENA 인터페이스에도 적용한 ENA Express
SRD 프로토콜은 그동안 고성능의 네트워크 대역폭을 제공해야 하는 EFA에만 한정적으로 적용되었으나, 다양한 네트워크 환경에 고성능을 보장하기 위해 ENA(Elastic Network Adaptor) 및 EBS(Elastic Block Storage) 네트워크에도 적용을 확대하기 시작하였습니다.
ENA Express는 ENA에 SRD 프로토콜이 적용된 일종의 변종 네트워크 인터페이스입니다. ENA Express는 다음과 같은 장점들을 가지고 있습니다.
- 단일 서브넷 내에서 하나의 트래픽 플로우의 최대 네트워크 대역폭이 기존 5Gbps에서 25Gbps로 확대됩니다.
- 혼잡한 네트워크 경로를 감지하고 회피합니다.
- 네트워크 부하가 높은 기간 동안, 네트워크 트래픽의 테일(tail) 지연 시간을 감소시킬 수 있습니다.
ENA Express를 사용하기 위해서는, 트래픽을 송신 및 수신하는 2개의 EC2 인스턴스 모두에 ENA Express가 활성화 되어야 합니다. 만약 2개의 EC2 인스턴스에서 하나라도 설정이 되어 있지 않다면, 2개의 노드 간 송수신은 SRD 없이 표준 ENA를 사용하게 됩니다. EFA와는 약간 다르게, ENA Express는 송수신 인스턴스 모두 동일한 가용 영역에 있다면 동작이 가능합니다. EFA의 경우에는 송수신 인스턴스 모두 동일한 서브넷에서 구성되어야 했습니다.
현재 AWS에서는 다양한 EC2 인스턴스에서 ENA Express를 제공하고 있으며 모든 AWS 상용 리전에서 추가 비용 없이 사용 가능합니다. 어떤 EC2 인스턴스에서 ENA Express를 제공하고 있는지, 그리고 ENA Express를 설정하는 방법에 대해 확인하려면 다음 링크를 참고하시기 바랍니다.
또한 ENA Express를 이용한 실제 활용 사례들은 다음의 테크 블로그를 통해 확인할 수 있습니다.
EBS에 SRD를 적용한 EBS Block Express
개별 EC2 인스턴스는 블록 스토리지인 EBS와 별도의 네트워크로 연결되어 있습니다. 이러한 EBS 네트워크 대역폭 역시 EC2 인스턴스마다 서로 다릅니다. 일반적으로 EC2 인스턴스의 사이즈가 클수록 EBS 대역폭 역시 비례하게 됩니다. 그림 7에서는 엔지니어링 시뮬레이션의 대표적인 워크로드인 CFD(Computational Fluid Dynamics) 해석에 많이 사용되는, c5n 인스턴스의 스펙을 보여주고 있습니다. 그림에서 볼 수 있는 것처럼, EBS 대역폭이 일반 네트워크 대역폭에 비해 상대적으로 적은 것을 확인할 수 있습니다.
<그림7. c5n 인스턴스 스펙>
이러한 EBS 네트워크의 성능을 향상시키기 위하여 EBS에 SRD를 적용하였으며, SRD가 적용된 블록 스토리지 아키텍처를 EBS Block Express라고 부릅니다. 현재 EBS Block Express는 Provisioned IOPS SSD 중 하나인 io2에 적용(io2 Block Express)되어 있습니다.
이러한 EBS 네트워크에 SRD 프로토콜을 적용하게 되면, 앞서 언급한 꼬리 지연(tail latency)이 최대 90%까지 개선됩니다. 여기서 응답 시간 관점에서 평균 지연이 아닌, 꼬리 지연을 언급한 이유는, 사용자 경험 때문에 그렇습니다. 예를 들어, 꼬리 지연이 99.9 퍼센타일(percentile)이라고 하는 것은 쓰기(읽기) 요청 1000건 중 가장 느린 1건으로 측정되는데, 그림8에서 일반적인 EBS 볼륨의 경우 가장 느린 1건이 5ms 정도 걸린다는 의미입니다. 그림8에서 볼 수 있는 것처럼, EBS 시스템에 SRD 적용 후에 모든 사용자의 쓰기 지연 경험이 99.9 퍼센타일에서 5ms 훨씬 이하이며, 이러한 값이 거의 일정하게 유지됨을 확인할 수 있습니다. 특히 99.999 퍼센타일에서는 그 값이 EBS Block Express 적용 전과 매우 큰 차이를 보이게 됩니다. 물론 일반 스루풋(throughput)도 SRD 적용을 통해 4배나 개선시켰습니다.
<그림8. SRD 적용 후 EBS 쓰기 지연과 관련된 꼬리 지연 개선. Re:Invent 2022의 AWS SVP Peter DeSantis 키노트에서 발췌>
그림9는 SSD 기반의 EBS 볼륨의 여러 타입을 보여주고 있습니다. 이 중에서도 Provisioned IOPS 볼륨인 io2에 EBS Block Express가 적용된 io2 block Express를 주목하시길 바랍니다. 동일 Provisioned IOPS 볼륨인 io1에 비해 약 4배 정도 스루풋이 높은 것을 확인할 수 있습니다.
<그림9. SSD 기반의 EBS 볼륨 타입>
맺음말
이 블로그에서는 EFA에 탑재되어, 고성능을 보장하는 AWS 자체 네트워크 프로토콜인 SRD에 대해 알아보았습니다. SRD의 등장 배경 및 SRD가 제공하는 3가지 장점에 대해서는 꼭 기억하시길 바랍니다. 기존에는 SRD가 EFA에만 탑재되어 엔지니어링 시뮬레이션이나 분산 트레이닝에 많은 도움을 주었으나, 최근에는 ENA나 EBS 네트워크에도 확산 적용되어 일반적인 워크로드의 성능 개선에 도움을 주고 있습니다. 따라서 일반적인 워크로드에서도 ENA Express나, io2 Block Express를 적용할 경우, 매우 좋은 사용자 경험을 제공할 수 있기 때문에 적극적으로 검토해 보실 것을 추천드립니다.
이번 블로그에서는 가급적 SRD에 대해 쉽게 설명하기 위해, 자세한 기술적 내용은 언급하지 않았습니다. SRD 및 EFA에 대해 깊이 있는 이해가 필요하신 분들은 AWS의 Annapruna labs에서 발표한 다음의 논문을 참고하시기 바랍니다.