14.8 사용자 정의(Custom) 백엔드 플러그인 개발 및 런타임 이식

14.8 사용자 정의(Custom) 백엔드 플러그인 개발 및 런타임 이식

엔터프라이즈 환경에는 상투적인 RocksDB나 InfluxDB와 같은 대중적 데이터베이스만이 존재하지 않는다. 특정 산업군에는 국방 도메인에서만 제한적으로 사용되는 기괴한 독자 규격 파일 시스템이 있을 수도 있고, 망 분리가 일상화된 금융 기관에서는 데이터를 무조건 AWS S3와 같은 클라우드 객체 저장소(Object Storage)나 사내 폐쇄망 블록 스토리지에 특수 암호화하여 밀어 넣어야 하는 엄격한 보안 규정이 강제될 수도 있다.

Zenoh 코어 생태계가 기본으로 제공하지 않는 이질적 데이터베이스나 미지원 레거시 스토리지를 연동하고자 할 때, 어떻게 해야 하는가?
고개를 숙이고 C++ 소켓 프로그래밍으로 무거운 이기종 프록시 브릿지(Middleware Proxy)를 외부에 주먹구구식으로 짜는 어리석은 오버헤드 낭비를 멈춰라. Zenoh는 당신이 직접 짜낸 순수 Rust 기반의 커스텀 클래스 로직 뭉치를, 라우터 데몬(Router Daemon)의 심장인 런타임 코어 에 프로세스 플러그인 형태로 직접 외과 수술해 이식해 넣을 수 있는 궁극의 확장성 네이티브 인터페이스(Extensibility Native Interface) 를 공식 제공한다. 본 장에서는 오직 나만의 커스텀 백엔드(Custom Storage Backend)를 밑바닥부터 개발하여 Zenoh의 물리적 한계를 부수는 고급 기점 런북(Runbook)을 전개한다.

1. 커스텀 백엔드 플러그인 개발 환경 세팅 (Rust 코어 중심)

Zenoh 라우터에 삽입할 백엔드 플러그인은 실행 오버헤드가 큰 파이썬(Python) 같은 인터프리터 스크립트 언어로 짤 수 없다. 무지막지한 트래픽이 몰아치는 라우터와 단 1밀리초의 지연이나 메모리 누수 오차도 없이, 동일한 힙 메모리 포인터(Memory Pointer)와 Tokio 코루틴 스레드를 동기화하여 주고받아야 하므로, 메모리 세이프(Memory Safe)와 제로 코스트(Zero-Cost) 추상화를 보장하는 Rust 언어로만 빚어내야 한다.

1.0.1 플러그인 뼈대(Skeleton) 바이너리 강제 주입 세팅

당신이 작성할 컴파일 코드는 독립된 일반 실행 파일(Executable Binary, fn main())이 아니다. Zenoh 라우터가 부팅 중 런타임 힙에 다이렉트로 삼켜 로드하기 좋은 “동적 공유 라이브러리(Dynamic Shared Library)” 형태로 시스템 구조를 조각해야 한다.

1) Cargo.toml 매니페스트 파괴적 설정 튜닝
보통의 애플리케이션 컴파일 타겟 규칙을 폐기하라. cdylib (C API 호환 동적 라이브러리) 패러다임으로 크레이트(Crate) 성격을 강제 전환해야 한다.

[package]
name = "zenoh-backend-my_secret_vault" # 플러그인 컴포넌트 고유명
version = "0.1.0"
edition = "2021"

[lib]
## Zenoh 데몬이 프로세스 런타임에 동적 로드(.so / .dll / .dylib) 할 수 있도록 강제 빌드 타입 지정!
crate-type = ["cdylib"]

[dependencies]
zenoh-plugin-trait = "0.10"       # 필수: 플러그인 등록 엑스포트(Export) 매크로
zenoh-backend-traits = "0.10"     # 필수: 스토리지 뼈대 트레이트(Trait) 규격
tokio = { version = "1", features = ["full"] } # 비동기 동시성 제어 코어 런타임

2) 심장에 생명 불어넣기: 런타임 매크로(Macro) 전역 등록
당신의 추상 코드가 시스템 데몬 프로세스에게 “내가 바로 그 스토리지 플러그인이다!” 라고 메모리 상에서 소리치려면, Rust 코드 최상단 전역 공간에 런티임 바인딩 매크로를 강제 찍어 낙인해야 한다.

use zenoh_plugin_trait::{export_plugin, Plugin};

// 백엔드 환경 관리를 담당할 최상위 매니저 구조체 선언
struct MyCustomVaultBackend;

// 데몬이 기동되어 .so 파일을 스캔할 때, 
// 이 매크로 지시자를 보고 엔트리 포인트를 낚아채어 엔진을 마운트 연동시킨다!
export_plugin!(MyCustomVaultBackend);

여기까지 세팅을 마쳤다면, Zenoh 데몬이라는 거대한 호스트 숙주의 시스템 바디에 기생하여 I/O를 통제할 기생수(Plugin)의 완벽한 유전자(DNA) 골격 뼈대가 준비 완성된 것이다.

2. Backend Trait 및 Storage Trait의 계층 구조와 구현

뼈대를 만들었다면 이제 라우터 데몬 커널이 엄격하게 요구하는 잔혹한 데이터 I/O 인터페이스 계약(Contract)을 이행해야 한다.
커스텀 스토리지 모듈을 짜려면 당신은 무조건 두 개의 인터페이스(Trait) 를 상하 종속 계층으로 강제 구현해야 한다.

2.0.1 투 트랙(Two-Track) 지휘 체계의 구조 분리 철학

1) Backend Trait: 인프라 관리 및 공장장 (Factory/Manager)

  • 이 최상위 클래스는 실제 트래픽 데이터를 굽거나 저장하지 않는다. 단지 JSON 설정 파일(zenohd.json5)에 적힌 파라미터를 파싱해 읽어내서, “자신 밑에서 실제 디스크 I/O를 담당하며 실무를 뛸 하위 일꾼(Storage Instance)” 객체를 동적으로 생성 팩토리(Factory)하는 매니저 역할만 수행한다.
  • 핵심 필수 구현 함수: new() (플러그인 모듈 초기 부트 생존), start() (라우터 런타임 스레드 진입), new_storage() (볼륨 마운팅 라인이 JSON에 등장하는 시점의 실무 일꾼 객체 동적 창조).

2) Storage Trait: 최전방 실무자 (I/O Worker)

  • 이 클래스가 진짜 피 터지게 데이터를 읽어 파일 시스템이나 클라우드 스토리지에 꽂고(Put), 지우고(Delete), 꺼내어 반환(Get)하는 핵심 처리기다.
  • 핵심 필수 구현 함수: put(), delete(), get() 등.
// 1. 공장장(Backend 인프라) 구현부
#[async_trait]
impl Backend for MyCustomVaultBackend {
    // 라우터가 json을 읽다 "내 특수 볼륨 DB 좀 새로 뚫어줘" 라고 명령하면, 
    // 실무자(MyActiveStorage) 구조체 인스턴스를 동적으로 팩토리 생성해서 권한을 던져준다!
    async fn new_storage(&self, admin_node: AdminNode) -> Arc<dyn Storage> {
        Arc::new(MyActiveStorage { /* 타겟 폴더나 URL 설정 맵핑 초기화 */ })
    }
}

// 2. 일꾼(Storage I/O 실무자) 구현부
#[async_trait]
impl Storage for MyActiveStorage {
    // 외부에서 라우터가 Put 메시지를 스니핑 파싱해 받으면 이 비동기 함수를 다이렉트로 때린다!
    async fn put(&self, key: &KeyExpr, payload: &ZBytes) -> ZResult<()> {
        // DB에 진짜 쓰기 작업을 수행하는 척 하는 모의 예시 코드
        println!("특수 보안 볼륨에 매립 중... Key: {}", key);
        // (실제라면 이곳에 파일 I/O나 특수 DB의 Insert 로직이 들어간다)
        Ok(())
    }

    // 누군가 Get을 때려 데이터를 내놓으라 윽박지르면 라우터가 이 함수를 호출한다!
    async fn get(&self, key: &KeyExpr) -> ZResult<Vec<Sample>> {
        // 하드디스크나 커스텀 클라우드를 뒤져서 찾아주는 척 하는 리턴 로직
        Ok(vec![])
    }
}

이 두 개의 트레이트 객체가 톱니바퀴처럼 정교하게 맞물려(Interlocking), “데몬 모듈 로딩” \rightarrow “하위 스토리지 볼륨(Volume) 동적 생성” \rightarrow “초고속 비동기 데이터 입출력 스트리밍” 으로 이어지는 Zenoh 시스템 뎁스의 거대한 라이프사이클을 돌리게 된다.

3. 멀티 코어 플러그인 컴파일 및 공유 라이브러리(.so, .dll) 동적 핫-로딩(Hot-Loading) 매커니즘

Rust 코드를 안전하게 다 짰다면, 이제 이 코드 스크립트를 CPU가 읽을 수 있는 단단한 쇳덩어리(Binary) 로 컴파일 구워서 라우터에게 먹여야(Feeding) 한다.

3.0.1 런타임 핫-로드(Hot-Load) 외과 수술 튜닝 전술

1) 릴리즈(Release) 극강 빌드 사수 파이프라인
I/O 렌더 레이턴시가 1ms 단위로 갈리는 로보틱스 데이터 런타임에서, 개발용 디버그(Debug) 모드 플러그인 바이너리를 넣는 것은 시스템 성능 스루풋을 50배 이상 하락 및 병목 마비시키는 치명적 바이러스 주입 행위다. 무조건 최적화가 걸린 릴리즈 모드로 강제 컴파일하라.

## LLVM 최적화가 극한으로 타겟 걸린 바이너리 컴파일 도출
cargo build --release

빌드 엔진 구동이 끝나면 맵 트리에 target/release/ 폴더 아래, 리눅스 커널 기준 libzenoh_backend_my_secret_vault.so (윈도우는 .dll, macOS는 .dylib) 라는 이진 파드 컴포넌트 파일이 떨어진다.

2) 런타임 무중단 데몬 주입 (Injection) 스캔 규칙
Zenoh 데몬 라우터는 메인 프로세스가 기동될 때 오직 딱 2가지 시스템 경로 장소에서만 동적 플러그인을 스위칭 찾는다.

  • 라우터 본체 실행 파일(zenohd)이 구동 켜진 바로 그 현재 작업 부트 디렉터리 폴더 주변.
  • 사용자가 시스템 환경으로 지정한 특별한 라이브러리 스니핑 경로 폴더(예: 리눅스의 ~/.zenoh/lib, /usr/local/lib/zenoh/).

직접 컴파일해 만든 .so 플러그인 바이너리 덩어리 파일을 스니핑 탐지 폴더에 툭 던져놓고 라우터를 부팅 켜라.

## 동적 플러그인 .so 파일이 위치한 폴더에서 라우터 가동 타건!
zenohd -c my_custom_vault_config.json5

라우터가 부팅되면서 로그 출력 콘솔 창에 “Oh, I successfully found and loaded my_secret_vault backend plugin!” 하는 엔트리 진입 성공 메시지를 띄우면 핫-로딩 엔진 이식 수술은 성공이다.
본체 시스템 코드(Zenoh Core 소스)를 단 한 줄도 건드리거나 재컴파일하지 않고도, 오직 나만의 커스텀 특수 DB I/O 드라이버를 데몬 프로세스 런타임(Runtime) 에 강압 주입해 융합시켜 버린 것이다.

4. 무한 클라우드 스토리지(AWS S3, Azure Blob)를 로컬 통신 볼륨처럼 연동하는 가상 영속화 구축 실무 실습

지구 반대편에 있는 가장 거대하며 동시에 I/O 호출 비용이 가장 느린 객체 스토리지 버킷 공간(Bucket, AWS S3)을 마치 에지(Edge) 단말의 로컬 SSD 하드디스크인 것처럼 속여 렌더링 스위칭해보자.

4.0.1 프로토콜 추상화 브릿징(Protocol Abstraction Bridging) 스로틀링 런북

Zenoh 의 커스텀 Storage Trait 구현부 안에, AWS 가 배포 제공하는 네이티브 Rust S3 SDK 를 결합 녹여 인서트 넣는다.

1) Storage::put() 오버라이딩: 구름(Cloud S3) 속으로 패킷 무빙 던지기 및 REST 방어
클라우드 객체 스토리지 연결 시엔 무조건 강력한 비동기 스로틀링(Throttling 제한) 기법을 코드에 반영 적용해야 한다.
고속 데이터가 100건 들어왔다고 해서 멍청하게 S3 REST API 를 개별적으로 100번 때리면 당장 아마존 빌링 서버에서 호출 요금 폭탄이 터지고 즉각 API 트래픽 블로킹(HTTP 429 Too Many Requests 에러) 락이 날아온다. 커스텀 스토리지 구현 시, 데이터를 RAM 힙 버퍼에 머금고 대기하다가 대략 10초에 한 번씩 S3 put_object 로 거대한 청크 단위 통짜 덤프를 쏘는 스마트 배치(Batch Processing Accumulation) 로직을 짜서 방어막을 쳐야 한다.

// [개념적 구현 매핑(Conceptual Implementation)]
async fn put(&self, key: &KeyExpr, payload: &ZBytes) {
    // 1. Zenoh 키를 토대로 S3 객체 경로 버킷 URL 생성 파싱
    let s3_path = format!("s3://my-cloud-drone-bucket/{}", key);
    
    // (실무에선 여기에 n초간 큐잉 타임 버퍼링 스로틀 로직이 들어감)
    
    // 2. 비동기 S3 청크 업로드 (직접 짜 넣은 AWS S3 Rust SDK 렌더 코드 연동)
    s3_client.put_object()
        .key(s3_path)
        .body(payload.to_vec())
        .send()
        .await;
}

2) Storage::get() 오버라이딩: 구름 해양 객체 다운로드 낚시질
지상 관제 센터 웹 패널에서 z_get "robot/s3_storage_area/**" 를 핑 호출하면, 이 커스텀 스토리지 에이전트 플러그인은 즉각 백그라운드에서 AWS S3 엔드포인트를 향해 list_objects 및 get_object 클라우드 타겟 API 를 날려 과거 데이터를 로컬 램 메모리 공간으로 파일 I/O로 당겨온다(Pull / Download). 그러고는 이 당겨온 거대 데이터를 재빨리 Zenoh 프로토콜 의 표준 이진 Reply 어레이 양식에 맞게 슬쩍 규격 포장 재단해서 관제 센터 포트로 네이티브 반환 슈팅 응답한다.

호출자인 엔드 클라이언트 사용자는 중간 미들웨어에 S3 접근 토큰이 뭔지도, 클라우드 HTTP API 가 어떻게 매핑 호출되는지 그 복잡한 과정을 전혀 1도 알지 체감 인지하지 못한다.
그저 평소처럼 터미널에서 z_get "robot/s3_storage_area/*" 쿼리 구문 하나 툭 치고 대기하면, 저 멀리 대륙 바다 건너 S3 클라우드로부터 아카이빙 데이터가 마치 로컬 메모리에 꽂혀 있던 것처럼 줄줄이 소켓을 타고 쏟아져 나온다. 스토리지 백엔드 플러그인 런타임 이식이 시스템 엔지니어에게 가져다주는 극강의 망 스로틀 추상화(Network Protocol Abstraction) 가 조율 이룩어낸 걸작의 산물이다.