Arsitektur Integrasi Rust FFI: Out-of-Process vs Shared Memory

Mengintegrasikan pustaka native Rust atau C ke backend berkinerja tinggi (seperti Go, Java, atau Node.js) memberikan efisiensi eksekusi tingkat rendah. Pendekatan integrasi menentukan stabilitas sistem secara menyeluruh. Bug memori pada level native seperti dereferensi null pointer atau out-of-bounds access menghasilkan sinyal SIGSEGV yang langsung menghentikan seluruh proses host.

Spektrum Arsitektur Integrasi Native

Terdapat tiga paradigma utama dalam menjembatani runtime aplikasi backend dengan native library Rust:

• In-Process FFI: Memanggil fungsi C ABI secara langsung melalui mekanisme FFI (Foreign Function Interface) host runtime (misalnya Go Cgo, Java JNI, Node.js N-API).
• Out-of-Process IPC: Menjalankan binary Rust sebagai daemon independen (sidecar atau worker terpisah) yang berkomunikasi via UNIX Domain Socket (UDS), named pipe, atau RPC.
• Shared Memory IPC: Menjalankan binary Rust di luar proses host, tetapi pertukaran payload data berukuran besar melewati segmentasi memori bersama (POSIX shm atau memory-mapped files) untuk menghindari overhead salin data (zero-copy).

1. In-Process FFI: Throughput Tertinggi, Risiko Terbesar

In-process FFI mengeksekusi instruksi Rust langsung di address space proses yang sama. Panggilan fungsi memiliki latensi sub-mikrodetik tanpa context switch antarproses OS.

Kelemahan dan Blast Radius

Segala bentuk memory corruption pada native binary membawa dampak fatal bagi host runtime:

• Fatal Crash: Runtime managed memory tidak dapat menangani SIGSEGV native secara andal. Panik di Rust yang melintasi boundary ABI C menyebabkan undefined behavior (UB).
• Scheduler Friction: Runtime dengan green threads atau goroutine (seperti Go runtime) mengalami overhead pergantian stack thread OS saat memanggil Cgo, yang dapat memblokir thread pool runtime jika eksekusi Rust berjalan terlalu lama.

// Rust: cdylib library exposing C-ABI
#[no_mangle]
pub extern "C" fn process_data(input: *const u8, len: usize) -> i32 {
    if input.is_null() {
        return -1; // Hindari panic melintasi FFI boundary
    }
    let data = unsafe { std::slice::from_raw_parts(input, len) };
    // Mutlak tangkap panic agar tidak unwind ke host
    std::panic::catch_unwind(|| {
        compute_checksum(data)
    }).unwrap_or(-2)
}

fn compute_checksum(data: &[u8]) -> i32 {
    data.iter().fold(0i32, |acc, &x| acc.wrapping_add(x as i32))
}

2. Out-of-Process IPC: Isolasi Total

Memindahkan Rust binary ke proses terpisah (daemon worker) membatasi blast radius. Apabila proses native mengalami crash, kernel OS mengisolasi terminasi hanya pada worker tersebut. Host backend tetap berjalan, menangani error status, dan dapat menginisialisasi ulang worker instance secara otomatis.

Metode komunikasi paling efisien pada satu mesin (single-host) adalah standard stream atau UNIX Domain Sockets (UDS):

• Keunggulan: Isolasi resource ketat (dapat dibatasi via cgroups), zero risk of host termination, kemudahan deployment dan testing independen.
• Kelemahan: Peningkatan latensi (~10-50 mikrodetik) dan saturasi CPU akibat serialization/deserialization serta multiple memory copying (User space → Kernel buffer → User space).

3. Shared Memory: Kompromi Optimal Zero-Copy

Arsitektur Shared Memory (shm) mengkombinasikan isolasi out-of-process dengan throughput read/write mendekati in-process FFI. Host dan worker native memetakan region memori virtual yang sama menggunakan shm_open dan mmap.

Mekanisme Sinyal Kontrol

Shared memory murni hanya berupa alokasi byte mentah. Diperlukan jalur sinkronisasi terpisah untuk memberi tahu adanya payload baru:

• UDS/Eventfd Signaling: Payload data besar disalin ke buffer memori bersama, sedangkan ringkasan kontrol (offset dan length) dikirim via UNIX domain socket atau eventfd berlatensi rendah.
• Lockless Ring Buffer: Memanfaatkan atomic pointer di dalam shared memory untuk struktur data circular buffer, mengeliminasi kebutuhan system call sinkronisasi kernel.

// Rust: Worker membaca dari shared memory descriptor via memmap2
use memmap2::MmapMut;
use std::fs::File;

pub fn attach_shared_buffer(file: File) -> Result<MmapMut, std::io::Error> {
    // Memetakan file descriptor shm langsung ke memory space worker
    let mmap = unsafe { MmapMut::map_mut(&file)? };
    Ok(mmap)
}

pub fn read_packet(shm: &MmapMut, offset: usize, len: usize) -> &[u8] {
    &shm[offset..offset + len]
}

Perbandingan Arsitektur

Panduan Pengambilan Keputusan

Pilih pendekatan berdasarkan prioritas sistem:

1. Gunakan In-Process FFI jika beban kerja menuntut jutaan pemanggilan per detik dengan payload kecil (misalnya komputasi matematika murni atau hashing string pendek) dan pustaka native terbukti stabil tanpa resiko panic tak terkelola.
2. Gunakan Out-of-Process (UDS/gRPC lokal) jika stabilitas ketersediaan backend adalah prioritas mutlak, payload relatif kecil (< 64 KB), dan throughput masih dalam batas kapasitas throughput socket lokal.
3. Gunakan Shared Memory Buffer untuk pemrosesan streaming data masif (seperti frame video, pemrosesan citra, atau transfer audio mentah berukuran megabyte) yang membutuhkan isolasi proses tanpa degradasi alokasi CPU akibat duplikasi data memori.