6.5 고성능 통신을 위한 메모리 관리와 제로 카피(Zero-Copy)

6.5 고성능 통신을 위한 메모리 관리와 제로 카피(Zero-Copy)

C++ 분산 시스템 개발자가 밤을 새우는 이유의 9할은 “데이터를 보냈는데 메모리가 복사되면서 CPU 점유율이 90%를 찍는 문제“를 고치기 위함이다. 일반적인 소켓 통신 라이브러리는 10MB짜리 카메라 영상을 네트워크 타일에 밀어 넣으려면 최소 두세 번의 메모리 딥 카피(Deep Copy)를 강제한다. 이는 ROS1의 고질적인 병목이기도 했다.

Zenoh C++ API는 개발자에게 무기에 가까운 자유도를 부여한다. 배열을 통째로 넘기는 스마트 포인터 연동 방식부터, 소켓 커널과 직접 연결되는 ZBuf 메커니즘, 나아가 동일 리눅스 보드 안에서 프로세스 간 통신(IPC) 오버헤드를 수학적 ’0’으로 수렴시키는 공유 메모리(Shared Memory) 아키텍처까지. 이 챕터는 당신의 C++ 코드가 어떻게 하드웨어의 VRAM이나 L3 캐시 한계까지 시스템 성능을 폭발시킬 수 있는지 증명하는 가장 하드코어한 튜닝 런북이다.

1. Zenoh 메모리 모델과 ZBuf (Zenoh Buffer)의 이해

publisher.put() 에 당신이 애써 만든 std::vector<uint8_t> 를 밀어 넣는 순간, 이 10MB 튜토리얼 코드는 실제로 통신선(Wire)을 타기 전까지 몇 번이나 메모리 복사를 겪을까?

기존의 memcpy 의존형 네트워크 개발을 버리고, 진정한 제로 카피의 첫걸음인 조각 버퍼(Fragmented Buffer) 의 미니멀리즘을 익힐 때다.

1.0.1 [Runbook] 연속적이지 않은(Non-contiguous) 메모리 핸들링

수신(Subscribing) 시, 패킷은 쪼개진 채로 도착할 수 있다. Zenoh는 이 패킷들을 하나로 통합하기 위해 억지로 10MB짜리 빈 메모리를 할당하지 않는다!

1. 조각난 데이터 순회 체계 (Zero-Copy 낭독)

auto sub = session.declare_subscriber("camera/feed", [](const%20zenoh::Sample&%20sample) {
    auto payload_view = sample.get_payload();

    // [초보자 안티 패턴] contiguous()를 호출하는 순간 
    // 내부적으로 malloc()이 터지며 무자비한 병합 복사가 발생한다!
    // auto copy_buf = payload_view.contiguous(); 
    
    // [고수 아키텍처] 잘게 쪼개져서 날아오는 버퍼 조각들을 "있는 그대로" 읽는다.
    for (const auto& chunk : payload_view) {
        // 이 chunk.data() 포인터는 수신 커널이나 소켓 버퍼를 다이렉트로 가리키고 있다.
        const uint8_t* raw_mem = chunk.data();
        size_t size = chunk.size();
        
        // 조각난 1KB 버퍼를 VRAM이나 압축 코덱에 곧바로 밀어 넣는다. 메모리 점유율 '0'!
        feed_to_h264_decoder(raw_mem, size);
    }
});

Zenoh 수신 단에서 payload 객체는 물리적으로 연결된 1개의 배열이 아니라 논리적으로만 연결된 조각난 체인 배열이다. 이걸 억지로 일렬로 맞추려고(Contiguous) 시도하는 자는 네트워크 엔지니어가 될 자격이 없다. 파편화된 스트림을 파편화된 그대로 소비(Consume)하는 스트리밍 파이프라인을 구축하라.

2. 제로 카피(Zero-Copy) 전송 기법을 통한 대용량 페이로드 처리

100MB 크기의 라이다(LiDAR) 포인트 클라우드 데이터를 송신부 스레드에서 생성했다. 이걸 어떻게 Zenoh TCP 버퍼로 전달할 것인가?
“바이트 복사“는 C++ 성능 최적화의 제1 적폐다. 여기서는 당신의 데이터를 복사하는 대신, “데이터 소유권” 자체를 Zenoh 코어 엔진에 내던지는(Throw) 기법을 다룬다.

2.0.1 [Runbook] 데이터 소유권 양도(Ownership Transfer) 전술

C++11 이후의 std::move 와 Zenoh의 Bytes 래퍼가 융합된 극한의 송신법.

1. std::vector 메모리 다이렉트 이양

#include "zenoh.hxx"
#include <vector>

void send_massive_data(zenoh::Publisher& pub) {
    // 100MB 힙 메모리 할당 (비즈니스 로직에 의해 센서값으로 채워짐)
    std::vector<uint8_t> lidar_data(100 * 1024 * 1024, 255); 
    
    // [경고] pub.put(lidar_data); 라고 치면 100MB memcpy()가 발생하며 CPU가 울부짖는다!
    
    // [해결책] std::move 를 사용하여 vector 내부의 동적 배열 포인터 자체를 Zenoh에게 넘긴다.
    // Zenoh 내부 코어는 이 포인터를 그대로 잡고 OS 소켓 write() 에 밀어버린다. (복사 제로)
    pub.put(std::move(lidar_data));
    
    // 이 줄에 도착하면 lidar_data 는 껍데기만 남고 비워진다. (Size: 0)
}

2. 커스텀 메모리 포인터 콜백 제어 (zenoh::ext::Bytes)
만약 메모리가 std::vector가 아니라, CUDA 가속기 코어나 커스텀 하드웨어가 할당한 원시 포인터(int* 또는 extern malloc)라면? C++ 전용 델리게이트 랩핑이 필요하다.

void* raw_cuda_memory = cuda_malloc_magic(100 * 1024 * 1024);

// Zenoh가 전송을 완료하고 나면 이 메모리를 대체 누가 해제해 주나? 
// 우리가 만든 Custom Deleter 람다를 버퍼와 같이 끼워 보낸다.
auto bytes = zenoh::Bytes::create(
    raw_cuda_memory, 
    100 * 1024 * 1024, 
    [](void*%20ptr) {
        // [중요] 백그라운드 스레드에서 커널 송신이 끝난 순간 이 함수가 불린다!
        cuda_free_magic(ptr); // 직접 만든 커스텀 해제 함수 연동
    }
);

publisher.put(std::move(bytes)); // 카피 없이 전송 개시!

메인 앱 단에서 데이터를 쏘고 메모리 소멸 책임을 잊는 것(Fire-and-Forget). 이것이 진정한 비동기 제로 카피 파이프라인의 완성형이다.

3. 공유 메모리(Shared Memory) 확장(SHM 플러그인) 활성화 및 활용

하나의 리눅스 보드(Jetson, 라즈베리 파이) 내에서 2개의 개별 C++ 프로세스가 움직인다고 가정하자.
카메라 AI 프로세스가 4K 영상을 라우터 앱으로 쏠 때, 위에서 배운 std::move 제로 카피를 써도 어쨌거나 데이터는 “유저 스페이스 -> 커널 OS 레이어 -> 루프백 TCP 소켓 -> 유저 스페이스” 로 이동하며 무지막지한 커널 복사(Syscall 1차, 2차)를 발생시킨다.

이것을 수학적 ‘0’ 복사로 만드는 것이 바로 리눅스 /dev/shm 에 똬리를 트는 Zenoh SHM(공유 메모리) 튜닝이다.

3.0.1 [Runbook] VRAM 및 IPC 극한 효율 튜닝 전술

Zenoh C++ CMake 빌드 당시에 SHM 확장이 무조건 활성화되어 있어야 구동된다.

1. 공유 메모리 티켓 발행 (송신부 앱)
미친 듯이 메모리를 파서 넘기는 게 아니다. 미리 거대한 공터(Shared Memory)를 잡아두고, 포인터 번지만 문자 메시지 돌리듯 전송해버리는 마법이다.

#include "zenoh/ext/shm.hxx"

// 1. 세션에 빌붙어 있는 공유 메모리 개척자(Provider)를 켠다.
auto shm_provider = zenoh::ext::ShmProvider::create(session).value();

// 2. 10MB짜리 텅 빈 공유 메모리 블록을 사전 할당(alloc) 받는다.
auto shm_buffer = shm_provider.alloc(10 * 1024 * 1024).value();

// 3. 센서는 이 공간에 직접 값을 쓴다! (일반 메모리처럼 보이지만 사실 /dev/shm 구역이다)
fill_4k_camera_data(shm_buffer.data());

// 4. [충격적인 비밀] 10MB가 아니라 공유메모리 ID(8 Byte) "참조 티켓"만 넘어간다!
publisher.put(std::move(shm_buffer));

2. 환희의 티켓 회수 (수신부 앱 검수)

auto sub = session.declare_subscriber("camera/feed", [](const%20zenoh::Sample&%20sample) {
    auto payload = sample.get_payload();

    // 이 데이터가 로컬 공유 메모리에서 날아온 참조 티켓인지 판별한다.
    if (payload.is_shm()) {
        // [경이로움] 이 순간, 수신 앱은 0.0001ms 만에 다른 프로세스의 10MB VRAM 주소 번지에 포인터 연동(mmap)을 마쳤다!
        const uint8_t* zero_copy_view = payload.data();
        process_video(zero_copy_view);
    }
});

멀티 프로세싱 자율주행 아키텍처에서 노드 간의 IPC 통신 방식을 ROS2의 고질적인 퍼포먼스 폭락(FastRTPS 커스텀 튜닝 지옥)에서 구출해 내는 백색 기사이자, 엔드-투-엔드 1ms 미만의 레이턴시를 담보하는 궁극기다.

4. C++ 스마트 포인터(std::shared_ptr, std::unique_ptr)와의 안전한 통합

C++11이 구상했던 “메모리 안전성“의 핵심인 std::shared_ptr 와 std::unique_ptr를, 외부 C 코어 엔진인 Zenoh와 어떻게 아귀를 맞출 것인가?

모던 C++로 만들어진 내부 엔진들은 보통 구조체 포인터를 shared_ptr 로 들고 서로 공유하고 빙빙 돌린다. 이걸 복사본 없이 곧바로 Zenoh 파이프에 밀어 넣고 싶다면 영리한 트릭이 필요하다.

4.0.1 [Runbook] 참조 카운트 유지 및 안전 우회(Bypass) 로직

목표는 레퍼런스 카운트 1을 추가하여 Zenoh가 다 쏠 때까지 메모리를 유지하는 것이다.

전술 1. std::shared_ptr 전송 브릿지

#include <memory>
#include <vector>
#include "zenoh.hxx"

// 어딘가에서 날아온 모던 C++ 스타일의 데이터 덩어리
using MyPayloadParams = std::shared_ptr<std::vector<uint8_t>>;

void zenoh_smart_tx(zenoh::Publisher& pub, MyPayloadParams sp_data) {
    
    // Zenoh가 쓸 수 있도록 포인터와 길이를 추출
    void* raw_ptr = sp_data->data();
    size_t length = sp_data->size();

    // 1. shared_ptr의 복사본을 만들어 생성 주기에 명시적 강제 복제(+1)를 일으킨다.
    // 이는 이 람다가 살아있는 한, 바깥쪽 원본이 죽어도 메모리가 파괴되지 않게(dangling 방지) 하는 방패다.
    auto bytes = zenoh::Bytes::create(raw_ptr, length, [sp = sp_data](void*) {
        // [소멸 람다] Zenoh의 TCP 전송 송출이 완료되고 나서 이 람다가 소멸 될 때, 
        // 캡처된 sp 도 같이 파괴되면서 reference count 가 -1 이 된다!
        // (만약 이게 마지막 카운트였다면 백그라운드 스레드에서 메모리가 우아하게 해제됨)
    });

    // 2. 복사 0 (Zero-copy) 상태로 락(Lock) 없이 전송!
    pub.put(std::move(bytes)); 
}

이 패턴은 1,000Hz 주파수를 가진 병목 스레드에서 new/delete를 사실상 회피하고, 다른 백엔드 로직들과 소유권을 기가 막히게 분배하는 고급 설계 패턴이다. 주의: 백그라운드 I/O 스레드(Zenoh core)에서 객체가 최종 소멸(Destruct)될 수 있으므로, 당신의 커스텀 C++ 객체 소멸자에 스레드 경합(Mutex 등)을 발생시키는 코드가 있다면 치명적인 크래시를 맛보게 될 것이다.

5. 동적 할당 최소화를 위한 커스텀 얼로케이터(Custom Allocator) 적용

대규모 분산 컴퓨팅(HPC) 클러스터나 HFT(초단타 트레이딩) 거래소에서 당신의 시스템이 malloc 이나 std::vector::emplace_back 을 무지성으로 호출한다면, 당신의 코드는 영원히 C++ 시니어 라인에 설 수 없다.
힙(Heap) 생성 수술은 커널(OS)의 컨텍스트 스위칭과 자물쇠(Lock)를 건드리기 때문에, 고성능 파이프라인에서는 오브젝트 풀(Object Pool) 또는 미리 할당된 링 버퍼(Ring Buffer)를 활용해야만 한다.

5.0.1 [Runbook] Zenoh 수신 단의 메모리 풀(Memory Pool) 흡수 전략

1초에 5만 번씩 튀어나오는(Trigger) Subscriber 콜백 안에서 로컬 버퍼를 찍어내지 마라.
전역에 배치된 거대한 메모리 풀 탱크(Pool Tank)를 끌어와 수신하는 파이프라인.

#include <mutex>
#include <vector>
#include "zenoh.hxx"

// --- [초간단 메모리 풀 캐싱] ---
class GlobalBufferPool {
public:
    std::vector<uint8_t> acquire() {
        std::lock_guard<std::mutex> lock(mtx);
        if(!pool.empty()) {
            auto b = std::move(pool.back());
            pool.pop_back();
            return b;
        }
        // 풀이 마르면 그제서야 울며 겨자 먹기로 10MB짜리 힙 할당
        std::vector<uint8_t> new_buf;
        new_buf.reserve(10 * 1024 * 1024);
        return new_buf;
    }
    void release(std::vector<uint8_t>&& buf) {
        buf.clear(); // capacity 는 그대로 유지한 채 size 만 0으로.
        std::lock_guard<std::mutex> lock(mtx);
        pool.push_back(std::move(buf));
    }
private:
    std::vector<std::vector<uint8_t>> pool;
    std::mutex mtx;
};

GlobalBufferPool g_buffer_bank;

void bind_subscriber(zenoh::Session& session) {
    auto sub = session.declare_subscriber("drone/vision/1080p", [](const%20zenoh::Sample&%20sample) {
        
        // 1. 메모리 생성(new/malloc)을 절대 하지 않고 풀에서 빈 탱크를 하나 가져온다.
        auto my_buffer = g_buffer_bank.acquire();
        
        // 2. Zenoh 가 조각내서 배달한 네트워크 파편(Chunk)을 나의 10MB 탱크에 조립해 넣는다.
        for(const auto& chunk : sample.get_payload()) {
            my_buffer.insert(my_buffer.end(), chunk.begin(), chunk.end());
        }
        
        // 3. 머신 러닝 추론(Inference) 로직 등 실행 무명 블록
        run_cuda_inference(my_buffer.data(), my_buffer.size());
        
        // 4. [중요] 사용이 완료된 탱크는 버리지 말고 다시 메모리 풀에 반납한다!
        g_buffer_bank.release(std::move(my_buffer));
    });
}

이 커스텀 링 풀(Pool) 패턴은 메모리 시스템의 조각화(Fragmentation)를 막으며, 며칠씩 돌아가는 산업용 시스템(Uptime 99.99%)의 필수 조건이다. Zenoh는 당신이 조각파편을 자유롭게 조립하도록 get_payload() 이터레이터 뷰를 허락함으로써 이 기예(Art)를 완벽하게 뒷받침한다.