13.9.4.1 싱크(Sink) 코드 단의 데이터베이스 블로킹 배제 및 타임 시리즈(Time-series) 덤프 분리

13.9.4.1 싱크(Sink) 코드 단의 데이터베이스 블로킹 배제 및 타임 시리즈(Time-series) 덤프 분리

분산 데이터플로우(Zenoh-Flow) 파이프라인의 끄트머리에 위치한 싱크(Sink) 노드의 가장 흔한 목적 중 하나는 과거 모터 온도, 조향각 센서값 등 시계열(Time-series) 데이터를 데이터베이스(DB)에 적재하여 관제 대시보드(Grafana 등)로 전시하는 것이다.
이때 싱크 노드 개발자가 가장 흔하게 저지르는 끔찍한 만행은, 파이프라인 싱크(Sink) C++ 코드 안에 InfluxDB 나 PostgreSQL 의 INSERT 쿼리 네트워크 호출 함수(curl 혹은 DB Connector)를 무식하게 박아 넣는 행위다.

DB 서버가 일시적으로 뻗거나 TCP 타임아웃 지연이 발생하면 어떻게 될까? 싱크 노드는 쿼리 응답을 기다리느라 10초간 스레드를 멈추고(Blocking), 결국 파이프라인 역방향으로 큐를 질식시키며(Backpressure) 앞단 자율주행 모터 제어판의 생명줄마저 초토화한다. DB 적재라는 하찮은 로깅(Logging) 로직 따위가 1마이크로초를 다투는 시스템 통제권을 통째로 박살 내는 것이다.

본 절에서는 데이터베이스의 네트워크 지연(Latency)이 파이프라인 핵심부에 단 일말의 블로킹 간섭도 일으키지 않도록, 타임 시리즈 로깅 로직을 파이프라인 외부 스토리지 플러그인(Storage Plugin) 데몬으로 완전히 찢어버려 비동기 격리 생태계를 구축하는 DB 블로킹 배제 런북을 갈파한다.

1. 1차원적 DB 커넥터의 폐해와 비즈니스 침식

어설픈 엔지니어의 싱크 노드 C++ 코드는 아래와 같은 패착을 범한다.

// [파멸적인 파이프라인 내부 DB 밀결합(Coupling) 코드]

void DBLoggingSink::on_data(Data capsule) {
    auto db_conn = connect("tcp://cloud_influxdb:8086");
    
    // 이 멍청한 코드 한 줄 때문에 파이프라인의 생사가 InfluxDB 핑(Ping) 속도에 종속된다!
    // DB가 버벅거리면 데이터플로우 큐 전체가 뻗어버리고 데몬이 OOM 으로 폭발한다.
    db_conn.execute_insert("INSERT INTO temperatures value=...", capsule.value);
}

이 코드는 “관제 로깅의 지연이 일어났을 때, 그것이 로봇의 제어 물리력을 붕괴시켜도 좋은가?” 라는 시스템 철학적 분기점에서 최악의 결단을 내린 것이다.
하드 리얼타임 데이터플로우 아키텍처에서 DB 밀결합은 범죄다. DB는 느리고, 언제든 터질 수 있는(Unreliable) 외부 세계의 이물질이다.

2. 파이프라인 코어에서의 데이터베이스 권한 몰수

아키텍트는 파이프라인 싱크 노드의 C++ 코드에서 DB 라이브러리 #include 자체를 모조리 척결해 버린다.
싱크 노드에게 부여된 임무는, 단지 다 파싱되고 정돈된 데이터를 “파이프라인 통신망 밖, Zenoh 메인스트림 퍼블리싱 토픽 우주(Pub Namespace)” 로 던져버리는 것으로 국한된다.

# [DB 커넥터를 완전히 삭제한 깨끗하고 비동기적인 Sink 런북]
sinks:
  - id: "Telemetry_Ejector"
    uri: "file:///opt/zenoh_flow/builtin_sinks/zenoh_pub_sink.so" 
    configuration:
      # DB 인서트는 알 바 아니다! 나는 데이터를 글로벌 `Zenoh` 토픽 허공망으로 뿌릴 뿐이다!
      key_expr: "telemetry/robot_1/temperature"

이렇게 하면 싱크 노드는 send, 즉 Zenoh Pub 메모리 푸시만 하고 1마이크로초 만에 즉시 쿨하게 자기 스레드 루프를 반환한다. (Zero Blocking). DB가 느리건 터져있건, 이 파이프라인 앞단에 몰려 있는 센서 큐(Queue)는 전혀 백프레셔 타격을 받지 않는다!

3. 타임 시리즈(Time-series) 덤프(Dump)의 방관자적 분리

파이프라인이 밖으로 내뱉은 telemetry/robot_1/temperature 토픽은 허공을 날아간다.
이제 누가 이 데이터를 InfluxDB 에 넣을 것인가?

파이프라인과는 완전히 물리적으로 찢어진 별도의 서버 클러스터(보통 관제 클라우드 백엔드)에 띄워진 Zenoh Storage Plugin (InfluxDB) 백그라운드 데몬이 그 역할을 맡는다. 파이프라인 데몬과 스토리지 데몬은 서로 스레드를 공유하지 않고 철저히 비동기로 통신한다(13.9.4.2장 참조).

파이프라인 연산기 계층(Compute Layer)은 0.1ms 의 무결점 속도로 연산만 하고 허공(Zenoh Router)에 텐서를 날리는 무책임한 방관자가 된다. 그리고 타임 시리즈 보관이라는 더럽고 무거운 DB I/O 작업 계층(Storage Layer) 은 파이프라인 바깥에서 천천히 자기 페이스대로 토픽을 주워담고 인서트(Insert)를 때리는 철저한 이원화 분업 체계.
이로써 파이프라인(Dataflow) 최말단 싱크망의 블로킹 교착(Deadlock) 공포는 논리적 이데올로기 관점에서 영구 삭제 소멸된다.