4.7 에지(Edge)와 클라우드(Cloud) 간의 통신 최적화

공장 바닥이나 차량 내부에 구축된 로컬 에지(Edge) 네트워크가 클라우드(Cloud)라는 거대한 광역망(WAN)과 만나는 순간, Zenoh(제노) 라우터는 완전히 새로운 차원의 장애물들을 마주하게 된다. 방화벽(Firewall)은 낯선 패킷을 가차 없이 폐기하고, NAT(Network Address Translation) 장비는 사설 IP를 집어삼키며, 저궤도 위성망이나 LTE는 높은 지연 시간(Latency)과 패킷 드롭(Drop)으로 통신을 괴롭힌다.

이 장에서는 에지 시스템이 고립된 섬을 벗어나 클라우드 백본망과 안정적으로 연동되기 위해 Zenoh 아키텍트가 반드시 통과해야 할 ’네트워크 최적화의 4가지 관문’을 해부한다.

방화벽(Firewall) 정책 통과 (4.7.1): 기업망과 클라우드의 인바운드/아웃바운드 포트 통제 환경에서 어떠한 포트를 개방해야 로컬 디스커버리와 광역 라우팅 메쉬를 꿰맬 수 있는지 명확한 가이드라인을 제시한다.
NAT 트래버설(NAT Traversal) (4.7.2): 클라이언트가 공유기(NAT) 뒤에 숨어있어 클라우드 라우터가 직접 접근(Connect)할 수 없는 비대칭적 네트워크에서, 데이터 흐름을 양방향으로 터놓는 포트 포워딩 기법과 라우팅 전략을 살펴본다.
클라우드 인스턴스 브릿징 (4.7.3): AWS, GCP, Azure 등 서로 다른 퍼블릭 클라우드의 가상 사설망(VPC) 인스턴스에 배포된 Zenoh 라우터들을 하나의 글로벌 브릿지로 이어붙이는 토폴로지 구성 기법을 짚어본다.
LPWAN / 저대역폭 최적화 (4.7.4): LoRaWAN, 협대역 IoT(NB-IoT) 등 초 단위의 극심한 통신 지연과 대역폭의 제약을 받는 척박한 회선 위에서, Zenoh 라우터의 페이로드를 극한으로 다이어트시키는 튜닝 포인트를 제시한다.

이 최적화 과정들을 완벽히 튜닝해 내어야만 ’클라우드 인프라’에서부터 ’마이크로컨트롤러’까지 지연 없이 부드럽게 이어지는 완벽한 “Cloud-to-Thing Continuum“을 달성할 수 있다.

1. 방화벽(Firewall) 환경에서의 라우터 포트 정책

에지 기기(Edge Device)가 뿜어내는 데이터를 기업의 인트라넷 환경이나 퍼블릭 클라우드 인프라(AWS Security Group, Azure NSG 등)로 끌어올리려면, 가장 먼저 보안 부서가 굳게 닫아둔 **방화벽(Firewall)**의 장벽을 설득 가능한 형태로 뚫어내야 한다.

Zenoh(제노) 코어가 내부적으로 어떠한 네트워크 포트와 프로토콜 포맷을 사용하는지 명확히 규명하지 못한다면, 인프라스트럭처 연동 승인을 받아낼 수 없다.

1.1 Zenoh의 기본 포트 할당 정책

Zenoh 데몬(zenohd) 및 피어 노드가 로컬 및 광역망 소켓을 개방할 때 사용하는 스탠다드 프로토콜 포트 맵핑은 다음과 같다.

TCP 7447 (필수 개방): 유니캐스트(Unicast) 데이터 전송과 엔드포인트 세션 연결을 담당하는 Zenoh의 척추 포트다. 라우터가 퍼블릭 호스트 모드로 동작하려면 방화벽의 인바운드(Inbound) 규칙에 반드시 TCP 7447이 열려 있어야 한다.
UDP 7447 (디스커버리용): 로컬 네트워크 내에서 노드들이 서로를 찾기 위한 스카우트 비콘(Scout Beacon, 4.5.1절)과 멀티캐스트 전송을 위해 사용된다. 폐쇄된 기업망 내부의 스니핑을 허용하려면 오픈해야 하지만, 인터넷 여정이 필요한 클라우드 아웃바운드 구간에서는 보안상 막아두는 것이 원칙이다.
TCP 8000 (설정/관리용 API): Zenoh 라우터의 설정을 제어하거나 모니터링 플러그인(Admin Space) 지표를 끌어갈 때 사용되는 REST API 대역이다. 외부 망에는 절대 인바운드로 노출하면 안 되며, 오직 관리 대역(VPC 내부망 또는 VPN) 인터페이스로만 바인딩(Binding)해야 한다.

1.2 보안 정책에 따른 커스텀 포트 우회(Traversal)

기업의 보안 지침이 유독 깐깐하여 Well-known HTTP/HTTPS 포트(80, 443)만 통과시키고 나머지 포트는 일괄 차단(Drop)하는 극단적인 DMZ 망이 존재할 수 있다.

이때는 Zenoh 라우터의 설정 파일(zenoh.json5) 리스너 엔드포인트를 강제로 80 또는 443 포트로 비틀어버리는 방법을 쓴다. 더 우아한 방법으로는 4.4.4절에서 다룬 웹소켓(WebSocket) 트랜스포트 플러그인을 활성화하여, 겉보기엔 평범한 Nginx HTTPS 웹 트래픽인 것처럼 위장(Encapsulation)한 뒤 리버스 프록시(Reverse Proxy) 방화벽을 유유히 통과시키는 우회 전략을 사용할 수 있다.

2. NAT 트래버설(NAT Traversal) 및 포트 포워딩 기법

공장 구석에 놓인 라즈베리 파이(Client)와 AWS 어딘가에 떠 있는 클라우드 서버(Router)를 연결해야 한다고 가정해 보자. 여기서 가장 골치 아픈 네트워크 장애물은 바로 공장 인터넷 망을 지키고 있는 NAT(Network Address Translation, 공유기) 장비다.

NAT 환경에서는 내부 망 192.168.x.x 대역의 클라이언트가 바깥세상(WAN)으로 나갈 수는 있으나, 외부망의 서버가 내부 클라이언트의 가짜 IP를 뚫고 먼저 들어오는 것(Inbound Connect)은 원천적으로 불가능하다. 즉, 연결의 비대칭성이 발생한다.

2.1 포워드 연결(Forward Connect) 기반의 NAT 우회

**Zenoh(제노)**는 이 문제를 극복하기 위해 클라이언트-라우터 간의 세션 지향적 특성을 교묘하게 활용한다.

클라이언트 주도 연결: 내부 망(NAT 뒤)에 갇혀있는 Zenoh 클라이언트 노드가 connect 설정을 통해 공인 IP를 가진 클라우드 라우터(TCP 7447)를 향해 직접 “포워드 연결(Forward Connect)” 소켓을 찔러 넣는다.
연결 구멍(Pinhole) 유지: NAT 장비는 내부에서 바깥으로 나간 이 TCP 세션 점유 기록(NAT Table)을 저장하고 구멍을 열어둔다.
양방향 라우팅 성립: 일단 TCP 터널이 뚫리기만 하면, Zenoh 와이어 프로토콜 구조상 이 하나의 터널을 통해 Publisher 데이터(Upstream)와 Subscriber 결과(Downstream) 양방향 트래픽이 무제한 교차(Multiplexing)할 수 있다.

클라우드 라우터 입장에서는 에지 클라이언트의 진짜 IP를 알 필요조차 없다. 그냥 먼저 걸려 온 전화를 끊지 않고 들고 통화만 유지하면 NAT 트래버설 문제가 말끔하게 해결된다.

2.2 라우터 대 라우터 NAT 문제와 포트 포워딩(Port Forwarding)

문제는 피어(Peer) 모드나 두 로컬 라우터 간에 끈적한 수평적 메쉬(Mesh) 네트워크를 구성하려 할 때 발생한다. 양쪽 라우터가 모두 서로 다른 NAT 장비 뒤에 숨어있다면, 양측 모두 먼저 전화를 걸 방법이 없다.

이 경우 아키텍트는 네트워크 인프라에 물리적 메스를 들이대야 한다.

공인 포트 포워딩(Port Forwarding): 에지 라우터가 물려 있는 최상단 공유기(게이트웨이)의 외부 공인 IP의 7447 포트를 열고, 이 트래픽을 내부 망 라우터의 로컬 IP(예: 192.168.1.100:7447)로 다이렉트 패스(Direct Pass) 시키도록 공유기 설정을 뚫어주어야 한다.
라우터 매개(Relay): 공인 IP를 확보할 수 없다면, 두 라우터 중간 지점(예: 클라우드)에 고정 공인 IP를 갖춘 허브 역할을 조율할 제3의 마스터 Zenoh 라우터를 띄워 양측이 모두 허브 라우터로 모이게 하는 우회 토폴로지(스타 구조)로 아키텍처를 전면 수정해야만 한다.

3. 클라우드 인스턴스(AWS, GCP, Azure) 간의 Zenoh 브릿징

거대한 글로벌 서비스를 운영하다 보면 단일 클라우드 제공자(CSP)에 묶이는 벤더 락인(Vendor Lock-in)을 피하거나, 최적의 리전(Region) 레이턴시를 쫓기 위해 멀티 클라우드(Multi-Cloud) 아키텍처를 도입하게 마련이다.

AWS 도쿄 리전에 떠 있는 예측 AI 모델과 GCP 사우스캐롤라이나 리전에 적재된 데이터베이스, 그리고 Azure 컨테이너에 담긴 실시간 대시보드를 하나로 묶어 이기종 환경이 맞나 싶을 정도의 매끄러운 원-플랫폼(One-Platform)으로 연동하는 기술, 이것이 바로 **Zenoh(제노) 브릿징(Bridging)**의 정수다.

3.1 멀티 클라우드 브릿징의 기본 아키텍처

클라우드 A(AWS)와 클라우드 B(GCP)를 연동할 때, 양쪽 VPC의 모든 백엔드 마이크로서비스 노드들이 서로 다이렉트로 연결을 맺는 것은 네트워크 보안 관리상 재앙에 가깝다. 대신 각 클라우드 VPC마다 관문(Gateway) 역할을 하는 거대한 **Zenoh 백본 라우터(Backbone Router)**를 하나씩 세워두고, 이 대장 라우터들끼리만 정적 연결(Static Connect)을 맺는 전략을 취해야 한다.

graph LR
    subgraph AWS VPC (Tokyo)
        R_AWS((Zenoh Router AWS))
        m1[Microservice 1] --> R_AWS
        m2[Microservice 2] --> R_AWS
    end
    
    subgraph GCP VPC (US-East)
        R_GCP((Zenoh Router GCP))
        R_GCP <-- "TLS Tunnel (TCP 7447)" --> R_AWS
        m3[DB Sync Service] --> R_GCP
    end

3.2 퍼블릭 IP 노출과 보안 터널링

대륙을 횡단하는 클라우드 간 연결은 필연적으로 트래픽이 살벌한 퍼블릭 인터넷(Public Internet) 망을 타게 된다.

QUIC과 TLS의 강제 적용: 방어막이 쳐져 있지 않은 퍼블릭 IP 간의 통신이므로, 단순 TCP 통신을 사용해서는 안 된다. 4.4.3절의 QUIC 트랜스포트를 활성화하여 UDP 기반의 빠른 전송 속도를 챙김과 동시에, 설정 파일(zenoh.json5)을 통해 TLS 인증서(Certificate) 기반의 암호화를 강제로 입혀 스니핑(Sniffing)을 원천 차단해야 한다.
Access Control List (ACL): 라우터 간 연결을 허용하더라도, GCP 라우터가 AWS 라우터의 모든 토픽에 접근할 수 있게 멱살을 열어두어서는 안 된다. 관리 플러그인을 통해 특정 토픽 접두사(Prefix, 예: /inter-cloud/sync/**)만 브릿징 되도록 화이트리스트(Whitelist)를 깐깐하게 설정하라.

3.3 라우팅 루프의 광역적 고려사항

3개 이상의 멀티 클라우드(AWS-GCP-Azure)가 서로 삼각형(Triangle) 메쉬 고리를 형성하며 브릿징을 맺을 때, 한 퍼블리셔의 트래픽이 지구를 끝없이 맴도는 브로드캐스트 스톰(Broadcast Storm)이 발생할 우려가 있다.

하지만 이전 장에서 여러 번 다루었듯, Zenoh 코어는 자체적으로 **링크 상태(Link State) 계산 알고리즘과 타임-투-리브(TTL)**를 내장하고 있으므로 광역 브릿징 환경에서도 데이터의 출처(Origin)를 기억하고 스패닝 트리 스톰을 능숙하게 쳐낸다. 개발자는 단지 라우터 간의 화살표만 이어주면 된다.

4. 저전력/저대역폭 네트워크(LPWAN)에서의 라우터 최적화

기가비트(Gigabit) 이더넷이 깔린 안락한 스마트 팩토리를 떠나, 산악 지대에 흩뿌려진 산불 감시 센서나 해상 부표에 달린 수위 측정기로 눈을 돌려보자. 이들이 사용하는 LoRaWAN, NB-IoT와 같은 **저전력 광역 통신망(LPWAN)**은 대역폭이 기껏해야 초당 수백 바이트(Bytes/sec)에 불과하고, 패킷 유실률(Drop Rate)이 절망적이며, 배터리로 1년을 버텨야 하는 극한의 가뭄 상태다.

Zenoh(제노) 코어는 이 척박한 토양에서도 살아남을 수 있도록 극한의 바이트 페이로드 다이어트를 단행하는 트위킹(Tweaking) 포인트를 제공한다.

4.1 와이어 프로토콜(Wire Protocol)의 최소 분모

Zenoh가 이기종 통신망 전반을 아우를 수 있는 비결은 태생부터 헤더 오버헤드를 1~3바이트 수준으로 깎아낸 와이어 프레이밍(Wire Framing) 설계(2.6절 참고) 덕분이다. LPWAN 환경의 에지 클라이언트 노드는 TCP/IP 스택을 통째로 덜어내고 4.4.5절에서 배운 가벼운 시리얼(Serial)이나 블루투스 LE(BLE)를 통해 지역의 소형 게이트웨이(Zenoh Router)로 데이터를 조심스럽게 넘긴다.

4.2 대역폭 쥐어짜기: 스카우팅 끄기와 킵얼라이브(Keep-Alive) 마사지

라우터 설정 파일(zenoh.json5)을 열어 군살을 모두 도려내야 한다.

스카우팅(Scouting) 즉시 비활성화: 초당 몇 번씩 멀티캐스트 비콘을 쏘아대는 스카우팅 기능은 LPWAN 환경에서 무의미한 배터리 낭비의 주범이다. 무조건 해당 기능을 끄고("enabled": false), 클라우드 라우터로 향하는 단방향 정적 연결(Static Connect)만 살려둔다.
킵얼라이브(Keep Alive) 타이머 늘리기: 기본 설정된 수 초 단위의 하트비트(Heartbeat)는 NB-IoT 종량제 요금 폭탄을 부른다. 세션 타임아웃 주기를 기기의 특성에 맞게 분 또는 시간 단위로 극단적으로 넉넉하게 늘려 잡아야 한다.
Liveliness 토큰 최소화: 노드의 생존 여부를 모니터링하는 Liveliness 선언 주기 역시 가장 긴 텀으로 늦추거나, 필수가 아니라면 과감히 생략한다.

4.3 구독(Subscription) 오프로딩과 지연 평가(Lazy Fetch)

배터리가 생명인 센서 클라이언트는 자신이 직접 토픽을 들고 온 동네에 “나 여기 있어“라고 소문(Gossip)을 퍼트릴 힘조차 없다.

이때는 데이터를 끊임없이 뿜어내는 푸시(Push)형 Publish/Subscribe 패턴을 포기하고, 1.6.3절의 쿼리-응답(Query-Reply) 모델을 활용해야 한다. 즉, 클라이언트는 깊은 절전 모드(Deep Sleep)에 빠져 있다가, 라우터가 “현재 수위 알려줘“라고 찔러줄(Pull) 때만 잠깐 깨어나 패킷을 던지고 다시 잠드는 철저한 오프로딩(Off-loading) 전략을 취함으로써 LPWAN의 가혹한 환경을 여유롭게 우회할 수 있다.