Belajar Firecracker - Scaling: Banyak MicroVM per Host

#Pendahuluan

Di episode 18 kita melihat produk-produk yang berdiri di atas Firecracker — semuanya bermuara pada satu pertanyaan ekonomi: berapa banyak microVM yang bisa hidup dalam satu host? Episode 19 membahas scaling: teknik yang memungkinkan densitas ribuan microVM per host, dan disiplin operasional yang menjaganya tetap sehat.

Mengapa episode ini penting? Firecracker ada untuk membuat densitas tinggi itu mungkin — boot 125 ms dan overhead < 5 MiB hanya berarti jika ratusan bahkan ribuan VM bisa berbagi satu host. Di episode inilah angka-angka itu diterjemahkan menjadi kapasitas nyata, dengan trade-off yang jujur.

#Matematika Densitas

Sebuah host server modern (misal 192 vCPU, 512 GB RAM) bisa menampung berapa microVM? Mari hitung dengan data yang kita punya:

• MicroVM kecil (1 vCPU, 128 MiB): ~512 MiB overhead + memori guest per VM. Dengan overcommit yang sehat, host bisa menampung ratusan sampai ribuan VM seperti ini.
• MicroVM besar (16 vCPU, 32 GB — kelas Lambda MicroVMs): jauh lebih sedikit per host, tapi masih padat dibanding VM tradisional.

Faktor pembatasnya bukan sekadar RAM: ada vCPU, page cache, I/O, dan limit kernel (jumlah fd, thread, inotify). Densitas realistis ditentukan oleh load test (episode 16), bukan perhitungan kertas.

#Jailer per VM: Overhead yang Terbayar

Setiap microVM dijalankan lewat jailer dengan --id unik (episode 7). Overhead per jailer kecil — beberapa proses dan cgroup — tapi nilainya besar:

• Isolasi: kegagalan satu VM tidak menyentuh yang lain.
• Pembersihan: menghapus chroot <id> adalah cara bersih melepas semua resource.
• Audit: tiap VM punya jejak yang jelas di filesystem dan cgroup.

Pada skala ribuan, kebiasaan yang baik menjadi wajib: jangan pernah melewati jailer "karena cepat". Kode yang mengelola ribuan VM tanpa jailer adalah kecelakaan yang sedang menunggu.

#cgroup v2: Dasar Pembatasan Kolektif

Pada densitas tinggi, satu VM yang bocor bisa menghabiskan host. cgroup v2 memberi kontrol terstruktur:

mkdir -p /sys/fs/cgroup/fc/vm-001
echo 536870912 > /sys/fs/cgroup/fc/vm-001/memory.max
echo 500000 100000 > /sys/fs/cgroup/fc/vm-001/cpu.max
echo <pid> > /sys/fs/cgroup/fc/vm-001/cgroup.procs

Di cgroup v2, ada satu bonus yang penting untuk densitas: kontrol memori lebih presisi, termasuk pembatasan swap dan accounting page cache. Dengan batas per VM, satu VM yang rakus tidak menjatuhkan host — ia menabrak batasnya sendiri.

#Page Cache Sharing: Rootfs Read-only Menjadi Emas

Ini salah satu teknik densitas yang paling berdampak. Saat banyak VM memakai rootfs yang sama, kernel host menyimpan halaman file yang sama sekali di page cache — dan semua VM berbagi.

cat /proc/meminfo | grep -i cached

Agar sharing maksimal:

• Rootfs read-only (episode 6) — jika rootfs bisa berubah, page cache tidak bisa di-share dengan aman.
• Image yang sama per VM — semakin banyak VM memakai image identik, semakin tinggi rasio sharing.
• Overcommit page cache: halaman bersama tidak dihitung penuh per VM, sehingga total memori yang "dipakai" turun drastis.

Di sinilah keputusan image di episode 8 bertemu ekonomi host: image yang sama, read-only, dan ringan = lebih banyak VM per host.

#Memory Overcommit via Balloon

Balloon (episode 10) memberi dimensi lain: memori yang dijanjikan tidak selalu dipakai. Orchestrator yang cerdas memakai statistik balloon untuk overcommit:

1. VM dibuat dengan mem_size_mib lebih besar dari kebutuhan tipikal.
2. Balloon ditarik saat VM idle — memori kembali ke host.
3. Saat VM butuh, balloon dikempiskan (dengan deflate_on_oom sebagai pengaman).

Overcommit memperbanyak jumlah VM yang bisa dijanjikan — dengan risiko: jika semua VM butuh memori puncak bersamaan, host bisa kehabisan. Disiplinnya:

• Overcommit moderat (misal 1.2–1.5x), bukan ekstrem.
• deflate_on_oom: true di semua VM.
• Pantau statistik balloon dan tekanan memori host secara real-time.

#Disiplin Operasional pada Skala Ribuan

Teknik di atas tidak berharga tanpa operasi yang disiplin. Tiga pilar:

#Daemon per MicroVM

Pada skala besar, VM tidak dikelola satu per satu lewat terminal. Satu daemon atau agent per microVM (atau per host) yang mengelola siklus hidup: launch, health check, restart, cleanup. Ini adalah peran Flintlock (episode 12) atau agent buatan sendiri. Polanya: kontrol terpusat, eksekusi per-VM, state yang bisa diaudit.

#Health Check

Setiap VM harus punya definisi "sehat". Indikator yang berguna:

• Proses Firecracker hidup (bukan zombie).
• Guest merespons (lewat vsock atau HTTP di dalam guest).
• Snapshot bisa di-restore dalam batas waktu.

Health check per-VM pada skala ribuan harus ringan — jangan menciptakan beban yang lebih besar dari VM yang dipantau.

#Garbage Collection Snapshot

Snapshot (episode 9) menumpuk cepat: tiap suspend/resume menyisakan file state dan memori. Tanpa pembersihan, disk host terisi dan pipeline restore melambat. Disiplin yang sehat:

find /snapshots -name '*.mem' -mtime +7 -delete
find /snapshots -name 'base' -mtime +7 -delete

Aturan praktis: snapshot yang tidak diakses dalam periode tertentu (sesuai SLA) dihapus, dan pembersihan dijalankan sebagai job terjadwal dengan audit.

#Densitas vs Latensi: Trade-off yang Jujur

Densitas bukan target yang bebas biaya. Semakin padat:

• Waktu boot cenderung naik (kompetisi CPU saat init).
• Restore snapshot bisa melambat (page cache terpecah, disk I/O sibuk).
• Risiko gangguan antar-tenant naik (tetangga yang berisik).

Grafik yang harus kalian bangun di lab (episode 16): boot time vs jumlah VM, restore time vs jumlah VM. Titik di mana kurva mulai menanjak adalah densitas yang sehat — bukan angka maksimal yang bisa di-boot sekaligus.

#Common Pitfalls

• Tanpa jailer per VM: satu VM bocor mencemari yang lain; isolasi hilang.
• Rootfs read-write: page cache sharing tidak efektif; memori host terbuang.
• Overcommit tanpa monitoring: OOM massal saat beban puncak.
• Snapshot menumpuk: disk penuh, restore lambat — GC terjadwal adalah wajib.
• Health check yang mahal: polling berat per VM membunuh manfaat densitas.
• Densitas diukur di kertas, bukan lab: angka nyata datang dari load test.

#Penutup

Inti yang harus dibawa pulang:

• Densitas = jailer per VM + cgroup v2 + page cache sharing + balloon overcommit.
• Rootfs read-only yang sama memungkinkan halaman file di-share antar VM.
• Overcommit via balloon butuh monitoring tekanan memori yang ketat.
• Daemon per VM, health check ringan, dan GC snapshot adalah disiplin wajib.
• Densitas sehat ditentukan oleh kurva boot/restore vs jumlah VM di lab.

Di episode 20 selanjutnya kita akan menjaga sistem tetap terlihat: Observability & Troubleshooting — membaca log Firecracker dengan level dan ratelimit, mengambil metrics lewat API /metrics, tracing, men-debug lewat serial console, menangani error KVM dan kegagalan restore snapshot, serta memakai firecracker --help dan gdb saat semua cara lain gagal.