11.11.4.1 로컬 데몬(zenohd) 부재에 따른 라우터 탐색 실패(Discovery Failure) 원인 분석

11.11.4.1 로컬 데몬(zenohd) 부재에 따른 라우터 탐색 실패(Discovery Failure) 원인 분석

Zenoh 생태계는 본질적으로 중앙 집중적인 브로커(Broker)를 필요로 하지 않는 피어 투 피어(Peer-to-Peer, P2P) 아키텍처를 근간으로 삼을 수 있으나, 분산망의 규모가 커질 경우 엣지 노드들을 하나로 묶어 올려주는 거대한 스위치 허브 격인 로컬 라우터 데몬(zenohd) 의 존재가 필수불가결해진다.

로봇 단말을 부팅시키고 파이썬이나 C++ 기반 Zenoh 어플리케이션을 구동시켰을 때, zenoh.open() 함수 호출이 치명적 타임아웃(Timeout) 에러를 발생시키며 영구적인 침묵의 강을 건너버리는 사태의 핵심 원인은 대개 소스코드 내부가 아니라 단말기의 백그라운드 구역에 위치해 있어야 할 라우터 데몬 인프라의 파산(Absence)에 있다. 본 절에서는 클라이언트 탐색 실패(Discovery Failure) 현상의 기저를 진단하고 하부 데몬의 생사 여부를 고발하는 런북을 거행한다.

1. 클라이언트(Client) 모드의 의존성과 이니셜라이즈 타임아웃

개발자가 어플리케이션 런타임 코드 내에 환경 설정(Config)을 주입할 때 가장 치명적으로 오해하는 구역이 통신 모드(Mode) 설정이다.

만약 Zenoh 코드를 짤 때 config.set_mode(zenoh.Mode.CLIENT) 라는 명시적, 혹은 암묵적 기본 플래그를 할당한 상태로 open() 을 터뜨렸다면, 이 런타임은 주위의 다른 P2P 노드들을 찾는 것이 아니다.
자신을 받아줄 상위 체급의 라우터망, 즉 로컬호스트나 사내 클라우드 망 어딘가에 거대하게 살아 숨 쉬고 있어야만 하는 zenohd 프로세스를 혈안이 되어 찾기(Discover) 시작한다.

만일 로봇의 배경 프로세스(Systemd Demon) 계층에 zenohd가 부팅되어 있지 않거나 실수로 장애(Crash)를 맞은 상태라면?
당신의 파이썬 코드는 백그라운드에서 멀티캐스트 UDP 신호를 수 초간 난사하지만 어떠한 포트 리플라이(Reply)도 돌아오지 않고, 결국 Zenoh 코어 엔진은 “라우터를 찾을 수 없습니다(Unable to find a router)“라는 한 줄의 차가운 유언을 남기며 프로세스를 폭파(Panic)시켜 버린다.

2. Scout 어설트: 터미널 기반 백그라운드 탐색 점검론

이 붕괴 상태에서 수만 줄의 소스코드를 수술대 위에 올리는 우매함을 멈춰라.
문제가 응용 지점인지 네트워크 인프라 지점인지 절단하기 위해, 시스템 엔지니어는 자신이 코더가 아니라 심장 외과 의사임을 상기하고 표준 커맨드 터미널을 열어 시스템 백그라운드의 맥박(Daemon Ping) 상태를 물리적으로 검증(Scout)해야 한다.

# [인프라 진단론] Zenoh 생태계 전용 레이더 탐색 명령 발동
zenoh-cli info

이 명령어를 발포했을 때, 응답으로 JSON 리스트나 터미널 트리가 장엄하게 뻗어 나오지 않고 “No Zenoh router found” 따위의 고요가 감돈다면 범인은 색출된 것이다.
이때 관리 프로세스 감시자 구역(systemctl 혹은 docker ps)으로 강하하여 로컬 데몬의 부재 원인을 따져 물어라.

  1. systemctl status zenohd.service가 죽어있는가? (설정 불량 혹은 메모리 부족 폭사)
  2. zenohd가 켜져 있긴 한데, 멀티캐스트를 차단하는 리눅스 터널 인터페이스 설정 속에 고립당해버린 것은 아닌가?

3. 피어(Peer) 모드 전환을 통한 분산 망 탄력성 확보

라우터 모델이 구조상 취약성(Single Point of Failure)을 지니고 있거나 굳이 거대 트래픽 스위칭 코어가 필요하지 않은 소규모 로봇 스웜 내부 통신망이라면, 개발자는 런타임의 환경 모드를 클라이언트에서 피어(Peer) 모드로 전격 교체하는 기동 방어 전술을 고심해야 한다.

config.set_mode(zenoh.Mode.PEER) 로 재무장한 응용 프로세스는 open() 을 수행할 때 더 이상 남(zenohd 부모)을 찾으며 울부짖지 않는다. 스스로가 로컬 망의 주체가 되어 브로드캐스팅 핑을 날리며, 옆에 위치한 다른 피어 로봇과 직접 P2P 귓속말 터널을 수립하여 통신 장애에 대한 압도적인 아키텍처 탄력성(Resilience)을 증명해 낸다. 발견 실패(Discovery Failure)는 오직 개발자가 클라이언트 런타임의 운명을 외부 데몬(Router)에 통째로 갖다 바친 대가로 치르는 1차원적 페널티임을 통감해야 한다.