적절한 균형 찾기: AI 클러스터를 위한 ECN 및 PFC 임계값 설정

서론

대규모 AI 학습 클러스터에서 혼잡 제어(Congestion Control)는 높은 GPU 활용도와 낮은 작업 완료 시간(Job Completion Time)을 유지하는 데 매우 중요합니다. RoCEv2(RDMA over Converged Ethernet) 패브릭의 두 가지 핵심 메커니즘은 명시적 혼잡 알림(ECN, Explicit Congestion Notification)과 우선순위 기반 흐름 제어(PFC, Priority Flow Control)입니다. ECN 마킹과 PFC 포즈(Pause) 임계값을 너무 공격적으로 튜닝하여 지나치게 타이트하게 설정하면 종종 역효과가 발생합니다. 지터와 테일 레이턴시(Tail Latency)를 줄이기는커녕 포즈 스톰(Pause Storm), 처리량 붕괴, 진동, 그리고 "고스트(Ghost)" 레이턴시 스파이크(극단적인 테일 레이턴시)와 같은 불안정성을 유발할 수 있습니다.

혼잡 관리에서의 ECN과 PFC

ECN과 PFC는 모두 RDMA(RoCEv2) 트래픽을 위한 무손실(Lossless) 이더넷 패브릭을 구현하는 데 사용되지만, 작동 방식은 매우 다릅니다.

• ECN은 선제적 혼잡 신호(Proactive Congestion Signal)입니다. 스위치의 큐(Queue)가 임계값을 초과하여 쌓이면, 스위치는 패킷을 드롭하는 대신 IP 헤더에 "혼잡 경험(CE, Congestion Experienced)" 비트를 마킹합니다. 수신 측 NIC(또는 호스트)는 CE 마크를 확인하고 송신 측에 혼잡 알림 패킷(CNP, Congestion Notification Packet)을 보냅니다. 이는 송신 측의 RoCE/DCQCN 알고리즘을 트리거하여 전송 속도를 줄이게 만듭니다. 본질적으로 ECN은 송신자에게 속도를 부드럽게 줄이도록 요청하는 것입니다. 중요한 점은 트래픽이 멈추지 않는다는 것입니다. 패킷은 계속 흐르되 제한된 속도로 흐릅니다. 이를 통해 처리량을 보존하면서 큐가 넘치는 것을 방지합니다. [juniper.net] [cisco.com] [RDMA]
• PFC는 반응형 링크 레벨 흐름 제어(Reactive Link-level Flow Control)입니다. 스위치의 이그레스(Egress) 큐가 PFC Xoff 임계값에 도달하면(버퍼가 가득 차기 직전임을 의미), 스위치는 상위 장치에 해당 우선순위 클래스에 대한 PAUSE 프레임을 보냅니다. 상위 NIC는 재개(Xon) 신호를 받을 때까지 해당 클래스의 모든 패킷 전송을 중단합니다. 따라서 PFC는 버퍼가 찰 때 트래픽을 문자 그대로 멈춤으로써 패킷 손실을 방지합니다. 그러나 트래픽을 멈추는 것은 부작용이 있습니다. 전송이 재개될 때 (송신자가 데이터를 쌓아두었기 때문에) 패킷이 폭발적으로 유입되어 또 다른 혼잡을 유발할 수 있습니다. 즉, PFC는 무손실을 보장하지만, 과도하게 사용할 경우 지터와 처리량 저하를 초래하는 "무딘 도구"와 같습니다. [juniper.net] [RDMA] [cisco.com]

잘 튜닝된 네트워크에서 ECN과 PFC는 함께 작동하여 혼잡을 제어합니다. ECN은 1차 방어선(송신원 속도를 점진적으로 조절)이고, PFC는 최후의 보루(드롭을 피하기 위해 꼭 필요한 경우에만 일시 중단)입니다. 이러한 보완적 접근 방식은 패킷 손실 없이 트래픽을 최대한 매끄럽게 유지하는 것을 목표로 합니다. 클라우드 데이터 센터부터 벤더의 베스트 프랙티스에 이르기까지 수많은 산업계 설계에서는 AI/ML 클러스터를 위해 ECN과 PFC를 함께 사용하는 것을 강조합니다. 핵심은 임계값을 올바르게 구성하는 것이며, 이에 대해 다음에 논의하겠습니다.

올바른 혼잡 대응 순서: ECN → DCQCN 스로틀링 → PFC (필요 시)

AI 워크로드를 위한 RoCE 네트워크에서 혼잡은 이상적으로 다음과 같은 순서로 처리되어야 합니다.

요약하자면, 스위치는 먼저 "천천히 가라"는 신호(ECN)를 시도하고, 그 다음에야 "멈춰라"는 신호(PFC)를 사용합니다. 왜 이 순서일까요? 트래픽을 잠시라도 멈추는 것은 연쇄적인 반응을 일으켜 많은 흐름에 지장을 줄 수 있지만, 마킹은 흐름이 느려지더라도 계속 유지될 수 있게 하기 때문입니다. ECN의 부드러운 백오프는 최소한의 중단으로 GPU를 계속 바쁘게 유지합니다. PFC의 하드 스탑(Hard stop)은 드롭을 방지하기 위한 안전망이지 주요 혼잡 제어 수단이 아닙니다. 모든 주요 AI 네트워크 설계는 이 순서를 지지하며, 이는 부하 상황에서도 더 높은 처리량과 더 낮은 지연 시간을 제공합니다. [juniper.net], [engineering.fyi] [cisco.com], [RDMA]

공격적인 튜닝의 함정: PFC가 앞서고 ECN이 뒤처질 때

실제로 네트워크 운영자들은 때때로 ECN이 작동할 기회를 얻기도 전에 PFC가 트리거되도록 임계값을 잘못 설정하곤 합니다. 이는 모든 버퍼링을 거의 제거하려는 시도(예: 매우 낮은 ECN 임계값과 더 낮은 PFC Xoff 설정)에서 자주 발생합니다. 의도는 큐 대기 지연을 최소화하고 혼잡 발생 시 신속하게 신호를 보내거나 일시 중단하려는 것입니다. 논리적으로 들릴 수 있지만(제어 루프를 "조여서" 큰 큐를 방지한다), 이는 극적으로 역효과를 낼 수 있습니다.

PFC가 너무 일찍 발생하면 무엇이 문제일까요?

PFC 포즈 임계값이 너무 낮게 설정되면, 트래픽 버스트가 도착했을 때 ECN 마킹이 시작될 만큼 큐가 쌓이기도 전에 스위치가 즉시 포즈 프레임을 보냅니다. 사실상 PFC가 ECN 메커니즘을 단락(Short-circuit)시키는 것입니다. NIC는 속도를 줄이라는 ECN 신호를 받지 못하고 대신 갑작스럽게 멈춰버립니다. 포즈 타이머가 만료되거나 큐가 비워지면, NIC는 내부적으로 속도를 줄인 적이 없으므로 다시 트래픽을 쏟아붓고, 이는 또 다시 포즈를 유발합니다. 네트워크는 결국 중단과 시작을 반복하는 사이클에 빠지게 됩니다.

아래는 ECN과 PFC의 "잘못된 순서"와 "올바른 순서"에 대한 개념적 설명입니다.

설정이 잘못된 경우(왼쪽) 모든 트래픽 버스트가 아주 작은 Xoff 임계값을 즉시 건드려 포즈 스톰을 일으킵니다. ECN이 작동할 "유예 기간"이 없습니다. 그 결과 큐가 비어 있거나(포즈 시) 급등하는(해제 시) 진동 패턴이 발생하며 적정 수준을 유지하지 못합니다. 이러한 진동은 비효율적이며 레이턴시에 치명적입니다. GPU 간 메시지 교환이 매 포즈마다 멈췄다가 폭발하기를 반복합니다. 이는 높은 테일 레이턴시(일부 반복 작업이 훨씬 오래 걸림)와 처리량 저하로 나타납니다. 운영자들은 이러한 예측 불가능한 지연을 "고스트 레이턴시 스파이크"라고 부르기도 합니다.

올바르게 튜닝된 경우(오른쪽) ECN 마킹 범위는 수백 KB에 달할 수 있습니다. 즉, 버스트가 도착하면 큐가 어느 정도(수십~수백 KB) 자랄 수 있고, 버퍼가 치명적으로 가득 차기 훨씬 전에 스위치가 CE 마킹을 시작합니다. RDMA 소스는 혼잡 피드백을 신속하게 받아 송신 속도를 늦춥니다. 이를 통해 대부분의 경우 큐를 PFC 임계값 아래로 유지할 수 있습니다. 트래픽은 온/오프 방식의 포즈(디지털 제어)가 아니라 ECN/DCQCN에 의해 지속적으로 조절(아날로그 제어)됩니다. ECN 제어 범위를 넘어서는 지속적인 무거운 버스트가 발생할 때만 드롭을 방지하기 위해 PFC가 개입합니다. 균형 잡힌 설정에서 이는 드문 일이어야 합니다.

요컨대, 너무 낮은 PFC 임계값과 이른 ECN 설정은 의도한 계층 구조를 뒤집어 버립니다. PFC가 주도하게 되고 ECN은 효과가 없어집니다. 이는 AI 클러스터용 RoCE 배포 초기에 가장 흔히 저지르는 실수 중 하나이며, 아래 설명하는 심각한 성능 문제를 야기합니다.

과도하게 공격적인 ECN/PFC 설정의 결과

⚠️ 빠른 진단 체크리스트

혼잡 관련 성능 문제를 해결할 때 이 체크리스트를 사용하세요:

• ☐ ECN 마킹은 그대로인데 PFC 포즈 프레임이 증가하나요? → ECN 시작 임계값을 높이거나 PFC Xoff를 낮추세요. PFC가 지배하기 전에 ECN이 참여해야 합니다.
• ☐ 톱니바퀴 모양의 처리량 패턴이 보이나요? → PFC-before-ECN 문제일 가능성이 높습니다. 임계값 순서를 확인하고 PFC Xoff에 도달하기 전에 ECN이 전체 마킹에 도달하는지 확인하세요.
• ☐ P50 레이턴시는 낮은데 P99만 높나요? → 특히 혼잡이 공유 업링크로 집중되는 구간에서 스위치 홉 간의 포즈 스톰 전파를 확인하세요.

이러한 문제들은 AI 학습 성능 저하로 직결됩니다. GPU는 통신을 위해 더 오래 기다려야 하고, 반복 시간(Iteration time)이 일관되지 않아 동기식 학습에 지장을 주며, 노드를 추가해도 예상만큼 처리량이 늘어나지 않습니다(네트워크 비효율로 인한 수익 체감). 최악의 경우, PFC 스톰이 확산되면 병리적인 혼잡 붕괴나 데드락(Deadlock)이 발생할 수 있습니다(현대적인 네트워크는 이를 방지하기 위해 PFC Watchdog을 구현합니다).

실제 사례: 초기 대규모 GPU 클러스터 배포 시, 큐 대기 시간을 최소화하기 위해 직관적으로 매우 작은 버퍼 임계값을 설정하는 경우가 많았습니다. 결과는 대개 실망스러웠습니다. 로그에는 끊임없는 PFC 포즈 프레임이 찍히고 네트워크 레이턴시는 요동쳤습니다. ECN이 작동할 여유를 주기 위해 임계값을 완화한 후에야 네트워크가 안정화되고 학습 처리량이 개선되었습니다.

ECN 및 PFC 튜닝을 위한 합리적인 전략

튜닝의 핵심 원칙은 PFC가 개입하기 전에 ECN이 작동할 기회를 주는 것입니다. 실제로는 충분한 ECN 마킹 범위와, ECN 전체 마킹보다 높지만 실제 패킷 드롭을 유발하지 않을 정도의 PFC 포즈 임계값을 구성하는 것을 의미합니다. 숙련된 AI 네트워크 운영자들이 사용하는 전형적인 전략은 다음과 같습니다.

• 스위치 측(ECN/WRED 구성): RDMA 트래픽 클래스에 ECN 마킹을 활성화하고 2단계 임계값을 설정합니다.
  • ECN 시작 임계값(Start Threshold): RDMA 이그레스 큐가 적정한 점유율(예: 포트당 수백 KB)에 도달하면 패킷에 CE 마킹을 확률적으로 시작합니다. 이 임계값은 혼잡이 조기에 신호될 만큼 낮아야 하지만, 사소한 부하에도 마킹될 만큼 낮아서는 안 됩니다. 많은 배포 사례에서 100GbE 링크의 경우 100~300KB 사이를 선택합니다. [cisco.com]
  • ECN 전체 마킹 임계값(Full/100% Threshold): 더 높은 큐 깊이(예: 버퍼 끝에 도달하기 전)에서 모든 패킷에 마킹하도록 높입니다. 예를 들어, 100G 스위치에서 약 2~3MB의 큐 길이에서 100% 마킹되도록 설정할 수 있습니다. 이는 큐가 계속 쌓일 경우 패킷이 드롭되기 전에 모든 흐름에 공격적으로 신호를 보내도록 보장합니다.
  • (선택 사항) ECN RED 프로필: 시작과 전체 임계값 사이의 마킹 확률 곡선(선형 등)을 튜닝하여 마킹이 너무 급격하게 변하지 않도록 합니다. 목표는 큐가 쌓임에 따라 마킹 속도가 매끄럽게 증가하는 것입니다.

이유: 이러한 설정은 버퍼 내에 "ECN 영역"을 생성하여 혼잡 신호를 점진적으로 보냅니다. CE 마크를 받은 NIC는 DCQCN을 사용하여 속도를 줄입니다. 결과적으로 네트워크는 버퍼가 넘치기 훨씬 전에 스스로 전송 속도를 조절하게 됩니다.

• 스위치 측(PFC 임계값 구성): 무손실 큐의 PFC Xoff 임계값을 ECN 전체 마킹 임계값보다 약간 높게 설정합니다. 이는 ECN 신호 이후 이미 파이프라인에 들어와 있는 패킷들을 수용할 수 있는 최소한의 헤드룸입니다. 실제 운영에서 이 Xoff는 절대적인 KB 단위로 보면 꽤 작을 수 있습니다.
  • 예를 들어, 100Gb 링크를 사용하는 일부 클라우드 데이터 센터에서는 큐가 ECN 범위를 단 수십 KB 초과했을 때 PFC 포즈를 트리거합니다. 이 작은 헤드룸(수십 KB)은 CNP 피드백이 송신자에게 도달하는 동안 이미 선로 위에 있거나 NIC 버퍼에 있는 패킷을 흡수하기에 충분합니다. 정확한 수치는 링크 속도와 RTT(왕복 시간)에 따라 달라집니다.
  • PFC Xon(재개) 임계값은 히스테리시스(Hysteresis)를 고려하여 Xoff보다 적절히 낮게 설정하여, 일단 포즈가 발생하고 큐가 빠지면 안전한 수준에서 재개가 이루어지도록 합니다.

이 전략을 따르면 혼잡 시퀀스는 다음과 같아집니다: (1) CE 마킹, (2) 송신원 속도 감소, (3) 속도 감소가 충분히 빠르지 않을 경우에만 포즈 발생. 수치적으로 100Gbps 링크의 예시 구성은 다음과 같습니다: [cisco.com], [engineering.fyi]

• ECN 마킹 시작: ~150KB, 100% 마킹: ~3,000KB (Cisco 레퍼런스 디자인 기준).
• PFC Xoff: ~3,100KB (초과분을 잡기 위해 바로 위로 설정).
• PFC Xon: ~2,500KB (충분히 비워진 후 재개).

버퍼가 더 작은 다른 스위치에서는 절대적인 수치가 다를 수 있지만, 분리 원칙은 동일합니다. ECN을 위해 수백 KB(또는 수 마이크로초 분량의 버퍼링)를 할당하고, PFC를 위해 최소한의 추가 여유를 둡니다.

결정적으로, 운영자들은 안정적인 성능을 얻기 위해 어느 정도의 버퍼링을 허용하는 것이 낫다는 것을 배웠습니다. 전형적인 스위치 포트의 12~16MB 버퍼에 비하면 수백 KB는 미미한 수준입니다. 버퍼링을 완전히 제거하려는 시도는 역효과를 냅니다. 약간의 큐는 ECN을 통해 혼잡을 조기에 신호하는 데 사용된다면 나쁜 것이 아닙니다.

ECN/PFC 임계값 설정 예시

📋 복사 가능한 구성 스니펫 – 사용 중인 스위치 OS 및 버퍼 모델에 맞게 조정하세요.

# ECN/PFC 임계값 구성 예시 (개념적 - 사용 중인 스위치 OS에 맞게 조정 필요)
# 100 GbE RoCEv2 트래픽 클래스 기준

# ECN 마킹 임계값 설정
ecn-marking-threshold start 150KB
ecn-marking-threshold full 3000KB
ecn-marking-probability linear

# PFC 임계값 설정 (반드시 ECN full 임계값보다 커야 함)
pfc-xoff-threshold 3100KB
pfc-xon-threshold 2500KB

# 확인 명령: show qos ecn-statistics

참고: 정확한 구문은 네트워크 운영 체제(NX-OS, EOS, Junos, SONiC 등)에 따라 다릅니다. 하지만 설계 원칙은 동일합니다. ECN 마킹은 PFC Xoff 임계값보다 훨씬 일찍 시작되어야 하며, PFC Xoff는 ECN의 전체 마킹 지점보다 높게 설정되어 포즈 동작이 최후의 보호 수단으로만 남도록 해야 합니다.

마무리: 베스트 프랙티스 및 시사점

복잡한 GPU 학습 네트워크에서 최저 레이턴시를 위해 모든 큐 대기열을 없애고 싶은 유혹이 들 수 있습니다. 그러나 네트워크 엔지니어의 역할은 버퍼링을 완전히 없애는 것이 아니라 버퍼링을 지능적으로 사용하는 것입니다. ECN과 결합된 소량의 버퍼링은 패킷 손실을 피하면서도 네트워크가 높은 활용도로 지속적으로 흐를 수 있게 합니다. 반면 PFC는 비상 브레이크입니다. 최후의 수단으로만 사용하세요.

RoCE 기반 AI 클러스터의 혼잡 제어를 위한 베스트 프랙티스를 요약하면 다음과 같습니다:

• ECN이 1차 대응자이고, PFC는 최후의 보루입니다. 항상 PFC 포즈가 트리거되기 전에 ECN 마킹이 발생하도록 구성하세요. 이는 일반적으로 ECN에 더 큰 임계값을, PFC에 훨씬 작은 헤드룸을 할당하는 것을 의미합니다. 대규모 GPU 클러스터에서 발생하는 대부분의 테일 레이턴시 폭발은 ECN을 희생하고 PFC를 남용한 것에서 비롯되었습니다. [juniper.net], [engineering.fyi]
• 고삐를 너무 죄지 마세요. 공격적인 설정(아주 작은 ECN/PFC 값)은 안정성을 해칠 수 있습니다. 온/오프 방식의 디지털 패턴이 아니라 매끄러운 아날로그 방식의 혼잡 제어가 필요합니다. 제어 루프가 제대로 작동하려면 어느 정도의 큐 대기는 괜찮을 뿐만 아니라 필수적입니다.
• 실제 피드백을 사용하여 튜닝하세요. 권장값(예: 벤더 또는 레퍼런스 디자인)에서 시작하여 관찰하세요. 여전히 PFC 프레임이 자주 발생한다면 ECN 마킹의 공격성을 높여야 할 수도 있습니다(또는 시작 임계값을 조금 더 낮춤). PFC는 발생하지 않는데 스위치 큐 점유율이 너무 높다면 ECN 임계값을 약간 낮추거나 PFC가 조금 더 일찍 트리거되도록 조정할 수 있습니다. 완벽한 균형은 워크로드 패턴(버스트성, 메시지 크기)에 따라 달라질 수 있으므로, 대표적인 트래픽이 있는 테스트 환경에서 미세 조정을 하는 것이 현명합니다.

결론적으로, 공격적인 ECN/PFC 튜닝의 부작용을 피하는 것은 이들 메커니즘의 본래 역할을 존중하는 것에서 시작됩니다. ECN을 사용하여 "적당한" 혼잡을 처리하고 트래픽 흐름을 유지하며, PFC는 "정말 큰일 났을 때"를 위해 아껴두세요. 이러한 계층적 접근 방식은 분산 AI 워크로드에 훨씬 더 나은 처리량, 낮은 레이턴시, 예측 가능한 성능을 제공합니다. 넉넉한 ECN 마킹 범위와 최소한의 필수 PFC 헤드룸을 구성함으로써, 제대로 튜닝되지 않은 RoCE 패브릭을 괴롭히는 포즈 유도 테일 레이턴시 폭발과 진동을 대부분 제거할 수 있습니다. 업계에서 나타나는 승리 공식은 바로 이것입니다: 능동적 혼잡 제어로서의 ECN, 백업 계획으로서의 PFC. 이 패턴을 따르면 AI 학습 클러스터가 원활하고 고성능인 네트워킹을 바탕으로 대규모로 운영되도록 도울 수 있습니다. [cisco.com]

다음 단계: 실무 적용

임계값 설계는 한 번으로 끝나는 작업이 아닙니다. 링크 속도, 버퍼 아키텍처, 워크로드 패턴이 진화함에 따라 랩 검증, 프로덕션 텔레메트리, 주기적인 재튜닝이 필요합니다.

🔧 오늘 시작하기: 실전 구성

이 글의 개념적 임계값 모델을 벤더 구현 가이드를 참고하여 사용 중인 스위치 OS에 적용해 보세요.

• Cisco Nexus QoS Configuration Guide for RoCEv2 – NX-OS 플랫폼용 단계별 임계값 구성
• Juniper AI Data Center Deployment Guide – Junos 기반 패브릭을 위한 전체 ECN/PFC 설정 예시

이 레퍼런스들은 큐잉 의도를 플랫폼별 명령, 단위, 검증 단계로 변환하는 데 도움이 될 것입니다.

📊 설정 검증

배포 후 패브릭이 의도한 대로 작동하는지 확인하세요.

• show interface priority-flow-control (Cisco) 또는 해당 스위치 OS의 유사 명령을 사용하여 PFC 프레임 카운트를 모니터링하세요.
• 스위치 텔레메트리 또는 큐 통계 대시보드를 통해 ECN 마킹 속도를 추적하세요.
• 핵심 신호: PFC는 자주 발생하는데 ECN 마킹은 적다면 임계값 조정이 필요합니다. PFC가 주도권을 잡기 전에 ECN이 작동할 기회를 얻지 못하고 있는 것입니다.

💬 토론 참여

• 아래 댓글로 여러분의 튜닝 경험을 공유해 주세요.
• 특정 토폴로지 관련 문제가 있나요? 상황을 설명해 주시면 커뮤니티에서 문제 해결을 도와드릴 수 있습니다.

참고 문헌

1. Juniper Networks – “Introduction to Congestion Control in Juniper AI Networks”, Best Practices for ECN/PFC (2025). [juniper.net]
2. Cisco – “Validated Design for Networking AI/ML Applications”, QoS Configuration for RoCEv2 (2023). [cisco.com]
3. Edgecore Networks – “Powering AI at Scale: Role of PFC and ECN for Large GPU Deployments” (Blog, 2025). [engineering.fyi]
4. Meta (Facebook) – “RoCE Networks for Distributed AI Training at Scale” (Engineering Blog, 2024).
5. Calnex Solutions – “Understanding Network Tail Latency in AI Training Data Centers” (Blog, 2023).
6. Arista Networks – “High-Performance Ethernet for AI Systems” (Deployment Guide, 2023).
7. Hoefler2023-RDMA: “Datacenter Ethernet and RDMA: Issues at Hyperscale,” arXiv:2302.03337, 2023. [Link]