WASM vs konteyner soğuk başlangıçları: çalışma zamanları ne diyor

Soğuk başlatma, uygulama kodu çalıştırılmadan önce yürütme ortamının başlatılması gerektiğinde bir istek tarafından ödenen ek gecikmeyi ifade eder. Klasik bir uç veya sunucusuz işlevde bu, marjinal bir durum olmaktan çok uzaktır: iki trafik zirvesi arasında sıfır örneğe inen veya yürütmesini coğrafi olarak dağınık düzinelerce uç düğüme dağıtan bir platform, bu maliyeti yalnızca ilk dağıtımda değil kalıcı olarak öder.

Docker'ın kurucu ortağı Solomon Hykes'in Mart 2019'da Twitter'da yayınladığı şu cümleden beri konu WASM ekosisteminde neredeyse sembolik bir önem kazandı: "Eğer WASM+WASI 2008'de mevcut olsaydı, Docker'ı yaratmamıza gerek kalmazdı. İşte bu kadar önemli. Sunucudaki WebAssembly bilgi işlemin geleceğidir. » Bu tanınmış bir uygulayıcının görüşüdür, bir ölçüm değil. Konunun neden büyüleyici olduğunu açıklıyor, kaynaklı bir rakamın yerini almaz.

Aurabase, uç işlevleri için iki yol sunar: Supabase geçiş kılavuzumuzdabelgelendiği gibi kodu Deno çalışma zamanında çalıştıran Studio editörü ve Rust'ta yazılan ve Wasmtime'da WASM'ye derlenen işlevler için ayrı bir yol hedefleyen aura functions deployCLI. Bu makalenin, henüz var olmayan bir başlangıç rakamı vermeden, ışık tuttuğu ikinci yol budur.

Aradaki fark, mutlak anlamda daha hızlı bir çalışma zamanından kaynaklanmıyor; sorgu ile uygulama kodu arasındaki adımların daha kısa yığınından kaynaklanıyor.

Bir kapsayıcıyı başlatmak ana bilgisayar çekirdeğini harekete geçirir: yeni bir süreç oluşturmak, onu izole eden grupları ve ad alanlarını ayarlamak, görüntünün katmanlarını monte etmek ve ardından uygulama çalışma zamanını içeride başlatmak (örneğin, Node.js ve onun V8 motorunun kendilerinin bir başlatma maliyeti vardır). Her adımda sistem çağrıları eklenir ve yerel olarak hiç görülmemiş bir görüntü için daha başlamadan ağdan indirme işlemi yapılır.

WebAssembly modülü, işletim sistemi düzeyinde değil, sanal makine dili düzeyinde yalıtılmıştır. Bir modülün başlatılması, onun doğrusal belleğinin tahsis edilmesi, içe aktarılanların bağlanması, ardından giriş noktasına atlanması anlamına gelir; bunların tümü ana bilgisayar çalışma zamanının önceden başlatılmış süreci dahilindedir. Yeni işlemler yok, görüntü katmanları yok, varsayılan dosya sistemi bağlantıları yok.

Derleme modunun seçimi ek bir değişken ekler. Wasmtime, modül yüklendiğinde Cranelift arka ucu aracılığıyla JIT'e derler veya önceden yerel makine koduna dönüştürülmüş bir .cwasm dosyası üreten wasmtime compileile önceden derleyebilir. Erken derleme (AOT), derleme adımını isteğin kritik yolundan kaldırır: Bu, tam olarak soğuk başlatmaya duyarlı bir uç mimarisinin etkinleştirmesi gereken kaldıraçtır.

# Aurabase deposundan gerçek alıntı
# WASM Çalışma Zamanı
wasmtime = { version = "43", features = ["async", "cranelift"] }

Bu bir geliştirme değil üretim bağımlılığıdır: Wasmtime'ın gerçekten Aurabase uç fonksiyonlarının CLI yolunda çalıştığını doğrular. Ancak herhangi bir gecikme rakamını doğrulamaz ve tarihli bir kıyaslama yayınlanmadığı sürece bu durum geçerli kalır.

Bu alanda en güçlü kaynak, bir pazarlama blog yazısı değil, bir sektör araştırma makalesidir. AWS tarafından geliştirilen ve özellikle Lambda ve Fargate için kullanılan hafif microVM teknolojisi Firecracker, USENIX NSDI 2020 konferansında Agache ve diğerleri tarafından sunuldu. “Firecracker: Sunucusuz Uygulamalar için Hafif Sanallaştırma” makalesinde.

Bu belge, aynı fiziksel makinede binlerce mikroVM'yi çalıştırma yeteneği ile birlikte, 125 ms'den daha az bir önyükleme süresini ve mikroVM başına 5 MiB'den daha az bir bellek ek yükünü belgelemektedir. Bu, hakemli bir akademik yayından alınan ve o zamandan bu yana sunucusuz izolasyonla ilgili literatürde geniş çapta alıntı yapılan eski bir rakamdır (2020).

Standart bir Docker kapsayıcısı genellikle daha yüksektir: görüntünün boyutuna, indirme ihtiyacına ve yerleşik uygulama çalışma zamanının önyükleme süresine bağlı olarak birkaç yüz milisaniyeden birkaç saniyeye kadar. Firecracker'ın aksine, burada evrensel olarak alıntılanan tek bir rakam yoktur: sonuç, fikir birliğine varmak için tek bir değer için test edilen görüntüye fazlasıyla bağlıdır.

Üç kaynak, üç farklı durum: tarihi bir tedarikçi, vakıf yönetimi altındaki bir proje ve bir araştırma makalesi.

Compute@Edge'i 2019'da kendi ön derleme WASM derleyicisi ve çalışma zamanı olan Lucet'te hızla başlattı. Bu lansmanda şirket, WASM örnekleme sürelerini bir milisaniyenin altında belgeledi; bu, sektördeki WASM soğuk başlangıç söylemi üzerinde kalıcı bir etkiye sahip olan bir büyüklük sırasıdır. 2021'de Fastly, Lucet'in otonom gelişimini durdurdu ve çabalarını, Cranelift derleme arka ucu bu optimizasyonların bir kısmını devralan Wasmtime'a yönlendirdi: Wasmtime'ın bugün bu tür yükler için bir referans olarak kalmasının nedenlerinden biri de budur.

CNCF yönetişimi (başlangıçta SSVM, Second State tarafından desteklenir) altındaki bir WASM çalışma zamanı olan WasmEdge, resmi belgelerinde, uç ve IoT yüklerinde açık bir konumlandırma ile eşdeğer bir Docker konteynerinden önemli ölçüde daha düşük bir başlangıç ve bellek alanı kapladığını iddia ediyor. Bu, proje yayıncısının kendisi tarafından yayınlanan ve şu şekilde okunacak bir rakamdır: bağımsız bir denetim değil, bir ürün iddiası.

Akademik araştırma tarafında, Faasm (Shillaker & Pietzuch, USENIX ATC 2020, ayrıca ön yayında mevcuttur), tam olarak bir işlevin konteyner veya VM ile izolasyondan çok daha düşük bir maliyetle başlatılmasına izin verdiği için WebAssembly izolasyonuna (Wasmtime değil, WAVM aracılığıyla) dayanan durum bilgisi olan sunucusuz bir platform oluşturur. Makale özellikle Wasmtime ile ilgili değil ancak önceki bölümdeki yapısal argümana bağımsız akademik doğrulama sağlıyor.

Bu üç çalışma zamanını yalnızca adlarına göre karşılaştırmak, gerçek değişkeni gizler: seçilen derleme arka ucu, başlatma hızı ile yürütme performansı arasındaki dengeyi kökten değiştirir.

Wasmer'in en hızlı derleme arka ucu olan Singlepass'ın var olmasının nedeni, ekibinin soğuk başlatmayı kararlı durum yürütme performansının farklı bir ekseni olarak tanımlamasıdır: Singlepass'ta derlenen bir modül, LLVM'de derlenen aynı modüle göre daha hızlı başlar, ancak yoğun yük sırasında daha yavaş çalışır. Bu kabul edilmiş bir uzlaşmadır, gizli bir kusur değil.

Bu beş satır tek bir sınıflandırma olarak okunmaz: farklı metodolojilerden, tarihlerden ve çalışma zamanı nesillerinden gelirler. Bu tür WASM kıyaslamalarının güvenilirliğine ilişkin daha derinlemesine bir metodolojik eleştiri için, WebAssembly kıyaslamalarının sınırları hakkındaki makalemiz, her kaynağın somut olarak iddia ettiği şeye odaklanmaya devam eden mevcut karşılaştırmanın ötesine geçer.

WASM'nin soğuk başlatma avantajı, tüm yüklerde eşit olarak değil, en çok ilk isteğin gecikmesine en duyarlı yüklerde dikkate alınır.

Özellikle çok düzensiz kenar trafiğine (ani patlamalar ve ardından sessizlikler), çeşitli istekler arasında paylaşılan konteyner başına izolasyon yerine istek başına izolasyona ve sıcak havuzu kalıcı olarak tutmak yerine aslında iki zirve arasında sıfır örneğe inen bir altyapıya ağırlık verir. Örneklerin yine de sıcak kaldığı istikrarlı ve öngörülebilir bir yükte, soğuk başlatma aralığı yapısal olarak daha az önemlidir.

WebAssembly ayrıca soğuk başlangıçtan farklı kısıtlamaları da korur: dosya sistemine veya ağa erişim, çalışma zamanlarına ve sürümlerine bağlı olarak hala gelişmekte olan bir arayüz olan WASI üzerinden geçer ve hızlı bir şekilde başlamak üzere derlenen bir modül (örneğin, Wasmer tarafında Singlepass), ağır yük altında kurulduğunda mutlaka en hızlısı olmayabilir. Soğuk başlatma ve en yüksek yürütme performansı iki ayrı eksen olarak kalır; aynı derleme profilinde aynı anda nadiren optimaldir.

Bu kritere göre uç mimari seçimini değerlendirmek için Aurabase, herhangi bir tedarikçiye sorulacak üç somut soruyu içeriyordu: tam olarak hangi çalışma zamanının kullanıldığı, hangi derleme arka ucunun (JIT veya AOT) kullanıldığı ve gelişmiş soğuk başlangıç rakamının bağımsız bir üçüncü taraf tarafından mı yoksa yalnızca çalışma zamanı yayıncısının kendisi tarafından mı ölçüldüğü.

Aynı sorunun veritabanı katmanı için sunucusuz Postgres soğuk başlatma hakkındaki makalemize bakın.