13.10.3.1 데몬 클러스터링(Swarm) 기반의 물리적 위치 변동 극복 및 IP리스(IP-less) 파이프라인 개통
로컬 드론 스웜(Swarm)이 건물 내부를 훑고 다니거나 자율주행 AGV가 거대한 공장 구역(Zone)과 외부 마당을 넘나들 때, 아키텍트가 가장 골머리를 앓는 문제는 단말들의 빈번한 IP 어드레스(IP Address) 변경이다.
LTE와 내부 Wi-Fi 구역을 오갈 때마다 로봇의 IP 주소는 서브넷(Subnet)을 옮겨 타며 박살(Tear Down) 난다. IP 기반의 소켓(Socket) 지향형 DDS나 ROS2 브릿지를 썼다면 연결 선이 끊기고 라우팅 테이블이 마비되며 시스템 전체가 5초간 기절(Freeze)하는 절망에 봉착한다.
이 파편화된 물리적 IP 종속성을 영원히 끊어내고, 기체(Node)가 어디로 날아가든 데이터의 흐름(Data-Flow) 파이프라인이 파괴되지 않는 아키텍처. 본 절에서는 Zenoh-Flow의 철학이 기반하는 물리적 위치 독립성, 즉 IP리스(IP-Less) 자생형 데이터 지향 네트워크(Data-Centric Network) 런북을 서술한다.
1. 정적 IP 엔드포인트(Endpoint) 결속의 끔찍한 한계
전통적인 ROS 노드 간의 브릿징이나 일반적인 분산 프로세싱 툴(Kafka, Redis 등)은 통신의 출발점과 도착점을 지목할 때 결벽증처럼 IP 주소(192.168.1.10:7447)를 하드코딩(Hardcoding) 한다.
이 설계 하에서 차량 1호기의 센서 데이터를 파이프라인 서버로 밀어 넣으려면, 양측의 터널망은 상대방의 물리적 거처(IP)가 변하지 않을 것이라는 헛된 믿음에 의존한다.
하지만 Wi-Fi 로밍이 발생해 로봇이 AP를 갈아타 IP가 10.0.0.5 로 변하는 그 찰나, TCP 소켓은 연결 거부(Connection Reset)를 토해내고, 파이프라인 오퍼레이터는 입력 데이터가 말라죽는 기아(Starvation) 상태에 빠진다. 다시 수동으로 DHCP 갱신을 인지하고 라우터를 갈아 끼우는 데 소모되는 시스템 딜레이로 인해 그날의 군집 비행 쇼는 공중에서 추락(Crash)으로 끝을 맺는다.
2. IP의 말살과 토픽 지향형 라우팅(Topic-Centric Routing) 선언
Zenoh 생태계는 통신의 주체를 “누구(IP)와 맺어지는가“에서 “무엇(Topic/Key Expression)을 다루는가” 로 180도 뒤집어버리는 데이터 지향 네트워킹(NDN) 철학의 정점이다.
Zenoh-Flow 파이프라인 매니페스트를 작성할 때, 데이터의 근원지(Source)와 종착지(Sink)를 기입하는 란에 결코 단말의 IP를 적어 넣지 않는다.
# [고가용성 IP-Less 파이프라인 선언 런북]
flow:
name: "Swarm_Drone_Tracker"
sources:
- id: "drone_camera_stream"
# IP 대신 데이터의 우주적 절대 주소(URI)인 'Key Expression' 만을 선언한다.
# 이 토픽이 아프리카 5G 통신망에 있든 사내 Wi-Fi에 있든 상관하지 않는다.
endpoint: "swarm/drone/*/camera/feed"
위의 런북을 받아 먹은 백그라운드의 Zenoh 노드들(zenohd 라우터 클러스터)은 스스로 분산 해시 테이블(DHT) 가십(Gossip) 프로토콜을 백그라운드로 미친 듯이 돌려 토픽의 배달 경로를 스스로 개척(Self-healing)한다.
드론이 Wi-Fi IP를 버리고 5G IP로 껍데기를 갈아입어도, 드론 내부의 Zenoh 런타임은 “내 IP가 바뀌었지만, 내가 들고 있는 정보는 여전히 swarm/drone/1/camera/feed다!” 라고 허공에 소리칠 뿐이다. 그러면 0.1초 만에 인근의 새로운 기지국 라우터들이 이 토픽의 냄새를 맡고 파이프라인의 연산 노드로 가는 최단 경로를 우아하게 다시 붙여(Relink) 낸다.
3. 데몬 스웜(Swarm) 클러스터링과 연속적 핸드오버(Handover)
이 사상의 폭발적 위력은 여러 대의 엣지 컴퓨터가 하나의 거대한 연산 망루(Compute Fabric) 로 묶였을 때 진가를 발휘한다.
공장 구석구석에 흩어진 10대의 엣지 컨트롤러들이 모두 Zenoh-Flow의 Worker 데몬으로 떠 있을 때, 드론 한 대가 구역 A에서 구역 B로 날아가면 어떤 일이 벌어지는가?
드론이 생산해 내는 토픽이 A 존 라우터를 벗어나 B 존 라우터망에 꽂히는 순간, 파이프라인 매니저(Zenoh-Flow Master)는 이 데이터의 중력(위치)이 이동했음을 감지한다. 그리고 구역 A의 엣지 서버에서 돌고 있던 추론 연산 오퍼레이터(Operator) 프로그램을 즉각 멈추고, 드론과 물리적으로 가장 가까워진 ‘구역 B의 엣지 서버’ 메모리 안으로 그 C++/Python 연산 코드를 날려 보내어 1초 만에 재기동(Live Migration) 시켜버린다.
데이터가 오기를 멀리서 앉아 기다리는 바보 같은 파이프라인은 파산한다. 연산(Compute) 엔진 자체가 데이터의 물리적 냄새를 맡고 IP의 장벽을 뚫은 채 단말기를 쫓아 옮겨 다니는 아키텍처. 이것이 물리적 서버의 위치라는 레거시 개념을 갈아버리고 우주적 토픽 지향(Topic-oriented) 메시망을 강제하는 스웜(Swarm) 융합 공학의 위대한 종착지다.