Netlify, Edge Functions'ı Firecracker microVM'lere taşıdı ve warm ek yükünü 5-6 ms'ye indirdi

Neler değişti

Şirketin mühendislik yazısına dayanan bir dev.to analizine göre Netlify, Edge Functions'ını hosted bir V8-isolate yürütme servisinden, kendi edge ağındaki compute node'larında çalışan Firecracker microVM'lere taşıdı. Platform artık günde kabaca bir milyar Edge Function çağrısı gerçekleştiriyor; bu da istek başına küçük maliyetleri iki kat pahalı hale getiriyor: kullanıcılar bunları gecikme olarak yaşar, platform ise muazzam bir hacim boyunca bedelini öder.

Bildirilen sonuçlar dikkat çekici. Medyan warm invocation ek yükü önceki altyapıda kabaca 25-40 ms iken yaklaşık 5-6 ms'ye düştü, p99 çağrılar yüzde 47,4 daha hızlı hale geldi, kullanılabilirlik yüzde 99,998 seviyesinde ve log teslimati yaklaşık beş kat daha hızlı. Yürütme katmanında Netlify ile çalışan Unikraft, filo genelinde microVM başlatma için 2 ms p99 bildiriyor.

dev.to yazısı, mimari kaymanın benchmark sayılarından daha önemli olduğunu savunuyor. Önceden, bir Edge Function rotasıyla eşleşen istek Netlify'in ağından tamamen çıkıyor ve harici bir sağlayıcıda çalışıyordu. Artık TLS'i sonlandıran edge node, deployment'ın rotalarını kontrol ediyor ve eşleşen istekleri bölgesel bir compute node'una iletiyor. Runtime başlatma, istek gecikmesinin yalnızca bir terimi: ağ hop'ları, yerleşim, image kullanılabilirliği ve logging kritik yolda yer alıyor; dolayısıyla harici bir hop'un ortadan kaldırılması, daha hızlı bir runtime kadar fark yaratabilir.\n

İstek, makine belirtimini taşır

İletimden önce edge node, fonksiyonu yürütmesi gereken makineyi tanımlayan bir belirtim ekler: runtime, bir platform image'i, müşterinin fonksiyon image'i, ayrıca CPU, bellek ve bağlantı limitleri. Netlify bu belirtimi siteye özgü verilerle birlikte hash'leyerek bir service ID türetir; böylece farklı deploy'lar veya environment-variable kümeleri farklı servislere eşlenir ve farklı servisler asla bir microVM'yi paylaşmaz. Deployment kimliği, paylaşılan bir süreç üzerine katmanlanmış bir kural olmaktan çıkıp izolasyon sınırının parçası haline gelir.

Yerleşim ve image dağıtımı

Her bölge bir compute node havuzu içerir ve Netlify, belirli bir servisin genellikle aynı node'a düşmesi için rendezvous hashing uygular. Bu, yerelliği korur: bir node bir fonksiyon image'ini bir kez çektikten sonra sonraki istekler diskteki kopyayı yeniden kullanır ve mevcut microVM'ler ya da snapshot'lar kullanışlı kalır. Saf yapışkanlık, meşgul bir kiracının seçtiği node'u doyurabilirdi; bu yüzden yerleşim bir eşiğin üzerinde gevşer ve yoğun bir servisi birkaç node'a yayar, bir miktar cache sıcaklığını kapasiteyle takas eder.

Cold start'lar büyük ölçüde bir image dağıtım sorunu olarak ele alınıyor. Netlify, cold yolunun çağrıların yaklaşık yüzde 1,2'sini etkilediğini ve ortalama kabaca 9 ms sürdüğünü bildiriyor. Node'lar image'leri her müşterinin kodunu önceden almak yerine ilk kullanımda çeker, bunları yerel olarak cache'ler ve eski kopyaları otomatik budar; Unikraft bu yaklaşımı on-demand image resolution olarak tanımlıyor. Dolayısıyla yeni bir deploy, trafik hizmeti verebilmek için filo genelinde senkronizasyon gerektirmez.

microVM'ler neden hızlı boot ediyor

Her fonksiyon, tam genel amaçlı bir guest yerine sadeleştirilmiş bir Linux ortamı boot eden kendi Firecracker microVM'sinde çalışır. Fonksiyon dosyaları sıkıştırılmamış, memory-map'lenmiş bir EROFS image'i olarak mount edilir; böylece VM, tüm bundle'ı önce belleğe kopyalamak yerine yalnızca gerçekten dokunduğu sayfaları okur. JavaScript sunucusu dinlemeye başladığında platform VM'yi snapshot'lar; boşta olan instanceler sıfıra kadar küçülür ve sonraki istekler, her sayfanın yüklenmesini beklemeden memory-map'lenmiş snapshot'tan geri yüklenir.

dev.to yazısı buradan daha geniş bir ders çıkarıyor: "VM" çok kaba bir performans kategorisidir, çünkü snapshot'tan geri yüklenen, amaca göre inşa edilmiş bir microVM, sıradan bir işletim sistemi boot eden geleneksel bir cloud VM'den çok farklı bir yoldan başlar.

İzolasyon iyileştirmeleri

Netlify migrasyonu ayrıca bir güvenlik değişikliği olarak çerçeveliyor. Müşteri kodu JavaScript runtime'ından kaçışırsa, artık başka bir kiracıya ya da compute host'una ulaşmadan önce bir VM sınırıyla karşılaşır; bu, birbirine güvenmeyen programların tek bir paylaşılan süreç içinde isolate olarak çalışmasından daha güçlü bir ayrımdır. dev.to yazısı hiçbir sanallaştırma sınırının kırılamaz olarak tanımlanmaması gerektiği konusunda uyarıyor; ancak migrasyon, bir ihlalin sıradaki adımda nereden geçmek zorunda kalacağını değiştiriyor.

Neden önemli

Edge platformları uzun süredir izolasyonu gecikmeye karşı takas etti: isolate'ler hızlıdır ama bir süreci paylaşır, VM'ler iyi izole eder ama yavaş boot eder. Günlük bir milyar çağrıda Netlify'ın sayıları, microVM'lerin kimlik tabanlı yerleşim ve on-demand image caching ile birleştirildiğinde, kiracılar arasında VM düzeyinde izolasyonu korurken isolate düzeyine yakın gecikmeye ulaşabileceğini gösteriyor. Yeniden kullanılabilir dersler tek bir platformu aşar: yürütmeyi kendi ağınızın içinde tutun, deployment kimliğini izolasyon modelinin parçası yapın ve cold start'ları salt bir boot sorunu değil, bir dağıtım sorunu olarak ele alın.