RoCE
RDMA over Converged Ethernet
이더넷 위에서 RDMA를 사용할 수 있게 해주는 프로토콜이다. InfiniBand의 RDMA 전송 계층을 그대로 가져와 이더넷 프레임 안에 실어 보낸다.
InfiniBand는 성능이 뛰어나지만 별도의 전용 패브릭이 필요하고 운영 노하우와 장비 모두 따로 마련해야 한다. 데이터센터 운영자 입장에서는 "기존 이더넷 인프라와 운영 도구를 그대로 활용하면서 RDMA의 이점만 가져오고 싶다"는 요구가 생겼고, 그래서 등장한 것이 RoCE이다.
V1 vs V2
RoCE는 두 가지 버전이 있으며, 동작 계층이 다르다.
| 구분 | RoCE v1 | RoCE v2 |
|---|---|---|
| 캡슐화 | Ethernet (EtherType 0x8915) | UDP/IP (UDP 4791) |
| 동작 계층 | L2 (Non-routable) | L3 (Routable) |
| 적용 범위 | 같은 브로드캐스트 도메인 안에서만 | 라우터 너머까지 가능 |
| 현재 위상 | 거의 사용 안 함 | 사실상 표준 |
RoCE v1은 InfiniBand 전송 헤더를 이더넷 프레임에 그대로 얹은 형태이다. L2 계층에서 동작하므로 같은 VLAN 안에서만 통신할 수 있고, 라우팅이 불가능하다는 명백한 한계가 있다.
RoCE v2는 InfiniBand 전송 헤더 위에 UDP/IP 헤더를 추가한다. 이로써 일반 IP 라우터를 통과할 수 있고, ECMP(Equal-Cost Multi-Path) 같은 IP 네트워크의 부하 분산 기능도 활용할 수 있다. 데이터센터 규모로 RDMA를 운영하려면 사실상 RoCE v2가 필수이고, 오늘날 "RoCE"라고 하면 대부분 v2를 의미한다.
DCB (Data Center Bridging)
RoCE의 가장 까다로운 부분은 무손실(lossless) 이더넷을 요구한다는 점이다. RDMA는 원래 InfiniBand의 무손실 패브릭을 가정하고 설계된 프로토콜이라, 패킷이 한 번이라도 드롭되면 성능이 급격히 무너진다.
이를 위해 이더넷 패브릭에서 DCB(Data Center Bridging) 기능을 활성화해야 한다. 핵심 두 가지는 다음과 같다.
- PFC(Priority Flow Control): 특정 우선순위 큐가 가득 차려고 하면 송신 측에 일시 정지 신호를 보내 패킷 드롭을 막는다. 802.3x의 일반 PAUSE를 우선순위별로 확장한 것이다.
- ECN(Explicit Congestion Notification): 혼잡 발생 시 패킷 드롭 대신 패킷에 마킹을 남겨, 종단 노드가 송신 속도를 줄이도록 한다.
이 두 가지가 함께 동작해야 RDMA의 성능 이점을 살릴 수 있다. PFC만 켜면 혼잡이 누적되면서 PFC Storm이나 HOL(Head-Of-Line) Blocking 같은 문제가 발생할 수 있어, ECN까지 함께 켜야 안정적인 운영이 가능하다.
또 PFC를 사용하려면 RoCE 트래픽을 별도 우선순위 클래스로 분리해야 하므로, 스위치와 NIC 양쪽에서 QoS 설정이 필요하다. 운영 복잡도가 일반 이더넷보다 한 단계 높아진다.
DCQCN
대규모 RoCE 패브릭에서는 DCQCN(Data Center QCN) 이라는 혼잡 제어 알고리즘이 사실상 표준으로 사용된다. DCB의 PFC/ECN 위에서 동작하는 종단 혼잡 제어 알고리즘으로, Microsoft가 자사 데이터센터에서 RoCE를 운영하면서 발표했고 현재 NVIDIA NIC를 비롯한 대부분의 RDMA 스택이 지원한다.
핵심 아이디어는 ECN 마킹을 받은 노드가 송신 속도를 점진적으로 줄이고, 마킹이 사라지면 다시 끌어올리는 방식이다. PFC가 작동하기 전에 ECN 단계에서 혼잡을 해소하려는 것이 목표이고, PFC는 어디까지나 마지막 안전망 역할이다.
RoCE vs iWARP
이더넷 위에서 RDMA를 구현하는 또 다른 방식으로 iWARP(internet Wide Area RDMA Protocol) 가 있다. RoCE와 비교하면 다음과 같다.
| 구분 | RoCE v2 | iWARP |
|---|---|---|
| 전송 계층 | UDP/IP | TCP/IP |
| 무손실 요구 | 필요 (PFC, ECN) | 불필요 (TCP가 신뢰성 보장) |
| 운영 부담 | DCB 설정, QoS 설계 필요 | 일반 이더넷 그대로 사용 |
| 성능 | 더 낮은 지연, 더 높은 처리량 | TCP 오버헤드로 약간 열세 |
| 시장 점유 | 사실상 표준 | 점차 감소 |
iWARP는 TCP의 신뢰성을 그대로 활용하므로 별도의 무손실 설정이 필요 없다는 운영상 장점이 있다. 하지만 TCP의 오버헤드와 복잡한 NIC 구현 때문에 성능 측면에서 RoCE에 밀리고, 시장에서도 점점 자리를 잃고 있다. 현재 데이터센터 RDMA의 주류는 RoCE v2이다.
RoCE vs InfiniBand
엄밀히 말하면 InfiniBand는 L1~L4를 모두 정의하는 풀스택 아키텍처이고, RoCE는 그중 전송 계층만 이더넷 위로 옮긴 프로토콜이라 두 개념의 추상화 레벨은 다르다. 실제로 RoCE는 InfiniBand의 전송 계층을 그대로 빌려 쓰는 관계이다. 다만 데이터센터에서 "RDMA를 어떻게 굴릴 것인가"라는 관점에서는 IB 패브릭(IB 케이블 + IB 스위치 + HCA) vs 이더넷 + RoCE 패브릭(이더넷 케이블 + 이더넷 스위치 + RoCE NIC) 형태로 비교하는 것이 일반적이며, 아래 표는 그 관점에서의 트레이드오프이다.
| 구분 | InfiniBand | RoCE v2 |
|---|---|---|
| 패브릭 | 전용 InfiniBand | 일반 이더넷 (DCB 지원 필요) |
| 운영 도구 | 별도 (UFM 등) | 기존 이더넷 운영 도구 활용 가능 |
| 멀티 벤더 | 사실상 NVIDIA 단독 | 멀티 벤더 |
| 지연 | 가장 낮음 (100~200 ns/스위치) | 약간 더 높음 (수백 ns ~ 1µs) |
| 무손실 보장 | 기본 제공 (크레딧 기반) | 별도 설정 필요 (PFC, ECN) |
| 운영 난이도 | 단순 (SM이 통제) | 높음 (혼잡 제어 튜닝 필요) |
| 도입 비용 | 패브릭 신설 비용 | 기존 인프라 재활용 가능 |
요약하면, InfiniBand는 성능과 단순함을 한 번에 사기 위해 별도 패브릭을 구축하는 선택이고, RoCE는 기존 이더넷 자산을 활용하는 대신 운영 복잡도를 떠안는 선택이다. AI 학습 클러스터처럼 성능을 최우선시하는 영역에서는 InfiniBand가 여전히 우세하지만, 일반 데이터센터에서 RDMA를 도입하는 경우에는 대부분 RoCE를 선택한다.
운영 시 주의사항
RoCE를 도입하면서 자주 발생하는 이슈는 다음과 같다.
- PFC Storm: 한 노드의 NIC 버그 또는 슬로우 리시버가 연쇄적으로 다른 노드에 PAUSE 프레임을 유발해 패브릭 전체 처리량이 무너지는 상황. 모니터링과 워치독이 필수이다.
- ECN 마킹 누락: 스위치 ECN 마킹이 잘못 설정되면 DCQCN이 작동하지 않아 PFC에 의존하게 된다. 설정 검증이 중요하다.
- MTU 불일치: RoCE는 큰 MTU(보통 4200B 이상)를 권장하는데, 경로상의 어느 한 장비라도 이를 따르지 않으면 단편화/드롭이 발생한다.
- 혼잡 제어 튜닝: 같은 DCQCN이라도 워크로드(올리듀스 vs 스토리지 IO)에 따라 파라미터를 조정해야 한다.
이 때문에 RoCE는 이더넷 기반이라는 이유만으로 운영이 수월하다고 보기는 어렵고, 사실상 InfiniBand와는 다른 종류의 운영 전문성을 요구한다.