Datacenter & Cloud - 02. DC 네트워크 토폴로지

도시의 도로를 어떻게 깔 것인가 — DC 네트워크 토폴로지

2014년, Facebook(현 Meta)은 자체 데이터센터 네트워크를 F16이라는 구조로 재설계했다. 기존 3-tier 네트워크에서 — 서버 간 통신(east-west)이 늘어나면서 상위 계층(core)이 병목이 됐기 때문이다. Facebook의 해답은 — 모든 서버가 같은 홉 수로 통신하는 spine-leaf 구조였다. 이 결정은 — 데이터센터 네트워크 설계의 패러다임 전환을 보여준다. "도시의 도로를 어떻게 깔 것인가" — 교차로를 몇 개 만들고, 차선을 얼마나 넓힐 것인가. 데이터센터도 같은 질문이다. 이 글은 DC 네트워크 토폴로지 — 3-tier에서 spine-leaf로의 진화, east-west 트래픽, oversubscription — 를 다룬다.

이 글은 이전 글(IDC 물리 시설) 위에 얹히는 네트워크 구조를 다룬다. foundations 01에서 본 추상화 계층이 — 데이터센터 규모로 확장된다. network fundamentals 영역에서 본 L2·L3 개념이 — 수만 대의 서버를 연결하는 규모에서 어떻게 다르게 적용되는지를 본다.

트래픽 방향 — north-south vs east-west

데이터센터 트래픽을 두 방향으로 나눈다.

North-South(남북) — 데이터센터 외부(인터넷)와 내부 사이의 트래픽. 사용자가 웹사이트에 접속하고, 서버가 응답하는 흐름. 비유하자면 — 도시와 외부를 잇는 고속도로. 데이터센터 입구(인터넷 게이트웨이)를 통과하는 트래픽.

East-West(동서) — 데이터센터 내부 서버 간의 트래픽. 웹 서버가 DB 서버에 쿼리를 보내고, 앱 서버가 캐시 서버에서 데이터를 읽는 흐름. 비유하자면 — 도시 내부의 교차로들. 서버 간 통신이 대부분이다.

flowchart TD
    INTERNET["인터넷 (사용자)"] -->|"North-South<br/>(남북 트래픽)"| DC["데이터센터 입구"]
    DC --> WEB["웹 서버 클러스터"]
    WEB <-->|"East-West<br/>(동서 트래픽)"| DB["DB 클러스터"]
    WEB <-->|"East-West"| CACHE["캐시 클러스터"]
    DB <-->|"East-West"| REPL["복제 클러스터"]

2010년대 이전에는 — north-south가 주를 이뤘다. 사용자가 데이터센터에 들어와서 — 한 서버에서 처리하고 나가는 단순한 흐름. 하지만 — 마이크로서비스·분산 데이터베이스·Hadoop/Spark 같은 분산 처리가 늘어나면서 — east-west 트래픽이 폭발했다. 웹 서버가 5개의 마이크로서비스를 호출하고, 각 마이크로서비스가 DB·캐시·메시지 큐에 접근하면 — 사용자 요청 1개당 내부 통신이 수십 번 일어난다. 2026년 기준 — 데이터센터 트래픽의 약 80%가 east-west다.

이 변화가 — 네트워크 토폴로지의 재설계를 불렀다. north-south에 최적화된 3-tier가 — east-west 폭증에 무너지고, east-west에 최적화된 spine-leaf가 대세가 됐다.

3-tier 토폴로지 — 전통적 구조

3-tier(또는 3계층) 토폴로지는 — 1990 ~ 2000년대 데이터센터의 표준 구조였다. 세 계층으로 나뉜다.

flowchart TD
    CORE["Core 계층<br/>(코어 스위치)"]
    CORE --> AGG1["Aggregation 계층<br/>(어그리게이션 스위치)"]
    CORE --> AGG2["Aggregation 계층"]
    AGG1 --> ACC1["Access 계층<br/>(ToR 스위치)"]
    AGG1 --> ACC2["Access 계층"]
    AGG2 --> ACC3["Access 계층"]
    AGG2 --> ACC4["Access 계층"]
    ACC1 --> SRV1["서버 랙 1"]
    ACC2 --> SRV2["서버 랙 2"]
    ACC3 --> SRV3["서버 랙 3"]
    ACC4 --> SRV4["서버 랙 4"]

• Access(접근) 계층 — 서버 랙마다 있는 ToR(Top of Rack) 스위치. 랙 안의 서버 40 ~ 50대가 이 스위치에 연결된다. L2 통신(MAC 주소)을 담당.
• Aggregation(집계) 계층 — 여러 ToR 스위치를 묶는 스위치. L3 라우팅, 방화벽, 로드 밸런서가 여기 위치.
• Core(코어) 계층 — 데이터센터 전체를 묶고 인터넷과 연결하는 최상위 스위치.

3-tier의 문제점

3-tier는 north-south 트래픽에 최적화돼 있었다 — 사용자가 들어와서 위로 올라가고(core), 처리하고, 나가는 흐름. 하지만 east-west 트래픽이 늘어나면서 — 두 서버가 통신하려면 — ToR → Aggregation → Core → Aggregation → ToR, 이렇게 최대 4홉을 거쳐야 했다. 경로가 길면 — 지연이 커지고 대역폭이 낭비된다.

Oversubscription(오버서브스크립션) 이 핵심 문제다. 하위 계층(access)의 총 대역폭이 — 상위 계층(aggregation)의 대역폭을 초과하도록 설계되는 것. 예를 들어 — ToR에 48개의 10Gbps 포트가 있으면 — 총 480Gbps의 하향 대역폭인데, 상향(업링크)은 4개의 40Gbps = 160Gbps. 오버서브스크립션 비율은 480/160 = 3:1. 즉 — 모든 서버가 동시에 최대 속도로 통신하면 — 업링크가 감당 못 한다.

3-tier에서 — 서버 간(east-west) 통신이 늘어나면 — aggregation·core 계층의 대역폭이 병목이 된다. "도시의 모든 차가 동시에 중심가로 몰리면 — 중심가가 막히는 것." 이 문제를 해결하려면 — 상위 계층의 스위치를 더 크고 비싼 것으로 교체해야 하는데 — 이미 최상위(core) 스위치는 데이터센터에서 가장 비싼 장비(수억 원)다. 확장 한계가 온다.

Spine-Leaf 토폴로지 — Clos 네트워크

Spine-Leaf(또는 Clos) 토폴로지는 — 3-tier의 문제를 해결하기 위해 등장한 2계층 구조다. 이름은 척추(spine)와 잎(leaf)에서 왔다.

flowchart TD
    S1["Spine 1"] --- L1["Leaf 1<br/>(ToR 랙 1)"]
    S1 --- L2["Leaf 2<br/>(ToR 랙 2)"]
    S1 --- L3["Leaf 3<br/>(ToR 랙 3)"]
    S1 --- L4["Leaf 4<br/>(ToR 랙 4)"]
    S2["Spine 2"] --- L1
    S2 --- L2
    S2 --- L3
    S2 --- L4
    S3["Spine 3"] --- L1
    S3 --- L2
    S3 --- L3
    S3 --- L4
    S4["Spine 4"] --- L1
    S4 --- L2
    S4 --- L3
    S4 --- L4

• Leaf 스위치 — 3-tier의 access(ToR)와 같은 역할. 서버 랙에 있고, 서버와 직접 연결. 모든 leaf는 모든 spine에 연결된다(full mesh).
• Spine 스위치 — leaf 간 연결을 담당. 서버에 직접 연결되지 않고 — leaf에서 오는 트래픽을 다른 leaf로 전달.

Spine-Leaf의 핵심 특징

1. 모든 서버가 같은 홉 수로 통신 — 서버 A에서 서버 B로 가려면 — Leaf A → Spine(어느 것이든) → Leaf B. 항상 2홉이다. 3-tier에서는 위치에 따라 2 ~ 4홉이었지만 — spine-leaf에서는 항상 2홉이다. 지연이 균일하고 예측 가능하다. 비유하자면 — 도시를 격자형(grid) 도로망으로 까는 것. 어느 교차로에서든 두 번 환승하면 된다.

2. ECMP로 대역폭 확장 — leaf 4개, spine 4개면 — leaf 간 경로가 4개(각 spine마다 하나). ECMP(Equal-Cost Multi-Path) 가 이 4개 경로에 트래픽을 분산. 3-tier에서는 aggregation 계층이 병목이었지만 — spine-leaf에서는 spine 수를 늘리면 대역폭이 선형적으로 증가한다.

3. 오버서브스크립션 1:1 (non-blocking) — spine 수를 충분히 늘리면 — 모든 서버가 동시에 최대 속도로 통신할 수 있다(non-blocking). leaf 48개 포트 중 절반은 서버, 절반은 spine 업링크. spine이 충분하면 오버서브스크립션이 1:1에 가까워진다.

4. 수평 확장(scale-out) — 서버를 늘리려면 — leaf를 추가하고, 모든 spine에 연결. spine 대역폭이 부족하면 — spine을 추가하고, 모든 leaf에 연결. 3-tier처럼 "더 크고 비싼 스위치"로 교체할 필요 없이 — "스위치 수를 늘리는" 것으로 확장한다.

특성	3-tier	Spine-Leaf
계층 수	3 (Access·Aggregation·Core)	2 (Leaf·Spine)
서버 간 홉 수	2 ~ 4 (위치에 따라)	항상 2
East-West 최적화	낮음	높음
확장 방식	더 큰 스위치로 교체(scale-up)	스위치 추가(scale-out)
오버서브스크립션	높음 (3:1 ~ 10:1)	낮음 (1:1 ~ 3:1)
예측 가능한 지연	낮음 (위치에 따라)	높음 (항상 2홉)
비용	core 스위치가 매우 비쌈	상대적으로 균등

왜 Clos라 부르나

Clos 네트워크는 — 1952년 Bell Labs의 Charles Clos가 전화 교환망을 위해 설계한 다단계 교환 구조(multistage switching fabric) 다. 전화망에서 "모든 발신자가 동시에 통화할 수 있으면서도 스위치 수를 줄이는" 구조를 고안한 것. spine-leaf는 이 Clos 구조의 현대적 버전이다. "Clos"와 "spine-leaf"는 같은 것을 가리킨다.

Oversubscription — 왜 1:1이 아닌가

이상적으로는 — 모든 서버가 동시에 최대 속도로 통신할 수 있어야(non-blocking, 1:1) 한다. 하지만 — 비용이 기하급수한다. spine-leaf에서 1:1을 달성하려면 — leaf의 업링크 포트 수만큼 spine이 필요하고, 각 spine이 충분한 다운링크를 가져야 한다. 서버 수가 늘면 — spine 수도 같이 늘어나고, 케이블 수도 기하급수한다.

그래서 — 현실적인 오버서브스크립션(2:1 ~ 4:1) 을 수용한다. "모든 서버가 동시에 최대 속도로 통신할 일은 드물다"는 가정. 모니터링하면서 — 특정 링크가 포화하면 — 해당 경로에만 spine을 추가하거나 ECMP 해시를 조정한다.

데이터센터에서의 라우팅 — BGP와 OSPF

network fundamentals 영역에서 본 라우팅(OSPF·BGP)이 — 데이터센터 규모에서도 쓰인다. 하면 — 데이터센터 특화 패턴이 있다.

데이터센터 BGP(RFC 7938) — spine-leaf 네트워크에서 — 각 leaf·spine 스위치가 BGP를 돌려 경로를 교환. OSPF보다 확장성이 좋고 — ECMP와 잘 맞는다. Google·Meta·Microsoft의 데이터센터가 BGP를 쓴다.

Link-state(OSPF/IS-IS) — 소규모 데이터센터에서는 여전히 OSPF나 IS-IS가 쓰인다. 수렴이 빠르고 설정이 단순하다.

특성	데이터센터 BGP	OSPF/IS-IS
확장성	수천 스위치	수백 스위치
ECMP 지원	네이티브	지원하지만 제한적
정책 기반 라우팅	강력	제한적
수렴 시간	수 초	수 초 (비슷)
설정 복잡도	중간	낮음
전형 환경	하이퍼스케일 DC	기업 DC, 소규모

Fabric — 현대 DC 네트워크의 새로운 이름

패브릭(fabric) 은 — spine-leaf 네트워크를 하나의 통합된 시스템으로 다루는 개념이다. 비유하자면 — 개별 도로(스위치)를 하나씩 관리하는 게 아니라 — 도로망 전체(fabric)를 하나의 "직물(fabric)"로 다루는 것. 패브릭은 — 스위치 간의 연결 토폴로지·라우팅 프로토콜·ECMP·오버레이(VXLAN)를 통합적으로 관리한다.

패브릭 컨트롤러(fabric controller) — 소프트웨어 정의 네트워킹(SDN) 기반으로 — 전체 스위치를 중앙에서 제어하는 시스템. Cisco ACI·Juniper Contrail·Arista CloudVision이 사례. 각 스위치를 개별적으로 설정하는 대신 — 중앙 컨트롤러가 전체 패브릭을 선언적으로 설정한다(foudations 06의 IaC 철학이 네트워크에 적용된 것).

케이블링 — 물리적 연결의 현실

spine-leaf는 — 논리적으로 우아하지만 — 물리적으로 케이블이 기하급수적으로 많이 필요하다. leaf N개, spine M개면 — 연결 수는 N x M. leaf 48개, spine 12개면 — 576개의 연결. 각 연결은 광케이블(SR4·LR4)이다. 랙 위의 케이블 트레이에 수백 개의 케이블이 깔린다.

케이블 종류:

• DAC(Direct Attach Copper) — 짧은 거리(5m 이하)의 구리 케이블. 싸고 저지연. 같은 랙 안의 leaf-spine 연결에 쓰임.
• 광케이블(SR4, Multi-Mode Fiber) — 짧은 거리(100m 이하). 데이터센터 내 표준. 대역폭이 높고 EMI(전자기 간섭)에 강함.
• 광케이블(LR4, Single-Mode Fiber) — 긴 거리(10km). 데이터센터 간 연결 또는 대규모 DC 내부.

케이블 관리는 — 단순한 미관이 아니라 운영 문제다. 576개의 케이블이 엉키면 — 어느 케이블이 어디 연결된지 못 찾고, 장애 복구 시간이 폭증한다. 색상 코딩(leaf별 색상 구분)·라벨링(양 끝에 포트 정보)·케이블 관리 소프트웨어(DCIM, Data Center Infrastructure Management)가 필수다.

실습 — DC 네트워크 확인

1. 서버의 네트워크 토폴로지 이해

# 서버가 연결된 스위치 포트 확인
ip link show
# NIC의 속도·듀플렉스
ethtool eth0 2>/dev/null | grep -E 'Speed|Duplex|Link'
# ARP 테이블 — 같은 leaf에 연결된 서버들
ip neigh show | head -10

확인할 것: NIC 속도가 10Gbps 또는 25Gbps(데이터센터 표준). ARP 테이블에 같은 서브넷의 다른 서버 MAC이 보이면 — 같은 leaf(ToR)에 연결된 것.

2. ECMP 경로 확인

# 같은 목적지에 여러 경로가 있는지 (ECMP)
ip route get 10.0.2.5
ip route get 10.0.2.5  # 다시 실행 — 다른 next hop이 나오면 ECMP

확인할 것: ip route get을 여러 번 실행했을 때 — next hop이 바뀌면 ECMP가 동작하고 있는 것.

3. traceroute로 홉 수 확인

# 같은 데이터센터 내 서버까지의 경로
traceroute 10.0.5.10 2>/dev/null || tracepath 10.0.5.10

확인할 것: 홉 수가 2이면 — spine-leaf 구조(Leaf → Spine → Leaf). 홉 수가 3 ~ 4이면 — 3-tier 구조일 가능성.

판단 표 — 3-tier vs spine-leaf 선택

기준	3-tier가 유리	Spine-Leaf가 유리
주 트래픽	North-South (외부)	East-West (내부)
규모	소규모 (~수백 서버)	대규모 (수천 ~ 수만 서버)
예산	제한적 (core 스위치 하나)	충분 (스위치 여러 대)
확장 패턴	드물게 크게	자주 조금씩
지연 요구	느슨함	엄격 (일관된 2홉)
전형 환경	소규모 기업 DC	클라우드, 하이퍼스케일 DC

도로망이 도시를 결정하듯 — 네트워크가 데이터센터를 결정한다

데이터센터 네트워크 토폴로지는 — "도시의 도로망"과 같다. 도로가 잘 깔려 있으면 — 모든 곳에 빠르게 도달하고(낮은 지연), 교통체증이 없고(충분한 대역폭), 새 지역이 개발되면 도로를 쉽게 연장할 수 있다(수평 확장). 3-tier는 — 도시가 작을 때는 효율적이었지만, 도시가 커지면서 중심가(core)가 막혔다. spine-leaf는 — 격자형 도로망을 깔아, 어느 곳이든 두 번 환승으로 도달하고, 필요하면 도로(switch)를 추가하는 구조다.

대규모 데이터센터 — Super-Spine

spine-leaf가 충분히 커지면 — 하나의 spine-leaf 패브릭으로 감당이 안 된다. 수만 대의 서버를 한 패브릭에 두면 — leaf 수가 수백 개가 되고, 각 leaf가 연결해야 하는 spine 수도 늘어난다. 케이블 수가 폭발한다.

해결책은 — super-spine(또는 spine-of-spines) 계층을 추가하는 것이다. 여러 개의 spine-leaf 패브릭(각각 수천 서버 규모)을 — super-spine 계층으로 묶는다. 구조는 "Clos의 Clos" — 2단계 Clos 네트워크다. Google의 Jupiter 네트워크가 이 구조를 쓴다(SIGCOMM 2015). 각 패브릭이 독립적으로 동작하고, 패브릭 간 통신은 super-spine을 거친다.

flowchart TD
    SS1["Super-Spine 1"] --> FAB_A["Fabric A<br/>(Leaf-Spine 그룹 1)"]
    SS1 --> FAB_B["Fabric B<br/>(Leaf-Spine 그룹 2)"]
    SS2["Super-Spine 2"] --> FAB_A
    SS2 --> FAB_B
    FAB_A --> RACKS_A["수천 서버"]
    FAB_B --> RACKS_B["수천 서버"]

ECMP 해시 — 트래픽이 골고루 가는가

spine-leaf에서 ECMP가 트래픽을 분산하지만 — 항상 골고루 가는 건 아니다. ECMP는 5-tuple(출발지 IP·목적지 IP·프로토콜·출발지 포트·목적지 포트)을 해시해서 — 경로를 결정한다. 해시가 균등해야 — 트래픽이 골고루 퍼진다.

문제는 — 두 서버 간의 모든 연결이 같은 5-tuple의 해시를 가지면 — 같은 spine으로만 간다. "elephant flow"(대용량 데이터 전송)가 한 경로를 독점하면 — 다른 트래픽이 밀린다. 해결책 — 동적 로드 밸런싱(dynamic load balancing): 경로의 실제 부하를 측정해서, 가장 한가한 경로로 보낸다. 또는 — packet spraying: 같은 연결의 패킷도 여러 경로로 분산(순서 보장 문제가 있어 신중하게 적용).

다음 글에서는 spine-leaf 위에서 동작하는 — 오버레이 네트워크(VXLAN·EVPN)를 다룬다. 물리적 네트워크(spine-leaf) 위에 — 논리적 네트워크를 "덧씌우는(overlay)" 기술이 — 어떻게 클라우드의 멀티테넌시를 가능하게 하는지.

3-tier에서 spine-leaf로의 마이그레이션

기존 3-tier 데이터센터를 spine-leaf로 마이그레이션하는 것은 — 단순한 하드웨어 교체가 아니라 아키텍처 전환이다. 점진적(rip-and-replace가 아닌)으로 진행하는 것이 일반적이다:

1. 새 랙은 spine-leaf로 — 새 서버 랙을 추가할 때 — 기존 aggregation 계층이 아니라 새 spine-leaf 패브릭에 연결
2. 기존 랙은 점진적 이전 — aggregation 계층의 서버를 — 새 leaf 스위치로 이관
3. 기존 core를 super-spine으로 재활용 — 기존 core 스위치를 — 새 spine-leaf 패브릭 간 연결(super-spine)로 용도 변경

이 과정에서 — 일시적으로 3-tier와 spine-leaf가 공존하는 상태가 된다. 두 구조 사이의 라우팅을 BGP 또는 OSPF로 처리하면서 — 점진적으로 전환한다. 마이그레이션 기간은 보통 6개월 ~ 수년. Google의 Jupiter 네트워크도 — 10년에 걸쳐 점진적으로 Clos로 전환했다(SIGCOMM 2015).

데이터센터 네트워크 토폴로지는 인프라의 뼈대다. 3-tier에서 spine-leaf로의 전환은 — east-west 트래픽 폭증이라는 현실적 필요에서 비롯됐다. 핵심은 — 모든 서버가 같은 홉 수로 통신하고(예측 가능한 지연), 스위치 추가로 선형 확장이 가능하고(scale-out), 오버서브스크립션을 낮출 수 있다는 것. 클라우드 벤더가 spine-leaf를 쓰는 이유가 여기에 있다.

---

참고

• RFC 7938, Lapukhov, P. et al. "Use of BGP for Routing in Large-Scale Data Centers", 2016 — 데이터센터 BGP. 접근 2026-07-21
• Clos, C. "A Study of Non-Blocking Switching Networks", Bell System Technical Journal, 1952 — Clos 네트워크 원논문. 접근 2026-07-21
• Facebook, "Introducing Data Center Fabric", Facebook Engineering Blog, 2014 — F16 Fabric 설계. 접근 2026-07-21
• Singh, A. et al. "Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google's Datacenter Network", SIGCOMM 2015 — Google의 Clos 네트워크. 접근 2026-07-21
• Al-Fares, M. et al. "A Scalable, Commodity Data Center Network Architecture", SIGCOMM 2008 — Clos 기반 DC 네트워크. 접근 2026-07-21
• Greenberg, A. et al. "VL2: A Scalable and Flexible Data Center Network", SIGCOMM 2009 — 데이터센터 네트워크 설계. 접근 2026-07-21
• Bari, M. F. et al. "Data Center Network Architecture", IEEE Communications Surveys, 2013 — DC 네트워크 서베이. 접근 2026-07-21
• Abts, D., Felderman, B. "A Guided Tour of Data-Center Networking", CACM, 2012 — DC 네트워크 개관. 접근 2026-07-21
• Cisco, "Cisco Data Center Spine-and-Leaf Architecture" white paper, 2020 — 상용 spine-leaf 설계 가이드. 접근 2026-07-21
• Arista Networks, "Cloud Building Architecture" — 상용 leaf 스위치 설계. 접근 2026-07-21
• Juniper, "IP Fabric Design Guide" — BGP 기반 데이터센터 패브릭. 접근 2026-07-21