Yapay zekânın ürettiği kodu güvenle çalıştırmak üzerine bir şeyler okuduysanız, genellikle Firecracker kelimesinin yanında microVM kelimesini görmüşsünüzdür. Ya “hafif bir VM” olarak (doğru ama işe yaramaz) ya da çekirdeğin iç yapısını gösteren bir diyagramla açıklanır. İşte ikisinin arasındaki sürüm.
İki eski seçenek ve neden hiçbiri uymuyor
MicroVM'in arasında durduğu iki şeyle başlayalım.
Konteyner, makinenizde çekirdeğin onlara yalan söylemeyi kabul ettiği sıradan süreçlerden oluşan bir gruptur. Namespace'ler onlara kendi dosya sistemlerini, süreç listelerini ve ağlarını gösterir; cgroup'lar ne kadar CPU ve bellek kullanabileceklerini sınırlar. Yeni hiçbir şey açılmadığı için milisaniyeler içinde başlar. Ama bir ana makinedeki tüm konteynerler aynı çekirdekle konuşur. Bir konteynerden erişilebilen bir çekirdek hatası, hepsinden çıkış yoludur.
Sanal makine kendi çekirdeğini getirir. Ana makinenin işlemcisi, donanım sanallaştırması (Linux'ta KVM) sayesinde konuğu kendi bilgisayarı varmış gibi çalıştırır. Sınır, bir çekirdeğin yüzlerce sistem çağrısından çok daha azını açığa çıkaran hipervizördür. Bedeli ağırlıktır. Klasik bir VM koca bir bilgisayarı emüle eder: aygıt yazılımı, bir PCI veri yolu, USB denetleyicileri, bir ekran kartı, bazen bir ses kartı. Tüm bunların içinden geçerek açılır, saniyeler ile dakikalar arası sürer ve her örnek onlarca ya da yüzlerce megabaytlık ek yük taşır.
Oldukça iyi işleyen bir benzetme: konteynerler aynı binadaki daireler gibidir; temeli, boruları ve kabloları ortaktır. VM'ler ise ayrı evlerdir. Evler daha güvenli komşulardır ama kimse 20 saniyelik bir ziyaret için ev inşa etmez.
Firecracker neleri atıyor
Firecracker, Rust ile yazılmış ve 2018'de açık kaynak olarak yayımlanmış bir sanal makine monitörüdür (KVM üzerinde bir VM'i kuran ve çalıştıran program). Tek bir iş için yapıldı: paylaşılan donanım üzerinde birbirine güvenmeyen çok sayıda kısa ömürlü iş yükünü çalıştırmak. Bunu çoğunlukla bir şeyleri çıkararak başarır:
- Aygıt yazılımı yok, donanım taraması yok. Çekirdek doğrudan belleğe yüklenir ve başlatılır. Kimse var olmayan cihazları aramaz.
- Minicik bir cihaz modeli. Bir ağ kartı, bir blok cihaz, bir seri konsol ve birkaç tane daha; hepsi virtio (fiziksel cihazların taklidi yerine sanal makineler için tasarlanmış cihazlar). USB yok, grafik yok, PCI yok.
- Küçük, bellek güvenli bir kod tabanı. Cihaz emüle eden kod azaldıkça, konuğun ana makineye ulaşmasını sağlayacak bir hataya yer veren noktalar da azalır.
- VMM'in kendisinin etrafında bir kafes. Her Firecracker süreci bir chroot içinde, kendi sistem çağrılarına seccomp filtreleri ve kaynaklarına cgroup'lar uygulanmış halde çalışır. Konuktan bir şey kaçsa bile ana makineye değil, bir kafese düşer.
Projenin kendi yayımladığı rakamlar: 125 ms gibi kısa bir sürede kullanıcı alanı ve microVM başına 5 MiB'den az bellek ek yükü. Bunlar en iyi laboratuvar değerleridir; gerçek bir sandbox'ın diskinin ve ağının hazırlanması ve içeride komut kabul etmeye hazır bir ajanın beklenmesi de gerekir, bu yüzden bizimki yaklaşık bir saniyede hazır olur. Bu yine de görev başına bir tane oluşturup sonra atacak kadar konteyner hızına yakındır.
Pratikte konteyner ve microVM
| Konteyner | Firecracker microVM | |
|---|---|---|
| Çekirdek | ana makineyle ortak | kendine ait |
| Ana makineyle sınır | ortak bir çekirdeğe sistem çağrıları | hipervizör + küçük VMM |
| Açılış süresi | milisaniyeler | ~0.1–1 sn |
| Örnek başına ek yük | çok küçük | birkaç MiB |
| Cihazlar | ana makine neyi açarsa | ağ, disk, konsol |
| GPU | mümkün | hayır |
| Uygun olduğu iş | kendi kodunuz, uygulama paketleme | güvenilmeyen kod, çok kiracılı iş yükleri |
Önemli olan ikinci satırdır. Konteynerde “bu kod kaçabilir mi?” sorusu “ana makinenin çekirdeğinde herhangi bir yerde erişilebilir bir hata var mı?” sorusuna dönüşür. MicroVM'de ise “hipervizörde ya da bir avuç sanal cihazda bir hata var mı?” sorusuna dönüşür. İkinci yüzey çok daha küçüktür ve bulut platformlarının kendi çok kiracılı barındırmaları için zaten savunduğu yüzey de budur.
Nelerden vazgeçiyorsunuz
MicroVM bedava bir yükseltme değildir.
- GPU yok, ekran yok. Kod çalıştırmak içindir; masaüstü ya da grafik için değil.
- Daha az cihaz, daha az esneklik. Gerçek donanım ya da uzun bir çekirdek modülü listesi bekleyen hiçbir şey kendini evinde hissetmez.
- Sınırların yine de kurallara ihtiyacı var. Giden trafiği açık bir microVM istemediğiniz trafiği yine gönderebilir; içinde API anahtarlarınız olan bir microVM onları yine sızdırabilir. Yalıtım ana makineyi konuktan korur, sırlarınızı onları verdiğiniz koddan değil.
Sandbox'larımız bunu nasıl kullanıyor
Her EQVPS sandbox'ı, kendi çekirdeği olan tek bir Firecracker microVM'dir; 0.25 vCPU ve 512 MB'tan 8 vCPU ve 16 GB'a kadar. İçinde Python 3.12, Node.js 22, bash, git ve curl bulunur; giden internet vardır, gelen port yoktur. Geçici sandbox'lar işiniz bittiğinde silinir; persistent olanlar disklerini korur ve birini duraklatmak microVM'in anlık görüntüsünü diske yazar, böylece devam edene kadar hiçbir maliyeti olmaz. Duraklatılmış anlık görüntüler 14 gün saklanır. Ardından sandbox silinir ve id'si 410 sandbox_deleted döndürür.
Konteyner yerine microVM'leri tek bir nedenle seçtik: bir sandbox'ta çalışan kod, tanımı gereği kimsenin incelemediği koddur. Bir yapay zekâ ajanının çıktısı, bir yabancının pull request'i, bir modelin yazdığı bin programlık bir benchmark. Bunun için kendine ait bir çekirdek, bedelini ödemeye değer sınırdır. Etrafına kurduklarımızın ayrıntıları — tarifeler, kotalar, senkron komutlar için 55 saniyelik limit — sandbox belgelerinde.
Bu sınırı diğer seçeneklerle daha ayrıntılı karşılaştırmak isterseniz güvenilmeyen kod için yalıtım seviyeleri süreçleri, konteynerleri, microVM'leri ve tam VM'leri yan yana koyuyor. Dikkatinizi saniye başına fiyat çektiyse saniye bazında faturalama gerçekte nasıl işliyor hesabı gösteriyor.
Yorumlar
Henüz yorum yok. İlk olun.