Netlify, günde bir milyar Edge Functions çağrısını Firecracker MicroVM'lere taşıdı: Medyan invocation süresi 5 kat hızlandı

Netlify, Edge Functions'ın arkasındaki compute katmanını yeniden inşa etti ve harici bir barındırma yürütme servisi üzerindeki V8 isolate'lerin yerine kendi edge ağı içinde çalışan Firecracker MicroVM'leri geçti. Netlify'in blog yazısına göre platformda her gün yaklaşık bir milyar Edge Functions çalışıyor — Sunweb için sayfaları kişiselleştiren, Loto-Québec için cookie tabanlı routing yapan ve yüz binlerce başka site için personalization, routing ve auth işlerini üstlenen fonksiyonlar — ve warm invocation süreleri artık medyan değerinde yaklaşık beş kat daha hızlı.

Performans rakamları

Bir warm invocation — bir compute düğümüne routing, MicroVM'e giriş, fonksiyonun çalıştırılması ve response header'larının üretilmesi — artık medyan (p50) seviyesinde yaklaşık 5–6ms sürüyor; önceki altyapıda bu süre 25–40ms'ydi. Netlify ayrıca %47,4 daha hızlı p99 invocation, %99,998 erişilebilirlik ve beş kat daha hızlı Edge Functions log teslimi bildiriyor.

Cold start, bir isteğin, fonksiyonu hiç görmemiş compute düğümlerine sahip bir bölgeye gelmesi ve herhangi bir şey çalışmadan önce image'lerin çekilmesi gerektiği durumlarda yaşanıyor. Netlify bunun invocation'ların yaklaşık %1,2'sini etkilediğini ve ortalama yaklaşık 9ms sürdüğünü belirtiyor. Tüm bu rakamlar şirketin kendi ölçümleri; bağımsız ölçümler değil.

Yeni istek yolu

Her istek, istemciye en yakın edge düğümüne düşer; burada TLS sonlandırılır ve yol, o deploy'a ait Edge Functions rotalarıyla karşılaştırılır. Eşleşmeyen istekler her zamanki gibi cache'e ve origin'e devam eder. Eski mimaride eşleşen bir istek Netlify'in ağından çıkıyor, genel internet üzerindeki barındırma yürütme servisinde çalışıp geri dönüyordu; artık Netlify'in kendi ağı içindeki bir compute düğümüne iletiliyor.

İletimden önce edge düğümü, her istekle birlikte yolculuk eden bir makine tanımı yazar. Bu tanım üç image'i adlandırır — JavaScript runtime, Netlify'in platform image'i ve müşterinin edge function image'i — ve CPU, bellek ve bağlantı limitlerini belirler. Tanımın hash'i artı siteye özgü bilgiler bir servis ID'si oluşturur; böylece farklı kod veya environment variable'lara sahip iki deploy, asla MicroVM paylaşmayan farklı servislerdir.

Compute düğümünde bir servis birden fazla MicroVM'ye sahip olabilir; parametreler instance'ların ne zaman ölçeklenip küçüleceğini kontrol eder. Her MicroVM, kapatılmadan önce sabit sayıda isteği işler ve platform önceden hazırlık olarak yedeğini açar. Eksik image'ler edge düğümünden çekilip diske yazılır; böylece bir bölge yalnızca orada gerçekten trafik alan fonksiyonları indirir.

Kaçış vanalı sticky scheduling

Compute düğümleri rendezvous hashing ile seçilir: aynı servis her zaman aynı düğüme düşer, bu da MicroVM'leri warm tutar ve kodu diskte ve cache'te tutar. Netlify, isteklerin düğümlere eşit dağıtılmasının çok daha fazla cold start üreteceğini belirtiyor. Bu yapışkanlığın bedeli hot spot'tur: tek bir düğüme sabitlenmiş yoğun bir fonksiyon, o makinedeki diğer her şeyi besleyemez hale getirir. Belirli bir trafik eşiğinin üzerinde Netlify bu yapışkanlığı gevşetir ve servisi bir grup düğüme yayar; böylece spike'lar, orijinal düğüme hash'lenen diğer servisleri kötüleştirmeden emilir.

MicroVM'nin içinde

Her fonksiyon kendi Firecracker MicroVM'sinde çalışır; bu VM bir milisaniyenin altında oluşturulur ve p99'da yaklaşık 2ms'de başlatılır — bu, VM'nin tam bir işletim sistemi yerine sadeleştirilmiş bir Linux ortamını açması sayesinde mümkündür. Fonksiyonun dosyaları sıkıştırılmamış bir EROFS image'i olarak mount edilir ve memory-map'lenir; böylece VM yalnızca bundle'ın gerçekten kullandığı kısımlarını okur.

VM içindeki JavaScript sunucusu bir portu dinlemeye başladığında Netlify bir snapshot alır. Boşta olan fonksiyonlar warm beklemek yerine sıfıra ölçeklenir ve bir sonraki invocation, tam snapshot'ın belleğe geri okunmasını beklemeden memory-map'lenmiş snapshot'tan devam eder. Unikraft'ın ürünü boot, snapshot, restore ve scale-to-zero yaşam döngüsünü yönetir; iki ekip göç boyunca birlikte çalıştı ve Unikraft projeye ilişkin kendi yazısını yayımladı.

Netlify izolasyonu belirleyici avantaj olarak sunuyor: ele geçirilmiş olma ihtimali olan bir deploy ayrı bir MicroVM'de çalışır ve runtime'dan kaçan kod bile diğer müşterileri veya compute katmanını etkileyemez — şirket, adlarına rağmen V8 isolate'lerin bu garantiyi sağlamadığını söylüyor.

Geliştiriciler için hiçbir şey değişmiyor: URL import'ları, npm paketleri, Node built-in'leri, netlify.toml tanımları ve yerel geliştirme eskisi gibi davranıyor. Operasyonel tarafta yeniden inşa, compute düğümlerine yerel DNS resolver'ları ekledi ve metrik toplamayı genişletti; sanal switch'lerde port tükenmesi dahil önceki derslerden yararlanıldı.

Neden önemli

Edge platformlar hızlı başlangıç ve yüksek yoğunluk nedeniyle V8 isolate'leri yaygın biçimde benimsedi; ancak tenant'lar tek bir runtime sürecini paylaşır, bu da bir müşterinin diğerinden ne kadar izole olduğunu sınırlar. Netlify'ın sonuçları, Firecracker MicroVM'lerin — snapshot restore, memory-map'lenmiş EROFS bundle'ları ve sadeleştirilmiş kernel'lerle — artık her deploy arasında donanım izolasyon sınırıyla isolate sınıfı gecikme sunabileceğini gösteriyor. Günde bir milyar invocation, personalization, routing ve auth iş yükleri boyunca katlanan milisaniyelik edge süreleriyle birleştiğinde, bu kombinasyon isolate'lere karşı MicroVM tartışmasında ciddi bir veri noktası ve diğer paylaşımlı runtime'lı serverless platformların yanıt vermesi gerekebileceği bir şablon oluşturuyor.