Evolusi Worker I/O di WebAssembly: Dari WASI 0.2 ke WASI 0.3

Sebelum WASI 0.3, eksekusi WebAssembly di luar browser bergantung pada interface synchronous (WASI 0.1/WASI-preview1) atau model async terbatas berbasis polling manual seperti wasi:io/poll.poll di WASI 0.2. Pendekatan ini memaksa runtime host mengalokasikan OS thread dedicated per instance worker atau mengeksekusi blocking syscall di level guest. Pola ini memicu memory footprint berlebih dan context-switching overhead saat ribuan worker menunggu job masuk dari message queue.

WASI 0.3 memperkenalkan native async primitives langsung ke dalam WebAssembly Component Model via canonical ABI extension (future, stream, dan subskripsi non-blocking). Guest code tidak lagi memerlukan loop polling aktif yang membebani CPU. Runtime guest dapat langsung mengembalikan kontrol (yield) ke host executor saat menunggu paket data jaringan atau I/O antrean selesai.

Arsitektur Non-Blocking Async Worker dan Backpressure

Saat mengonsumsi antrean berskala tinggi, worker harus mampu mengendalikan laju konsumsi pesan (backpressure) agar tidak mengalami resource exhaustion. Worker non-blocking di WASI 0.3 mengintegrasikan asynchronous stream dari network socket host langsung ke event loop guest.

Berikut contoh implementasi worker antrean non-blocking menggunakan Rust targeting WASI 0.3 component model:

use std::sync::atomic::{AtomicUsize, Ordering};
use std::sync::Arc;
use tokio::sync::Semaphore;

// Abstraksi representasi WASI 0.3 native async stream
pub struct QueueMessage {
    pub id: String,
    pub payload: Vec<u8>,
}

pub struct AsyncQueueConsumer {
    max_concurrency: usize,
    in_flight: Arc<Semaphore>,
}

impl AsyncQueueConsumer {
    pub fn new(max_concurrency: usize) -> Self {
        Self {
            max_concurrency,
            in_flight: Arc::new(Semaphore::new(max_concurrency)),
        }
    }

    pub async fn run_loop(&self) {
        loop {
            // Backpressure: Tunggu permit tersedia sebelum membaca pesan berikutnya
            let permit = self.in_flight.clone().acquire_owned().await.unwrap();

            // Native non-blocking poll socket I/O via WASI 0.3 async ABI
            match self.fetch_next_job().await {
                Ok(Some(msg)) => {
                    tokio::spawn(async move {
                        let _permit = permit; // Dipertahankan hingga task selesai
                        if let Err(e) = process_job(&msg).await {
                            eprintln!("Gagal memproses pesan {}: {:?}", msg.id, e);
                        }
                    });
                }
                Ok(None) => {
                    // Queue kosong, yield eksekusi sementara
                    drop(permit);
                    tokio::task::yield_now().await;
                }
                Err(e) => {
                    drop(permit);
                    eprintln!("I/O error dari queue socket: {:?}", e);
                    break;
                }
            }
        }
    }

    async fn fetch_next_job(&self) -> Result<Option<QueueMessage>, std::io::Error> {
        // Implementasi interaksi native async WASI stream
        // Tidak memblokir OS thread guest
        Ok(Some(QueueMessage {
            id: "job-102948".into(),
            payload: b"{\"task\":\"process_invoice\"}".to_vec(),
        }))
    }
}

async fn process_job(msg: &QueueMessage) -> Result<(), Box<dyn std::error::Error>> {
    // Simulasi eksekusi I/O intensif tanpa memblokir thread
    tokio::time::sleep(std::time::Duration::from_millis(50)).await;
    println!("Sukses memproses ID: {}", msg.id);
    Ok(())
}

Efisiensi Footprint Memori: WASM vs Container Linux Tradisional

Pada arsitektur microservices berbasis Linux container (Docker/OCI), setiap container menjalankan runtime Linux minimal, dynamic linker, glibc, dan process supervisor tersendiri. Ini menghasilkan overhead statis yang besar meskipun container berada dalam status idle.

  • Linux Container (Alpine/Distroless): Membutuhkan alokasi memori baseline antara 15MB hingga 50MB per instance sebelum kode aplikasi dijalankan. Context switching antar containered worker dikelola oleh OS kernel scheduler, yang menurunkan throughput saat konkurensi mencapai ribuan instansi.
  • WASI 0.3 Worker Component: Modul WASM yang terkompilasi berjalan dalam isolasi memory linear runtime host (seperti Wasmtime). Modul ini hanya mengonsumsi 50KB hingga 500KB per instance. Runtime host menangani polling I/O secara terpusat (epoll/kqueue/io_uring) tanpa menduplikasi kernel metadata antar instance.

Verifikasi Idempotensi Saat Koneksi Antrean Drop

Salah satu skenario kegagalan kritis pada async worker terdistribusi adalah hilangnya koneksi TCP antara worker dan broker antrean (Redis, RabbitMQ, atau SQS) saat worker sedang mengeksekusi payload. Hal ini berpotensi memicu duplicate delivery ketika broker menganggap lease/visibility timeout berakhir.

Untuk menjamin pemrosesan at-least-once tanpa menghasilkan state corruption, worker wajib mengimplementasikan idempotent lock key dengan state store persisten sebelum dan sesudah mengeksekusi payload:

use std::collections::HashSet;
use std::sync::Mutex;

pub struct IdempotencyStore {
    processed_keys: Mutex<HashSet<String>>,
}

impl IdempotencyStore {
    pub fn try_lock(&self, job_id: &str) -> bool {
        let mut set = self.processed_keys.lock().unwrap();
        if set.contains(job_id) {
            false
        } else {
            set.insert(job_id.to_string());
            true
        }
    }

    pub fn commit(&self, _job_id: &str) {
        // Simpan status final ke KV store persisten
    }

    pub fn rollback(&self, job_id: &str) {
        let mut set = self.processed_keys.lock().unwrap();
        set.remove(job_id);
    }
}

Catatan: Jika koneksi terputus tepat setelah eksekusi payload tetapi sebelum ACK dikirim ke broker, job akan dikirimkan kembali ke worker lain. Pengecekan status pada store terdistribusi wajib dilakukan sebelum mutasi state eksternal dijalankan kembali.