[AI 인프라] RoCEv2 기반 AI GPU 클러스터 네트워크 설계 고려사항

 

kt cloud Foundation플랫폼팀 서준호 님

 

📝 요약 SUMMARY

이 글에서는 RoCEv2 기반 AI GPU 클러스터 네트워크 설계와 무손실 이더넷 구현 고려사항을 다룹니다.
안정적인 AI 인프라 운영과 비용 효율적인 확장 전략 수립의 중요성을 정리합니다.

#RoCEv2 #AI_GPU_클러스터 #무손실_이더넷 #RDMA #InfiniBand

---

kt cloud에서는 현재 인피니밴드(InfiniBand)와 같은 폐쇄적·독점적 솔루션에서 개방형 이더넷 기반인 RoCEv2로의 전환을 위한 기술 검증(PoC)이 진행 중입니다. Cloud Service Provider(CSP) 운영자 입장에서 이러한 전환은 마이크로초(μs) 단위의 Tail Latency와 네트워크 패브릭 활용도 극대화 사이의 근본적인 trade-off에서 비롯됩니다. 이 두 요소가 만나는 '스윗 스팟(Sweet Spot)'을 찾는 것이 Job Completion Time을 최소화하는 핵심입니다. 만약 네트워크가 혼잡이나 패킷 손실로 인해 중단될 경우, 대당 3만 달러가 넘는 GPU들은 연산(FLOPs)을 수행하지 못한 채 유휴 상태로 남게 되며, 이는 곧 운영 비용(OPEX)의 낭비로 이어집니다.

 

본 글에서는 RoCEv2 기반 Lossless AI backend fabric을 구축하는 데 필요한 아키텍처 고려 사항과 정밀한 엔지니어링 과정을 살펴봅니다.

---

The Great Debate: InfiniBand vs. RoCEv2

AI 커뮤니티에서 가장 먼저 던지는 질문은 항상 이겁니다. "인피니밴드를 쓸 것인가, 이더넷을 쓸 것인가?"

인피니밴드(IB)는 설계 단계부터 Lossless, Credit-based, low latency 인터커넥트로 만들어졌으며, 하드웨어 레벨에서 혼잡 제어를 처리합니다. 반면, RoCEv2는 어디에나 존재하는 이더넷 생태계에 이러한 RDMA(Remote Direct Memory Access) 기능을 이식하려는 시도라고 볼 수 있습니다.

InfiniBand vs. RoCEv2: 아키텍처 비교

비교 항목	인피니밴드 (NDR/GDR)	RoCEv2 (이더넷)
흐름 제어 (Flow Control)	크레딧 기반 (하드웨어 네이티브)	PFC (Priority Flow Control) - 추가 탑재 방식
혼잡 관리	하드웨어 레벨의 적응형 라우팅	ECN / DCQCN / Quantized Congestion
생태계	독점적 (NVIDIA/Mellanox)	개방형 (Broadcom, Cisco, Arista, Marvell 등)
관리 체계	서브넷 매니저 (중앙 집중형)	표준 BGP/EVPN (분산형)
확장성	대규모 (수만 대 규모)	무한함 (표준 리프-스파인 구조)
비용 (TCO)	높음 (고가의 전용 하드웨어/케이블)	낮음 (범용 광모듈 및 스위칭 장비)
기술 역량	전문적인 IB 지식 필요	표준 NetOps / CCIE / 클라우드 운영 지식

 

무엇이 "올바른" 선택인가?

CSP 입장에서 RoCEv2는 종종 전략적인 선택이 됩니다. 인피니밴드가 초기 설정 상태(Out of the box)에서 약간 더 나은 Tail Latency을 제공하는 것은 사실이지만, RoCEv2는 통합된 관리 체계, 기존 광선로 인프라와의 용이한 통합, 그리고 특정 벤더 종속(Vendor Lock-in) 탈피라는 강력한 이점을 제공합니다. 다만, RoCEv2에서 Lossless 특성을 구현하기 위해서는 훨씬 더 엄격하고 정밀한 설정 작업이 요구됩니다.

---

RoCEv2의 작동 원리

AI 네트워킹에서 RoCEv2란 무엇인가?

RoCEv2는 RDMA 전송 계층을 UDP/IP 헤더로 캡슐화한 것입니다. 이를 통해 RDMA 트래픽이 L3(3계층) 경계를 넘어 라우팅될 수 있게 됩니다. 궁극적인 목표는 제로 카피(Zero-Copy)와 커널 바이패스(Kernel Bypass)를 실현하는 것입니다.

 

CPU의 TCP 스택을 거치지 않고 NIC(네트워크 인터페이스 카드)가 원격 서버의 GPU 메모리에 직접 데이터를 기록합니다. 이를 통해 지연 시간을 밀리초(ms) 단위에서 마이크로초(μs) 단위로 단축하고 CPU 부하를 획기적으로 줄입니다. 이는 수천 개의 GPU가 All-Reduce 연산을 수행하는 환경에서 매우 결정적인 요소입니다.

무손실 이더넷 구현을 위한 3요소

이더넷은 본래 '손실이 발생하는(lossy)' 특성을 가집니다. 버퍼가 가득 차면 스위치는 패킷을 드롭(drop)합니다. 하지만 RDMA 환경에서 단 하나의 패킷 손실은 막대한 재전송 페널티를 유발하여 JCT(작업 완료 시간)를 망가뜨립니다. 이를 방지하기 위해 다음 세 가지 메커니즘을 사용합니다.

A. PFC (Priority Flow Control - IEEE 802.1Qbb)

PFC는 홉 바이 홉(hop-by-hop) 방식의 메커니즘입니다. 링크 전체의 트래픽을 중단시키는 대신, 특정 '레인(Priority Code Point)'만 일시 정지시킬 수 있습니다. 스위치 B의 수신 버퍼가 임계치에 도달하면, 스위치 A에 해당 우선순위에 대한 PAUSE 프레임을 보내 전송 중단을 요청합니다.

B. ECN (Explicit Congestion Notification)

PFC가 '무딘 도구'라면 ECN은 '정밀한 메스'와 같습니다. 스위치 버퍼가 가득 차기 전, 혼잡이 시작되려고 할 때 스위치는 IP 헤더의 ECN 비트를 마킹합니다. 수신측은 이 마킹을 확인하고 송신측에 속도를 줄이도록 알립니다.

C. DCQCN (Data Center Quantized Congestion Control)

네트워크 패브릭의 혼잡 신호를 기반으로 작동하는 이 메커니즘은 주로 NIC(예: NVIDIA ConnectX)에서 구현되는 전체 시스템의 '두뇌' 역할을 합니다. ECN과 PFC를 결합하여 다음과 같이 작동합니다.

1. 스위치가 혼잡 시 ECN을 마킹합니다.
2. 목적지 NIC가 송신측으로 CNP(Congestion Notification Packet)를 보냅니다.
3. 송신 NIC는 정교한 알고리즘에 따라 데이터 주입 속도를 줄입니다.

---

차세대 기술: TIMELY 및 SWIFT

표준 DCQCN은 스위치 기반의 ECN 마킹에 의존하는데, 이는 멀티 벤더 환경에서 튜닝하기가 매우 까다롭기로 유명합니다. 이에 구글과 같은 하이퍼스케일러들은 지연 시간 기반(Delay-Based) 방식을 개척했습니다.

• TIMELY: 고정밀 하드웨어 타임스탬프를 사용하여 RTT(왕복 지연 시간)의 변화율(gradient)을 측정합니다. RTT가 미세하게라도 증가하기 시작하면 혼잡이 발생하고 있다고 판단하여 송신 속도를 제한합니다.
• SWIFT: TIMELY의 진화된 형태입니다. 지연 시간 분해(Delay Decomposition) 기능을 도입하여 '패브릭 지연(스위치)'과 '호스트 지연(NIC/PCIe)'을 분리합니다. 이를 통해 느린 호스트 때문에 무관한 네트워크 트래픽까지 속도가 줄어드는 '희생자 흐름(victim flows)' 현상을 방지합니다. 단순 속도 제어가 아닌 혼잡 윈도우(cwnd) 방식을 사용하여 P99.9 수준의 매우 타이트한 꼬리 지연 시간을 보장합니다.

---

저지연 및 대역폭 극대화를 위한 최적화

하드웨어 선택: Shallow Buffer vs. Deep Buffer

이는 CSP 운영자에게 매우 중요한 아키텍처 결정 사항입니다.

• 얕은 버퍼 스위치 (예: Broadcom Tomahawk 5): 온칩(on-chip) 메모리를 사용합니다. 포트 간 지연 시간(나노초 단위)을 최소화할 수 있습니다. 효율적인 혼잡 제어가 이루어지는 정밀하게 튜닝된 AI 패브릭에서는 혼잡 상황을 NIC로 빠르게 환류(feedback)시키는 얕은 버퍼 스위치가 선호됩니다.
• 깊은 버퍼 스위치 (예: Broadcom Jericho3-AI / Arista 7800): 외부 메모리(HBM)를 사용합니다. 대규모 트래픽 폭주(인캐스트, Incast)를 흡수할 수 있는 능력이 탁월합니다.

아키텍트의 결론: 백엔드 AI 패브릭(GPU-to-GPU)에는 High-Radix 얕은 버퍼 스위치를 사용하십시오. 반면, 예측 불가능한 남북(North-South) 트래픽 폭주를 처리해야 하는 데이터 센터 간(Inter-DC) 연결이나 스파인(Spine) 패브릭에는 깊은 버퍼 스위치가 더 안전한 선택입니다.

---

스위치 버퍼 관리 및 시뮬레이션

RoCEv2를 튜닝하려면 알파 값(버퍼 공유 비율)과 PFC/ECN 임계값에 대한 복잡한 계산이 필요합니다.

• 아키텍트 팁: 실제 운영 장비에서 먼저 튜닝을 시도하지 마십시오. NS-3와 같은 패킷 레벨 시뮬레이터를 사용하여 특정 워크로드(예: 1,750억 개 파라미터 규모의 LLM 학습)의 트래픽 패턴을 모델링하고, 최적의 ECN/PFC 교차 지점을 찾아내야 합니다.

---

Incast 및 PFC 스톰 대응

• 문제점: 1,024개의 GPU가 동시에 하나의 GPU로 데이터를 보낼 때(인캐스트), 버퍼는 즉시 오버플로됩니다. 이때 PFC 설정이 잘못되면 PFC 스톰(PFC Storm)이 발생하여 PAUSE 프레임이 전파되고, 결국 전체 패브릭이 데드락(Deadlock, 교착 상태)에 빠질 수 있습니다.
• 해결책: 모든 리프/스파인 스위치에 PFC 와치독(PFC Watchdog)을 구현하십시오. 특정 큐가 일정 시간(예: 100ms) 이상 '일시 정지(Paused)' 상태로 유지되면, 스위치가 자율적으로 해당 큐를 드롭하여 데드락을 해소해야 합니다.

---

Collective Communication Library 최적화

NCCL(NVIDIA)이나 RCCL(AMD)과 같은 라이브러리는 반드시 네트워크 토폴로지를 인식해야 합니다. 우리는 레일 최적화(Rail-Optimized) 설계를 활용합니다.

1. 모든 서버의 GPU 0번은 리프(Leaf) 1번에 연결하고, GPU 1번은 리프 2번에 연결하는 방식입니다.
2. 이를 통해 대부분의 트래픽이 단일 '레일(스위칭 플레인)' 내에 머물게 하여 유효 대역폭을 극대화합니다.
3. QP(Queue Pair) 스케일링 또한 패브릭 대역폭 활용을 극대화하기 위해 NCCL에서 사용하는 핵심 최적화 기술 중 하나입니다.

---

 

RoCEv2를 기반으로 AI 백엔드 네트워크를 구축한다는 것은 단순한 '네트워크 엔지니어링'에서 'AI 풀스택 엔지니어링'으로의 전환을 의미합니다.

 

독점적인 인피니밴드에서 벗어남으로써 ktcloud는 이더넷 생태계의 유연성을 확보하게 되었습니다. 하지만 그 대가로 '무손실(Lossless)' 신뢰성을 보장해야 하는 막중한 책임은 이제 온전하게 네트워크 아키텍트의 몫이 되었습니다.

 

성공적인 RoCEv2 구현을 위해서는 하드웨어 특성, 혼잡 제어 알고리즘, 그리고 상위 계층의 AI 워크로드 패턴까지 관통하는 깊은 통찰이 필요합니다.

 

---

❔자주 묻는 질문 FAQ

Q 왜 굳이 InfiniBand 대신 RoCEv2를 검토해야 하나?

AInfiniBand는 여전히 최고 수준의 초저지연 성능과 안정적인 RDMA 환경을 제공하지만, 폐쇄형 생태계와 높은 비용, 벤더 종속성이 단점입니다. 반면 RoCEv2는 Ethernet 기반 개방형 구조이기 때문에: - 기존 데이터센터 네트워크와 통합 용이 - 장비 선택 폭 확대 (Cisco, Arista, Broadcom 등) - 운영 인력 확보 용이 (기존 NetOps 활용) - 장기적인 TCO 절감 가능 즉, CSP 사업자인 ktcloud 입장에서는 단기 최고 성능보다 확장성·운영성·경제성까지 포함한 전략적 선택지로 RoCEv2를 검토하는 것입니다.

Q RoCEv2가 InfiniBand보다 어렵다고 하는 이유는 무엇인가?

AInfiniBand는 기본적으로 lossless 네트워크로 설계되어 있어 비교적 안정적으로 고성능을 구현할 수 있습니다. 하지만 RoCEv2는 Ethernet 위에서 RDMA를 구현하므로 다음 요소를 직접 설계·튜닝해야 합니다. PFC 설정 ECN Threshold 조정 DCQCN 파라미터 튜닝 Buffer 관리 Spine/Leaf 경로 최적화 Incast / Hotspot 대응 설정이 잘못되면: PFC Storm Deadlock GPU Idle 증가 학습 시간 증가(JCT 악화) 즉, RoCEv2는 장비보다 운영 역량이 더 중요한 기술입니다.

Q kt cloud가 지금 가장 먼저 준비해야 할 핵심 역량은 무엇인가?

A단순 네트워크 엔지니어링 역량만으로는 부족합니다. AI 클러스터 환경에서는 네트워크와 GPU 워크로드가 직접 연결되기 때문입니다. 따라서 필요한 인재는: Network Engineering Linux / Kernel / RDMA GPU Cluster Architecture NCCL / AI Framework 이해 Telemetry / Performance Tuning 대규모 분산 시스템 운영 경험 즉, 앞으로 중요한 것은 네트워크 엔지니어가 아니라, GPU부터 패브릭, AI 워크로드까지 연결해서 최적화할 수 있는 AI Full Stack Engineer 확보 입니다. 향후 AI 데이터센터 경쟁력은 이 인재 확보 여부가 결정할 가능성이 높습니다.

---

📚 관련 / 출처 REFERENCES

🔗

https://www.naddod.com/blog/pfc-flow-control-technology-and-challenges-in-rocev2-network-deployment?srsltid=AfmBOoraByOH-eDh_OTrxRVQ0J_1kgW7MTRPyxmeFum315S7x7Hz7eaP

↗