RoCEv2를 이용한 로스리스(Lossless) 네트워크 검증 ~ 3. 동작 확인 편 ~

본 기사는 총 세 회에 걸쳐 전달해 드리고 있는, RoCEv2를 이용한 실기 검증 시리즈의 세 번째 기사입니다.

두 번째였던 지난 기사에서는, Ethernet 상에 로스리스(Lossless) 네트워크를 구축하기 위한 전제가 되는 네트워크 측(Cisco Nexus)의 구체적인 기능에 대해 흐름을 따라 해설했습니다.

본 시리즈의 최종회인 이번 기사에서는, 실제로 패킷 제네레이터(Packet Generator)를 사용하여 RoCEv2 트래픽을 생성하고, 지난 기사에서 다루었던 각종 설정(QoS/부하 분산)의 동작에 대해 자세히 확인해 보겠습니다.

Switch

Leaf：Cisco Nexus 9364C-GX ×2

Spine：Cisco Nexus C9316D-GX ×2

Leaf-Spine에 의한 Fabric 구성을 채택하였으며, Leaf-Spine 간은 OSPF에 의한 ECMP(Equal-Cost Multi-Path)를 사용하여 접속.

Server

・Cisco UCS C240 M7SX ×2

・OS：Ubuntu 22.04 LTS

각 서버에는 RoCEv2 대응 NIC를 4포트 탑재하여, 100GbE ×4로 Leaf 스위치에 접속.

RoCEv2 대응 NIC

・NVIDIA Mellanox ConnectX-5

RoCEv2에 의한 RDMA 통신을 수행하며, PFC 및 ECN/DCQCN에 의한 혼잡 제어(Congestion Control)를 실시.

(※ 이번 검증에서는 후술할 트래픽 제네레이터를 사용하여 RDMA 트래픽을 생성합니다. 이 제네레이터와 상기 NIC를 연계함으로써, 실제로 GPU를 사용하지 않고도 RoCEv2 트래픽을 생성할 수 있습니다.)

Keysight AI Data Center Builder

RDMA 트래픽을 생성하기 위한 트래픽 제네레이터로서, Keysight사가 제공하는 「AI Data Center Builder(이후, Builder라고 기재)」를 사용합니다.

이 솔루션은 GPU 간에 발생하는 대량의 RoCEv2 트래픽을 모의 재현하여, 대역폭·지연(Latency)·혼잡 상황을 계측할 수 있습니다.

이를 활용함으로써 AI 데이터 센터 네트워크 상의 병목(Bottleneck)을 가시화하고, 최적의 네트워크 설계를 지원하는 것이 가능해집니다.

본 솔루션에는 하드웨어 버전과 소프트웨어 버전이 있지만, 이번에는 소프트웨어 버전을 Ubuntu 서버 상에 설치하여 RoCEv2 테스트 트래픽을 생성합니다.

(참고) Builder의 내부 컴포넌트(Component)

1. DFE Software (데이터 플레인 (Data Plane))

• NIC와 연계하여 RoCEv2 트래픽을 생성하는 역할을 담당.

2. DSE Controller (컨트롤 플레인 (Control Plane))

• Docker 컨테이너 상에서 동작하며, 시뮬레이션에 관한 설정 및 테스트 결과 관리를 수행.

3. License Server (라이선스 관리)

• KVM 또는 VMware 상에서 동작하며, 라이선스 관리를 담당.

(이번에는 가상 환경으로서 KVM을 사용)

※ 1은 상술한 서버 두 대 각각에 설치

※ 2와 3은 트래픽을 흘리는 서버와는 별도로 서버를 한 대 준비(Cisco UCS C220 M6)하여 설치. 1의 DFE Software 측과 주고받음으로써 각종 필요한 정보의 교환을 수행.

※ (참고) Keysight사 「AI Data Center Builder」 공식 URL

☆본 기사에 등장하는 "Rank"라는 개념에 대하여

Rank란 분산 처리에서 사용하는 논리적인 ID를 말하며, 분산 처리 소프트웨어가 통신을 제어할 때 「누가 어떤 상대와 통신할 것인가」 또는 「어떤 데이터를 주고받을 것인가」 등을 제어하기 위해 사용됩니다.

본 검증에서는 GPU끼리의 그래디언트(Gradient) 데이터 주고받기를 시뮬레이션하기 위해 이 개념을 사용합니다. 이번 환경에서는 Rank와 GPU(및 NIC)가 일대일로 대응하도록 설정되어 있습니다.

이번에는 다음과 같은 흐름으로 검증을 실시합니다.

RoCEv2 트래픽을 위해 설정한 각종 QoS 기능이 상정대로 동작하는지 확인합니다.

1. DCQCN의 동작 확인

구체적으로는 지난 기사에서 설명한 일련의 동작(스위치 측에서 ECN이 발행되고, 이를 받은 서버 측 NIC가 CNP 패킷을 송신하는 흐름)을 관찰합니다.

2. PFC 설정 ON/OFF에 따른 패킷 로스(Packet Loss) 발생 여부 관찰

PFC의 유효/무효를 전환하면서, RoCEv2 통신에서의 패킷 로스 발생 상황을 확인합니다.

※ 참고로, 본 효과 측정 시의 로드 밸런싱 (Load Balance) 기법은 Flowlet DLB로 고정하여 실시합니다.

이번에는 로드 밸런싱 (Load Balance) 기법으로 아래 4가지를 사용하여, 각각의 동작 및 통신 효율을 비교합니다.

・5-tuple ECMP

・Flowlet DLB

・Per Packet DLB

・Static Pinning

※ 참고로, 이 검증에서는 PFC/ECN을 상시 활성화한 상태에서 실시합니다.

로드 밸런싱 (Load Balance) 성능 측정 지표

각 로드 밸런싱 (Load Balance) 기법의 성능 비교에는 CV (Coefficient of Variation: 변동 계수)를 사용합니다.

CV는 "각 링크로 트래픽을 얼마나 균등하게 분산시켰는가"를 정량적으로 평가하기 위한 지표입니다.

본 검증에서는 각 Leaf-Spine 간 링크에서의 송신 바이트 수 (Tx Bytes)를 취득하여, 아래를 계산합니다.

・평균

・표준 편차

그 후, 아래 식을 통해 CV를 산출합니다.

・CV = 표준 편차 ÷ 평균

CV는 값이 작을수록 각 링크로 트래픽이 균등하게 분산되어 있음을 의미합니다.

즉, CV가 0에 가까울수록 이상적인 로드 밸런싱 (Load Balance) 상태라고 할 수 있습니다.

(예시 1) 균등하게 분산되어 있는 경우

Link1: 25 GB

Link2: 25 GB

Link3: 25 GB

Link4: 25 GB

이 경우, 각 링크로 통신이 균등하게 분산되어 있기 때문에 표준 편차는 0이 되며, CV도 0이 됩니다.

(예시 2) 편중이 있는 경우

반면, 아래와 같이 통신량에 편중이 있는 경우에는 CV가 커집니다.

Link1: 70 GB

Link2: 20 GB

Link3: 5 GB

Link4: 5 GB

본 검증에서는 각 Leaf-Spine 간 링크의 Tx Byte 수를 취득하고, 그 분산 정도를 CV로 비교함으로써 각 로드 밸런싱 (Load Balance) 기법이 어느 정도 균등하게 Fabric 전체로 트래픽을 분산시키고 있는지를 평가합니다.

이번에 사용하는 트래픽 제네레이터 (Traffic Generator)에서는 다양한 파라미터를 지정할 수 있도록 되어 있으며, 본 검증에서는 아래 항목들을 GUI 상에서 설정하였습니다.

트래픽 패턴: Ring All Reduce

NCCL 기반의 AI 학습 환경에서 대표적으로 사용되는 통신 패턴입니다.

(Ring All Reduce 통신의 특징에 대해서는 첫 번째 기사에서 해설)

1회 테스트 시 흘려보내는 총 트래픽 양: 1.56 TB

본 검증에서는 1회 테스트 시 약 1.56TB 상당의 통신을 Fabric 내부로 흘려보내고 있습니다.

이는 단일 플로우 (Flow)의 통신량이 아니라, All Reduce 통신 전체로서 Fabric 내부를 흐르는 총 통신량을 나타냅니다.

RDMA Message Size: 32 MB

RDMA Message Size는 1회의 RDMA 통신에서 전송되는 데이터 덩어리 (Chunk)의 크기를 나타냅니다.

이번에 지정한 32MB라는 사이즈는 딥러닝 (Deep Learning)에서의 그래디언트 동기화 (Gradient Synchronization) 문맥에서, 비교적 큰 데이터 청크 (Chunk)를 효율적으로 전송하기 위해 일반적으로 사용되는 사이즈의 한 예입니다.

QP (Queue Pair) 수: 1

QP (Queue Pair)는 RDMA 통신에서의 통신 단위입니다.

RoCEv2에서는 기본적으로 "1개의 QP = 1개의 RDMA 플로우 (Flow)"로 생각할 수 있습니다.

이번에는 QP 수를 1개로 설정했기 때문에, ECMP 해시 계산에 사용되는 정보의 변동성이 적어 특정 링크로 통신이 쏠리기 쉬운 조건입니다.

따라서 각 로드 밸런싱 (Load Balancing) 기법에 따른 차이가 비교적 잘 나타나기 쉬운 구성이라고 판단됩니다.

ECN/PFC 각각의 설정 유무를 변경하면서 트래픽의 거동을 측정한 결과를 정리한 것이 아래 그림입니다.

먼저, DCQCN/PFC가 기대한 대로 동작하는지 확인하기 위해, ECN/PFC를 모두 ON으로 한 상태 (빨간색 테두리)의 결과를 살펴보겠습니다.

그림 중 Drop (Rx pkts) 열을 확인하면, Drop=0으로 되어 있는 것을 알 수 있습니다.

또한, 그 아래 행 (Test number=2), 즉 ECN을 비활성화하고 PFC만 ON으로 한 경우에도 Drop=0임을 확인할 수 있습니다.

즉, PFC가 활성화되어 있는 경우에는 로스리스 (Lossless) 통신을 구현할 수 있음을 알 수 있습니다.

이 결과는 지난 기사에서 해설한 PFC의 역할과 일치하며, 기대한 대로 동작하고 있음을 확인했습니다.

☆PFC가 OFF인 경우

PFC가 OFF인 경우, ECN의 ON/OFF 여부와 관계없이 Server 측과 Nexus 측 양쪽 모두에서 패킷 드롭 (Packet Drop)이 관측되었습니다.

한편 자세히 살펴보면, ECN이 ON인 경우에는 ECN을 OFF로 설정했을 때와 비교하여 드롭(Drop) 수가 비교적 억제되어 있음을 확인할 수 있습니다.

이는 DCQCN의 메커니즘에 의해 Server 측 NIC가 RDMA 트래픽 송출 시의 레이트(Rate)를 제어하고, 그 결과로 스위치 측 버퍼의 압박 정도를 일정 수준 완화할 수 있기 때문이라고 생각됩니다.

・작업 완료 시간 (JCT=Job Completion Time) 관점

작업 완료 시간 (JCT) 관점에서는, ECN/PFC를 모두 무효화했을 때 JCT가 가장 길게(약 412초) 나타났습니다.

다만, PFC/ECN을 모두 활성화했을 경우(약 386초)와 비교하면, 이번 검증에서는 극적인 차이가 발생하고 있지는 않은 것으로 보입니다.

이 결과에는 다양한 요인이 관계되어 있다고 생각되지만, 예를 들어 테스트 시의 총 트래픽 양이나 All-Reduce 통신에 참여하는 GPU 수를 증가시켰을 경우, 패킷 드롭 (Packet Drop)에 의한 영향은 더욱 현저해지며 결과적으로 JCT에 미치는 영향도 커질 가능성이 있다고 보고 있습니다.

(DCQCN의 동작 플로우에 대해서는 이전 기사에서 해설)

ECN/PFC를 모두 ON으로 설정한 경우 (Test number=1)에 대해, DCQCN이 실제로 동작하는 모습을 따라가 보겠습니다.

・show queuing interface ethernet 1/49 (Leaf2의 Spine2향 출력 포트)

Server-2 측으로부터 수신한 RoCEv2 트래픽을 Leaf2가 Spine-2 측으로 전송할 때, Spine-2향 출력 큐(Output Queue)에서 ECN이 발동하여 데이터 패킷에 CE 마크가 부여되고 있는 모습입니다.

즉, Spine-2향 출력 버퍼의 혼잡(Congestion) 상황이 일정 임계값(Threshold)을 초과한 상태임을 의미합니다.

・Server1의 NIC에서 송출된 Priority6 패킷 카운트 (Builder의 GUI 기준)

본 환경에서는 각 Server에서 CNP 패킷에 Priority6를 부여하도록 설정되어 있습니다.

즉, 이 결과는 Server1에서 Server2를 향해 CNP를 송신하고 있는 상태를 나타냅니다.

이전 단계에서 Server1은 Leaf2 측으로부터 CE 마크가 붙은 데이터 패킷을 수신했습니다.

Server1은 이를 통해 Leaf2 측에서 일정 수준의 혼잡이 발생하고 있음을 인식합니다.

그 후, Server1은 Server2 측으로 CNP를 송신함으로써 RDMA 트래픽 송출 레이트를 낮추도록 통지하는 것입니다.

・show policy-map interface ethernet 1/1 (Server1으로부터의 수신 포트)

Server1에서 송신된 CNP 패킷에 대해서도 Leaf1 측 수신 인터페이스의 카운터를 통해 확인할 수 있습니다.

・show interface priority-flow-control

DCQCN에 의해 Server 측의 송신 레이트를 일정 기간 낮춘 후에도 혼잡이 지속되어, Leaf 측 출력 버퍼가 임계값에 도달할 것 같으면 PFC가 발동합니다.

이번에는 Nexus2에서 상대측 Server를 향해 Pause Frame이 송신되고 있는 모습을 확인할 수 있습니다.

・Nexus2 측으로부터 Pause Frame을 수신하고 있는 모습 (각 행은 Server-2의 각 NIC에 대응)

・Pause Frame 수신을 트리거로 RDMA 트래픽의 송출을 일정 기간 (Pause Duration) 정지하고 있는 모습

・ECN/PFC를 ON으로 설정한 상태에서 각 로드 밸런싱 (Load Balancing) 기법의 계측 결과를 정리한 것은 다음과 같습니다.

(1) 5-tuple ECMP의 경우

먼저 첫 번째 포인트는 5-tuple ECMP에 의한 부하 분산 시의 CV 값입니다 (아래 그림 녹색 테두리).

Leaf1/Leaf2 모두 다른 기법과 비교하여 CV 값이 높아져 있음을 알 수 있습니다.

이는 링크 간에 트래픽을 균등하게 분산하지 못하고 있음을 의미합니다.

그 결과, 작업 완료 시간 (Job Completion Time = JCT)에 대해서도 동일한 플로우 기반 부하 분산인 Flowlet DLB와 비교하여 길어지고 있음을 확인할 수 있습니다.

이러한 결과가 나타난 요인으로는, 5-tuple ECMP에서는 5-tuple이 동일한 한 동일한 플로우가 항상 같은 물리 링크를 계속 통과하게 된다는 점에 기인한다고 생각됩니다.

본 검증 환경에서는,

・5-tuple이 같다 = RDMA 플로우가 같다

는 것을 의미합니다.

즉, 동일한 RDMA 플로우는 통신이 진행되는 동안 계속해서 동일한 경로를 이용하게 됩니다.

그 결과, 플로우마다 이용 경로 및 혼잡 상황에 편차가 발생하여, 송신측 NIC에서 수신측 NIC에 도달하기까지의 시간 차이가 발생하기 쉬워집니다.

이전 기사에서도 해설한 바와 같이, All-Reduce 통신에서는 각 Rank(GPU) 간에 동기(Synchronization)를 맞추며 처리가 진행됩니다.

따라서 이번과 같은 Rank 간 도착 시간의 편차가 작업 완료 시간(Job Completion Time, JCT) 전체를 크게 악화시키는 결과로 이어졌을 것으로 추측할 수 있습니다.

(2) Per Packet DLB / Static Pinning의 경우

반면, Per Packet DLB 및 Static Pinning에 대해서는 CV(Coefficient of Variation) 값이 매우 낮아, 트래픽이 거의 균등하게 분산되고 있음을 알 수 있습니다.

(①이 Per Packet DLB, ②가 Static Pinning)

・Per Packet DLB는 그 이름처럼 패킷 단위로 링크를 나누어 사용할 수 있기 때문에, 링크 간에 거의 균등한 부하 분산(Load Balancing)을 실현하기 쉽다는 점을 쉽게 유추할 수 있습니다.

・다음으로 Static Pinning입니다. Static Pinning에서는 "어느 수신 포트에서 수신했는가"에 따라 송출 포트가 고정됩니다.

따라서 각 수신 포트에서의 수신 트래픽량이 균등하다면, 송출 포트 측의 송신 트래픽량에 대해서도 균등해지기 쉬운 특징이 있습니다.

본 검증 환경에서는 각 NIC(Rank)에서 송출되는 트래픽량이 거의 동일하기 때문에, 결과적으로 각 송출 포트에 대해서도 균등한 부하 분산을 실현할 수 있었던 것으로 생각됩니다.

그 결과, 작업 완료 시까지 링크 대역폭(Bandwidth)을 효율적으로 이용할 수 있었던 것으로 추측됩니다.

한편, Static Pinning은 그 이름처럼 정적 매핑(Static Mapping)을 전제로 한 수법입니다.

즉,

・RDMA 이외의 트래픽도 혼재하는 환경

・서버마다 역할이나 통신량이 다른 환경

・통신 패턴의 변동이 큰 환경

에서는 최적의 매핑 설계가 어려워지며, 운용 및 튜닝 난이도가 대폭 상승할 것으로 생각됩니다.

이번 부하 분산 검증에서는 작업 완료 시간(JCT) 관점에서 또 하나의 무시할 수 없는 중요한 결과가 도출되었습니다.

그것은 Per Packet DLB 사용 시, JCT가 극단적으로 길어졌다(약 3500초)는 점입니다.

이는 Per Packet DLB에 의해 트래픽이 부하 분산되었을 때, NIC 측에서의 처리 동작을 고려함으로써 설명할 수 있을 것 같습니다.

Per Packet DLB는 그 이름처럼 동일 플로우 내의 통신이라 할지라도 패킷 단위로 서로 다른 경로로 분배하는 메커니즘입니다.

그렇기 때문에 결과적으로 NIC에 도착하는 패킷 순서의 뒤바뀜(Re-order)이 발생하기 쉬워집니다.

일반적인 TCP 통신에서는 패킷 순서가 다소 앞뒤로 바뀌더라도 수신측 OS가 나중에 재정렬하는 메커니즘을 가지고 있습니다.

반면, RoCEv2는 저지연(Low Latency)·고효율을 극한까지 추구한 통신 방식이며, NIC 측이 패킷 순서를 엄격하게 관리하는 것을 전제로 합니다.

따라서 패킷 순서가 뒤바뀌어 도착하면, 수신측 NIC는 "본래 도착해야 할 패킷이 결락되었다"라고 판단하여 후속 처리를 일시 정지한 후 재전송 요청(Retransmission Request)을 발생시킵니다.

이러한 대기 처리나 재전송 처리가 발생하면 통신 전체의 스루풋(Throughput)과 레이턴시(Latency)에 큰 영향을 미치게 됩니다.

특히 이번 All-Reduce와 같이 여러 GPU(Rank)가 동기를 맞추며 처리를 진행하는 통신 패턴에서는, 단 하나의 통신 경로에서 지연이 발생하는 것만으로도 다른 GPU 측의 처리까지 대기 상태가 됩니다.

그 결과 계산 클러스터 전체의 효율이 저하되어, 최종적인 작업 완료 시간(JCT)이 크게 악화되는 것입니다.

이번 검증에서는 NIC로 ConnectX-5를 사용하였으나, ConnectX-7 이후(SuperNIC 세대)의 NIC에는 "Out-of-Order Handling" 기능이 탑재되어 있습니다.

이 기능을 가진 NIC에서는 네트워크 측으로부터 순서 없이 도착한 패킷에 대해서도, GPU나 메모리로 전달하기 직전에 NIC 내부에서 고속으로 재정렬을 실시할 수 있습니다.

이를 통해,

・네트워크 계층에서는 Per Packet DLB를 통한 세밀한 부하 분산을 실시

・애플리케이션 계층(NCCL 등)에는 순서가 보장된 데이터를 제공

하는 양립이 가능해집니다.

결과적으로 Re-order에 의한 재전송이나 재전송 발생에 따른 대기 시간을 대폭 삭감할 수 있어, Job Completion Time(JCT) 단축으로 이어질 것으로 기대됩니다.

(※참고) Per Packet DLB 환경에서의 Re-order 제어에 대해서는 LINE Yahoo의 해설 자료가 매우 유용합니다.

다음으로, Rank 쌍(pair)별로 패킷 도착 시간에 어느 정도 차이가 발생했는지 Builder GUI를 사용하여 시각화해 보겠습니다.

위 그림으로부터,

・「Rank0→Rank1」

・「Rank3→Rank4」

의 통신에 대해서는 비교적 도착이 빠른 반면, 그 외의 통신(예: 「Rank1→Rank2」)에 대해서는 도착까지 더 긴 시간이 소요되고 있음을 확인할 수 있습니다.

앞서 언급한 바와 같이, All-Reduce 통신에서는 모든 GPU (Rank)가 동기화를 유지하며 처리를 진행합니다.

따라서 일부 플로우(Flow)만 도착이 빠르더라도, 다른 플로우의 도착이 늦어짐으로써 다음 단계 전체의 시작 타이밍도 지연되게 됩니다.

즉, 효율적인 그래디언트 (Gradient) 동기화를 실현하기 위해서는 각 Rank 간의 도착 시간 차이를 작게 억제하는 것이 중요합니다.

그러한 관점에서 볼 때, 플로우마다 이용 경로 나 혼잡 상황에 편중이 생기기 쉬운 5-tuple ECMP는 All-Reduce 통신과의 친화성이 반드시 높다고는 할 수 없음을 알 수 있습니다.

Per Packet DLB의 경우, 5-tuple ECMP와 비교하여 각 Rank 간의 패킷 도착 시간 차이가 매우 작음을 확인할 수 있습니다.

즉, 그래디언트 데이터 배송이라는 네트워크 관점에서는 매우 효율적으로 통신을 분산시키고 있음을 알 수 있습니다.

※ 단, 앞서 언급했듯이 Per Packet DLB에서는 별도로 NIC 측에서 Re-order 처리/재전송 처리가 큰 병목(Bottleneck)이 될 가능성이 있으며, 그 결과 작업(Job) 전체의 완료 시간에 큰 영향을 미칠 수 있다는 점에는 주의가 필요합니다.

이번 검증 결과를 바탕으로, AI 트레이닝 환경에 대한 각 로드 밸런싱 (Load Balancing) 기법의 친화성에 대해 정리해 보았습니다.

성능 검증을 실시할 때의 '성능'을 무엇으로 정의하느냐에 따라 다르겠지만, JCT가 짧을수록 '성능이 높다'고 표현할 경우, NIC 성능이나 통신 특성에 의존하기 어렵고 안정적인 성능을 발휘하기 쉬운 것은 Flowlet DLB라고 할 수 있을 것 같습니다.

반면, 앞서 언급한 것처럼,

・Per Packet DLB

・Out-of-Order Handling 대응 NIC (예: ConnectX-7)

을 조합할 경우에는 순서 보장(Order Guarantee) 및 대역폭 이용 효율을 높은 수준으로 양립할 수 있는 가능성이 있습니다.

따라서 그러한 구성을 전제로 할 수 있는 환경에서는 Per Packet DLB가 가장 고성능인 선택지가 될 가능성도 있다고 생각됩니다.

기법	분산 입도 (Granularity)	순서 보장	대역폭 효율	RDMA 적성
5-tuple ECMP	플로우 단위	◎	△	△
...

이번 검증에서는 AI/LLM용 RoCEv2 네트워크에서 다음과 같은 항목들에 대해 전반적인 동작을 확인할 수 있었습니다.

RDMA 통신용 QoS 설정 (PFC/ECN)이 Nexus 상에서 기대한 대로 동작함을 확인

Nexus와 Server (RoCEv2 NIC) 간의 일련의 DCQCN 동작을 확인

각 로드 밸런싱 기법 (5-tuple ECMP / Flowlet / Per Packet / Static Pinning)의 특성을 확인

ECMP 링크 이용률 편중 및 JCT 영향에 대해 CV 등을 사용하여 비교

QP 수나 RDMA 메시지 크기 (Message Size)에 따라 ECMP 엔트로피(Entropy) 및 혼잡 특성이 변화함을 확인

한편, JCT를 더욱 단축한다는 관점에서는 네트워크 측 튜닝을 통한 개선 여지도 남아 있다고 생각합니다.

예를 들어, 다음과 같은 파라미터를 세밀하게 조정하며 검증함으로써 더욱 포괄적인 고찰이 가능할 것으로 보입니다.

(1) QoS 관련 파라미터 조정

・ Queue buffer size

・ WRED/ECN 발동 임계값 (Threshold)

・ AFD (Approximate Fair Drop)를 통한 혼잡 제어 알고리즘 조정

※ AFD는 단순한 Tail Drop이나 기존의 ECN과 비교하여, Elephant Flow라고 불리는 크기가 큰 플로우를 우선적으로 억제하기 쉬운 메커니즘이며, AI Fabric 환경에서의 혼잡 완화 효과가 기대됩니다. 자세한 내용은 Nexus9000 시리즈의 화이트 페이퍼나 Cisco Live 자료 등을 참조하십시오.

(2) DLB (Dynamic Load Balancing) 관련 파라미터 조정

・ Flowlet Timer (다른 경로로 전환하는 타이밍을 제어)

본 시리즈에서는 지금까지 AI 모델 학습 환경을 뒷받침하는 RoCEv2 네트워크를 주제로 총 세 차례에 걸쳐 해설을 진행해 왔습니다.

이번에 실제로 실기를 사용하여 환경 구축 및 검증을 진행하면서 가장 먼저 강하게 느낀 점은, "기존의 Cisco/Nexus 지식을 활용한 채로 AI 네트워킹 (AI Networking)에 응용할 수 있다"는 점이 역시 매우 접근하기 쉽다는 점입니다.

QoS, ECMP, PFC, ECN 등 기존의 데이터 센터 네트워크에서 다뤄져 온 기술이나 명령어를 그대로 AI 패브릭 (AI Fabric)에도 전용할 수 있기 때문입니다.

반면, RoCEv2 환경의 구축은 네트워크 설정만으로 완결되는 것이 아니라는 어려움도 강하게 느꼈습니다.

그 이유는 기사 중에서도 반복해서 언급했듯이, 로스리스 (Lossless) 네트워크는,

・ 스위치 (Switch)

・ NIC (Network Interface Card)

・ GPU 통신 라이브러리 (GPU Communication Library)

・ 애플리케이션 (Application)

등 여러 레이어 간의 연계에 의해서 비로소 성립되기 때문입니다.

따라서 네트워크, 서버, GPU 통신 라이브러리를 횡단하여 이해하는 지식이 필요합니다.

또한, 성능 최적화라는 관점에서도,

・ NIC 성능

・ QoS

・ ECMP

・ DLB (Dynamic Load Balancing)

・ GPU 통신 특성

등을 종합적으로 설계 및 조정해야 하므로, AI 네트워크 구축은 매우 종합적인 역량이 요구되는 분야라고 느꼈습니다.

그런 의미에서, 언젠가 기회가 된다면 AI/HPC 특화 로스리스 기술인 InfiniBand에 대해서도 실제로 접해보면서, Ethernet 기반의 RoCEv2와의 차이점에 대해 고찰해 보고 싶다는 생각도 듭니다.