WASM versus koude start van container: wat runtimes zeggen

Koude start verwijst naar de extra latentie die door een aanvraag wordt betaald wanneer de uitvoeringsomgeving moet worden geïnitialiseerd voordat de applicatiecode wordt uitgevoerd. Bij een klassieke edge- of serverloze functie is dit verre van een marginaal geval: een platform dat tussen twee verkeerspieken naar nul exemplaren gaat, of dat de uitvoering ervan verdeelt over tientallen geografisch verspreide edge-nodes, betaalt deze kosten permanent, en niet alleen bij de eerste implementatie.

Het onderwerp heeft een bijna symbolische betekenis gekregen in het WASM-ecosysteem sinds een zin van Solomon Hykes, mede-oprichter van Docker, gepubliceerd op Twitter in maart 2019: "Als WASM+WASI in 2008 bestond, hadden we Docker niet hoeven te creëren. Zo belangrijk is het. WebAssembly op de server is de toekomst van computergebruik. » Dit is een mening van een erkend vakman, geen meting. Het verklaart waarom het onderwerp fascineert, het vervangt niet een afkomstige figuur.

Aurabase biedt twee paden voor zijn edge-functies: de Studio-editor, die code uitvoert in de Deno-runtime zoals gedocumenteerd in onze Supabase-migratiehandleiding, en de aura functions deployCLI, die streeft naar een apart pad voor functies geschreven in Rust en gecompileerd naar WASM op Wasmtime. Het is deze tweede weg waar dit artikel licht op werpt, zonder er een koudstartcijfer aan te geven dat nog niet bestaat.

Het verschil komt niet uit een snellere runtime in absolute termen: het komt uit een kortere stapel stappen tussen de query en de applicatiecode.

Het starten van een container mobiliseert de hostkernel: het creëren van een nieuw proces, het instellen van de cgroups en naamruimten die het isoleren, het mounten van de lagen van de afbeelding en het starten van de runtime van de applicatie binnenin (Node.js en zijn V8-engine hebben bijvoorbeeld zelf initialisatiekosten). Elke stap voegt systeemaanroepen toe en, voor een afbeelding die nog nooit lokaal is gezien, een netwerkdownload voordat deze zelfs maar begint.

Een WebAssembly-module is geïsoleerd op het taalniveau van de virtuele machine, niet op het niveau van het besturingssysteem. Het instantiëren van een module betekent het toewijzen van het lineaire geheugen, het binden van de importen en het springen naar het toegangspunt, allemaal binnen het reeds gestarte proces van de hostruntime. Geen nieuwe processen, geen afbeeldingslagen, geen standaard bestandssysteemaankoppelingen.

De keuze van de compilatiemodus voegt een extra variabele toe. Wasmtime compileert naar JIT via de Cranelift-backend wanneer de module wordt geladen, of kan deze vooraf precompileren met wasmtime compile, wat een .cwasm-bestand produceert dat al is omgezet in native machinecode. Vroege compilatie (AOT) verwijdert de compilatiestap uit het kritieke pad van het verzoek: dit is precies de hefboom die een edge-architectuur die gevoelig is voor koude start moet activeren.

# Werkelijk uittreksel uit de Aurabase-repository
# WASM-runtime
wasmtime = { version = "43", features = ["async", "cranelift"] }

Dit is een productieafhankelijkheid, geen ontwikkeling: het bevestigt dat Wasmtime feitelijk op het CLI-pad van de Aurabase edge-functies draait. Het bevestigt echter geen latentiecijfers, wat waar blijft zolang er geen gedateerde benchmark wordt gepubliceerd.

Op dit gebied is de sterkste bron een onderzoekspaper uit de sector, en niet een marketingblogpost. Firecracker, de lichtgewicht microVM-technologie ontwikkeld door AWS en met name gebruikt voor Lambda en Fargate, werd op de USENIX NSDI 2020-conferentie gepresenteerd door Agache et al. in het artikel “Firecracker: lichtgewicht virtualisatie voor serverloze applicaties”.

Dit artikel documenteert een opstarttijd van minder dan 125 ms en een geheugenoverhead van minder dan 5 MiB per microVM, met de mogelijkheid om duizenden microVM's op dezelfde fysieke machine te draaien. Dit is een gedateerd cijfer (2020), afkomstig uit een peer-reviewed wetenschappelijke publicatie, en sindsdien veelvuldig geciteerd in de literatuur over serverloze isolatie.

Een standaard Docker-container is over het algemeen langer: van een paar honderd milliseconden tot enkele seconden, afhankelijk van de grootte van de afbeelding, de noodzaak om deze te downloaden en de opstarttijd van de runtime van de ingebedde applicatie. Er wordt hier geen enkel cijfer universeel aangehaald, in tegenstelling tot Firecracker: het resultaat hangt te veel af van het geteste beeld voor een enkele waarde om consensus te bereiken.

Drie bronnen, drie verschillende statussen: een historische leverancier, een project onder stichtingsbestuur en een onderzoekspaper.

Lanceerde Compute@Edge in 2019 snel op Lucet, zijn eigen pre-compilerende WASM-compiler en runtime. Bij deze lancering documenteerde het bedrijf WASM-instantiatietijden van minder dan een milliseconde, een orde van grootte die een blijvende impact had op het WASM-koudestartdiscours in de branche. In 2021 stopte Fastly met de autonome ontwikkeling van Lucet en verlegde zijn inspanningen naar Wasmtime, waarvan de Cranelift-compilatie-backend een deel van deze optimalisaties erfde: dit is een van de redenen waarom Wasmtime vandaag de dag een referentie blijft voor dit soort belasting.

WasmEdge, een WASM-runtime onder CNCF-beheer (oorspronkelijk SSVM, ondersteund door Second State), claimt in zijn officiële documentatie een aanzienlijk lagere opstart- en geheugenvoetafdruk dan een gelijkwaardige Docker-container, met een expliciete positionering op edge- en IoT-belastingen. Dit is een cijfer dat door de projectuitgever zelf is gepubliceerd en als zodanig moet worden gelezen: een productclaim, geen onafhankelijke audit.

Aan de academische onderzoekskant bouwt Faasm (Shillaker & Pietzuch, USENIX ATC 2020, ook beschikbaar in pre-publicatie) een stateful serverloos platform dat vertrouwt op WebAssembly-isolatie (via WAVM, niet Wasmtime), juist omdat het het mogelijk maakt een functie te instantiëren tegen veel lagere kosten dan isolatie per container of per VM. Het artikel gaat niet specifiek over Wasmtime, maar biedt onafhankelijke academische validatie van het structurele argument uit het vorige deel.

Als je deze drie runtimes alleen op naam vergelijkt, verberg je de echte variabele: de gekozen compilatie-backend, die de balans tussen opstartsnelheid en uitvoeringsprestaties radicaal verandert.

Singlepass, de snelste compilatie-backend van Wasmer, bestaat juist omdat het team koude start heeft geïdentificeerd als een aparte as van steady-state uitvoeringsprestaties: een module gecompileerd in Singlepass start sneller, maar draait langzamer tijdens piekbelasting dan dezelfde module gecompileerd in LLVM. Het is een geaccepteerd compromis, geen verborgen fout.

Deze vijf regels kunnen niet als één enkele classificatie worden gelezen: ze komen uit verschillende methodologieën, data en runtime-generaties. Voor een meer diepgaande methodologische kritiek op de betrouwbaarheid van dit type WASM-benchmark gaat ons artikel over de grenzen van WebAssembly-benchmarks verder dan de huidige vergelijking, die gefocust blijft op wat elke bron concreet beweert.

Het koude startvoordeel van WASM telt het meest op de belastingen die het meest gevoelig zijn voor de latentie van het eerste verzoek, en niet op alle belastingen in gelijke mate.

Het weegt vooral op zeer onregelmatig edge-verkeer (bursts gevolgd door stiltes), op isolatie per verzoek in plaats van per container die wordt gedeeld tussen verschillende verzoeken, en op een infrastructuur die tussen twee pieken feitelijk naar nul exemplaren gaat in plaats van permanent een hot pool te behouden. Bij een stabiele en voorspelbare belasting, waarbij instances hoe dan ook warm blijven, doet de koudestartkloof er structureel minder toe.

WebAssembly hanteert ook beperkingen die verschillen van een koude start: toegang tot het bestandssysteem of het netwerk gaat via WASI, een interface die nog steeds evolueert afhankelijk van de runtimes en hun versies, en een module die is gecompileerd om snel te starten (bijvoorbeeld Singlepass aan de Wasmer-kant) is niet noodzakelijkerwijs de snelste als deze eenmaal onder zware belasting is opgezet. Koude start en maximale uitvoeringsprestaties blijven twee verschillende assen, die zelden tegelijkertijd optimaal zijn op hetzelfde compilatieprofiel.

Om een keuze voor edge-architectuur op dit criterium te beoordelen, heeft Aurabase drie concrete vragen gesteld die aan elke leverancier kunnen worden gesteld: welke exacte runtime wordt gebruikt, welke compilatie-backend (JIT of AOT), en is het geavanceerde koude startcijfer gemeten door een onafhankelijke derde partij of alleen door de runtime-uitgever zelf.

Voor de databaselaag van ditzelfde probleem, zie ons artikel over de serverloze Postgres koude start.