13.10.3.2 가중치(Weight) 폐기 런북 및 데드라인(Deadline) 패킷 로스 로직 강제화 적용

13.10.3.2 가중치(Weight) 폐기 런북 및 데드라인(Deadline) 패킷 로스 로직 강제화 적용

분산 컴퓨팅 파이프라인에서 데이터를 처리하는 오퍼레이터(Operator) 노드 간의 릴레이(Relay) 통신은 마치 컨베이어 벨트에 부품을 올리는 행위와 같다. 전처리 노드가 가공한 데이터를 넘기면, 추론 노드가 이를 받아먹는 방식이다.
이 과정에서 기존 메시지 큐(Message Queue) 시스템들(Kafka, RabbitMQ 등)의 고질적 한계는, 큐 버퍼 안에 든 모든 패킷에 “공평한 지분(Fairness)” 이나 “순차 처리 가중치(Weight)“를 매겨 어떻게든 잃어버리지 않고 다 처리해주려 안달이 난다는 점에 있다.

로보틱스와 초저지연 스웜 드론 관제망에서 이런 “공평한 가중치 배분” 사상은 시스템 지연을 폭증시키고 최신 상태(Latest State) 추종을 가로막는 재앙의 지뢰밭이다. 본 절에서는 Zenoh-Flow 프레임워크 내에서 파이프라인 링크에 박힌 과거 처리 의무(Weight)를 완전히 소각하고, 잔혹한 데드라인(Deadline) 폐기 스토리지 로직을 강제해 하드 리얼타임을 온존시키는 방책을 제안한다.

1. 큐 가중치(Weight)의 관성화와 처리량(Throughput) 역전

로봇 카메라에서 60FPS로 쏟아지는 화상 블록이 첫 번째 Resize Operator(크기 변환 노드)를 거쳐, 두 번째 딥러닝 Inference Operator(추론 노드)로 떨어지는 파이프라인을 구축했다고 가정해 보자.
크기 변환 연산은 초당 60장을 쉽게 해내지만, 무거운 딥러닝 추론 연산은 GPU 한계상 초당 30장밖에 처리하지 못한다.

만약 두 노드 사이의 연결망(Link)에 데이터를 보존하는 일반적인 가중치 큐(Weight Queue) 패러다임이 적용되어 있다면 끔찍한 사태가 도래한다. 파이프라인은 버려지는 프레임 없이 ‘모두’ 학습하겠다고 큐 사이즈를 팽창시키며 발열을 버티고 순서를 유지한다.
10초가 지나면 300장의 처리하지 못한 오래된 프레임이 대기열에 고립(Stuck)된다. 드론은 이미 10초를 날아가 절벽 앞에 다가가고 있는데, 딥러닝 추론 엔진 파이프라인은 여전히 10초 전(과거) 구역의 빈 잔디밭 사진을 보며 “안전하다!“라고 헛소리를 외치며 시스템 통제권을 날려 먹는다.

2. 과거 가중치(Weight) 완전 소각 런북

이러한 레이턴시 부채(Latency Debt)를 타파하기 위해서는, 데이터 플로우를 정의하는 매니페스트(Yaml) 선언부에서 노드 간의 링크(Link) 배관에 걸린 데이터 유보 정책을 극한의 “최신 선호(Latest Only)“로 강제로 부수어(Rewrite) 놓아야 한다.

가치(Weight)를 오직 “가장 최근 도착한 프레임 1개“에만 100% 몰아주고, 대기열에 있는 과거 프레임 따위에는 처리 권한 가중치를 부여하지 않는 족쇄를 채우는 것이다.

# [Zenoh-Flow 링크 강제 소거 런북] 
# (Node A -> Node B)
links:
  - from: "resize_operator_output"
    to: "inference_operator_input"
    # 채널의 길이를 기계적으로 박살 낸다 (Queue Depth = 1)
    # 뒤쪽 노드가 밀려도, 큐에는 절대 쓰레기 패킷이 겹겹이 쌓이지 못함.
    capacity: 1

이렇게 단 1개의 캡슐 용량(Capacity)만을 허락하는 순간, 앞 노드(Resize)가 분출하는 초당 60장 중 뒤 노드(Inference)가 처리할 수 없는 속도의 잉여 30장은 큐 안착에 실패하고 그냥 허공으로 쓸려나가 폐기된다(Fire and Forget). 그 결과 딥러닝 추론 노드가 연산을 끝내고 고개를 들어 다음 데이터를 요청할 때, 그 큐 안에는 항상 ’방금 도착한 단 1장의 최신 사진’만이 반짝거리고 대기하게 된다.

3. 데드라인(Deadline) 패킷 로스(Loss)의 철학 구축

단순히 큐의 공간을 줄이는 데에서 멈추어선 안 된다. 클라우드 횡적 확장을 통해 이 파이프라인이 여러 서버로 쪼개져 동작할 때, 네트워크 레이턴시 자체가 100ms를 초과해버리는 경우도 고려해야 한다.
데이터가 큐 공간(Capacity 1)을 차지하고 있더라도, 그 큐 공간 안에 머무른 지 시간 한계(예: 50ms)가 지났다면 이 역시 무가치한 좀비(Zombie) 데이터로 전락한 상태다.

파이프라인의 오퍼레이터 코어 내부 C++ 수신부 로직에 Time-To-Live (TTL) 데드라인 파괴 로직을 추가하라.

void on_data_received(const Context& ctx, const Data& data) {
    auto current_time = std::chrono::system_clock::now();
    // 데이터 캡슐에 포장되어 온 생산 시간표(Timestamp) 추적
    auto elapsed_ms = duration_cast<milliseconds>(current_time - data.creation_time).count();

    if (elapsed_ms > 50) {
        // [잔혹한 강제 폐기] 도착했지만 이미 상해(Expiration)버렸다! 
        std::cout << "[Warn] Deadline Miss! Data Dumped. (" << elapsed_ms << "ms)" << std::endl;
        return; // 어떠한 추론 연산도 타지 않고 그대로 리턴(Drop)
    }
    
    // 생존한 50ms 이내의 최신 초격차 데이터망으로만 연산 전개
    run_heavy_inference_model(data.payload);
}

하드 리얼타임 데이터 플로우 아키텍처에서 노드망과 데이터에 영구적인 가중치(Weight)란 존재하지 않는다. 모든 정보는 철저히 유통기한(Deadline)을 지닌 시한폭탄과 같으며, 그 기한이 지났을 때 과감하게 데이터 스트림을 스스로 도려내는(Drop) 결단력이야말로 CPU와 메모리의 연산 자원을 오직 ’가장 가치 있는 현재’에 올인할 수 있게 해주는 거대한 시스템 수비학적 율법이다.