13.6.4.1 우아한 라이프사이클 훅(Hook) 기반 파이프 관문 개방(Start) 및 데이터 발진

13.6.4.1 우아한 라이프사이클 훅(Hook) 기반 파이프 관문 개방(Start) 및 데이터 발진

분산 시스템의 권력자는 인프라를 지배(Deploy)하는 것에 그치지 않고, 그 위를 달리는 생명체의 맥박, 즉 데이터 플로우의 시작과 끝점(Lifecycle) 을 호흡하듯 제어해야만 한다.
Zenoh-Flow 파이프라인은 단순히 한 번 켜지면 무지성으로 데이터를 뽑아대는 구식 C-while 루프의 나열이 아니다. 거대한 노드들이 톱니바퀴처럼 맞물려 동시에 깨어나고 동시에 잠들기 위해서는, 각 노드 스레드 내부에 강제로 심어 놓은 생명주기 콜백 훅(Lifecycle Hook) 에 아키텍트가 개입하여(Intervention) 관문을 열고 닫는 무결점의 제어 런북이 강제되어야 한다.

1. 노드 생명주기(Lifecycle)의 4형태 통치

Zenoh-Flow 의 모든 오퍼레이터 노드(Source, Operator, Sink)는 파이프라인 엔진 내에서 독립적인 생명주기를 부여받는다. 개발자는 자신이 짠 함수들이 언제 호출될지 결정할 수 없으며, 오직 데몬의 스케줄러가 찔러주는 4대 훅(Interface Methods) 구멍 안에서만 얌전하게 코드를 작성해야 한다.

  1. initialize():
  • [부화 페이즈] 파이프라인이 Deploy 될 때 단 한 번 불린다. 외부 환경변수(Env)나 YAML의 configuration 을 읽어들이고, GPU VRAM에 무거운 텐서 가중치를 적재(Warm-up)하는 행위가 이 안에서 이루어져야 한다. 이 단계에서는 절대 데이터를 뱉으면 안 된다.
  1. start():
  • [심장 박동 フェイズ] 관제 마스터가 활성화(Activate/Start) 를 때렸을 때 불린다. 카메라의 DMA 인터럽트를 활성화하고 외부 세상과 연결된 비동기 루프의 무한 톱니바퀴를 돌리기 시작한다.
  1. on_data(...):
  • [근육의 수축] 앞단 노드에서 데이터가 넘어올 때마다 불리는 본체 연산부.
  1. drop() / finalize():
  • [말소 フェイズ] 파이프라인이 삭제(Destroy)되거나 종료할 때 호출된다. 연결해 둔 소켓을 우아하게 끊거나(close), GPU 캐시를 완전히 날려(cudaFree) 운영체제 메모리 환원을 달성해야 한다.

2. Start 관문의 폭발적 동시성 개방 런북

1,000대의 노드에서 initialize 가 모두 무사히 끝나(Stand-By) 준비 깃발을 꼽았다면, 시스템은 완벽한 정적 진공 상태다.
이때 CLI 나 클라우드 통제 서버에서 강제 활성화 타격을 날린다.

# [전 지구적 동시 발진(Start) 타격 커맨드] 
zfctl start 550e8400-e29b-41d4-a716-446655440000

저 엔터키 타격 수 밀리초 후, 분산 네트워크를 타고 각 데몬 워커들의 인터페이스 바닥에 박혀있는 start() 훅 콜백이 융단 폭격처럼 동시 다발적으로 불려 나간다.

[소스 노드 관점의 Start 훅 설계]

// [스마트 로봇의 LiDAR 소스 노드 내부 폭풍 전야]

impl zenoh_flow::Source for LidarSourceNode {
    // 마스터의 start 명령이 하달되는 그 순간, 이 함수가 비로소 깨어난다!
    async fn start(&mut self) -> Result<()> {
        info!("Lidar Source Node is Starting! Unlocking motor spin...");
        
        // 이때 되어서야 진짜 물리 모터 스핀(RPM)을 켠다!
        self.hardware_driver.enable_motor_spin().await; 
        
        // 끝없는 데이터 추출 펌핑을 시작하는 비동기 분기(Spawn) 스레드 강제 발진
        tokio::spawn(async move {
            self.pump_data_to_pipeline().await;
        });
        Ok(())
    }
}

3. 우아한 시작(Graceful Start)의 미학: 스로틀 부재의 참상 차단

왜 initialize() 와 start() 를 쪼개 놓았는가에 대한 해답은 인프라 안정성의 본질에 닿아있다.

오디오(Audio) 노드는 0.01초 만에 준비를 마치고, 3D 랜더링(Vision) 노드는 준비하는 데 15초가 걸린다 가정해 보자.
만일 initialize 하자마자 둘 다 무식하게 데이터를 발행(Publish)하기 시작한다면, 오디오 노드는 지난 15초간 수만 개의 الصوت(음성) 캡슐을 파이프라인에 뱉어버리게 된다. 결국 뒷단의 병합(Join/Fusion) 노드에는 “정확히 동일한 타임 스탬프(Timestamp)를 가진 오디오와 비전 데이터“가 도달해야 하는데, 오디오 패킷만 15초 치가 큐에 쌓여 폭발적인 타이밍 어긋남(Skewing)과 큐 초과(OOM) 오류를 일으킨다.

모든 이기종 장비의 초기화 시간 불균형을 온전히 흡수하기 위해, “전 장비가 initialize 완료“를 외칠 때까지는 어떠한 데이터도 발진하지 못하게 거대한 스로틀(Throttle) 장벽을 치는 런북. 그것이 끝나야 비로소 관리자의 권위로운 서곡 지휘(start 훅 찌르기)와 함께 무결점 데이터 융합 대오(Dataflow Formation)가 출발선을 동시에 넘게 되는 것이다.