Belajar Firecracker - Snapshot & Restore

#Pendahuluan

Boot 125 ms terasa cepat — sampai kalian bayangkan ribuan cold start per detik. Episode 9 menjawab pertanyaan yang belum terjawab: bagaimana menghidupkan microVM yang sudah "panas" dalam milidetik, bukan detik? Jawabannya adalah snapshot: membekukan microVM berjalan, menyimpan state-nya, dan menghidupkannya kembali persis di titik yang sama.

Mengapa episode ini penting? Snapshot adalah teknologi yang mengubah ekonomi serverless. Cold start instan, scale-to-zero, dan suspend/resume hingga 8 jam — semua fitur yang dipakai AWS Lambda MicroVMs — berdiri di atas snapshot Firecracker. Memahami snapshot berarti memahami bagaimana platform serverless modern benar-benar bekerja.

#Konsep: Membekukan Waktu

Sebuah microVM berjalan memiliki banyak state: isi memori, register vCPU, dan kondisi device. Snapshot menangkap semuanya ke dalam file, sehingga state itu bisa di-restore di proses Firecracker lain di host yang sama atau berbeda.

Dua file yang dihasilkan:

• Snapshot file — state device, vCPU, dan konfigurasi VM (bukan isi memori).
• Memory file — isi memori guest, ditulis sebagai file di host.

Restore adalah kebalikannya: proses Firecracker baru membaca kedua file, memuat state, dan melanjutkan eksekusi dari titik beku — seolah-olah tidak pernah berhenti. Guest tidak menyadari apa-apa.

#Membuat Snapshot

Sebelum snapshot, microVM harus di-pause agar state stabil. Alur lengkapnya:

curl --unix-socket /tmp/firecracker.sock -i \
  -X PUT http://localhost/actions \
  -H 'Accept: application/json' -H 'Content-Type: application/json' \
  -d '{ "action_type": "Pause" }'

Lalu buat snapshot:

curl --unix-socket /tmp/firecracker.sock -i \
  -X PUT http://localhost/snapshot/create \
  -H 'Accept: application/json' -H 'Content-Type: application/json' \
  -d '{
    "snapshot_type": "Full",
    "snapshot_path": "/snapshot/base",
    "mem_file_path": "/snapshot/base.mem"
  }'

Field penting:

• snapshot_type — Full (seluruh memori) atau Diff (hanya halaman yang berubah sejak base; episode 19).
• snapshot_path — file state VM.
• mem_file_path — file isi memori.

Setelah snapshot dibuat, resume atau stop VM:

curl --unix-socket /tmp/firecracker.sock -i \
  -X PUT http://localhost/actions \
  -H 'Accept: application/json' -H 'Content-Type: application/json' \
  -d '{ "action_type": "Resume" }'

#Restore: Menghidupkan Kembali

Restore dilakukan dengan proses Firecracker baru (bukan melanjutkan proses lama). Buka proses baru, lalu kirim PUT /snapshot/load:

firecracker --api-sock /tmp/firecracker-restored.sock --config-file /dev/null &

curl --unix-socket /tmp/firecracker-restored.sock -i \
  -X PUT http://localhost/snapshot/load \
  -H 'Accept: application/json' -H 'Content-Type: application/json' \
  -d '{
    "snapshot_path": "/snapshot/base",
    "mem_backend": {
      "backend_type": "File",
      "path": "/snapshot/base.mem"
    },
    "enable_diff_snapshots": false,
    "resume_vm": false
  }'

Kemudian resume:

curl --unix-socket /tmp/firecracker-restored.sock -i \
  -X PUT http://localhost/actions \
  -H 'Accept: application/json' -H 'Content-Type: application/json' \
  -d '{ "action_type": "Resume" }'

Perhatikan: resume_vm: false saat load memberi kesempatan mengatur ulang konfigurasi jaringan (MAC, rate limiter) sebelum eksekusi dilanjutkan — langkah wajib bila VM di-restore di host atau jaringan yang berbeda.

#Kunci Kesesuaian CPU: cpu_template

Snapshot ditangkap di satu host dan di-restore di host lain. Masalahnya: CPU host bisa berbeda mikroarsitekturnya, dan instruksi yang tersimpan di register vCPU mungkin tidak valid di CPU baru. Solusinya adalah cpu_template di machine-config: Firecracker menyembunyikan perbedaan mikroarsitektur dengan mengekspos CPU guest sebagai model standar (misalnya T2, T2S, T3).

Konsekuensi praktisnya: host yang menghasilkan snapshot dan host yang me-restore harus punya cpu_template yang sama dan vcpu_count/memori yang kompatibel. Inilah alasan platform serverless menerapkan snapshot ke host dengan tipe yang homogen — dan mengapa kalian harus menetapkan template sejak awal, bukan setelah snapshot ada.

#Pola Nyata: Cold Start Instan, Scale-to-Zero, Suspend/Resume

Snapshot membuka tiga pola yang mengubah desain sistem:

#Cold Start Instan

Alih-alih boot kernel + init + aplikasi (ratusan ms sampai detik), restore snapshot aplikasi yang sudah diinisialisasi: buka proses, load state, resume — aplikasi langsung siap dalam milidetik. Pola ini dipakai serverless untuk menghidupkan fungsi tanpa menunggu boot.

#Scale-to-Zero

Saat tidak ada traffic, VM bisa dihentikan total — tidak ada biaya memori, tidak ada CPU. Saat permintaan datang, snapshot di-restore dalam milidetik. Efisiensi biaya scale-to-zero penuh dicapai karena restart tidak lagi mahal.

#Suspend/Resume

VM dibekukan dan state-nya disimpan untuk durasi panjang — AWS Lambda MicroVMs mengizinkan suspend hingga 8 jam, lalu resume persis di titik berhenti. Ini memungkinkan workload yang butuh menjaga koneksi dan state tetap "hidup" meski tidak aktif.

#Alur Kerja Lengkap Snapshot di Orchestrator

Ini pola yang dipakai orchestrator microVM (firecracker-containerd, Flintlock, Lambda) dalam praktik:

1. Warm pool — beberapa microVM di-boot dari image base dan diinisialisasi aplikasinya, lalu di-pause.
2. Snapshot base — buat Full snapshot dari VM yang sudah siap.
3. Restore on demand — saat request datang, restore snapshot di host yang cocok (cpu_template sama), set konfigurasi jaringan, lalu resume.
4. Diff snapshot (opsional) — setelah dipakai, simpan hanya perubahan sejak base untuk audit atau replay.

Pola ini menghilangkan waktu boot dari jalur kritis: aplikasi di-restore, bukan di-boot.

#Common Pitfalls

• Drive read-write: VM dengan drive read-write tidak bisa di-snapshot — gunakan read-only rootfs.
• cpu_template tidak konsisten: restore di host berbeda dengan template beda → kandidat crash. Standarisasi template.
• Lupa resume: setelah load, VM masih pause sampai Resume dikirim.
• Snapshot di host yang sama saat VM masih jalan: snapshot harus dari VM yang paused, dan restore di proses terpisah — bukan proses yang sama.
• File snapshot tidak synced: pastikan file snapshot dan mem disalin utuh ke host tujuan sebelum load.
• Jaringan di-set ulang setelah load: MAC dan rate limiter harus dikonfigurasi ulang sebelum resume bila berpindah host.

#Penutup

Inti yang harus dibawa pulang:

• Snapshot = state VM lengkap (vCPU, memori, device) dalam dua file.
• Pause → PUT /snapshot/create → (opsional) resume/stop.
• Restore di proses Firecracker baru: PUT /snapshot/load → Resume.
• cpu_template konsisten adalah prasyarat migrasi snapshot antar host.
• Full vs Diff snapshot menentukan biaya storage dan kecepatan.
• Pola produksi: warm pool → snapshot base → restore on demand → resume.

Di episode 10 selanjutnya kita akan menyetel sumber daya agar microVM hidup berdampingan dengan sehat: Balloon, Entropy & Resource Control — memakai device balloon untuk menarik kembali memori dari guest, mengukur statistiknya, memastikan entropy via virtio-rng, dan menegakkan batas CPU/memori lewat cgroup v2.