11.7 ROS2 통신 성능 측정 및 벤치마킹: DDS 대 Zenoh

11.7 ROS2 통신 성능 측정 및 벤치마킹: DDS 대 Zenoh

엔지니어는 입으로 코딩하지 않는다. 숫자로 증명해야 한다.
“Zenoh 가 DDS 보다 무조건 더 좋다” 는 맹신은 위험하다. 각자의 환경(LAN vs WAN, 페이로드 크기)에 따라 승자는 매번 뒤바뀐다.

이 챕터에서는 CTO나 투자자의 의구심을 완전히 박살 낼 수 있도록, ROS2 환경에서 이 두 미들웨어를 링 위에 올리고 극한의 데이터를 때려 박는 벤치마크 학살(Slaughter) 시나리오 와 그 측정 전술을 공개한다.

1. 지연 시간(Latency) 및 지터(Jitter) 측정 방법론

1ms 의 지연(Latency)은 100km/h 로 달리는 자동차에서 수십 cm 의 오차를 만든다. 그리고 지연 시간의 흔들림(Jitter)은 제어기를 미치게 만든다.

1.0.1 [Runbook] 마이크로초 핑퐁(Ping-Pong) 측정 전술

ros2 topic hz 같은 멍청한 도구로는 지연 시간을 잴 수 없다. 오직 핑퐁(Round-Trip Time, RTT) 방식만이 진실을 말한다.

1. ROS2 Performance Test 패키지 기동
Apex.AI 가 만든 performance_test 패키지를 쓴다. C++ 로 짜여진 가장 정확한 계측 도구다.

2. DDS (FastDDS) 지연 시간 측정

## 터미널 1 (수신자)
RMW_IMPLEMENTATION=rmw_fastrtps_cpp ros2 run performance_test perf_test --communication ROS2 --rate 1000 --topic PingPong --msg Array1k --size 1024 --test_duration 60
## 터미널 2 (송신자)
RMW_IMPLEMENTATION=rmw_fastrtps_cpp ros2 run performance_test perf_test --communication ROS2 --rate 1000 --topic PingPong --msg Array1k --size 1024 --test_duration 60 --publish

3. rmw_zenoh 지연 시간 측정

## 백그라운드에 zenohd (라우터) 구동 필수
RMW_IMPLEMENTATION=rmw_zenoh_cpp ros2 run performance_test perf_test ... (위와 동일)

[인스펙션] 예상되는 결과의 진실:

  • 로컬망(LAN) 결과: 1KB 수준의 작은 데이터에서는 DDS (FastDDS) 가 0.2ms, rmw_zenoh 가 0.3ms 로 DDS 가 미세하게 승리 한다. DDS 의 Shared Memory 통신 속도를 네트워크 스택 기반의 Zenoh 가 이길 수는 없다.
  • 방화벽 간(WAN/VPN) 결과: DDS(Over VPN) 는 50ms 에 Jitter 가 폭발하지만, rmw_zenoh 는 순수 TCP 관통으로 15ms 대의 일관된 Jitter 를 보여주며 Zenoh 여포(학살) 가 시작된다.

2. 메시지 페이로드 크기별 처리량(Throughput) 한계 테스트

작은 데이터 통신과 카메라 영상 통신(수 메가바이트)은 아예 물리학적 법칙이 다르다. 네트워크 톨게이트를 얼마나 넓게 쓸 수 있느냐의 싸움이다.

2.0.1 [Runbook] 데이터 폭포(Data Waterfall) 스로틀링 전술

앞선 performance_test 도구를 사용하여 페이로드 사이즈를 1KB 에서 4MB 로 끌어올려 본다.

## Size 4MB, 초당 30프레임 발사 (약 1Gbps 대역폭 강제소모)
RMW_IMPLEMENTATION=rmw_zenoh_cpp ros2 run performance_test perf_test \
--communication ROS2 \
--topic BigData \
--msg Array4m \
--size 4194304 \
--rate 30 \
--test_duration 60 \
--publish

[인스펙션] 터널 붕괴 시점 분석:

  • DDS: 데이터 크기가 1MB 를 넘어가는 순간 UDP 프래그먼테이션(Fragmentation)이 박살 나면서 패킷 로스(Packet Loss)율이 5% 에서 40% 로 급격하게 수직 상승한다. (DDS 특유의 큐 초과 현상).
  • Zenoh: 크기가 커져도 패킷 드랍은 일어나지 않는다. 왜냐하면 TCP 스택 기반으로 내부 버퍼에서 철저히 쪼개서(Chunking) 보내기 때문이다. 단, 대역폭 한계에 부딪히면 FPS 가 30Hz 에서 15Hz 로 떨어지는 병목(Bottleneck) 현상이 나타난다.

결론: 대용량 데이터에서 DDS 는 “데이터를 찢어버리고”, Zenoh 는 “숨을 참는다”. 자율주행 알고리즘 입장에서는 찢겨서 망가진 프레임(DDS)을 받는 것보다는, 늦더라도 완전한 프레임(Zenoh)을 받는 것이 100배 유리하다.

3. 네트워크 단절 및 복구 시나리오에서의 회복(Reconnection) 시간 비교

터널 속에 들어간 로봇(Wi-Fi 음영지대)이 다시 빛을 보았을 때, 관제 모니터에 자기 위치를 다시 띄울 때까지 걸리는 시간이다. 생명과 직결되는 가장 중요한 테스트다.

3.0.1 [Runbook] 네트워크 가위(Scissors) 단절 테스트

1. 정상 상태 루프 구동
로봇에서 관제 서버로 계속 10Hz 로 상태를 쏜다.

2. 강제 단절 (Iptables DROP)
로봇 측 리눅스 터미널에서 강제로 와이파이 어댑터의 트래픽을 가위로 잘라버린다.

## 리눅스 방화벽으로 모든 외부 통신 차단 (터널 진입)
sudo iptables -A OUTPUT -p udp -j DROP
sudo iptables -A OUTPUT -p tcp -j DROP

관제 서버의 화면에서 로봇이 멈춘다. (이때 수 초(Stopwatch)를 잰다).

3. 강제 복구 (Iptables ALLOW)
10초 뒤, 터널에서 빠져나왔다고 가정하고 족쇄를 푼다.

sudo iptables -F

[인스펙션] 부활의 카운트다운 분석:

  • DDS (FastDDS): 방화벽 족쇄가 풀렸음에도 불구하고 관제 화면에 데이터가 뜨기까지 평균 8초 ~ 15초 가 걸린다. DDS 는 연결이 끊어졌음을 인지하고, 다시 멀티캐스트를 날려 상대방의 XML 을 받아오는 지루한(Discovery) 과정을 통째로 다시 겪기 때문이다.
  • rmw_zenoh: 족쇄가 풀리고 핑이 살아나는 즉시, 0.5초 이내 에 관제 화면에 데이터가 터지기 시작한다. 라우터(zenohd)에 다시 TCP 로 접속하기만 하면, 라우터가 이미 상대방 경로를 다 기억하고 있기 때문에 디스커버리 오버헤드 없이 즉시 데이터가 콸콸 쏟아져 들어온다.

4. CPU, 메모리 자원 사용량 및 전력 소모량 프로파일링

로봇은 배터리로 움직인다. 알고리즘을 돌리기도 빠듯한 로봇 컴퓨터원(Compute)을 얼만큼 통신 체계가 빼앗아 먹고 있는지 적나라하게 까발린다.

4.0.1 [Runbook] 시스템 기생충(Parasite) 프로파일링 전술

htop 같은 허접한 도구는 버려라. 리눅스 perf 와 sysstat 을 통해 정확한 메모리 점유율과 컨텍스트 스위칭 카운트를 잡아낸다.

1. 노드 100개 띄우기 (스트레스 테스트)
로봇 안에 talker 노드를 반복문을 통해 100개를 강제로 띄워버린다. (가혹 조건)

for i in {1..100}; do
  ros2 run demo_nodes_cpp talker --ros-args -r __node:=talker_$i &
done

2. 통신 인프라 메모리(RAM) 도륙 측정

  • DDS (FastDDS): 100개의 노드가 켜지는 순간, 각 노드마다 자기만의 DDS 캐시 메모리와 디스커버리 스레드가 올라가면서 시스템의 램(RAM)을 약 1.5GB 나 집어삼킨다. 데몬리스(Daemon-less)의 비극이다.
  • rmw_zenoh: 100개의 노드가 켜져도, 노드는 아주 얇은 C 소켓 클라이언트일 뿐이다. 진짜 무거운 일은 백그라운드의 단 1개의 zenohd 가 처리한다. 전체 자원 소모량이 300MB ~ 400MB 선에서 기적처럼 방어된다. (약 3배~4배 램 다이어트 성공).

3. CPU 유휴(Idle) 전력 소모의 진실
데이터를 주고받지 않는 대기 상태에서도 DDS 는 서로 자기가 살아있다고(Liveliness) 속삭이느라 CPU 를 3~5% 지속적으로 갉아먹는다. 이건 고스란히 드론이나 AMR 의 방전(Discharge) 속도를 올린다. Zenoh 라우터는 대화가 없으면 커넥션만 유지한 채 완벽하게 0% 로 잠든다.