Chapter 13. 분산 데이터 컴퓨팅: Zenoh-Flow
에지부터 클라우드까지(Edge-to-Cloud Continuum) 확장되는 현대의 분산 시스템 아키텍처는 센서, 로봇, 자율주행 차량 등 물리적 환경으로부터 쏟아져 들어오는 막대한 양의 데이터를 지연 없이 처리할 것을 요구한다. 기존의 중앙 집중형 스트림 처리 프레임워크(예: Apache Flink, Kafka Streams)는 정적인 클러스터 환경과 풍부한 대역폭(Bandwidth)을 전제로 설계되었기 때문에, 제한된 자원(Resource Constrained)을 가지는 에지 디바이스와 불안정한 광역 통신망(WAN) 환경에서 구동하기에는 태생적인 한계가 존재한다.
이러한 한계를 극복하기 위해 제노(Zenoh) 프로젝트는 데이터가 존재하는 위치로 컴퓨팅 연산을 직접 이동시키는 데이터플로우 프로그래밍(Dataflow Programming) 프레임워크인 Zenoh-Flow를 선보였다. 본 장(Chapter 13)에서는 Zenoh 생태계 내에서 진정한 의미의 분산 컴퓨팅(Distributed Computing) 연산을 실현하는 Zenoh-Flow의 코어 설계 원칙과 아키텍처, 그리고 다국어 환경에서의 구체적인 파이프라인 구축 방법을 상세히 탐구한다.
1. 데이터 중심 연산(Data-centric Computation)으로의 패러다임 전환
Zenoh-Flow는 데이터 중심 네트워킹(Data-centric Networking) 철학을 연산의 영역으로 확장시킨 결과물이다. 마이크로서비스 아키텍처(MSA, Microservices Architecture)나 동기식 원격 프로시저 호출(RPC, Remote Procedure Call) 방식이 연산 노드 간의 빈번한 트래픽 왕복율(Round-Trip)을 유발하는 것과 달리, Zenoh-Flow는 전체 연산 과정을 방향성 비순환 그래프(DAG, Directed Acyclic Graph) 형태의 선언적 파이프라인(Declarative Pipeline)으로 추상화한다.
데이터는 소싱되는 즉시 가장 최적화된 라우팅 경로를 통해 연속적으로 다음 연산 노드로 전달되며, 이 과정에서 Zenoh 라우터(Router) 시스템 내부에 구축된 제로 카피(Zero-Copy) 및 지연 시간 우회(Latency-Bypass) 프로토콜을 적극 활용한다. 클라우드 서버에서만 수행되던 무거운 AI 추론 연산의 일부를 에지 라우터나 로컬 디바이스 수준에서 즉각적으로 전처리(Pre-processing)할 수 있도록 물리적 장비 간 연산을 동적으로 재배치(Relocation)하는 것이 가능해진다.
2. Zenoh-Flow 파이프라인의 핵심 구성 요소
Zenoh-Flow 파이프라인을 구축하기 위해서는 데이터를 발생시키고, 이를 가공하며, 최종적으로 소비하는 일련의 과정을 구조화해야 한다. 이를 구성하는 핵심 아키텍처 단위는 다음과 같다.
- 소스(Source): 외부 세계의 이벤트를 Zenoh-Flow 파이프라인 내부로 끌어들이는 진입점이다. IoT 센서 데이터 인터페이스 캡처, 로봇 제어 신호 수신, 또는 Zenoh Pub/Sub 토픽 데이터의 스트리밍 구독이 포함된다.
- 오퍼레이터(Operator): 유입된 원시 데이터(Raw Data)를 변환, 필터링, 평활화(잡음 제거 등)하거나 머신러닝 알고리즘에 기반하여 추론(Inference)을 수행하는 중추적인 데이터 플로우 연산 노드이다.
- 싱크(Sink): 파이프라인의 최종 목적지로, 처리된 연산 결과를 다른 Zenoh 라우터로 퍼블리시(Publish)하거나 영구적인 백엔드 데이터베이스에 집어넣는(Ingest) 역할을 수행한다.
- 링크(Link): 위 세 가지 노드들을 논리적으로 연결하는 통신 채널이며, 동일 장비 내(Intra-device) 혹은 네트워크 장비 간(Inter-device) 통신을 투명(Transparent)하게 브릿징(Bridging)한다.
graph LR
classDef sourceClass fill:#e3f2fd,stroke:#1565c0,stroke-width:2px;
classDef operatorClass fill:#fff3e0,stroke:#e65100,stroke-width:2px;
classDef sinkClass fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px;
subgraph 에지 환경(Edge Environment)
S1([Source: 진동 센서]):::sourceClass
S2([Source: 고해상도 카메라]):::sourceClass
O1[Opeator: 노이즈 필터링]:::operatorClass
O2[Operator: 엣지 비전 전처리]:::operatorClass
end
subgraph 포그 및 클라우드(Fog & Cloud Continuum)
O3[Operator: 딥러닝 AI 추론기]:::operatorClass
O4[Operator: 다중 센서 데이터 융합]:::operatorClass
Sink1([Sink: 대시보드 시각화]):::sinkClass
Sink2([Sink: 시계열 DB 저장]):::sinkClass
end
S1 -->|Raw Data| O1
S2 -->|Raw Video| O2
O1 -->|Filtered Signal| O4
O2 -->|Cropped Frame| O3
O3 -->|Bounding Boxes| O4
O4 -->|Anomaly State| Sink1
O4 -->|Aggregated Data| Sink2
도식에서 볼 수 있듯, 엣지 환경에서 수행된 1차 오퍼레이터 연산 결과물은 Zenoh-Flow 데몬(Daemon) 인프라를 통해 클라우드 측 오퍼레이터로 자연스럽게 라우팅된다. 이는 개발자가 네트워크 통신의 복잡성을 직접 제어하지 않고도, 분산 런타임을 통해 논리적인 데이터 플로우 그래프를 구성할 수 있음을 입증한다.
3. 단일 지식 기반 다국어 런타임 환경 (Polyglot Runtime)
분산된 디바이스는 각기 다른 목적과 성능 제약을 가지고 있으며, 이에 따라 선호되는 프로그래밍 언어 생태계가 파편화되어 있다. Zenoh-Flow는 이러한 파편화를 극복하기 위해 다국어 기반 노드 개발 및 호스팅 메커니즘을 지원한다.
- Rust: 메모리 안전성(Memory Safety)과 극한의 동시성(Concurrency) 성능이 요구되는 핵심 엣지 컴포넌트에 할당하라.
- Python: PyTorch나 TensorFlow를 이용한 인공지능 분석 파이프라인 및 데이터 사이언스 모듈의 래핑(Wrapping)에 사용하라.
- C/C++: 기존의 레거시(Legacy) 제어 시스템이나 직접적인 하드웨어 인터럽트 제어를 요구하는 오퍼레이터로 컴파일하라.
모든 언어로 작성된 노드 모듈은 단일 YAML 디스크립터(Descriptor) 상에서 정의되며, 런타임(Runtime) 시에 Zenoh-Flow 데몬에 의해 동적으로 연결(Link)되어 작동한다.
4. 본 장의 구성
본 장에서는 위와 같이 분산 데이터 파이프라인 전반을 혁신하는 Zenoh-Flow에 대해 다각적인 접근 방식을 적용한다.
- 처음(13.1 ~ 13.3)에는 Zenoh-Flow의 철학과 기반 코어 아키텍처, 데몬의 실행 구성을 상세히 기술한다.
- 중반(13.4 ~ 13.6)에는 선언적 파이프라인의 설계 문법인 YAML 디스크립터 작성법과 각 언어별 노드 개발 파트, 배포 및 라이프사이클 관리를 제시한다.
- 후반(13.7 ~ 13.10)에서는 고급 흐름 제어(Flow Control), 장애 발생 시의 복원 기법(Fault Tolerance), Zenoh Pub/Sub 등 생태계 심화 통합 기법을 전개하며, 궁극적으로 실전 로보틱스 모빌리티 및 스마트 팩토리를 위한 분산 AI 파이프라인 설계 전략을 완성한다.
데이터플로우를 통한 분산 컴퓨팅의 결합은 현대 소프트웨어 공학이 마주한 트래픽 임계점 및 연산 병목 현상을 타파하는 가장 실질적이고 구체적인 해답이 될 것이다.