13.7 데이터 동기화 및 고급 흐름 제어 (Flow Control)

카메라 영상과 라이다(LiDAR) 데이터가 각기 다른 센서에서 출발해 네트워크를 타고 오면, 도착 시간이 엇갈린다. 로봇은 0.1초 전의 사진과 0.5초 전의 레이저를 융합하는 치명적 헛발질을 하게 된다.

Zenoh-Flow 가 자랑하는 궁극의 무기. 분산 데이터 망에서 시간을 통제하고, 트래픽 폭주를 막아내는 댐(Dam) 과 수문장(Gatekeeper) 의 극한 런북을 펼친다.

1. 타임스탬프(Timestamp) 및 워터마크(Watermark) 기반의 이벤트 시간 동기화

데이터플로우에서 도착 시간 은 아무 버무림(Garbage) 이다. 진짜 중요한 건 센서가 켜진 찰나의 발생 시간(Event Time) 이다.

1.0.1 [인스펙션] 지연 도착(Late-Arrival) 조율 전술

1. HLC (Hybrid Logical Clocks) 의 강제 편입
Zenoh 통신망 코어는 애초에 메시지를 던질 때마다 그 데이터에 고도화된 하이브리드 시간 도장(HLC) 을 찍는다. 시스템 시간이 서로 1~2초씩 틀어진 수천 대의 AWS 서버와 로봇 간에도 전 지구적 순서 보장이 가능하다.

2. 워터마크 (Watermark) 댐의 원리

• 센서 퓨전 노드 앞에는 가상의 댐(Buffer) 이 쳐져 있다.
• 카메라 영상 T=10, T=11 이 도착했다 하더라도, 라이다 데이터의 T=10 이 네트워크 랙(Lag) 으로 안 오고 있다면?
• 필터 노드는 섣불리 계산을 돌리지 않는다. “워터마크 기준선” 이 T=10 을 통과할 때까지 스케줄러를 블로킹(Blocking) 시키고, T=10 짜리 라이다 데이터가 지각 도착하는 순간 댐을 방류하여 정확히 같은 순간의 데이터 2쌍을 묶어 연산기로 넘긴다.

2. 시계열 데이터를 위한 윈도우잉(Windowing) 전략 (Sliding, Tumbling, Session)

주식 차트처럼, 데이터 1개만 보고는 AI가 판단을 못 내린다.
“최근 5초 치 데이터를 묶음 상자(Window) 로 싸서 줘!” 라고 오퍼레이터를 세팅해야 한다.

2.0.1 [Runbook] 데이터의 시간적 그룹 결속 전술

Zenoh-Flow 의 상태 의존성(Stateful) 을 극대화하는 런북이다.

1. 텀블링 윈도우 (Tumbling Window) - 끊어 읽기

• 1초부터 5초까지 상자에 담아 [계산], 6초부터 10초까지 상자에 묶어 [계산].
• 상자가 겹치지 않는다. IoT 온도 센서의 “10분 단위 평균” 을 클라우드로 올릴 때 쓴다.

2. 슬라이딩 윈도우 (Sliding Window) - 겹쳐 읽기

• 1초~5초 [계산], 2초~6초 [계산].
• 자율주행의 레이더 센서 트래킹 필터(Kalman) 에 필수적이다. 파이프를 타고 들어온 데이터 큐(Queue) 를 끄트머리 1프레임만 빼고 나머지는 로컬 캐시에 살려둔 채로 프레임을 미끄러지듯 이동시키며 끝없는 배열 컨텍스트 연산을 뽑아낸다.

이 로직은 데이터 관리가 까다롭다. 메모리 해제 시점을 잘못 잡으면 윈도우 상자가 영원히 비워지지 않아, 데몬이 며칠 뒤 OOM(메모리 초과) 으로 폭발하는 시한폭탄이 되므로 주의하라.

3. 시스템 과부하 방지를 위한 백프레셔(Backpressure) 처리 원리

파이프 A에서 물이 초당 100L씩 쏟아지는데, 파이프 B의 처리가 초당 10L밖에 안된다.
파이프는 언젠가는 터진다.

3.0.1 [인스펙션] 파이프라인의 숨통 트기

1. 소켓 버퍼의 한계계측
일반적인 ROS2 (DDS) 라면 이 상황에서 무지성으로 통신 큐(Queue) 에 데이터를 쌓다가 리눅스 커널 소켓 버퍼를 다 먹고 블루스크린이 뜬다.

2. 프로액티브 조임 밸브 (Proactive Throttling)
Zenoh-Flow 데몬은 큐 버퍼 게이지를 모니터링하다가 80% 가 차면 아날로그 신호를 역추적해 강을 거슬러 올라간다.

• “야 앞 노드! 나 큐 꽉 찼어. 너 다음 데이터 만들지 마!”
• 이 신호가 발원지인 Source 노드(ex: 카메라 드라이버) 까지 도달하면 카메라 프레임 캡처 스레드 자체가 일시 정지(Sleep) 에 들어간다.
• 큐가 비워지면 다시 밸브가 열린다.

이것이 시스템 전체를 마비시키지 않고도, 그저 로봇의 영상 FPS 를 자연스럽게 10으로 떨어뜨리는(Graceful Degradation) 살벌하고도 완벽한 에이다 런북이다.

4. 실시간성 보장을 위한 데드라인(Deadline) 및 QoS(Quality of Service) 설정

백프레셔(Backpressure) 가 걸려 밸브가 닫힌다는 건, 5초 전의 브레이크 밟으라는 데이터가 지금 도착할 수도 있다는 말이다. 자동차는 즉각 박살 난다.

4.0.1 [Runbook] 데드라인 절단술(Deadlining Drop)

로보틱스 런타임에서 “가장 나쁜 데이터는 늦은 데이터” 이다.

1. 낙하산 옵션의 활성화
파이프라인 통신 계층에서 반드시 데드라인 QoS 를 걸어라.
“이 데이터는 생성된 지 50ms (0.05초) 가 지나면 즉각 메모리 상에서 삭제해 (Drop) 버려라!”

2. 통신망 L7 QoS 와의 교차 폭격
Zenoh-Flow 프레임워크는 단순히 노드 로직을 짤 뿐만 아니라, 기반이 되는 Zenoh 의 L7 통신 채널에 이 설정을 그대로 밀어 넣는다.

• 자율주행 브레이크 신호 Priority: 1
• 카메라 영상 Priority: 5
  로봇 안테나에서 바다 건너 클라우드로 나가는 터널(TCP) 대역폭이 모자랄 때, Zenoh 라우터 엔진은 비디오 프레임 패킷 수백 개를 휴지통에 버리고 우선순위 1번이었던 브레이크 신호 단 하나를 칼같이 가로채 전송해 냄으로써 물리 엔진의 데드라인을 사수한다.