2.3 네트워크 토폴로지와 라우팅 메커니즘

2.3 네트워크 토폴로지와 라우팅 메커니즘

분산 시스템의 성능과 생존력을 결정짓는 가장 핵심적인 인프라는 노드들이 서로 어떻게 연결되어 있는지(토폴로지, Topology)와 그 안에서 데이터가 길을 찾는 원리(라우팅, Routing)이다. 기존 미들웨어 생태계는 대부분 IP 주소와 포트(Port) 번호에 의존하는 하부 네트워크의 라우팅 체계에 무임승차(Piggybacking)하는 방식을 취해왔다. 그러나 이러한 호스트 중심(Host-centric)의 라우팅은 물리적인 네트워크 구조가 변동될 때마다 극심한 취약성을 드러낸다.

**Zenoh(제노)**는 이러한 한계를 극복하기 위해 물리적 네트워크 레이어와 완전히 분리된 독자적인 **오버레이 라우팅 평면(Overlay Routing Plane)**을 구축한다. L3 네트워크 스위치가 IP 주소를 기반으로 패킷을 포워딩하듯, Zenoh 라우팅 엔진은 애플리케이션 레벨의 ‘리소스 이름(Resource Name)’ 자체를 라우팅의 유일한 식별자로 삼는다.

본 장에서는 Zenoh가 단일한 통신 구조에 얽매이지 않고 P2P 메쉬(Mesh)와 계층형 트리(Tree) 토폴로지를 자유롭게 오가며 변환하는 유연성을 살펴보고, 이 복잡한 그물망 속에서 어떻게 라우팅 루프(Loop)를 방지하고 최단 경로(Shortest Path)를 실시간으로 개척해 내는지, 그 기저의 수학적 알고리즘과 링크 상태(Link State) 관리 메커니즘을 심도 있게 분석한다.

1. 유연한 토폴로지 지원 (P2P 메쉬, 브로커형, 트리형 혼합 구조)

통신 미들웨어 공학의 오랜 철학 논쟁 중 하나는 “중앙 집중형 브로커 아키텍처가 우월한가, 아니면 완전 분산형 P2P 아키텍처가 우월한가?“이다. 이 질문에 대해 **Zenoh(제노)**는 “네트워크 환경과 스케일에 따라 정답은 동적으로 변한다“는 실용주의적 결론을 내리고, 모든 토폴로지를 하나의 프로토콜로 융합(Convergence)하는 아키텍처를 창조해 냈다.

Zenoh 네트워크는 단일 형태(Monomorphic)를 강요하지 않는 다변형(Polymorphic) 토폴로지를 완벽하게 지원한다. 시스템 설계자는 노드의 배포 방식(Role)을 조정하는 것만으로 다음과 같은 세 가지 상이한 네트워크 위상을 자유롭게 오가거나 결합할 수 있다.

1.1 분산 P2P 메쉬(Mesh) 토폴로지

라우터 노드를 일절 배제하고, 동일 서브넷(Subnet) 내의 디바이스들을 오직 Zenoh 피어(Peer) 모드로만 배포할 경우 완전한 분산 메쉬 망이 형성된다.
이 토폴로지에서는 특정 관리 노드가 존재하지 않으며, 각 피어가 서로의 링크 상태(Link State)를 교환하여 거미줄 같은 통신로를 확립한다. 브로커가 파괴되면 망이 마비되는 단일 실패 지점(SPoF)이 전혀 없으므로, 국방 전술망이나 자율주행 로봇(ROS 2) 군집 통신처럼 ’절대적인 생존성’과 ’최단 홉(Hop)을 통한 초저지연’이 필수적인 환경에 최적화되어 있다.

1.2 허브-앤-스포크(Hub-and-Spoke) 브로커형 토폴로지

MQTT의 전형적인 중앙 집중식 구조를 그대로 모방할 수도 있다. 수백 개의 Zenoh 클라이언트(Client) 센서 노드들이 중앙의 단일 **Zenoh 라우터(Router)**만을 바라보고 연결(Upstream)되는 구조다.
피어 메쉬 망 구조에서 발생하는 O(N²) 수준의 디스커버리 오버헤드가 부담스러운 초소형 IoT 네트워크나, 중앙에서 트래픽을 일괄 통제하고 백업해야 하는 레거시 산업 환경에 매우 효과적이다.

1.3 라우팅 트리(Tree) 및 혼합(Hybrid) 토폴로지

Zenoh의 진정한 가치는 앞선 메쉬와 브로커 구조를 유기적으로 엮어 하나로 합치는 데 있다.

  • 복수의 공장(Local LAN)에서는 수십 대의 설비들이 무중단 P2P 메쉬로 통신한다.
  • 이 로컬 피어들은 공장 출구에 설치된 **에지 라우터(Edge Router)**와 허브 형태로 묶인다.
  • 전 세계의 공장 에지 라우터들은 다시 퍼블릭 클라우드의 **백본 라우터(Backbone Router)**들과 연결되어 거대한 **계층적 트리(Hierarchical Tree)**를 형성한다.

결과적으로 Zenoh는 에지 말단의 치열한 P2P 로컬 통신과, 클라우드를 관통하는 거대한 백본 통신을 어떠한 게이트웨이(Gateway)나 트랜슬레이터(Translator)의 개입 없이 매끄럽게 흡수해 내는 하이브리드 토폴로지를 완성한다.

2. 이름 기반 라우팅(Name-based Routing)의 핵심 원리

전통적인 IP(TCP/UDP) 네트워크 망에서는 패킷의 라우팅 방향을 결정짓는 절대적인 식별자가 ’목적지 호스트의 IP 주소’이다. 반면, Zenoh(제노) 라우팅 아키텍처의 심장부에서는 IP 주소라는 물리적 굴레를 완전히 탈피하여, 흐르는 데이터의 내용 자체를 식별하는 **‘리소스 이름(Resource Name, Key Expression)’**을 척도로 삼아 트래픽을 포워딩한다. 이는 정보 중심 네트워킹(ICN, Information-Centric Networking)의 사상을 미들웨어 코어에 완벽히 이식한 결과이다.

2.1 IP 라우팅의 한계와 이름 기반 라우팅의 당위성

A 디바이스가 [센서 온도 값]을 필요로 할 때, 기존 방식에서는 “온도 센서를 장착한 B 디바이스의 서버(IP: 192.168.1.10)로 HTTP 요청을 보낸다“는 개념으로 접근해야 했다. 이는 물리 토폴로지의 종속성을 야기한다. B 디바이스의 IP가 바뀌거나, 에지 캐시(Cache) 서버가 중간에 구축되었을 때, 응용 애플리케이션의 엔드포인트 코드가 수정되어야 하는 치명적 취약점을 안고 있다.

Zenoh 환경에서 애플리케이션은 대상의 위치나 IP를 묻지 않는다. 그저 전역 데이터 평면(Global Data Plane)을 향해 “factory/sensor/temp 데이터를 내놓아라(Query)” 혹은 “factory/sensor/temp 데이터를 여기 던진다(Publish)“라는 의도(Intent)만을 선언한다. 즉, 라우팅의 초점이 ’Where(어디로)’에서 ’What(무엇을)’으로 완전히 전환되는 것이다.

2.2 트라이(Trie) 구조를 통한 초고속 경로 매칭 알고리즘

Zenoh 네트워크의 핵심 노드(피어, 라우터)들은 이 거대한 이름 공간에 대한 내비게이션 엔진인 **라우팅 테이블(Routing Table)**을 보유하고 있다. 일반적인 IP 서브넷 마스크(Subnet Mask) 트리 대신, Zenoh 엔진은 수십만 개의 복잡한 문자열 기반 Key Expression을 극도로 빠르게 검색하고 병합(Aggregation)할 수 있는 트라이(Trie, Prefix Tree) 혹은 변형된 Patricia Trie 자료구조를 메모리에 구축한다.

  • 관심사(Interest)의 전파: 어떤 클라이언트 노드가 factory/door/+/status라는 와일드카드가 포함된 리소스를 구독(Subscribe)하면, 이 구독 선언(Interest)정보는 즉시 상위 라우터 트리망을 타고 네트워크 전역으로 전파된다.
  • 포워딩 평면(Forwarding Plane): 이후 지구 반대편의 누군가가 factory/door/1/status라는 이름을 달고 10 바이트짜리 데이터를 쏘아 올리면(Publish), 각 라우터들은 데이터 패킷의 헤더에 박힌 이 ’이름(Key)’을 추출한다. 그리고 자신의 메모리에 구축된 Trie 구조와 순식간에 매칭(Matching) 연산을 수행하여, 사전에 등록되어 있던 관심사(Interest)의 가지(Branch) 방향으로만 데이터를 정확히 흘려보낸다.

2.3 구독 병합(Aggregation)에 의한 폭발적 스케일링

이름 기반 라우팅의 백미는 멀티캐스트 오버헤드를 제로(0)에 가깝게 소멸시키는 **병합 메커니즘(Aggregation Mechanism)**에 있다.
어떤 에지 라우터 하위에 100만 대의 센서 노드가 각각 factory/sensor/1부터 factory/sensor/1000000까지 100만 개의 구독을 선언했다고 가정하자. 이 에지 라우터는 100만 개의 라우팅 정보를 상위 백본으로 일일이 올려보내지 않는다. 영리한 Zenoh 트라이 엔진은 이들을 묶어, 상위 라우터에게는 단 1단어, 즉 “factory/sensor/**에 대한 데이터는 나에게 다 보내라“라고 요약(Reduce)하여 보고한다.

이러한 선언적 이름의 압축과 요약 덕분에 Zenoh 네트워크는 라우팅 제어 대역폭의 낭비 현상(Broadcast Storm) 없이 IoT 수준의 초밀집 노드 스웜(Swarm)을 거뜬히 제어해 낼 수 있다.

3. 최단 경로 탐색 알고리즘과 링크 상태(Link State) 관리

거대한 P2P 메쉬(Mesh)나 라우터 트리(Tree) 토폴로지 내부에서 데이터가 목적지(Subscriber 혹은 Query 대상)를 향해 나아갈 때, 단순히 이름(Name)을 안다는 것만으로는 부족하다. 해당 이름이 등록된 곳으로 향하는 ’가장 빠르고 효율적인 길(Shortest Path)’을 찾아내는 능력이 필수적이다.

Zenoh(제노) 라우팅 아키텍처는 IP 네트워크의 OSPF(Open Shortest Path First)나 IS-IS 프로토콜에서 영감을 받은, 그러나 자원 제약 환경에 맞게 극도로 경량화된 링크 상태(Link State) 라우팅 알고리즘을 변형하여 사용한다.

3.1 링크 상태(Link State) 데이터베이스 구축

네트워크 상의 모든 라우터 및 피어(Peer) 노드는 자신과 직접 연결된 이웃 노드들과의 연결 상태, 즉 링크 상태(Link State)를 주기적으로 측정한다. 이때 측정되는 지표는 단순히 연결 유무(Alive/Dead)를 넘어서, 해당 링크의 대역폭, 물리적 지연 시간(Latency), 그리고 사용 중인 와이어 프로토콜(TCP, UDP, QUIC 등)의 신뢰성 가중치(Cost)를 포함한다.

노드들은 이 정보(Link State Advertisement, LSA)를 가십 프로토콜(Gossip Protocol)을 통해 전 네트워크에 파급(Flooding)시킨다. 수렴(Convergence) 과정을 거친 후, 각 라우터는 네트워크 전역의 미니어처 맵(Topology Database)을 자신의 로컬 메모리에 동일하게 보유하게 된다.

3.2 다익스트라(Dijkstra) 알고리즘을 통한 최단 경로 트리(SPT) 계산

글로벌 토폴로지 지도가 완성되면, 각 라우터 노드는 자신을 루트(Root)로 삼아 네트워크상의 모든 타 노드 도달 비용을 계산하는 다익스트라(Dijkstra’s Algorithm) 혹은 이를 변형한 최단 경로 알고리즘을 독자적으로 구동한다.
이 연산의 결과물로 만들어진 **최단 경로 트리(Shortest Path Tree, SPT)**는 곧바로 라우팅 포워딩 테이블(Forwarding Table)을 갱신하는 데 사용된다.

예를 들어 라우터 A에서 라우터 D로 가는 경로가 두 가지 (A \rightarrow B \rightarrow D, A \rightarrow C \rightarrow D) 존재할 때, 전자의 누적 가중치 비용(Cost)이 더 낮다면, 트래픽은 무조건 B 라우터를 거쳐 흘러가도록 테이블이 세팅된다.

3.3 이벤트 기반의 라우팅 테이블 동적 갱신

산업용 에지(Edge) 네트워크는 불안정하다. Wi-Fi 신호가 끊기거나 특정 라우터 서버가 다운되면, 링크 상태가 변동되고 기존의 최단 경로 트리는 즉각 유효성을 상실한다.
Zenoh 엔진은 주기적인 풀링(Polling)에 전적으로 의존하지 않고, 물리적 소켓 단절이나 하트비트(Heartbeat) 유실 같은 이벤트(Event)를 감지하는 즉시 국지적 링크 업데이트 플래딩을 발동시킨다.

변화된 토폴로지 맵을 수신한 라우터들은 즉각적으로 다익스트라 알고리즘을 백그라운드에서 재연산(Re-computation)하며, 0.1초의 지연도 없이 백업 경로(Backup Path)로 트래픽을 선회시킨다. 이는 브로커 기반 미들웨어에서는 절대 구현할 수 없는 자율적이고 탄력적인(Resilient) 네트워크 치유 과정이다.

4. 네트워크 파티셔닝(Partitioning) 대응 및 동적 재구성(Dynamic Reconfiguration)

분산 시스템, 특히 산업 토폴로지에서 가장 회피하기 어려운 치명적인 재난은 바로 방대한 네트워크가 물리적으로 두 개 이상의 독립적인 섬(Island)으로 쪼개져 버리는 네트워크 파티셔닝(Network Partitioning) 현상이다. 해저 케이블이 단선되거나 중간 기지국의 안테나가 파괴되었을 때, 기존의 중앙 집중식 MQTT 브로커 시스템이나 분산 데이터베이스(CAP 정리의 희생양)는 브레인 스플릿(Split-brain) 현상에 빠지며 전체 서비스가 먹통(Halt)이 되곤 했다.

**Zenoh(제노)**의 아키텍처는 에지(Edge) 인프라가 본질적으로 ’불안정하고 단절 가능성이 농후하다’는 척박한 전제하에 설계되었다. 네트워크가 파티셔닝 되더라도 각 생존 구역 내에서는 지연 없는 동작을 보장하고, 다시 회선이 복구되었을 때 충돌 없이 유기적으로 재배치(Dynamic Reconfiguration)되는 치유 메커니즘을 내재하고 있다.

4.1 파티셔닝 상황에서의 국지적 자율성 (Local Autonomy)

본래 A, B, C 구역으로 통합 연결되어 있던 Zenoh 로컬 에어리어 통신망(LAN) 그룹이 굴삭기 사고로 광케이블이 끊어져 ’A 구간’과 ’B-C 통합 구간’으로 두 동강 났다고 가정하자.

  • 중앙 브로커(Broker)가 A 구간에 있었다면 일반적인 미들웨어의 경우 B, C 구간의 수만 대 통신 센서들은 즉각 셧다운된다.
  • 반면 Zenoh 피어(Peer) 및 라우터 그룹은 단절을 감지한 직후, 파티셔닝된 자신들의 생존 바운더리 내에서 즉각적으로 새로운 **로컬 최단 경로 트리(Local SPT)**를 독립 재연산한다.
  • B와 C 구간의 센서와 로봇들은 A로 보내야 했던 외부망 송출 트래픽만 보류(Queuing)할 뿐, 서로 B와 C 구간끼리 수행해야 하는 로컬 Pub/Sub 및 로컬 로봇 제어 쿼리 통신은 단 1초의 중단 없이 완벽한 정합성으로 로컬 처리(Local Autonomy)해 낸다.

4.2 동적 재동기화 (Dynamic Re-synchronization)

몇 시간 후 광케이블이 복구되어 물리적 TCP/UDP 회선이 다시 살아나게 되면 통상의 파티셔닝 복구 알고리즘에서는 양 진영의 트래픽이 일시에 쏟아지며 브로드캐스트 스톰(Broadcast Storm)이 발생할 위험이 크다.

Zenoh 라우팅 엔진은 연결이 감지되자마자 전향적 스마트 재동기화(Smart Re-sync) 프로토콜을 가동한다.
양 진영의 브릿지 역할을 하는 에지 라우터 노드들은 전체 데이터 베이스를 복사하여 넘기는 대신, 파티셔닝되어 있던 기간 동안 갱신된(Updated) 상태 델타(State Delta), 즉 변경된 구독/쿼리 라우팅 리스트의 차집합만을 추출하여 교환한다. 방대한 토폴로지가 쪼개졌다가 다시 하나로 꿰매어지는(Stitched) 이 과정은 O(N)의 부담 최소화 로직으로 처리되며, 일순간에 양 진영은 다시 거대한 글로벌 트라이(Trie) 라우팅 트리로 재결성된다.

5. 라우팅 루프(Loop) 방지 기법 및 포워딩 최적화

수십, 수백 개의 Zenoh 라우터와 피어(Peer)들이 거미줄처럼 얽혀 있는 메쉬(Mesh) 및 혼합(Hybrid) 토폴로지 환경에서, 네트워크 엔지니어가 가장 기피하는 악몽은 데이터 패킷이 목적지를 찾지 못하고 무한히 순환하는 라우팅 루프(Routing Loop) 현상이다. 루프에 빠진 패킷은 대역폭을 소진하며 스노우볼처럼 불어나 결국 네트워크 전체의 치명적 붕괴(Meltdown)를 유발한다.

DDS 계열의 프로토콜이나 단순 브로드캐스트 브릿지 환경에서는 루프를 막고 스파닝 트리(Spanning Tree)를 유지하는 것 자체가 엄청난 컴퓨팅 자원을 요구했다. 그러나 **Zenoh(제노)**는 프로토콜 헤더 단위의 식별자와 트라이(Trie) 알고리즘 결합을 통해, 구조적으로 루프를 방지하고 최단 홉(Hop) 포워딩을 강제하는 명료한 포워딩 최적화 레이어를 선언했다.

5.1 패킷 식별자를 통한 선제적 루프 컷 스루(Loop Cut-through)

Zenoh를 통과하는 모든 와이어 프로토콜(Wire Protocol) 메시지 프레임은 고유한 식별자 스탬프를 부착받는다.
어떤 라우터 노드가 인접한 피어들로부터 데이터를 수신하여 포워딩(Forwarding)할 때, 라우터 엔진은 프레임의 헤더 속성을 즉시 검문한다.

  • 만약 이 데이터가 **“과거에 내가 방금 전에 전달했던 바로 그 패킷”**이라면, 즉 내가 포워딩한 데이터가 네트워크를 한 바퀴 돌아 다시 나에게 돌아온(Loopback) 상황이라면, 라우터는 해당 패킷을 다음 노드로 버스태깅(Bus-tagging)하지 않고 즉각 **폐기(Drop)**해 버린다.
    이는 IP 헤더의 TTL(Time-To-Live) 필드가 0이 되기를 기다리는 피동적인 방어기제가 아니라, 분산 라우팅 노드 자체가 패킷의 이력을 인지하고 즉결 심판을 내리는 능동적 방화벽(Active Firewall)에 가깝다.

5.2 역방향 경로 학습(RPF, Reverse Path Forwarding) 최적화

라우팅 루프 방지와 더불어 멀티캐스트(Multicast) 트래픽의 증폭(Amplification)을 억제하는 핵심 기법이 역방향 경로 포워딩(RPF) 체크이다.
어떤 구독자 그룹에게 데이터를 살포(Fan-out)할 때, 라우터는 데이터가 들어온 인터페이스(물리적 포트나 세션)가, 발신자로 향하는 최단 경로 지도(Shortest Path Tree)상에서 일치하는 인터페이스일 경우에만 나머지 모든 하위 가지(Branch) 인터페이스로 패킷을 복제하여 전송한다. 만일 데이터가 비정상적인 지름길이나 백업 포트로 비집고 들어왔다면, 라우터 엔진은 이를 루프의 전조증상으로 간주하여 과감하게 잘라낸다(Pruning).

5.3 포워딩 엔진의 하드웨어적 최적화 방향

Zenoh의 포워딩 엔진(Forwarder)은 Rust 코어로 작성되어 동시성(Concurrency)과 메모리 해제(Memory Safe) 성능을 극한으로 끌어올렸다.
패킷이 라우터에 도착하고 나가는 전체 파이프라인 구간 동안, 패킷 데이터의 덩어리(Payload)는 메모리상에서 복사(Copy)되지 않는다(Zero-copy 아키텍처 지원).
포워딩 엔진은 오직 10 바이트 남짓의 초경량 헤더(Header)만 읽어 들여 리소스 이름(Resource Name)의 트라이(Trie) 매칭을 수행한 뒤, 목적지 소켓으로 포인터만 던져버리는 방식으로 데이터 평면(Data Plane)의 포워딩 오버헤드를 마이크로초(µs) 단위로 단축시켰다. 이 루프 프리(Loop-free) 및 제로카피 메커니즘이야말로 Zenoh가 기가비트 이더넷(Gigabit Ethernet) 환경의 회선 한계(Line-rate) 트래픽을 거뜬히 방어해 내는 기술적 뼈대이다.