MicroVM Firecracker dengan bahasa sederhana: VM sungguhan yang menyala dalam sepersekian detik

Jika Anda pernah membaca tentang cara menjalankan kode buatan AI dengan aman, Anda pasti pernah melihat kata microVM, biasanya di samping Firecracker. Kata itu dijelaskan sebagai “VM ringan” (benar, tapi tidak membantu) atau dengan diagram jeroan kernel. Inilah versi di antaranya.

Dua pilihan lama, dan mengapa keduanya tidak cocok

Mulailah dari dua hal yang diapit oleh microVM.

Kontainer adalah sekelompok proses biasa di mesin Anda yang dibohongi oleh kernel dengan persetujuannya. Namespace menunjukkan kepada mereka sistem berkas, daftar proses, dan jaringan milik sendiri; cgroup membatasi berapa banyak CPU dan memori yang boleh mereka pakai. Kontainer menyala dalam milidetik karena tidak ada yang baru dinyalakan. Tetapi setiap kontainer di sebuah host berbicara dengan kernel yang sama. Bug kernel yang bisa dijangkau dari satu kontainer adalah jalan keluar dari semuanya.

Mesin virtual membawa kernelnya sendiri. CPU host, melalui virtualisasi perangkat keras (KVM di Linux), menjalankan tamu seolah-olah ia punya komputer sendiri. Batasnya adalah hypervisor, yang membuka jauh lebih sedikit dibanding ratusan panggilan sistem sebuah kernel. Harganya adalah bobot. VM klasik mengemulasikan seluruh PC: firmware, bus PCI, pengendali USB, kartu grafis, kadang kartu suara. Ia menyala melewati semua itu, butuh detik hingga menit, dan setiap instans membawa puluhan atau ratusan megabita overhead.

Analogi yang cukup tepat: kontainer adalah apartemen dalam satu gedung, berbagi fondasi, pipa, dan kabel. VM adalah rumah terpisah. Rumah adalah tetangga yang lebih aman, tetapi tak ada yang membangun rumah untuk kunjungan selama 20 detik.

Apa yang dibuang Firecracker

Firecracker adalah virtual machine monitor (program yang menyiapkan dan menjalankan VM di atas KVM) yang ditulis dalam Rust dan dirilis sebagai sumber terbuka pada 2018. Ia dibuat untuk satu tugas: menjalankan beban kerja berumur pendek dalam jumlah sangat besar, yang saling tidak percaya, di atas perangkat keras bersama. Ia mencapainya terutama dengan membuang banyak hal:

• Tanpa firmware, tanpa deteksi perangkat keras. Kernel dimuat langsung ke memori lalu dijalankan. Tak ada yang mencari perangkat yang tidak ada.
• Model perangkat yang mungil. Kartu jaringan, perangkat blok, konsol serial, dan beberapa lagi, semuanya virtio (perangkat yang dirancang untuk mesin virtual, bukan tiruan perangkat fisik). Tanpa USB, tanpa grafis, tanpa PCI.
• Basis kode kecil yang aman memori. Lebih sedikit kode yang mengemulasikan perangkat berarti lebih sedikit tempat untuk bug yang memungkinkan tamu menjangkau host.
• Kandang di sekeliling VMM itu sendiri. Setiap proses Firecracker berjalan di dalam chroot, dengan filter seccomp pada panggilan sistemnya sendiri dan cgroup pada sumber dayanya. Jika ada yang lolos dari tamu, ia akan mendarat di kandang, bukan di host.

Angka yang dipublikasikan proyek itu sendiri: ruang pengguna dalam waktu hanya 125 ms dan overhead memori di bawah 5 MiB per microVM. Itu nilai laboratorium terbaik; sandbox sungguhan juga perlu menyiapkan disk dan jaringan serta menunggu agen di dalam yang siap menerima perintah, karena itu sandbox kami siap dalam sekitar satu detik. Itu tetap cukup dekat dengan kecepatan kontainer untuk membuat satu per tugas lalu membuangnya setelahnya.

Kontainer dan microVM dalam praktik

Baris yang penting adalah baris kedua. Dengan kontainer, pertanyaan “bisakah kode ini lolos?” berubah menjadi “adakah bug yang bisa dijangkau di mana pun dalam kernel host?”. Dengan microVM, ia berubah menjadi “adakah bug di hypervisor atau di segelintir perangkat virtual?”. Permukaan kedua jauh lebih kecil, dan itulah yang sudah dipertahankan platform cloud untuk hosting multi-penyewa mereka sendiri.

Apa yang Anda korbankan

MicroVM bukan peningkatan gratis.

• Tanpa GPU dan tanpa layar. Ia untuk menjalankan kode, bukan untuk desktop atau grafis.
• Lebih sedikit perangkat, lebih sedikit fleksibilitas. Apa pun yang mengharapkan perangkat keras asli atau daftar panjang modul kernel tidak akan merasa betah.
• Batas tetap butuh kebijakan. MicroVM dengan lalu lintas keluar terbuka tetap bisa mengirim lalu lintas yang tidak Anda inginkan; microVM berisi kunci API Anda tetap bisa membocorkannya. Isolasi melindungi host dari tamu, bukan rahasia Anda dari kode yang Anda serahi rahasia itu.

Cara sandbox kami menggunakannya

Setiap sandbox EQVPS adalah satu microVM Firecracker dengan kernel sendiri, dari 0.25 vCPU dan 512 MB hingga 8 vCPU dan 16 GB. Di dalamnya ada Python 3.12, Node.js 22, bash, git, dan curl, dengan internet keluar dan tanpa port masuk. Sandbox sementara dihapus saat Anda selesai; sandbox persistent menyimpan disknya, dan menjeda satu sandbox akan menulis snapshot microVM ke disk sehingga tidak ada biaya sampai dilanjutkan. Snapshot yang dijeda disimpan 14 hari. Setelah itu sandbox dihapus dan id-nya menjawab 410 sandbox_deleted.

Kami memilih microVM daripada kontainer karena satu alasan: kode yang berjalan di sandbox, menurut definisinya, adalah kode yang belum ditinjau siapa pun. Keluaran agen AI, pull request orang asing, benchmark berisi seribu program tulisan model. Untuk itu, kernel sendiri adalah batas yang layak dibayar. Rincian yang kami bangun di sekitarnya — tarif, kuota, batas 55 detik untuk perintah sinkron — ada di dokumentasi sandbox.

Jika Anda ingin membandingkan batas ini dengan pilihan lain secara lebih mendalam, tingkat isolasi untuk kode tidak tepercaya menyandingkan proses, kontainer, microVM, dan VM penuh. Dan jika harga per detik yang menarik perhatian Anda, cara kerja penagihan per detik yang sebenarnya menunjukkan hitungannya.