20.6 이기종 통신 및 브릿지(Bridge) 장애 해결

20.6 이기종 통신 및 브릿지(Bridge) 장애 해결

세상의 모든 장비가 Zenoh 프로토콜 하나로 통일된다면 완벽하겠지만, 현실의 산업 현장은 낡은 프로토콜과 치열하게 엉켜 돌아간다. 10년 된 Mosquitto 기반 MQTT 온도 센서, DDS 기반의 무거운 ROS2 산업용 자율주행 셔틀, 그리고 최신 Zenoh 클라우드 라우터가 완벽하게 한 테이블에서 소통해야 한다.

이 언어의 장벽을 허무는 것이 바로 브릿지(Bridge)다. 하지만 브릿지는 단순한 전달자가 아니라, 두 세계의 설계 철학(QoS, Liveliness, Encoding)을 강제로 번역하는 험난한 매개체다. DDS의 무거운 규격을 Zenoh의 경량 규격으로 압축하다가 메시지 영속성(Durability)이 증발하거나, ROS2의 /tf 같이 폭발적인 데이터를 브릿지가 막아내지 못해 병목의 원흉이 되기도 한다.

이 절에서는 로보틱스 개발자들이 가장 많이 겪는 rmw_zenoh, zenoh-bridge-dds, 그리고 MQTT 브릿지 연동 시의 치명적인 교착 상태와 데이터 변환 실패를 깊숙이 디버깅하여 이기종 프로토콜의 진정한 평화를 구축하는 비법을 다룬다.

1. MQTT 및 DDS 브릿지 병목 및 데이터 변환 오류

공장에는 ROS2 로봇 외에 10년 된 구형 PLC 온도 센서 장비들이 MQTT 브로커(Mosquitto 등)에 붙어 동작하기도 한다. 이렇게 중앙 집중식으로 돌아가는 MQTT를 Zenoh의 분산 라우팅 망으로 가져오기 위해 zenoh-plugin-mqtt 플러그인을 사용할 때 흔히 겪는 데이터 손상 및 대역폭 파괴를 주의하라.

1.0.1 원시 바이너리와 문자열(JSON) 인코딩 변환 실패 현상

MQTT 센서는 대부분 아스키(ASCII) 기반의 평문(Plain text) JSON 문자열을 보낸다. 반면 Zenoh C++ 퍼블리셔 등은 통신 퍼포먼스를 위해 압축된 바이너리 패킷을 선호한다.
브릿지가 MQTT 토픽을 수신해 Zenoh 라우터 망으로 중계하는 과정에서 페이로드(Payload)를 강제 문자열 디코딩(String parsing)하려 시도하다가 바이트 배열 규칙이 깨지는 파괴적 현상이 잦다.

회피 기동: 브릿지 설정 시에 페이로드 타입 매핑 오토(Auto) 모드를 믿지 마라. 브릿지 단에서는 강제로 데이터 타입을 ’Raw Bytes’로 일원화(Unified)하여 넘기도록 통제하라. 그리고 비즈니스 로직(TypeScript 측)에서 최종 소비자만이 역직렬화(Deserialization)를 직접 코드로 제어하게 만들면 인코딩 손상을 근원적으로 차단할 수 있다.

1.0.2 MQTT 브로커 지점의 집중 병목 현상 (Bottleneck)

사방 팔방으로 우회 라우팅이 원활한(Multi-path) Zenoh와 달리, 중앙 집중식 별도 데몬인 MQTT 브로커는 단일 노드 성능과 커넥션 한계에 취약하다.
공장 한 라인에 설치된 1만 개의 MQTT 센서 토픽을 한 대의 MQTT-Zenoh 브릿지 머신으로 몰아넣으면 라우터가 아니라 MQTT 브로커의 CPU나 브릿지 데몬의 I/O 리미트 스레드가 목에 걸려 죽게(Hang) 된다.

구조적 분산(Sharding):
1개의 브릿지 허브로 MQTT 전체를 엮으려는 생각을 버려라. 물리적 구역 단위로 소형 MQTT 브로커와 Zenoh 브릿지를 세트로 묶어 10개 이상 분할 배치(Sharding)하라. 특정 센싱 구역에 트래픽 마비가 걸려도 해당 브릿지 세트 1개만 죽을 뿐, 전체 데이터 호수(Data Lake)의 흐름에는 영향을 미치지 않도록 아키텍처의 트래픽 병목 구역(Choke Point)을 찢어 발겨야 한다.

2. Zenoh-Flow 데이터 파이프라인의 노드 간 통신 단절

복잡한 비디오 영상 모델이나 자율주행 AI 추론을 위해 데이터 플로우 기반 프레임워크인 Zenoh-Flow를 도입했다면, 트러블슈팅의 관점이 바뀐다. 일반적인 Pub/Sub의 단순 네트워크 오류가 아니라, 선형적이거나 방향성 비순환 그래프(DAG)를 갖는 논리적 파이프라인(Logical Pipeline) 상의 ‘노드 에지(Edge)’ 단절을 추적해야 한다.

2.0.1 파이프라인 매니페스트(YAML) 내 I/O 타입 오류

Zenoh-Flow는 source -> compute -> sink의 엄격한 데이터 흐름을 갖는다. 배포(Deploy) 시점부터 파이프라인 생성이 실패하고 서버가 에러를 뱉는다면 99% 확률로 타입 불일치(Type Mismatch)다.

  • Compute 노드 1번의 출력이 float64 포맷이 표출되는데
  • 2번 Sink 노드의 기대 입력이 int32로 YAML 다이어그램 인터페이스에 기술되었다.
    이때 배포 데몬은 연결 파이프 자체를 결속하지 않고 끊어버린다. 에러 로그(Type Mismatch at Data Flow Node_2)를 추적하여 각 컨테이너 간의 송수신 인터페이스(Signature)를 프로토콜 버퍼나 플랫버퍼 레벨까지 엄밀하게 정렬하라.

2.0.2 런타임 특정 노드 크래시에 따른 역류(Backpressure) 파동

AI 침입 탐지 모델이 포함된 Compute 노드(파이썬 텐서플로 머신)에 OOM 버그가 있어서 크래시가 나며 프로세스가 내려갔다.
그런데 이전 Source 노드(카메라 영상 스트리밍)는 그 사실을 모르고 멈춰버린 Node를 향해 초당 30프레임의 거대한 영상 압축 데이터를 계속 뿜어넣는다.

파이프라인의 백프레셔(Backpressure) 감지기가 곧바로 울리며 공유 메모리 버퍼가 차오르고, 이 파동 거품이 역류하여 결국 온전했던 Source 카메라 노드마저 타임아웃에 빠뜨린다(단일 고장 지점이 전체 마비로 확산).
설계 보완: 해당 AI 처리 노드의 K8s나 Docker 재시작(Restart) 정책을 패스트(Fast) 타임으로 설정하고, 무엇보다 데드 레터 큐(Dead Letter Queue) 시스템을 중간 로직에 결합하라. 다운스트림 노드가 500ms 이상 지연되면 오갈 데 없는 막힌 데이터를 가차 없이 드롭(Drop) 시켜야먄 전체 흐름도(Pipeline)가 괴사하지 않고 소생할 수 있다.