13.7.3.1 통신망 소켓 버퍼 폭발 및 커널 포화 방어 전술

거대한 선언적(YAML) 로직에 의해 직조(Deploy)된 수백 대의 분산 시스템 워커(Zenoh-Flow Daemon)는 각자 부여받은 연산 임무에만 충실하려 드는 이기적인 장기말이다.
소스(Source) 카메라 로봇 보드가 초당 120장의 이미지를 직렬화하여 클라우드 통신망 소켓으로 들이붓는다 해보자. 클라우드의 VRAM 딥러닝 추론 노드(Operator)는 초당 40장밖에 소화하지 못할 때, 그 남은 차액인 ’초당 80장(약 400MB)’의 텐서 패킷 압력 파도는 과연 어디로 증발하는가?

소실되지 않는다. 이 거대한 지연 압력(Backpressure)은 고스란히 운영체제(Linux) 커널의 TCP 송수신 소켓 버퍼(Socket Buffer) 풀장 벽면을 후려갈기게 된다.
본 절에서는 스케줄링이 뒤틀려 폭주하는 파이프라인의 찌꺼기 트래픽들이 커널 공간을 잠식하여 시스템을 완전히 빈사 상태(OOM & Kernel Panic)로 추락시키는 메커니즘을 해부하고, 이를 찢어버릴 인메모리 배관 통신망 포화 방어 런북을 설파한다.

1. 운영체제 TCP Socket 버퍼의 침묵과 포화(Saturation) 병목

데이터 플로우 시스템에서 앞단 오퍼레이터(A)가 외부 멀티캐스트 원격 배관으로 데이터를 쏠 때(send()), 일반 개발자는 이것이 즉각적으로 원격지 뒷단(B) 큐에 안착했다고 착각한다.
하지만 실상은 수화물(Payload)을 운영체제(Linux) 커널 저 아래의 TCP 전송 샌드박스(Tx Buffer) 안으로 쑤셔 넣고 끝낸 것에 불과하다.

뒷단(B)이 느려 터져 수신 속도가 지연되면 어떻게 될까? 원격지(B) 커널의 수신 버퍼(Rx Buffer)가 먼저 임계 수준까지 가득 차버리고, TCP 윈도우 사이즈(TCP Window Size)를 제로(0)로 떨어트려 “데이터를 그만 쏴라!” 라고 역방향 신호(Zero-Window Probe)를 날린다.
신호를 받은 송신지(A)의 커널은 송신 버퍼(Tx Buffer) 출구를 잠가 버리고 닫게 된다.
하지만 이때 멍청하게도 A의 Zenoh-Flow 연산 스레드는 여전히 초당 120장씩 쇳덩어리 센서에서 끊임없이 데이터를 읽어와서 어떻게든 A 커널 소켓 버퍼 안으로 구겨 넣어려 시도한다! 그 결과 A의 C++ 스레드는 커널 공간(Syscall)에서 블로킹(Blocking Lock)이 걸리어 1걸음도 나아가지 못하고 온몸이 마비되는 치명적인 교착(Deadlock Cascade)의 연쇄 반응에 감전당한다.

2. 애플리케이션 레벨 큐(Queue)와 커널 공간의 완전한 격리

이 자멸적 프로세스 독점을 피하기 위해 런타임 프레임워크는 커널 소켓 블로킹 함수인 send() 의 노골적 호출을 절대 용인하지 않는다.
커널 네트워크 드라이버 공간과 Zenoh-Flow 시스템 비즈니스(데이터 캡슐 로직) 스레드 공간 중간에 거대하고도 탄력성 있는 애플리케이션 비동기 링-버퍼 큐(Non-blocking Ring Buffer Queue) 가 쿠션(Buffer)처럼 방벽을 친다.

// [TCP 소켓 커널 마비 방지를 위한 비동기 차단 런북]

// 1. 소스 스레드가 만든 데이터를 절대 소켓에 직접 때리지 않는다! 
//    애플리케이션(RAM) 영역에 떠 있는 거대한 쿠션망(Channel Queue)에 던진다.
async fn operator_produce_pipeline(channel_queue: &mpsc::Sender<Data>) {
    // 큐가 가득 차지 않는 한, 연산 스레드는 커널 마비의 공포 없이 광속으로 돌아간다.
    channel_queue.send(massive_camera_frame).await; 
}

// 2. 오직 네트워크 전송(Socket Tx)만을 전담하는 별동대(Tokio I/O Worker) 스레드를 백그라운드에 따로 찢어 격리시킨다.
async fn network_socket_poller(channel_queue: &mut mpsc::Receiver<Data>, tcp_socket: TcpStream) {
    while let Some(capsule) = channel_queue.recv().await {
        // 이 놈이 TCP 커널망(Backpressure)과 피 튀기며 싸우는 동안,
        // 메인 센서 연산 스레드는 아무런 레이턴시 영향을 받지 않고 보호된다(Decoupling).
        tcp_socket.write_all(capsule).await; 
    }
}

이 I/O 격리(Decoupling) 전술은, 네트워크 케이블이 끊어지거나 원격지가 퍼져서 발생한 저열한 스레드 블로킹(Socket Hang) 병목이 시스템 메인 센서/딥러닝 연산 스텝 수명을 갉아먹지 못하도록 투명한 방어선(Demilitarized Zone)을 조각(Carving)해낸다.

3. 큐 만수위(High-Water Mark) Drop 전술과 망 생존성

쿠션 큐(Queue) 공간을 애플리케이션 영역에 파두었다고 모든 재앙이 사라진 것은 아니다.
원격지 클라우드가 무려 10분 동안 연산을 지연당하고 뻗어있다면, 저 거대한 중간 쿠션망(Channel Queue)마저 가득 차서 넘치고(Memory OOM), 데몬 엔진이 폭파된다.

궁극의 파이프라인 아키텍처는 이때 방어 기제인 임계 만수위(High-Water Mark) 강제 도살 전술을 결단한다.
엔지니어는 파이프라인 YAML 구성 시 각 링크(Link) 배관의 큐 사이즈를 무제한(Infinite)으로 두는 멍청한 짓을 절대 해선 안 된다. 큐 사이즈를 정확히 메모리가 버틸 수 있는 Queue_Size: 1000 상단 캡(Cap)으로 철봉을 친 뒤 정책을 내린다.

큐가 1,000개가 넘치어 임계점을 부수는 순간, 새로 유입되는 센서 데이터 캡슐들을 큐 엉덩이에 밀지 말고(No blocking), 즉시 허공의 메모리 덤프로 도살(Drop) 처분하고 영구 파기(Forget)시켜 버려라!

분산 세계의 배관망(Pipeline)에서 10분 지연된 자율주행 데이터는 살려보았자 휴지 조각보다 가치가 없는 오염된 과거 쓰레기다.
통신 소켓 버퍼가 가득 차 커널이 멈추려 할 때, 비동기 중간 큐를 넓혀 충격을 일차적으로 방어하고, 그것마저 임계치를 넘는 순간 낡은 지연 데이터를 자비 없이 영구 절단(Drop) 처리하는 결단 지휘. 이것이 죽어가는 워커 데몬 시스템 본체를 영구적인 커널 프리즈(Kernel Freeze)로부터 소생시키고 네트워크 스웜 뼈대를 지켜내는 파괴의 공학이다.