0x2A Engineering

04. Spine-Leaf Deep Dive

16 min read

Spine-Leaf Deep Dive

Clos 네트워크 원형, East-West 트래픽 폭증 배경, BGP/VXLAN EVPN 구성, 실제 적용 사례

🎯 왜 Spine-Leaf인가?

트래픽 패턴의 변화

전통 데이터센터는 North-South 트래픽이 대부분이었음. 클라이언트가 서버에 요청하고 응답을 받는 단순한 구조.

flowchart TB
    subgraph Traditional["2000년대: North-South 중심"]
        Client["클라이언트"]
        Core["Core"]
        Server["서버"]
        Client <-->|"N-S 트래픽"| Core <--> Server
    end

그런데 2010년대 이후 상황이 바뀌었음:

변화결과
서버 가상화VM 수백~수천 대, VM 간 통신 폭증
vMotion/라이브 마이그레이션VM이 서버 간 이동 → 대용량 메모리 복사
분산 스토리지Ceph, vSAN, HDFS → 노드 간 복제 트래픽
마이크로서비스서비스 간 API 호출이 수십~수백 배 증가
빅데이터/AIMapReduce Shuffle, GPU 클러스터 간 통신

East-West 트래픽이 전체의 70~80%를 차지하게 되면서, 3-Tier 구조의 한계가 드러남.

3-Tier의 구조적 문제

flowchart TB
    Core["Core"]
    Agg1["Agg 1"]
    Agg2["Agg 2"]
    Acc1["Access 1 (Server A)"]
    Acc2["Access 2 (Server B)"]
    
    Core --> Agg1 --> Acc1
    Core --> Agg2 --> Acc2
    
    Acc1 -.->|"A-B: 최대 4홉, STP 제한"| Acc2
문제설명
STP 병목루프 방지를 위해 링크 절반 비활성화 → 대역폭 낭비
가변 지연같은 Agg 아래면 2홉, 다른 Agg면 4홉 → 예측 불가
Aggregation 병목East-West 트래픽이 Agg 계층에 집중
확장 한계Agg 스위치 포트 수가 확장 상한

📐 Clos Network: 이론적 원형

Charles Clos (1953)

Spine-Leaf는 갑자기 나온 게 아님. 1953년 Bell Labs 엔지니어 Charles Clos가 전화 교환망을 위해 설계한 Clos Network가 원형임.

핵심 아이디어: 소규모 스위치를 여러 단계로 조합하면, 하나의 거대한 Non-blocking 스위치와 동일한 효과를 얻을 수 있음.

3-Stage Clos

flowchart LR
    subgraph Ingress["Ingress (입력)"]
        I1["Switch 1"]
        I2["Switch 2"]
        I3["Switch 3"]
    end
    
    subgraph Middle["Middle (중간)"]
        M1["Switch A"]
        M2["Switch B"]
        M3["Switch C"]
    end
    
    subgraph Egress["Egress (출력)"]
        E1["Switch 1"]
        E2["Switch 2"]
        E3["Switch 3"]
    end
    
    I1 --- M1 & M2 & M3
    I2 --- M1 & M2 & M3
    I3 --- M1 & M2 & M3
    
    M1 --- E1 & E2 & E3
    M2 --- E1 & E2 & E3
    M3 --- E1 & E2 & E3

Clos의 조건:

  • Middle 스위치 수 ≥ Ingress 스위치의 입력 포트 수 → Non-blocking (어떤 입력이든 출력으로 경로 보장)

Clos → Spine-Leaf

데이터센터에서는 3-Stage Clos를 접어서 2계층으로 만든 것이 Spine-Leaf다.

Clos 3-Stage:    Ingress — Middle — Egress
                      ↓ 접기 (Ingress = Egress)
Spine-Leaf:      Leaf — Spine — Leaf

Leaf가 서버에 직접 연결되므로 Ingress이자 Egress 역할을 동시에 수행함.

🏗️ Spine-Leaf 상세 구조

기본 규칙

규칙설명
모든 Leaf ↔ 모든 Spine 연결Full mesh (Leaf-Spine 간)
Leaf 간 직접 연결 없음반드시 Spine을 경유
Spine 간 직접 연결 없음2-Stage에서는 불필요
서버는 Leaf에만 연결Spine에 서버 연결 안 함

홉 수 보장

flowchart LR
    SA["Server A (Leaf 1)"]
    S["Spine"]
    SB["Server B (Leaf 3)"]
    
    SA -->|"1홉"| S -->|"1홉"| SB

어떤 서버에서 어떤 서버로든 항상 최대 2홉. 지연이 예측 가능해짐.

5-Stage Clos (Super Spine)

대규모 데이터센터에서 Spine-Leaf 2계층으로 부족하면 Super Spine을 추가하여 5-Stage Clos로 확장함.

flowchart TB
    subgraph SS["Super Spine"]
        SS1["Super Spine 1"]
        SS2["Super Spine 2"]
    end
    
    subgraph Pod1["Pod 1"]
        S1["Spine"]
        L1["Leaf"]
        L2["Leaf"]
        L1 & L2 --- S1
    end
    
    subgraph Pod2["Pod 2"]
        S2["Spine"]
        L3["Leaf"]
        L4["Leaf"]
        L3 & L4 --- S2
    end
    
    S1 --- SS1 & SS2
    S2 --- SS1 & SS2
규모구조홉 수
중소2-Stage (Spine-Leaf)최대 2홉
대규모5-Stage (Super Spine)최대 4홉

Facebook, Google, Microsoft 같은 하이퍼스케일러들이 이 구조를 사용함.

⚖️ ECMP 상세

STP의 한계

3-Tier에서 STP는 루프를 방지하기 위해 하나의 경로만 활성화함.

flowchart LR
    A["Switch A"]
    B["Switch B"]
    C["Switch C"]
    
    A -->|"✅ Active"| B
    A -.->|"❌ Blocked"| C
    B -->|"✅ Active"| C

링크가 2개 있어도 하나는 차단 → 대역폭 50% 낭비.

ECMP 동작 원리

ECMP (Equal-Cost Multi-Path): 동일 비용의 모든 경로를 동시에 사용하여 트래픽을 분산함.

flowchart TB
    L1["Leaf 1 (Server A)"]
    
    S1["Spine 1"]
    S2["Spine 2"]
    S3["Spine 3"]
    S4["Spine 4"]
    
    L2["Leaf 2 (Server B)"]
    
    L1 -->|"25%"| S1 -->|"25%"| L2
    L1 -->|"25%"| S2 -->|"25%"| L2
    L1 -->|"25%"| S3 -->|"25%"| L2
    L1 -->|"25%"| S4 -->|"25%"| L2

ECMP 해싱: 각 플로우(src IP + dst IP + src port + dst port + protocol)를 해시하여 경로를 결정함. 같은 플로우는 항상 같은 경로로 → 패킷 순서 보장.

ECMP가 가능한 이유

Spine-Leaf에서는 L3 라우팅을 사용하기 때문에 STP가 필요 없음.

구분3-Tier (L2 중심)Spine-Leaf (L3 중심)
루프 방지STP (링크 차단)L3 라우팅 (TTL)
경로 활용Active 1개ECMP로 전체 활용
장애 복구STP 수렴 (초~십초)라우팅 수렴 (초 이내)

🔀 BGP in Datacenter

왜 BGP인가?

전통적으로 데이터센터 내부에서는 OSPF를 썼음. 그런데 대규모 Spine-Leaf 환경에서 문제가 생겼음:

프로토콜문제
OSPF단일 Area에 노드가 많으면 LSA 폭증, SPF 재계산 부하
OSPF Multi-AreaArea 설계 복잡, ABR 병목

eBGP가 대안으로 부상한 이유:

장점설명
확장성수천 노드까지 안정적
경로 제어Policy 기반 세밀한 제어
ECMPMulti-path 네이티브 지원
수렴 속도BFD 연동으로 빠른 장애 감지
멀티벤더모든 벤더가 지원

BGP Unnumbered

전통 BGP는 피어마다 IP를 할당해야 했음. Spine 4대 × Leaf 40대 = 160개 링크에 일일이 IP를 부여하면 관리가 힘듦.

BGP Unnumbered: 인터페이스의 IPv6 Link-Local 주소로 피어링. IP 할당 불필요.

# 전통 BGP (IP 필요)
Spine1 (10.0.1.1) ←→ Leaf1 (10.0.1.2)   # /30 서브넷 할당
Spine1 (10.0.2.1) ←→ Leaf2 (10.0.2.2)   # 또 할당...
Spine1 (10.0.3.1) ←→ Leaf3 (10.0.3.2)   # 링크마다 IP 관리

# BGP Unnumbered (IP 불필요)
Spine1 (fe80::1) ←→ Leaf1 (fe80::2)     # Link-Local 자동
→ IP 계획, 서브넷 관리가 필요 없음

ASN 설계

각 Leaf에 고유 ASN, 각 Spine에 고유 ASN을 부여하는 것이 일반적임.

flowchart TB
    subgraph Spines
        S1["Spine 1 (AS 65000)"]
        S2["Spine 2 (AS 65001)"]
    end
    
    subgraph Leaves
        L1["Leaf 1 (AS 65011)"]
        L2["Leaf 2 (AS 65012)"]
        L3["Leaf 3 (AS 65013)"]
    end
    
    S1 --- L1 & L2 & L3
    S2 --- L1 & L2 & L3

eBGP 피어링 관계:

  • Leaf 1 (AS 65011) ↔ Spine 1 (AS 65000): eBGP
  • Leaf 1 (AS 65011) ↔ Spine 2 (AS 65001): eBGP
  • 모든 연결이 eBGP → iBGP의 full-mesh/route-reflector 문제 없음

FRRouting 설정 예시

# Leaf 1 (AS 65011) — FRRouting (Cumulus Linux 등)
router bgp 65011
  bgp router-id 10.0.0.11
  bgp bestpath as-path multipath-relax    # ECMP 활성화
  
  neighbor fabric peer-group
  neighbor fabric remote-as external       # eBGP (상대 ASN 자동 감지)
  
  neighbor swp1 interface peer-group fabric # Spine 1 연결
  neighbor swp2 interface peer-group fabric # Spine 2 연결
  
  address-family ipv4 unicast
    network 10.0.0.11/32                   # Loopback 광고
    maximum-paths 4                        # ECMP 최대 경로 수
  exit-address-family

🌐 VXLAN EVPN

문제: L2 확장

Spine-Leaf는 L3 라우팅 기반인데, VM은 같은 서브넷(L2) 안에서 이동해야 하는 경우가 있음. vMotion으로 VM이 Leaf 1에서 Leaf 3로 이동하면, IP는 그대로인데 물리적 위치가 바뀜.

flowchart TB
    subgraph Before["이동 전"]
        L1B["Leaf 1"]
        VMB["VM (10.0.1.5)"]
        L1B --- VMB
    end
    
    subgraph After["이동 후 (vMotion)"]
        L3A["Leaf 3"]
        VMA["VM (10.0.1.5)"]
        L3A --- VMA
    end
    
    Before -->|"vMotion"| After

L3 네트워크 위에 L2를 확장할 방법이 필요함 → VXLAN

VXLAN 동작

VXLAN (Virtual Extensible LAN): L2 프레임을 UDP로 캡슐화하여 L3 네트워크 위에 터널링.

flowchart LR
    VM_A["VM A<br/>10.0.1.5"]
    VTEP1["VTEP<br/>(Leaf 1)"]
    IP_Net["IP Network<br/>(Spine-Leaf)"]
    VTEP2["VTEP<br/>(Leaf 3)"]
    VM_B["VM B<br/>10.0.1.10"]
    
    VM_A -->|"L2 Frame"| VTEP1 -->|"UDP:4789<br/>VXLAN 캡슐화"| IP_Net -->|"UDP:4789"| VTEP2 -->|"L2 Frame"| VM_B
용어설명
VTEPVXLAN Tunnel Endpoint. 캡슐화/역캡슐화 수행. 보통 Leaf 스위치
VNIVXLAN Network Identifier. VLAN ID의 확장판 (24비트 → 약 1,600만 개)
Underlay물리 네트워크 (Spine-Leaf, IP 라우팅)
Overlay가상 네트워크 (VXLAN 터널)

EVPN: Control Plane

VXLAN만으로는 어떤 VM이 어떤 VTEP 뒤에 있는지 알 방법이 flood-and-learn(브로드캐스트)뿐임. 이러면 대규모에서 BUM 트래픽 폭증.

EVPN (Ethernet VPN): BGP를 확장하여 MAC/IP 주소 정보를 Control Plane으로 배포함.

flowchart TB
    subgraph CP["Control Plane (BGP EVPN)"]
        direction LR
        L1_CP["Leaf 1:<br/>VM-A(10.0.1.5) = MAC aa:bb<br/>→ BGP로 광고"]
        L3_CP["Leaf 3:<br/>학습! VM-A는 Leaf 1 뒤에 있구나"]
        L1_CP -->|"BGP EVPN<br/>Route Type 2"| L3_CP
    end
    
    subgraph DP["Data Plane (VXLAN)"]
        direction LR
        L1_DP["Leaf 1 (VTEP)"]
        L3_DP["Leaf 3 (VTEP)"]
        L1_DP <-->|"VXLAN 터널"| L3_DP
    end
    
    CP --> DP

EVPN Route Type:

Type이름용도
1Ethernet Auto-Discovery멀티호밍, 빠른 수렴
2MAC/IP AdvertisementMAC+IP 위치 광고 (핵심)
3Inclusive MulticastBUM 트래픽 처리
5IP PrefixL3 라우팅 정보

VXLAN EVPN의 장점

장점설명
L2 확장L3 Underlay 위에서 L2 서브넷 자유롭게 확장
멀티테넌시VNI로 테넌트별 네트워크 완전 분리 (최대 ~16M)
VM 이동성어떤 Leaf로 이동해도 IP/MAC 유지
BUM 최소화Control Plane 학습으로 불필요한 브로드캐스트 제거
분산 게이트웨이각 Leaf가 Anycast GW 역할 → 트래픽 최적화

🖥️ 화이트박스 스위치와 NOS

전통 vs 화이트박스

구분전통 (Cisco, Arista 등)화이트박스
하드웨어벤더 전용ODM 범용 (Edgecore, Dell 등)
OS벤더 전용 (IOS, EOS)선택 가능 (Cumulus, SONiC)
비용높음낮음 (30~60% 절감)
유연성벤더 로드맵 의존오픈소스 커뮤니티

주요 NOS (Network OS)

NOS개발특징
Cumulus LinuxNVIDIA (인수)Debian 기반 Linux, FRRouting 내장
SONiCMicrosoft (오픈소스)Azure에서 검증, SAI 추상화
OpenSwitch (OPX)DellDell OS10 기반
Arista EOSAristaLinux 기반이지만 상용, 자동화 강점

하이퍼스케일러들의 선택:

  • Microsoft Azure → SONiC
  • Facebook/Meta → FBOSS (자체 NOS)
  • Google → 자체 NOS
  • 일반 기업 → Cumulus Linux 또는 Arista EOS

🏢 실제 적용 사례

Facebook (Meta) — Data Center Fabric

2014년 발표. 기존 클러스터 단위 네트워크를 Fabric으로 전환.

항목내용
규모데이터센터당 수만 대 서버
구조4-post Spine-Leaf (Pod 단위) + Fabric Spine
특징모든 서버 간 균일한 대역폭
효과서비스 배치를 네트워크 토폴로지와 무관하게 자유롭게

Microsoft Azure

항목내용
규모60+ 리전, 리전당 수십만 서버
구조5-Stage Clos (Super Spine 포함)
NOSSONiC (자체 개발 → 오픈소스 공개)
특징화이트박스 + SONiC으로 비용 절감

국내 사례

환경적용 패턴
공공 클라우드 IDCHCI(Nutanix/VxRail) + Spine-Leaf 조합. 10G/25G Leaf
금융 차세대VXLAN EVPN 기반 멀티테넌시. 망분리 요구 대응
통신사 NFV가상화된 네트워크 기능(VNF)의 East-West 트래픽 처리
대기업 프라이빗 클라우드VMware NSX + Spine-Leaf Underlay

📐 설계 시 고려사항

용량 산정

[예시: 서버 500대, 서버당 25G]

1. Leaf 산정
   - Leaf 스위치: 48포트 (서버) + 8포트 (Spine 업링크)
   - 필요 Leaf: 500 ÷ 48 ≈ 11대

2. Spine 산정  
   - Leaf 업링크: 8포트 × 100G = 800G
   - 서버 다운링크: 48포트 × 25G = 1,200G
   - Oversubscription: 1,200G ÷ 800G = 1.5:1
   - Spine 포트: 11개 Leaf 연결 → 최소 11포트
   - Spine 스위치: 32포트 100G → 4대 (8포트씩 사용)

3. 결과
   - Leaf 11대 (48×25G + 8×100G)
   - Spine 4대 (32×100G)
   - Oversubscription 1.5:1

주요 설계 파라미터

파라미터일반 권장설명
Oversubscription1:1 ~ 3:11:1이면 Non-blocking
Spine 수2~8대이중화 최소 2대, ECMP 경로 수
Leaf 업링크 속도서버 포트의 4배25G 서버 → 100G 업링크
MTU9216 (Jumbo)VXLAN 오버헤드(50B) 수용
BFD활성화빠른 장애 감지 (50~300ms)

VXLAN 설계 시 추가 고려

항목설명
VNI 설계테넌트/서브넷별 VNI 매핑 계획
Anycast Gateway모든 Leaf에 동일 GW IP/MAC → 분산 라우팅
ARP SuppressionEVPN으로 ARP 브로드캐스트 억제
Route Reflector대규모 시 BGP RR로 피어링 수 줄임

📋 기술 스택 조합 예시

엔터프라이즈 (검증 우선)

HW: Cisco Nexus 9000 / Arista 7050X
NOS: NX-OS / Arista EOS
Underlay: eBGP
Overlay: VXLAN EVPN
관리: Cisco ACI / Arista CloudVision

비용 최적화 (오픈소스)

HW: Edgecore / Dell S5200 시리즈
NOS: Cumulus Linux / SONiC
Underlay: eBGP (FRRouting)
Overlay: VXLAN EVPN
관리: Ansible + NetBox (IPAM)

하이퍼스케일 (자체 운영)

HW: 화이트박스 (ODM 주문 제작)
NOS: SONiC / 자체 NOS
Underlay: eBGP
Overlay: 필요 시 VXLAN 또는 자체 Encap
관리: 자체 자동화 플랫폼

🔗 관련 문서

🔗 참고 자료

그래프 뷰

백링크