11.11.4.2 대용량 메시지(Oversized Message) 드롭 현상 대응 및 QoS 재조정 런북

ROS2와 Zenoh를 브릿징하여 구동할 때, IMU나 모터 엔코더 같은 가벼운 상태 값은 빛처럼 통과하지만, 4K 해상도의 압축 해제된 카메라 이미지(수 메가바이트 급)나 LiDAR 포인트 클라우드 맵(Point Cloud Map) 데이터를 터트리는 순간 로컬망과 백엔드 서버 간의 수신 콜백이 완전히 먹통(Blackout)이 되어버리는 현상에 부딪히게 된다.

이것은 Zenoh 망이 느리거나 끊어진 것이 아니라, 네트워크 스택 중 어딘가의 버퍼가 넘쳐흘러서 패킷이 수술대에 오르지도 못하고 폐기(Drop) 처분당하고 있는 명백한 ‘용량 초과(Oversized Message)’ 에러다. 본 절에서는 DDS와 Zenoh 경계에서 벌어지는 대용량 메시지 프래그멘테이션(Fragmentation) 실패 원인을 규명하고, QoS(Quality of Service) 및 런타임 버퍼 튜닝을 통해 트래픽 동맥경화를 시원하게 뚫어내는 런북을 서술한다.

1. 커널 UDP 수신 버퍼 사이즈 초과와 Silent Drop

ROS2의 기본 통신망인 DDS(특히 FastDDS 벤더)는 기저에 UDP 소켓 통신을 깔고 앉아있다. 로봇이 5MB짜리 프레임 이미지를 Publish 하면, DDS는 이를 수백 개의 UDP 패킷 조각(Fragments)으로 쪼개서 zenoh-bridge-dds 에게 맹렬하게 발포한다.

문제는 이 수백 개의 파편들이 짧은 순간 브릿지의 수신 큐(Receive Queue)에 일시에 꽂힐 때 발생한다. 리눅스 운영체제 커널이 기본적으로 할당하는 소켓 최대 수신 버퍼의 크기(일반적으로 200KB 남짓)를 초과하는 트래픽 덩어리가 떨어지면, 커널은 이 패킷 조각 중 일부를 야만적으로 드롭시켜 버린다.
결과적으로 브릿지는 99개의 파편은 받아 조립을 시도하지만 단 1개의 조각 포인터가 비어있음을 인지하고, 완전성(Completeness)이 훼손된 그 거대한 5MB 프레임 전체를 쓰레기통에 폐기하는(Silent Drop) 잔혹한 결단을 내린다.

이 파괴적 현상을 잠재우려면 가장 먼저 리눅스 커널의 목줄을 풀어 네트워크 버퍼 파이프라인의 입구를 무식하게 확장해야(Over-provisioning) 한다.

# 리눅스 커널 소켓 튜닝 런북 (루트 권한 필수)
# 최대 UDP 수신/송신 버퍼 한계치를 25MB 수준으로 폭증시킨다
sudo sysctl -w net.core.rmem_max=26214400
sudo sysctl -w net.core.wmem_max=26214400

# 영구 반영을 위한 파일 삽입
echo "net.core.rmem_max=26214400" | sudo tee -a /etc/sysctl.conf
echo "net.core.wmem_max=26214400" | sudo tee -a /etc/sysctl.conf

2. ROS2 QoS History Depth 초과와 큐 파편화

커널 버퍼를 늘려주었음에도 여전히 이미지가 전달되지 않는다면 2차 방어선인 QoS(Quality of Service) 결함 구역을 조사해야 한다.

퍼블리셔 스레드가 초당 30프레임으로 5MB 이미지를 쏘아대는 반면, 가여운 브릿지 데몬이 이 패킷을 Zenoh 프로토콜로 직렬화하여 클라우드로 뱉어내는 스루풋이 초당 10프레임에 불과할 수 있다.
이 속도 차이로 인해 브릿지의 내부 DDS 수신 History Queue(기본값 Length 10)가 0.3초 만에 꽉 차버린다. Queue가 꽉 차면 DDS 철학에 의해 옛날 프레임이 밀려서 삭제(Keep Last 규약)되거나, 퍼블리셔의 동작 자체를 블로킹해버린다.

이 경우 퍼블리셔를 구동하는 ROS2의 QoS 뎁스(Depth)와, 데이터를 낚아채는 zenoh-bridge-dds 로컬 구동 시의 큐 용량을 쌍둥이처럼 일치성 있게 팽창시켜야 한다.

3. 브릿지 설정 무결성: Max Size 파라미터 방어 해제

결정적으로, Zenoh-DDS 브릿지 자체 엔진 레벨에서의 보안 방탄복을 해제해야 한다.
브릿지는 디도스(DDoS) 공격이나 무의미한 가비지 트래픽 폭주를 막기 위해, 시스템 설정 파라미터상으로 라우트(Route) 가능한 단일 메시지의 Max Size를 보수적으로 제한하고 있다.

거대한 Point Cloud나 복합 텐서(Tensor) 비전 배열이 이 허들을 넘지 못해 분쇄된다면 브릿지를 가동할 때 JSON이나 파라미터를 통해 페이로드 한계치를 명시적으로 개방하라.

/* 브릿지 설정 파일(zenohd-bridge-dds_config.json)의 Payload Limits 튜닝 */
{
  "max_size": 104857600 // 한 번에 수용할 메시지를 최대 100MB로 개방
}

네트워크 엔지니어링의 병목 진단은 수동적 기다림이 아니다. “커널단의 버퍼 증축(Sysctl)” -> “통신 미들웨어단의 큐 길이 확보(QoS)” -> “직렬화 브릿지 엔진의 한계 스피어 개방(Config Limits)“에 이르는 입체적인 3단 돌파 전략(Three-tier Breakthrough)을 매도할 줄 아는 기술자만이 대용량 파이프라인의 진정한 스루풋을 목격할 수 있다.