🙋♂️ 이런 분들을 위해 작성했습니다.
- 기존 3-Tier 네트워크의 성능 한계와 운영 복잡성에 지치신 네트워크 엔지니어
- 데이터센터의 100G급 업그레이드를 계획 중인 IT 인프라 관리자
- Spine-Leaf 아키텍처와 ECMP의 실제 구축 사례가 궁금하신 실무 개발자 및 아키텍트
들어가며: 문제의 시작과 우리의 목표 (Introduction & Goal)
History & Why: 왜 이 프로젝트가 필요했나요?
A대학교는 수많은 학생과 교직원, 그리고 방대한 연구 데이터를 처리하는 거대한 IT 인프라를 운영하고 있었습니다. 하지만 기존의 전통적인 3-Tier(Access - Aggregation - Core) 네트워크 구조는 한계에 봉착했습니다. 😒
트래픽 패턴이 변했기 때문입니다. 과거에는 주로 사용자가 인터넷(Core)에 접속하는 '남-북(North-South)' 트래픽이 대부분이었지만, 가상화와 클라우드 도입으로 서버 간 통신, 스토리지 접근, VM 마이그레이션 등 데이터센터 내부의 '동-서(East-West)' 트래픽이 폭증했습니다.
이 모든 트래픽이 Aggregation(집선) 스위치와 Core 스위치로 몰리면서 고질적인 병목 현상이 발생했습니다. 설상가상으로, 네트워크 안정성을 위해 사용하던 STP(Spanning Tree Protocol)는 이중화된 경로 중 하나를 강제로 'Block' 시켜 대역폭의 50%를 낭비하고 있었죠. 10G로 증설해도 절반밖에 쓰지 못하는 비효율의 극치였습니다.
우리의 핵심 목표(Goal)는 명확했습니다. "100G급 대역폭을 완벽히 지원하며, 장애 시에도 중단이 없고, 확장이 용이한 차세대 Non-blocking 네트워크를 구축한다."
이를 위해 설정한 핵심 지표(Key Metric)는 다음과 같았습니다.
- 코어 대역폭: 10G → 100G (10배 증설)
- 네트워크 지연 시간: 기존 대비 50% 이상 감소
- 장애 복구 시간(RTO): 거의 무중단 0초 (Active-Active 경로를 통한 무중단)
Our Vision
단순히 장비를 교체하는 것이 아니었습니다. 트래픽이 막힘없이 흐르는 '고속도로'를 새로 설계하는 것이었습니다. 이 솔루션을 통해 A대학교의 모든 구성원이 언제 어디서든 끊김 없이 연구와 학업에 몰두할 수 있는 디지털 캠퍼스를 만드는 것이 우리의 비전이었습니다.
💥 핵심 과제와 해결 과정 (Challenges & Solutions)
The Problem: 100G 시대에 맞지 않는 3-Tier와 STP
가장 큰 기술적 난제는 '어떻게 3-Tier의 구조적 한계를 극복하고 무중단으로 100G로 전환할 것인가'였습니다.
100G 장비를 도입해 Core와 Aggregation을 단순히 업그레이드하는 것은 답이 아니었습니다. 트래픽이 몰리는 '병목 지점'이 그대로 존재하기 때문이죠. 또한, STP가 활성화된 L2 네트워크에서 100G 링크를 이중화해도, 결국 하나의 링크는 놀고 있게 됩니다. 100G짜리 백업 회선을 두는 셈이죠.
아래 다이어그램은 이러한 전통적인 3-Tier 구조의 문제점을 시각적으로 보여줍니다. 트래픽이 Core와 Aggregation 스위치로 집중되는 병목 현상(붉은색 박스)과, STP로 인해 차단(Block)되어 낭비되는 경로(빨간 점선)를 확인할 수 있습니다. 특히 서버 간 '동-서 트래픽'(주황색 점선)이 Core까지 올라갔다 내려와야 하는 비효율도 볼 수 있습니다.
graph TD
subgraph "전통적인 3-Tier 아키텍처의 문제점"
direction TB
C1[Core 1] --- A1[Agg 1]
C1 --- A2[Agg 2]
C2[Core 2] --- A1
C2 --- A2[Agg 2]
A1 --- Ac1[Access 1]
A1 --- Ac2[Access 2]
A2 --- Ac3[Access 3]
A2 --- Ac4[Access 4]
%% STP Block 표시
linkStyle 3 stroke:red,stroke-dasharray: 5 5,stroke-width:2px
C2 -.->|❌ STP Block| A1
Ac1 --- S1[Server A]
Ac2 --- S2[Server B]
Ac3 --- S3[Server C]
Ac4 --- S4[Server D]
%% 병목 현상 강조 (Core/Agg)
style C1 fill:#f99,stroke:#c00,stroke-width:2px
style C2 fill:#f99,stroke:#c00,stroke-width:2px
style A1 fill:#f99,stroke:#c00,stroke-width:2px
style A2 fill:#f99,stroke:#c00,stroke-width:2px
%% 동-서 트래픽 (문제)
S2==>|East-West 트래픽|Ac2
Ac2==>A1
A1==>C1
C1==>A2
A2==>Ac3
Ac3==>S3
linkStyle 8 stroke:orange,stroke-width:3px,stroke-dasharray: 3 3
linkStyle 9 stroke:orange,stroke-width:3px,stroke-dasharray: 3 3
linkStyle 10 stroke:orange,stroke-width:3px,stroke-dasharray: 3 3
linkStyle 11 stroke:orange,stroke-width:3px,stroke-dasharray: 3 3
linkStyle 12 stroke:orange,stroke-width:3px,stroke-dasharray: 3 3
linkStyle 13 stroke:orange,stroke-width:3px,stroke-dasharray: 3 3
end
< 그림 1: 3-Tier 구조의 병목과 STP로 인한 비효율적인 경로 >
우리는 100G 링크 여러 개를 동시에 모두 사용하며, 특정 장비가 장애 나도 트래픽이 1초도 끊기지 않고 자동으로 우회하는 아키텍처가 필요했습니다.
The Journey: L2 Fabric의 유혹과 L3로의 선회
처음에는 기존 L2 구성을 최대한 재활용할 수 있는 L2 Fabric 기술들(예: Cisco FabricPath, TRILL)을 검토했습니다. 매력적으로 들렸죠. 하지만 깊이 파고들수록 두 가지 큰 문제에 부딪혔습니다.
- 벤더 종속성: 이 기술들은 대부분 특정 벤더의 장비에서만 동작하는 사양(Proprietary)이었습니다. A대학교처럼 다양한 시스템이 연결된 환경에서 벤더에 종속되는 것은 미래 확장성에 치명적이었습니다.
- L2의 본질적 한계: 아무리 포장해도 L2는 L2였습니다. 브로드캐스트 스톰의 위험에서 완전히 자유로울 수 없었고, 스케일링에도 분명한 한계가 있었습니다. "그래, 어차피 새로 까는 거. 검증된 표준 기술로 가자. 코어까지 전부 L3 라우팅으로 올리자!"
The Solution: Spine-Leaf 아키텍처와 BGP-ECMP
우리의 최종 선택은 Spine-Leaf 아키텍처였습니다.
Spine-Leaf 아키텍처는 모든 Leaf 스위치가 모든 Spine 스위치에 연결되는 2-Tier 구조입니다. 아래 다이어그램처럼, 이 구조는 모든 경로를 ECMP를 통해 동시에 활성화(녹색선)하며, 서버 간 통신(파란 점선)이 항상 예측 가능한 2-Hop(Leaf-Spine-Leaf) 내에 완료되도록 보장합니다. 병목 지점이 사라지고 모든 대역폭을 100% 활용할 수 있게 됩니다.
graph TD
subgraph "Spine-Leaf 아키텍처 (2-Tier)"
direction TB
subgraph "Spine (Backbone) 🌿"
direction LR
SP1[Spine 1]
SP2[Spine 2]
SP3[Spine 3]
end
subgraph "Leaf (Access) 🍃"
direction LR
L1[Leaf 1]
L2[Leaf 2]
L3[Leaf 3]
end
%% Leaf to Spine (Full-Mesh / ECMP)
L1 --- SP1
L1 --- SP2
L1 --- SP3
L2 --- SP1
L2 --- SP2
L2 --- SP3
L3 --- SP1
L3 --- SP2
L3 --- SP3
%% ECMP 경로 강조 (모든 경로 Active)
linkStyle 0 stroke:green,stroke-width:2px
linkStyle 1 stroke:green,stroke-width:2px
linkStyle 2 stroke:green,stroke-width:2px
linkStyle 3 stroke:green,stroke-width:2px
linkStyle 4 stroke:green,stroke-width:2px
linkStyle 5 stroke:green,stroke-width:2px
linkStyle 6 stroke:green,stroke-width:2px
linkStyle 7 stroke:green,stroke-width:2px
linkStyle 8 stroke:green,stroke-width:2px
%% 서버 연결
L1 --- SRV1[Server A]
L1 --- SRV2[Server B]
L2 --- SRV3[Server C]
L2 --- SRV4[Server D]
%% 동-서 트래픽 (개선)
SRV2 ==> |"East-West (Max 2-Hop)"| L1
L1 ==> SP1
SP1 ==> L2
L2 ==> SRV3
linkStyle 13 stroke:blue,stroke-width:3px,stroke-dasharray: 3 3
linkStyle 14 stroke:blue,stroke-width:3px,stroke-dasharray: 3 3
linkStyle 15 stroke:blue,stroke-width:3px,stroke-dasharray: 3 3
linkStyle 16 stroke:blue,stroke-width:3px,stroke-dasharray: 3 3
end<그림 2: Spine-Leaf 구조의 예측 가능한 2-Hop 경로와 ECMP>
이는 3-Tier 구조를 2-Tier(Spine-Leaf)로 단순화한 모델입니다.
- Leaf 🍃: 서버, 스토리지, 사용자 단말이 연결되는 스위치입니다. (Access 계층 역할)
- Spine 🌿: 모든 Leaf 스위치를 100G로 연결하는 백본 스위치입니다. (Core/Aggregation 역할)
핵심 규칙은 간단합니다.
- 모든 Leaf는 모든 Spine에 연결된다.
- Leaf끼리, Spine끼리는 절대 연결되지 않는다.
이 구조의 장점은 명확합니다.
- 예측 가능한 성능: 모든 트래픽은 정확히 2-Hop(Leaf → Spine → Leaf) 만에 데이터센터 내 어디든 도달합니다. 3-Tier처럼 핑퐁을 치며 어디서 막힐지 고민할 필요가 없습니다.
- Non-blocking Fabric: Spine 스위치의 용량만 충분하다면, 모든 Leaf가 100G로 동시에 통신해도 막힘이 없습니다.
- 수평 확장(Scale-Out): 대역폭이 더 필요하면 Spine 스위치를 추가하고, 포트가 더 필요하면 Leaf 스위치를 추가하면 끝입니다.
이 구조 위에서 우리는 BGP(Border Gateway Protocol)와 ECMP(Equal-Cost Multi-Path)라는 마법을 구현했습니다.
- ECMP: Spine으로 가는 모든 경로(100G 링크)를 '동일 비용(Equal-Cost)'으로 설정합니다. ECMP는 이 모든 경로를 'Active-Active'로 취급하며, 트래픽을 해시 기반으로 골고루 분산시킵니다. 100G 링크 3개가 있다면, A대학교는 300G의 대역폭을 동시에 사용하는 것입니다!
- BGP: Leaf와 Spine 간의 라우팅 프로토콜로 BGP를 사용했습니다. (정확히는 eBGP) BGP는 인터넷을 지탱하는 매우 안정적이고 검증된 L3 프로토콜입니다.
만약 Spine 스위치 하나가 다운되거나 100G 링크 하나가 끊어져도, ECMP는 즉시 해당 경로를 제외하고 나머지 살아있는 경로로 트래픽을 자동 분산합니다. 서비스 중단은 '0'입니다. ✅
🏛️ 우리가 선택한 기술과 아키텍처 (Solution Overview)
Why this Stack?
- Why Spine-Leaf (vs. 3-Tier)?
- 3-Tier의 고질적인 병목 지점(Aggregation/Core)을 원천적으로 제거했습니다.
- 수직 확장(Scale-Up)이 아닌 수평 확장(Scale-Out)이 가능해져, 비용 효율적으로 미래 트래픽 증가에 대응할 수 있습니다.
- Why ECMP (vs. STP/L2)?
- STP가 대역폭의 50%를 낭비하는 반면, ECMP는 모든 물리적 링크를 100% 사용합니다.
- L2의 루프(Loop)와 브로드캐스트 스톰 문제를 고민할 필요가 없습니다. L3 라우팅은 TTL(Time-To-Live) 값으로 루프를 방지하며, 트러블슈팅이 훨씬 명확합니다.
- Why BGP-EVPN (VXLAN)? (Bonus)
- A대학교의 다양한 학과와 연구실 네트워크를 논리적으로 분리하고 격리하기 위해, 물리적 Spine-Leaf 네트워크 위에 VXLAN이라는 오버레이(Overlay) 기술을 적용했습니다.
- BGP-EVPN은 이 VXLAN 환경에서 L2/L3 가상 네트워크 정보를 효율적으로 전달하는 컨트롤 플레인입니다. 이를 통해 물리적 인프라에 구애받지 않고 유연하게 네트워크 서비스를 제공할 수 있게 되었습니다.
Key Components
- Leaf Switches (ToR): 100G 업링크(Spine 방향)와 10G/25G 다운링크(서버/단말 방향)를 제공하는 고성능 스위치를 배치했습니다.
- Spine Switches (Backbone): 모든 Leaf로부터 100G 트래픽을 받아 지연 없이 처리할 수 있는 대용량 Non-blocking 스위치를 배치했습니다.
- BGP-EVPN Controller: VXLAN 터널링과 네트워크 정책을 중앙에서 관리하는 컨트롤러를 도입하여 운영 효율성을 높였습니다.
📈 주요 성과와 비즈니스 임팩트 (Result)
프로젝트 완료 후, 우리는 설정했던 핵심 지표(Key Metric)를 초과 달성했습니다.
정량적 성과
- 코어 대역폭 100G 확보: 기존 10G 대비 10배의 대역폭을 확보했으며, ECMP 적용으로 실제 가용 대역폭은 400G 이상으로 증대되었습니다. (Spine 수량에 따라 다름)
- 네트워크 지연 시간 70% 감소: 2-Hop 만에 통신이 완료되면서 서버 간 응답 속도가 획기적으로 향상되었습니다.
- 무중단 서비스 달성: 실제 운영 중 Spine 스위치 하나를 의도적으로 재부팅하는 테스트를 진행했으며, 단 1-Packet의 손실도 없이 서비스가 정상 유지됨을 확인했습니다.
정성적 효과
- 운영 복잡성 대폭 감소: "또 STP 때문에 장애 났어?"라는 말이 사라졌습니다. L3 기반의 명확한 라우팅 테이블은 장애 분석과 트러블슈팅 시간을 획기적으로 단축시켰습니다.
- 비즈니스 민첩성 확보: 대규모 연구(예: AI 모델링)를 위한 고대역폭 서버 클러스터를 증설할 때, 며칠씩 걸리던 네트워크 구성 작업이 몇 시간 만에 완료됩니다.
- 안정적인 서비스 제공: 대규모 온라인 강의, 수강 신청 등 트래픽이 폭주하는 상황에서도 지연 없는 안정적인 서비스를 제공할 수 있게 되었습니다. 👌
마무리하며: 우리의 경험이 당신에게 주는 가치 (Conclusion)
A대학교의 100G 시대로의 전환은 단순히 케이블과 장비를 바꾸는 '교체' 작업이 아니었습니다. 트래픽이 흐르는 '길'을 다시 설계하는 '아키텍처'의 문제였습니다.
전통적인 3-Tier와 STP의 시대는 저물고 있습니다. 폭증하는 동-서 트래픽을 감당하기 위해서는 Spine-Leaf와 L3 기반의 ECMP가 표준적인 해답이 되고 있습니다.
이 프로젝트를 통해 얻은 가장 큰 교훈은 "기술은 '최신'이 아니라 '목적'에 맞아야 하며, 병목 현상은 결국 예측 가능한(predictable) 아키텍처 설계를 통해 해결할 수 있다"는 것이었습니다.
💡 Call to Action: 당신을 위한 제언
이 글을 읽고 비슷한 고민을 하고 계신 분들께 두 가지 실질적인 조언을 드리고 싶습니다.
- 당신의 네트워크에 STP가 있다면, 지금 당장 L3 라우팅 도입을 검토하세요. 낭비되고 있는 50%의 대역폭을 되찾는 것만으로도 엄청난 성능 향상을 경험할 수 있습니다.
- '무중단 마이그레이션'을 두려워하지 마세요. 저희 역시 기존 3-Tier 네트워크와 새로운 Spine-Leaf 네트워크를 일정 기간 연동하는 하이브리드 전략을 사용했습니다. 코어부터 단계적으로 전환하고 트래픽을 서서히 이전하는 방식으로 리스크를 최소화할 수 있습니다.
앞으로의 Future
A대학교의 차세대 네트워크는 이제 SDN(Software-Defined Networking)과 네트워크 자동화(Network Automation)를 받아들일 준비를 마쳤습니다. 향후 Ansible이나 Python 스크립트를 통해 반복적인 네트워크 구성 작업을 자동화하여, 우리 엔지니어들이 더 가치 있는 아키텍처 설계에 집중할 수 있도록 발전시킬 계획입니다.
긴 글 읽어주셔서 감사합니다. 여러분의 100G 고속도로 구축 여정에 이 글이 작은 도움이 되기를 바랍니다.
'Tech_Goest' 카테고리의 다른 글
| 수백 명 동시 접속에도 끊김 없는 Wi-Fi의 비밀: C대학교 무선망 구축 회고 (0) | 2025.10.24 |
|---|---|
| [VLAN/QoS] 전화가 끊기던 B기업 네트워크, '트래픽 분리'와 '이중화'로 살려낸 이야기 (0) | 2025.10.24 |
| EPP(Endpoint Protection Platform)를 활용한 혁신: 통합 관리 기반 엔드포인트 (0) | 2025.10.21 |
| 2-Tier로의 단순화 : 차세대 보안 네트워크 구축 솔루션🤨 (0) | 2025.10.15 |
| SSL VPN을 활용한 혁신: 공공 기관 원격근무 환경의 Active-Active HA 기반 안정성 확보 🛡️ (0) | 2025.10.01 |
