데이터센터 네트워크

거대 물류 창고 안으로

데이터센터의 기본 단위는 랙(rack)이다. 높이 2 m 남짓한 철제 선반에 납작한 서버 20~40대가 꽂힌다. 랙 맨 위에는 그 랙의 서버들을 모으는 스위치가 하나(또는 두 개) 있는데, 자리 때문에 ToR 스위치(Top of Rack)라 부른다. 서버와 ToR 사이는 1~3 m라 값싼 구리 케이블(4장)로 잇고, ToR에서 위쪽 스위치로 가는 수십~수백 m 구간은 광케이블(5장)을 쓴다. 광케이블은 천장 아래 노란 케이블 트레이를 따라 네트워크 전용 랙으로 모인다.

랙은 앞면끼리, 뒷면끼리 마주 보도록 줄지어 놓는다. 서버 팬은 앞에서 찬 공기를 빨아들여 뒤로 뜨거운 공기를 내뿜으므로, 앞면 사이 통로는 찬 통로(cold aisle), 뒷면 사이는 뜨거운 통로(hot aisle)가 된다. 이 공기를 식히는 냉각 장치가 건물 전력의 상당 부분을 쓴다.

나무에서 그물로: 3계층 vs 리프-스파인

2000년대 기업 데이터센터는 회사 네트워크와 같은 3계층 트리로 지었다. 서버가 붙는 접속(access) 스위치, 이를 모으는 집선(aggregation) 스위치, 맨 위의 크고 비싼 코어(core) 스위치다. 트래픽 대부분이 “사용자 ↔ 서버”였던 시절에는 잘 맞았다. 바깥에서 들어와 아래로 내려가는 이런 흐름을 그림의 위아래 방향을 따라 남북 트래픽(north-south traffic)이라 한다.

그런데 웹 서비스가 거대해지면서 상황이 뒤집혔다. 사용자 요청 하나를 처리하려고 웹 서버가 캐시, 데이터베이스, 검색 색인, 추천 모델 서버 수십 곳에 물어보고, 저장 장치는 데이터를 세 벌씩 복제하고, 분산 계산은 중간 결과를 서로 섞는다. 이런 동서 트래픽(east-west traffic), 즉 서버 ↔ 서버 트래픽이 남북 트래픽보다 훨씬 많아졌다. 대형 사업자들은 데이터센터 안 트래픽의 대부분(흔히 70~80% 이상, AI 학습 클러스터는 거의 전부)이 동서 방향이라고 보고한다.

트리에서는 동서 트래픽이 꼭대기 코어를 거쳐야 하고, 꼭대기 몇 대가 병목이자 고장 한 곳이 된다. 그래서 등장한 것이 리프-스파인(leaf-spine) 구조다. 모든 리프(ToR) 스위치가 모든 스파인 스위치에 하나씩 연결된다. 어떤 서버에서 어떤 서버로 가든 “리프 → 스파인 → 리프”, 정확히 세 개의 스위치만 지난다. 스파인 하나가 고장 나도 나머지 길로 간다. 이 구조는 1953년 벨 연구소의 찰스 클로스(Charles Clos)가 전화 교환기용으로 고안한 다단 교환망을 되살린 것이라 Clos 네트워크(Clos network)라고도 부른다.

포트 수로 서버 수를 계산하기

리프-스파인의 아름다움은 규모를 계산할 수 있다는 점이다. 스위치 칩의 포트 수를 래딕스(radix) k라 하자. 서버로 가는 대역폭과 위로 올라가는 대역폭이 같으면(막힘 없는 구성) 리프는 포트 절반(k/2)을 서버에, 나머지 절반을 스파인에 쓴다. 스파인은 k개 포트로 리프 k대를 받을 수 있으니, 2단 구조의 최대 서버 수는 다음과 같다.

그 이상이 필요하면 단을 하나 더 쌓는다. 리프와 그 위의 스위치들을 묶어 팟(pod)이라는 작은 Clos를 만들고, 팟들을 다시 코어 스파인으로 잇는 3단 구조를 팻 트리(fat tree)라 한다. 위로 갈수록 링크가 줄어드는 보통 나무와 달리, 위로 가도 굵기(총 대역폭)가 줄지 않는 “뚱뚱한 나무”라는 뜻이다. 2008년 알파레스(Al-Fares) 등의 논문이 같은 상용 스위치만으로 수만 대를 막힘 없이 잇는 법을 보여 준 뒤 업계 표준이 되었다.

현실에서는 비용을 아끼려고 리프의 서버 쪽 포트를 위쪽 포트보다 많이 단다. 서버 쪽 대역폭 : 위쪽 대역폭의 비를 오버서브스크립션(oversubscription)이라 한다. 3:1이면 모든 서버가 동시에 랙 밖으로 보낼 때 1/3 속도밖에 못 낸다. 모든 서버가 동시에 전속력으로 보내는 일은 드물다는 통계에 거는 셈이다. 네트워크 전체의 실력을 한 숫자로 말할 때는 이분 대역폭(bisection bandwidth)을 쓴다. 서버를 절반씩 두 무리로 나눴을 때 두 무리 사이로 동시에 흐를 수 있는 최대 대역폭이다(어떻게 나눠도 가장 나쁜 경우).

ECMP: 여러 길에 흐름 나누기

리프에서 스파인으로 올라가는 길이 64개 있다면, 어느 길로 보낼까? 모두 길이가 같으니 어느 길이든 최단 경로다. 라우터는 이런 ECMP(Equal-Cost Multi-Path, 등비용 다중 경로) 경로 사이에 트래픽을 나눈다. 다만 패킷마다 아무 길로나 보내면 길마다 대기열 길이가 달라 패킷 순서가 뒤바뀌고, TCP(9장)는 순서가 뒤바뀌면 손실로 오해해 속도를 줄인다. 그래서 ECMP는 보통 흐름(flow) 단위로 나눈다. 패킷 헤더의 다섯 값(출발·도착 IP, 출발·도착 포트, 프로토콜)을 해시 함수에 넣어 나온 번호로 길을 고른다. 같은 흐름의 패킷은 늘 같은 해시 → 같은 길 → 순서 유지다.

문제는 해시가 흐름의 크기를 모른다는 것이다. 데이터센터 흐름은 대부분 몇 KB짜리 짧은 생쥐 흐름(mice flow)이지만, 바이트의 대부분은 수 GB짜리 소수의 코끼리 흐름(elephant flow)이 차지한다. 해시가 우연히 코끼리 두세 마리를 같은 길에 몰아넣으면, 다른 길이 텅 비어 있어도 그 길은 넘친다. 동전 던지기로 공을 상자에 넣으면 고르게 들어가지 않는 것과 같은 해시 충돌이다.

가장 느린 하나를 기다린다: 테일 지연과 인캐스트

검색 요청 하나는 색인을 나눠 가진 서버 수천 대에 동시에 뿌려지고(팬아웃, fan-out), 모든 답을 모아야 결과 페이지가 완성된다. 서버 한 대가 평소 1 ms 만에 답하더라도, 가끔 가비지 컬렉션, 디스크 대기, 큐 밀림 때문에 수십 ms가 걸린다. 서버 하나만 보면 100번에 한 번이지만, 1,000대에 동시에 물으면 그중 누군가는 거의 확실히 느리다. 그래서 대규모 서비스의 응답 시간은 평균이 아니라 분포의 꼬리, 즉 테일 지연(tail latency)이 좌우한다. 구글의 제프 딘(Jeff Dean)과 루이스 바로소(Luiz Barroso)가 2013년 “The Tail at Scale”에서 정리한 문제다.

팬아웃은 네트워크에도 독특한 병목을 만든다. 수백 대가 거의 같은 순간에 답을 보내면, 그 답들은 모두 집계 서버로 가는 ToR의 출구 포트 하나로 몰린다. 들어오는 링크는 수백 개인데 나가는 링크는 하나라, 스위치 버퍼(17장)가 순식간에 넘치고 패킷이 버려진다. 이를 인캐스트(incast)라 한다. 잃어버린 패킷은 TCP 재전송 타이머가 끝나야 다시 보내는데, 리눅스의 최소 재전송 대기는 기본 200 ms다. 1 ms면 끝날 일이 200배로 늘어나는 것이다. 대책으로는 재전송 타이머를 µs 단위로 줄이기, 응답 시점을 조금씩 흩뜨리기, 큐가 차기 시작하면 ECN 표시로 미리 속도를 줄이는 DCTCP(9장의 혼잡 제어를 데이터센터에 맞춘 것), 그리고 버퍼가 큰 스위치가 쓰인다.

RDMA: CPU를 건너뛰는 메모리 직송

보통 서버끼리 데이터를 보내면 앱의 데이터가 운영체제 커널로 복사되고, 커널의 TCP/IP 코드가 헤더를 붙이고, 드라이버를 거쳐 NIC로 간다. 받는 쪽은 그 반대다. 이 과정에서 CPU가 일하고, 데이터가 몇 번씩 복사되고, 왕복 지연이 수십 µs가 된다. 100 Gbps 이상에서는 CPU가 패킷 처리만으로도 벅차다.

RDMA(Remote Direct Memory Access)는 이 길을 통째로 건너뛴다. 앱이 미리 메모리 영역을 등록해 두면, NIC가 직접 그 메모리를 읽어 네트워크로 보내고, 상대 NIC가 상대 앱의 메모리에 바로 써 넣는다. 커널을 거치지 않고(커널 우회), 중간 복사가 없고(제로 카피), 받는 쪽 CPU는 데이터가 도착한 줄도 모를 수 있다. 작은 메시지의 왕복 지연이 몇 µs 수준으로 줄고 CPU는 계산에 전념한다. 택배로 치면 창고 직원(CPU)이 상자를 풀고 다시 싸는 대신, 컨베이어가 이쪽 선반에서 저쪽 선반으로 물건을 바로 옮겨 주는 셈이다.

RDMA를 나르는 네트워크는 크게 두 가지다. InfiniBand는 처음부터 고성능 컴퓨팅용으로 설계된 별도의 네트워크 기술이다. 받는 쪽 버퍼에 자리가 있을 때만 보내는 크레딧 기반 흐름 제어로 원래부터 패킷을 버리지 않는(무손실) 망이다. 다른 하나는 RDMA를 보통 이더넷 위에 얹은 RoCEv2(RDMA over Converged Ethernet, 버전 2)로, RDMA 패킷을 UDP(목적지 포트 4791)/IP에 실어 일반 데이터센터 라우터를 지날 수 있게 했다.

까다로운 점은 RDMA NIC의 재전송이 단순하다는 것이다(손실이 나면 그 뒤를 통째로 다시 보내는 방식이 많다). 그래서 이더넷도 패킷을 거의 버리지 않게 만들어야 한다. 두 가지 장치가 쓰인다.

• PFC(Priority Flow Control, IEEE 802.1Qbb): 스위치 버퍼가 차오르면 앞 장비에게 “그 우선순위 클래스는 잠깐 멈춰”라는 일시 정지 프레임을 보낸다. 버리지 않고 세운다. 대신 멈춤이 꼬리를 물고 퍼지면(PFC 폭풍, 교착) 상관없는 흐름까지 멈출 수 있다.
• ECN + DCQCN(Data Center Quantized Congestion Notification): 큐가 일정 길이를 넘으면 스위치가 패킷에 “혼잡” 표시(ECN)를 한다. 받는 NIC가 이를 보내는 쪽에 알리면, 보내는 NIC가 하드웨어에서 속도를 줄였다가 서서히 올린다. PFC가 작동하기 전에 미리 속도를 낮추는 것이 목표다. 2015년 마이크로소프트가 대규모 RoCE 운용을 위해 제안했다.

AI 클러스터: GPU 수만 개를 한 몸처럼

대형 언어 모델 학습은 GPU 수천~수십만 개가 한 모델을 나눠 계산한다. 각 GPU는 자기 몫의 데이터로 기울기(gradient)를 계산한 뒤, 모든 GPU의 기울기를 더해 똑같이 나눠 가져야 다음 단계로 갈 수 있다. 이렇게 모두가 참여하는 통신을 집합 통신(collective communication)이라 하고, 그 대표가 올리듀스(all-reduce)다. 가장 느린 GPU가 끝날 때까지 모두가 기다리므로, 네트워크가 느리면 수천억 원어치 GPU가 논다. AI 클러스터에서 네트워크가 “부속품”이 아니라 컴퓨터의 일부가 된 이유다.

AI 클러스터 네트워크는 두 층으로 나뉜다.

• 스케일업(scale-up): 한 서버나 한 랙 안의 GPU들을 아주 굵은 전용 연결로 묶는다. 엔비디아의 NVLink가 대표적이며, 최신 세대는 GPU 하나당 양방향 1.8 TB/s(약 14 Tbps) 수준이고, NVLink 스위치로 랙 하나의 GPU 72개를 한 덩어리로 묶는 제품도 있다. 거리가 짧아 구리선을 주로 쓴다. UALink 같은 개방형 표준도 나왔다.
• 스케일아웃(scale-out): 서버(랙)와 서버를 잇는 백엔드 네트워크. InfiniBand나 RoCE 이더넷으로 만든 리프-스파인이며, GPU 하나마다 400~800 Gbps NIC를 따로 단다. 사용자 요청과 저장 장치를 위한 일반 프런트엔드 네트워크와는 물리적으로 분리하는 경우가 많다.

스케일아웃에는 레일 최적화(rail-optimized) 구조가 흔하다. GPU 8개짜리 서버라면, 모든 서버의 1번 GPU는 1번 레일 스위치에, 2번 GPU는 2번 레일 스위치에… 이런 식으로 연결한다. 집합 통신에서는 같은 번호의 GPU끼리 대화하는 일이 많으므로 대부분의 트래픽이 레일 스위치 한 대만 거치고 스파인까지 올라가지 않는다. 다른 번호끼리는 서버 안의 NVLink로 먼저 옮긴 뒤 레일을 탄다.

올리듀스를 가장 단순하게 하는 방법은 모든 GPU가 한 GPU에 보내고 그 GPU가 합쳐 다시 뿌리는 것이지만, 그 GPU의 링크가 병목이 된다. 링 올리듀스(ring all-reduce)는 GPU들을 고리로 세우고, 데이터를 N조각으로 나눠 이웃에게만 보낸다. 앞의 N−1단계(reduce-scatter)에서는 조각을 받아 자기 것에 더해 다음 GPU로 넘기고, 뒤의 N−1단계(all-gather)에서는 완성된 조각을 돌려 모두가 갖게 한다. 각 GPU가 보내는 총량은 2(N−1)/N × S로, GPU가 아무리 많아져도 데이터 크기의 2배를 넘지 않는다. 대역폭 면에서 최적이다.

전력, 냉각, 그리고 광케이블의 숲

데이터센터의 한계는 점점 공간이 아니라 전력이다. 일반 클라우드 데이터센터 건물 하나는 수십 MW를 쓰고, 최신 AI 캠퍼스는 수백 MW에서 GW급을 계획한다. 랙 하나의 전력도 예전 5~10 kW에서 AI GPU 랙은 100 kW를 넘어, 공기로는 식히지 못해 칩에 냉각수를 직접 흘리는 수랭이 늘고 있다. 전체 전력 중 IT 장비가 아닌 냉각·전력 변환에 쓰는 비율은 PUE(Power Usage Effectiveness)로 나타내는데, 최신 대형 데이터센터는 1.1~1.2 수준이다(1.0이 이상적).

그중 네트워크(스위치·NIC·광 트랜시버)는 IT 전력의 약 5~10% 수준으로 서버에 비하면 작지만, 규모가 커질수록 광 트랜시버의 전력과 개수가 무시할 수 없게 된다. 800G 광 트랜시버 하나가 대략 15 W 안팎을 쓰는데, GPU 10만 개 규모 클러스터에는 이런 트랜시버가 수십만 개 들어간다. 위 Clos 계산기에서 3단 팻 트리의 트랜시버 수를 확인해 보자. 광 트랜시버의 전력을 줄이려고 스위치 칩 바로 옆에 광 엔진을 붙이는 CPO(Co-Packaged Optics, 19장)와, 짧은 구간에 신호 재생만 하는 저전력 광 모듈 같은 기술이 등장했다.