13.8.4.2 스토어 앤 포워드(Store and Forward) 기반 로컬 디스크 기록용 싱크(Sink) 분기(Split) 아키텍처

13.8.4.2 스토어 앤 포워드(Store and Forward) 기반 로컬 디스크 기록용 싱크(Sink) 분기(Split) 아키텍처

LTE/5G 통신망이 절단(Network Partition, 13.8.4.1장 참조)되어 클라우드로 가는 큐(Queue)가 꽉 막히고 백프레셔에 의해 데이터가 영구 도살(Drop)되는 시스템 생존론은 자율주행의 즉각적 마비는 막아내지만, 뒷단 클라우드 데이터 본부 입장에서는 극도의 갈증을 낳는다.
“통신이 터졌던 5분 동안 로봇이 무슨 짓을 했는지 블랙박스 영상 원본(Raw Data)이 1바이트도 남아있지 않다!”

통신이 부러진 오프라인(Offline) 상황에서도 로봇의 데이터를 휘발시키지 않고, 망이 복구된 직후 그 누락된 과거 데이터를 멱살 잡아 클라우드로 소급 환원시키는 집요한 아카이빙(Archiving) 사상. 본 절에서는 휘발성 메모리 큐(Queue)의 파멸적 한계를 버리고, 파이프라인을 쪼개어(Fork) 로컬 SSD 하드디스크 장판 밑으로 우회 데이터를 직렬화 타격 해버리는 오프라인 스토어 앤 포워드(Store-and-Forward) 하드웨어 분기 런북을 갈파한다.

1. RAM Queue의 한계와 논리망 분기(Split)의 결단

메모리(RAM)는 비싸고 좁다. 망 단절 10분 동안의 카메라 원본 영상 10GB를 큐 버퍼 안에 욱여넣는 것은 정신 나간 망상이다.
아키텍트는 데이터플로우 디스크립터(YAML) 안에서, 원본 카메라 소스 노드의 출력 배관(Link)을 V자 형태로 거칠게 찢어(Fork/Split)버린다.

# [로컬 디스크 블랙박스 분기 사출(Forking) 런북]
links:
  # 배관 1: 메인 딥러닝 판단과 클라우드 싱크로 향하는 리얼타임 통신로 (망이 끊기면 Drop 됨)
  - from: { node: "Camera", output: "Raw" }
    to: { node: "Cloud_AI_Sink", input: "In" }
    
  # 배관 2: 네트워킹을 포기하고! 무조건 장비 자기 배알(SSD)에 데이터를 들이붓는 로컬 저장소 싱크
  - from: { node: "Camera", output: "Raw" }
    to: { node: "Local_Disk_Blackbox_Sink", input: "In" }

이 매니페스트 선언 하나로, 엣지 보드(Zenoh 데몬) 내부에서는 멀티캐스트 네트워크 카드 레이어와 아무런 통신 오버헤드 간섭 없이 완벽히 격리된 초고속 병렬 스레드 분배망이 솟아난다 (Zero-copy clone). 카메라 데이터 포인터 주소증 단 하나만 복사되어 디스크 저장 스레드(Sink)에 즉각 하달된다.

2. Local Disk Sink 의 RocksDB 우겨넣기 (Store)

망이 멀쩡하건, 해저 케이블이 단선 나있건 Local_Disk_Blackbox_Sink 오퍼레이터는 일말의 관심도 없이 자신에게 주어진 분기 데이터를 무식하게 씹어먹기만 한다. 이 오퍼레이터 노드 내부는 파일 입출력(File I/O) 성능을 극한으로 뽑아내기 위해 커다란 비동기 파일 버퍼를 물고 있다.

// [오프라인 블랙박스 강제 수납 스토어(Store) 런북]
void BlackboxSink::on_data(Data capsule) {
    // 1. 네트워크 통신망 `send()` 따위는 아예 부르고 안 부른다.
    // 2. 받은 캡슐의 EventTime 과 바이트 덩어리를 NVMe 디스크 파일 시스템 관(RocksDB) 안으로!
    std::string key = generate_timestamp_key(capsule);
    this->local_rocksdb->Put(write_options, key, capsule.serialize());
}

이로써 망이 단절되어 클라우드 쪽 큐 버퍼가 Drop 살육 파티를 벌이든 말든, 엣지의 SSD 파티션 어딘가에는 찰나의 순간도 놓치지 않고 모든 센서 원본 텐서가 시계열(Time) 키값과 함께 견고하게 박제(Store)되어 무덤을 이룬다.

3. 네트워크 복원 찰나의 데몬 탈취 및 펌핑(Forward)

단절 30분 후, 5G 안테나 통신망 상태가 극적으로 [ALIVE] 로 점화되었다!
평범한 파이프라인이라면 방금 도착한 신규 데이터를 클라우드로 날리며 만족하겠지만, Zenoh 의 시스템 런북은 SSD 무덤을 후벼 판다.

별도로 시스템 컨테이너에 상주하던 백그라운드 아카이빙 에이전트(Archiving Agent) 프로세스가 즉시 눈을 뜬다. 이 에이전트는 Zenoh-Flow 배관에 끼여 있지 않고, 독자적인 Zenoh 메인 Pub/Sub API 권한을 쥐고 있다.
이 녀석은 망 복구를 감지한 즉시, 그동안 Local_Disk_Blackbox_Sink 가 SSD에 꽉꽉 처박아 두었던 RocksDB 데이터를 타임스탬프 순서대로 무식하게 읽어 들이며(GET), 클라우드 데이터 허브의 복구 파이프망 수신처를 향해 거대한 지연 발사(Forward Transfer) 폭격을 쏟아낸다.

“스토어 앤 포워드(Store and Forward)”. 통신망 의존 데이터 분단(Network Partition)을 실시간성(RAM Queue Drop)으로 일차 방어해 자율주행을 보존하고, 뒤로는 분기된 디스크 배관(Local Archiving)을 시켜 오프라인을 뚫어낸 후 통신 복구 시 잔여물을 쏘아 올리는 행위. 메모리와 디스크, 런타임 큐와 백그라운드 데몬이라는 상반된 4개의 축을 비동기적으로 스윙(Swing)시키며 인프라 가용성의 궁지에 몰린 물리 한계를 백엔드 설계 권력으로 제압해버리는 것이다.