Belajar Firecracker - Testing & Performance Benchmark

#Pendahuluan

Firecracker diklaim boot ~125 ms dan overhead < 5 MiB. Klaim seperti itu harus diuji — di host kalian, dengan workload kalian. Episode 16 mengubah kalian dari pengguna Firecracker menjadi insinyur yang mengukur Firecracker: metodologi benchmark yang benar, angka yang harus diukur, dan cara validasi ketahanan platform di bawah tekanan.

Mengapa episode ini penting? Semua keputusan produksi — berapa banyak microVM per host, kapan memakai snapshot, berapa besar overhead — harus berbasis angka, bukan intuisi. Episode ini memberi kerangka untuk mendapat angka-angka itu dengan cara yang bisa dipertanggungjawabkan.

#Mengukur Waktu Boot: Cold vs Snapshot

Waktu boot adalah metrik paling ikonik. Yang perlu dibedakan dengan jelas:

• Cold boot: dari nol — proses Firecracker start, kernel dimuat, init jalan, aplikasi siap.
• Snapshot restore: dari snapshot yang sudah diinisialisasi — proses baru, load state, resume.

Metode mengukur yang praktis — pakai timestamp di dalam guest dan bandingkan dengan waktu host:

# Di guest: catat waktu kernel dimuat (dari dmesg) dan saat aplikasi siap
cat /proc/uptime

Untuk pengukuran yang presisi dari sisi host, ukur selisih antara InstanceStart dan saat output guest "ready":

time curl --unix-socket /tmp/firecracker.sock -X PUT http://localhost/actions \
  -d '{ "action_type": "InstanceStart" }'

Interpretasi yang benar:

• Cold boot diharapkan di kisaran 100-300 ms untuk image ringan — angka di atas 1 detik menandakan image terlalu gemuk atau kernel terlalu banyak bekerja.
• Restore snapshot diharapkan jauh di bawah cold boot — puluhan milidetik untuk VM kecil — inilah yang membuat cold start serverless terasa instan.

Perhatikan variabilitas: ukur 10+ kali, ambil median dan p95, bukan sekali jalan. Waktu boot dipengaruhi beban host, NUMA, dan page cache.

#Overhead Memori

Overhead Firecracker (< 5 MiB per VM di atas memori guest) bisa diukur dengan cgroup atau /proc:

ps -o pid,rss,comm -C firecracker

Baca dengan benar:

• RSS adalah memori yang dipakai proses VMM — di atas memori yang dialokasikan untuk guest (mem_size_mib).
• Guest memori terpisah: mem_size_mib + overhead = total footprint VM.

Untuk pengukuran menyeluruh, jumlahkan juga page cache dari rootfs yang di-share — inilah alasan rootfs read-only bisa membuat 10 VM dengan image sama memakai page cache yang sama. Pengukuran yang jujur: ukur host sebelum dan sesudah menambah N VM, bagi selisihnya dengan N — bukan sekadar menjumlahkan RSS.

#IOPS dan Bandwidth

Storage dan network perlu angka throughput. Dua alat standar:

fio --name=test --rw=randread --size=64m --bs=4k \
  --direct=1 --numjobs=4 --runtime=30 --group_reporting

iperf3 -s  # di satu guest
iperf3 -c <ip-guest-lain>  # di guest lain

Interpretasi: IOPS storage dan bandwidth network diukur setelah rate limiter dan cgroup aktif — itulah angka yang relevan untuk produksi. Bandingkan juga angka tanpa rate limiter untuk memahami margin yang tersedia. Ukur beberapa arah (rx/tx) dan beberapa ukuran blok; satu angka tidak menceritakan keseluruhan cerita.

#Load Test: Ribuan MicroVM per Host

Keputusan arsitektur terbesar — berapa microVM per host — harus diverifikasi dengan load test nyata. Metodologi yang sehat:

1. Scale bertahap: mulai 50 VM, naik ke 500, lalu target (ratusan sampai ribuan sesuai kapasitas host).
2. Pantau metrik host selama naik: CPU, memori, page cache, load average, dan waktu boot.
3. Tentukan titik jenuh: ketika waktu boot memburuk signifikan atau host mulai thrash — itu kapasitas realistis kalian.

Script sederhana untuk scale test memakai jailer + API:

for i in $(seq 1 200); do
  jailer --id "vm-$i" --exec-file /usr/local/bin/firecracker \
    --uid 123 --gid 100 --chroot-base-dir /srv/jailer &
done

Amati kurva boot time terhadap jumlah VM. Densitas yang sehat menjaga boot tetap stabil; densitas yang terlalu tinggi membuat boot melambat eksponensial. Data ini yang menentukan angka kapasitas di episode 19.

#Failure Injection: Menguji Ketahanan

Platform yang sehat tidak terlihat saat normal — ia terlihat saat gagal. Failure injection mensimulasikan kegagalan untuk memvalidasi bahwa sistem pulih:

• Kill paksa proses Firecracker — apakah orchestrator mendeteksi, me-restart, dan membersihkan resource (TAP, chroot)?
• Matikan satu host — apakah workload dipindahkan dari snapshot yang tersimpan?
• Kosongkan disk snapshot — apakah pipeline snapshot gagal dengan error yang jelas?
• Perlambat I/O (misal dengan tc netem atau throttling) — apakah timeout handling berfungsi?

kill -9 <firecracker-pid>

Amati: apakah socket dibersihkan? Apakah TAP dibebaskan? Apakah cgroup kosong? Sistem yang baik meninggalkan sedikit sampah; sistem yang buruk mengakumulasi sumber daya bocor hingga host kehabisan.

#Testing: Unit, Integrasi, dan E2E

Untuk platform kalian sendiri di atas Firecracker, tiga tingkat pengujian:

• Unit test — logika internal (konfigurasi, pemetaan image).
• Integrasi test — Firecracker + jailer + networking bersama-sama; boot VM dan jalankan assertion di dalamnya.
• E2E — alur pengguna penuh: build image → create VM → boot → jalankan workload → snapshot → restore → cleanup.

Pola penting untuk test yang stabil: selalu bersihkan resource di akhir test (hapus chroot, TAP, cgroup), dan jangan menjalankan test paralel yang berbagi socket atau port yang sama. Test Firecracker yang baik bisa diulang ribuan kali tanpa degradasi host.

#Common Pitfalls

• Ukur sekali: waktu boot itu noisy; ukur berkali-kali dan ambil distribusi.
• Benchmark tanpa rate limiter/cgroup: angka yang tidak mewakili produksi.
• Mengabaikan page cache: RSS saja tidak cukup; ukur total footprint dengan selisih host.
• Load test mengubah banyak variabel: hasilnya tidak bisa diinterpretasi.
• Tidak membersihkan resource saat test: host kehabisan TAP/socket setelah ribuan iterasi.
• Failure test yang hanya menguji satu skenario: uji kill, crash, dan error disk sekaligus.

#Penutup

Inti yang harus dibawa pulang:

• Cold boot ~100-300 ms; restore snapshot jauh lebih cepat — ukur keduanya terpisah.
• Overhead < 5 MiB per VM di atas memori guest; ukur dengan selisih total, bukan RSS saja.
• IOPS dan bandwidth diukur setelah rate limiter dan cgroup aktif.
• Load test bertahap menentukan densitas nyata per host.
• Failure injection memvalidasi bahwa sistem pulih — bukan hanya berjalan saat normal.
• Testing berlapis: unit, integrasi, E2E, dengan pembersihan resource yang disiplin.

Di episode 17 selanjutnya kita akan melihat fitur terbaru: Firecracker 1.16 & Fitur Terbaru — perbaikan CVE-2026-5747 di v1.16.1, dukungan VMClock device, pengujian di Intel Granite Rapids, peningkatan snapshot, device passthrough VFIO eksperimental, dan arah integrasi rust-vmm.