13.8.3.3 Zenoh Storage 기반 데이터플로우 외곽망(put-get) 위탁 저장소 연동 런북

Zenoh-Flow 파이프라인 엔진이 죽고 부활하는 처절한 Segfault 참사(13.8.2.1장)와 깡통(Amnesia) 복구 시나리오 속에서, 로컬 NVMe SSD 에 상태를 직렬화(RocksDB)하여 개인 위탁하는 런북(13.8.3.1장)은 극단적으로 빠르지만 치명적인 단점을 한 가지 안고 있다.
“해당 로봇 엣지의 물리적 보드(SSD 하드디스크) 자체가 염산에 녹거나 산산조각 나버린다면, 그동안 백업해 둔 과거의 컨텍스트(State) 역시 로봇과 함께 우주에서 영구히 증발(Hardware Obliteration)한다“는 점이다.

진정한 불멸(Immortality)의 분산 파이프라인 아키텍처는, 극단적으로 중요한 ’몇몇 상태 변수’만큼은 로컬 장판 밑이 아닌, 전 지구에 분산되어 절대 죽지 않는 Zenoh Storage (데이터플로우 외곽 통신망)의 영속적 Key-Value 메모리망에 위탁(PUT/GET) 보관하는 결단을 내려야 한다. 본 절에서는 파이프라인 내부 코어가 외부 스토리지 코어와 결탁하는 하이브리드 저장소 연동 런북을 갈파한다.

1. 인메모리 배관과 영속적 공간(Storage Space)의 분리

Zenoh-Flow 만 가지고 시스템을 짤 때 개발자들은 착각한다. “파이프라인이 데이터를 들고 있으니 저장도 파이프라인 안에서 돌면 되겠지.”
데이터플로우(Dataflow)는 강물(Stream)이다. 강물은 흐를 뿐 멈춰 서 기억을 축적하지 않는다. 기억의 댐(Storage)은 강물 밖에 존재해야 한다.
Zenoh 생태계에는 Zenoh-Flow (연산) 와 독립적인 Zenoh Storage (저장/RocksDB/InfluxDB 연동) 플러그인 데몬이 클라우드 백본 어딘가에 거대하게 띄워져 있다.

이 거대한 클라우드 스토리지 공간은 key/value 형태로 파이프라인의 연산 찌꺼기를 흡수할 준비가 되어 있다.

2. Operator 노드 내부의 Put 폭격 런북

오퍼레이터 노드 C++ 코드는 이 외곽 스토리지 망에 접속하기 위해 파이프라인 배관(Port) 말고, 몰래 백도어 Zenoh Session 을 뚫어버린다.

// [Zenoh-Flow 노드 내부에서 외부 Zenoh Storage 망을 해킹(Put)하는 런북]

void KalmanFilterNode::initialize(Configuration conf) {
    // 1. 파이프라인 엔진과는 별개로! Zenoh 메인 라우터 세션을 하나 더 뚫어버린다.
    this->zs = zenoh::open(zenoh::Config::default()).unwrap();
}

void KalmanFilterNode::on_data(Data capsule) {
    auto current_state = compute_trajectory(capsule);
    
    // [선택적 결단] 매 100 틱마다 한 번씩만! (네트워크 OOM 방지)
    if (tick_count % 100 == 0) {
        // 2. 내 로봇(로컬 디스크)이 아닌 전 지구 허공에 떠 있는 클라우드 
        // Zenoh Storage 군집망을 향해 "Put" 포격(Upload)을 때려 넣는다!
        std::string key = "pipeline/state/vehicle_tracker_01";
        zs.put(key, current_state.serialize()); 
    }
    send_out();
}

이 연산 노드 코드는 100번에 한 번씩(Sampled Checkpoint) 자신의 뇌 속 정보(State)를 로컬 디스크가 아닌 인터넷 망 너머의 Zenoh Storage 로 무식하게 쏴버린다(Put).
네트워크를 타므로 로컬 RocksDB 보다 수백 배 느리지만(Latency), 그 대가로 “이 엣지 로봇 보드 전체가 절벽으로 굴러떨어져 폭사하더라도” 지난 100틱 전의 기억만큼은 AWS 클라우드의 무적 저장소에 영원히 각인되는 재난 복원성(Disaster Recovery)의 절대계(Absolute Plane) 를 확보하게 된다.

3. 부활 시점의 이계(Storage) 역소환(Get)

만일 해당 자율주행 차량 보드가 전소되어, 회사가 새로운 차량으로 갈아 끼운 뒤 동일한 파이프라인 노드를 새 보드에 구동(Deploy) 시켰다고 가정하자.
이 새로운 로봇의 빈 껍데기 데몬은 컴파일되어 램에 뜬 직후, 자신의 텅 빈 SSD 바닥을 긁어보지만 아무것도 없음을 깨닫는다.

이때 아키텍트가 심어둔 initialize() 런북은 외부 우주(Zenoh Storage)를 향해 질의(Get)를 발사한다.

// [이계(Storage)로부터의 기억 역-소환술 런북]
void KalmanFilterNode::initialize(Configuration conf) {
    this->zs = zenoh::open(...);
    
    // 이 쇳덩어리(차량)는 새것이지만, 논리적 자아(vehicle_tracker_01)는 과거를 요구한다!
    auto replies = zs.get("pipeline/state/vehicle_tracker_01").res();
    
    for (auto reply : replies) {
        // [위대한 강림!] 전소된 이전 차량이 죽기 직전 클라우드에 쏴둔 궤적 바이트 덩어리!
        this->my_state = deserialize(reply.sample().payload());
        info!("State recovered from Zenoh Cloud Storage! I remember my past life.");
    }
}

새 기체에 띄워진 파이프라인 노드는 클라우드 공간에 위탁해두었던 전생(Past Context)의 핏자국(Bytes)을 무사히 삼킨 뒤, 아무 일 없었던 것처럼 이전 차량의 궤적 제어 영속성을 고스란히 이어나간다.
데이터플로우 연산망 내부에 메모리를 묶어두는 결벽증을 쓰레기통에 내다 버리고, 필요할 때는 거침없이 외부 Zenoh Key-Value Storage 망의 권력에 자신의 생명줄(State)을 Put-Get 위탁하는 혼종 결합술(Hybrid Architecture). 오직 이 전능한 런타임 외곽망 연동 시나리오만이 로봇 디바이스 통째 물리 멸절이라는 최악의 자연재해 엔트로피조차 가볍게 씹어 넘길 수 있다.