Belajar Firecracker - Konsep Dasar & Arsitektur Utama

#Pendahuluan

Di episode 1 kita memahami mengapa Firecracker ada: isolasi hardware untuk serverless dengan boot kilat dan overhead minimal. Sekarang saatnya membuka kap mesin dan melihat bagaimana desain itu diwujudkan. Episode 2 membedah konsep dasar dan arsitektur utama Firecracker — model proses, perbandingan dengan QEMU, perangkat virtio, rate limiter, jailer, dan API.

Mengapa episode ini penting? Karena seluruh series ini — networking, storage, snapshot, scaling, hingga observability — adalah konsekuensi dari keputusan arsitektur yang dibahas di sini. Satu proses untuk satu microVM menjelaskan kenapa densitas ribuan VM per host mungkin; keluarga virtio device menjelaskan kenapa device hanya bisa ditambahkan sebelum boot; rate limiter menjelaskan bagaimana satu host bisa melayani banyak penyewa tanpa saling berebut bandwidth.

#Satu Proses, Satu MicroVM

Model mental paling penting tentang Firecracker adalah: satu proses Firecracker = satu microVM. Tidak ada daemon pusat yang mengelola banyak VM. Setiap firecracker yang berjalan adalah VM yang independen, dengan memori, API socket, dan siklus hidupnya sendiri.

Analoginya, anggap container Docker: satu daemon mengelola banyak container. Firecracker justru sebaliknya — seperti menjalankan satu proses nginx untuk satu situs. Konsekuensinya:

• Isolasi di level OS: jika satu VM di-tembus, penyerang hanya mendapat proses Firecracker tersebut — bukan daemon yang menguasai ratusan VM lain.
• Kill dan recovery sederhana: matikan proses, matikan VM. Tidak ada state global yang bisa korup.
• Densitas tinggi: karena setiap VM adalah proses ringan (< 5 MiB overhead), satu host bisa menampung ribuan proses — dan kernel host yang mengatur scheduling-nya.

Firecracker memang mendukung menjalankan lebih dari satu microVM per proses dalam konfigurasi tertentu (misalnya dengan vmgenid atau multiple API), tapi model kanonik dan praktik produksi AWS adalah satu proses per VM, diperkuat oleh jailer di episode 7.

#VMM Rust vs QEMU

Pendekatan Firecracker berbeda fundamental dari QEMU:

• QEMU: VMM serba bisa — emulasi penuh berbagai arsitektur, banyak device, hotplug, GUI, dan kawan-kawan. Kaya fitur, tapi besar dan lambat, dengan attack surface luas.
• Firecracker: VMM sempit — hanya KVM, hanya device virtio yang dikurasi, tanpa emulasi device eksotik. Lebih sedikit kode, lebih cepat, lebih aman.

Satu detail arsitektural penting: Firecracker tidak melakukan device emulation di userspace untuk perangkat utama. Ia memanfaatkan KVM dan virtio sedemikian rupa sehingga lalu lintas data perangkat mengalir langsung antara guest dan host tanpa interpretasi CPU yang mahal. Inilah alasan kenapa overhead-nya bisa ditekan jauh di bawah QEMU.

Proses Firecracker memuat beberapa thread: thread VMM utama, thread API, thread vCPU (satu per vCPU), dan thread untuk setiap device. Threading ini menjaga isolasi — kesalahan di thread device tidak langsung menjatuhkan seluruh VM.

#Keluarga Device Virtio

Semua perangkat I/O microVM Firecracker menggunakan spesifikasi virtio: standar device paravirtualisasi yang dikenali kernel guest melalui driver bawaan. Karena driver sudah ada di kernel, guest tidak butuh driver tambahan dari vendor. Keluarga device yang didukung Firecracker:

• virtio-net — interface jaringan. Perangkat paling umum: menghubungkan microVM ke TAP interface host.
• virtio-block — disk block. Menempelkan rootfs dan disk tambahan sebagai file image di host.
• virtio-vsock — socket host↔guest tanpa networking IP. Ideal untuk komunikasi control-plane dan agent di dalam guest.
• virtio-balloon — menarik kembali memori dari guest ke host (episode 10).
• virtio-rng — entropy untuk guest, sumber keacakan untuk kriptografi.
• virtio-vmem (dalam 1.16) dan perangkat lain — menunjang fitur-fitur terbaru.

Perangkat hanya bisa ditambahkan sebelum VM di-start. Setelah InstanceStart, konfigurasi device terkunci — konsekuensi dari desain boot sekali, lalu tidak berubah. Perubahan berarti membuat VM baru atau memakai snapshot (episode 9).

#Rate Limiter Token Bucket

Setiap device virtio-net dan virtio-block bisa dibungkus rate limiter berbasis token bucket. Konsepnya sederhana: sebuah bucket berisi token; setiap paket atau byte yang lewat mengonsumsi token; bucket diisi ulang dengan kecepatan tertentu. Dua dimensi yang bisa dibatasi: bandwidth (bytes/sec) dan ops (ops/sec), masing-masing dengan parameter size (kapasitas bucket), refill_time (interval isi ulang), dan one_time_burst (lonjakan awal).

Ini bukan fitur sekunder — ini jantung model multi-tenant. Tanpa rate limiter, satu microVM bisa memonopoli bandwidth host dan merusak pengalaman semua tetangganya. Dengan rate limiter, SLA bandwidth per VM bisa dijanjikan secara kontraktual, persis seperti yang dilakukan AWS untuk layanan berbasis Firecracker. Detail konfigurasinya kita praktikkan di episode 5.

#Komponen Utama: firecracker, jailer, dan API

Arsitektur Firecracker terpusat pada beberapa komponen kunci:

• firecracker binary — VMM itu sendiri. Membaca konfigurasi, mengekspos API, menjalankan vCPU, dan mengelola device.
• jailer — pembungkus keamanan. Membungkus proses Firecracker dalam namespace, cgroup, seccomp, rootfs read-only, dan user non-root. Detail di episode 7.
• API endpoint — seluruh interaksi dengan microVM terjadi lewat API HTTP di Unix socket: PUT /boot-source, PUT /machine-config, PUT /drives, PUT /network-interfaces, PUT /snapshot/create, dan InstanceStart via /actions.

API adalah satu-satunya cara mengelola microVM — tidak ada perintah firecracker start. Orchestrator seperti firecracker-containerd atau Flintlock pada dasarnya adalah client API yang cerdas.

#MMDS: Metadata Service

MicroVM sering butuh konfigurasi dinamis: alamat IP sendiri, kredensial, atau metadata workload. Untuk ini Firecracker menyediakan MMDS (MicroVM Metadata Service) — server metadata yang diekspos ke guest di alamat 169.254.169.254, mirip dengan metadata service EC2.

Host menulis data JSON ke MMDS lewat PUT /mmds, lalu guest membacanya lewat HTTP GET di alamat tersebut. Karena IP-nya reserved link-local, data ini tidak pernah keluar ke jaringan luar — cocok untuk mendistribusikan secret atau konfigurasi boot tanpa mengan: data sudah tersedia sebelum aplikasi di guest dijalankan. Kita akan memakai MMDS di episode 6.

#Siklus Hidup MicroVM

Sebuah microVM melewati siklus yang jelas:

1. Configure — proses Firecracker dijalankan (biasanya lewat jailer), API socket dibuat, lalu konfigurasi dikirim: kernel, machine config, drives, network.
2. Start — InstanceStart memuat kernel dan mulai mengeksekusi; perangkat terkunci.
3. Run — guest berjalan; komunikasi lewat network, vsock, atau serial console.
4. Pause/snapshot/suspend — state bisa dibekukan dan disimpan (episode 9).
5. Stop — proses dihentikan; semua resource dilepas.

Setiap tahap memiliki API dan tooling sendiri. Memahami siklus ini membuat episode-episode berikutnya — yang sebagian besar adalah variasi dari tahap-tahap ini — jauh lebih mudah diikuti.

#Penutup

Inti yang harus dibawa pulang:

• Satu proses Firecracker = satu microVM; isolasi di level OS, densitas tinggi.
• Firecracker minimalis vs QEMU serba-bisa; device emulation dijauhkan dari jalur data.
• Device hanya bisa dikonfigurasi sebelum start; setelan terkunci setelah boot.
• Rate limiter token bucket (bandwidth + ops) adalah dasar isolasi multi-tenant.
• Komponen utama: firecracker, jailer, API Unix socket, dan MMDS.
• Siklus hidup VM: configure → start → run → pause/snapshot → stop.

Di episode 3 selanjutnya kita akan berhenti berteori dan mulai menyalakan mesin: setup dan instalasi — mengunduh binary v1.16.x, menyiapkan kernel dan rootfs, verifikasi KVM dan cgroup, menjalankan firecracker --api-sock, serta memahami perbedaan mode --no-api (fast boot lewat command line) melawan mode API. Bersiaplah untuk microVM pertama kalian!