Cold start: WASM contro container, cosa dicono i runtime

L'avvio a freddo si riferisce alla latenza aggiuntiva pagata da una richiesta quando l'ambiente di esecuzione deve essere inizializzato prima dell'esecuzione del codice dell'applicazione. In una classica funzione edge o serverless, questo è lungi dall'essere un caso marginale: una piattaforma che scende a zero istanze tra due picchi di traffico, o che distribuisce la sua esecuzione su dozzine di nodi edge geograficamente dispersi, paga questo costo in modo permanente, non solo al primo utilizzo.

L'argomento ha assunto un'importanza quasi simbolica nell'ecosistema WASM da una frase di Solomon Hykes, co-fondatore di Docker, pubblicata su Twitter nel marzo 2019: "Se WASM+WASI esistesse nel 2008, non avremmo avuto bisogno di creare Docker. Ecco quanto è importante. WebAssembly sul server è il futuro dell'informatica. » Questa è un'opinione di un professionista riconosciuto, non una misurazione. Spiega perché l'argomento affascina, non sostituisce una fonte figura.

Aurabase offre due percorsi per le sue funzioni edge: l'editor Studio, che esegue il codice nel runtime Deno come documentato nella nostra guida alla migrazione su Supabasee la aura functions deployCLI, che mira a un percorso separato per le funzioni scritte in Rust e compilate in WASM su Wasmtime. È su questa seconda strada che questo articolo mette in luce, senza darle una cifra di partenza a freddo che ancora non esiste.

La differenza non deriva da un runtime più veloce in termini assoluti: deriva da uno stack di passaggi più breve tra la query e il codice dell'applicazione.

L'avvio di un contenitore mobilita il kernel host: creando un nuovo processo, impostando i cgroup e gli spazi dei nomi che lo isolano, montando i livelli dell'immagine, quindi avviando il runtime dell'applicazione al suo interno (Node.js e il suo motore V8, ad esempio, hanno essi stessi un costo di inizializzazione). Ogni passaggio aggiunge chiamate di sistema e, per un'immagine mai vista localmente, un download di rete prima ancora che inizi.

Un modulo WebAssembly è isolato a livello del linguaggio della macchina virtuale, non a livello del sistema operativo. Istanziare un modulo significa allocare la sua memoria lineare, vincolare le sue importazioni, quindi passare al punto di ingresso, il tutto all'interno del processo già avviato del runtime dell'host. Nessun nuovo processo, nessun livello di immagine, nessun montaggio di file system predefinito.

La scelta della modalità di compilazione aggiunge un'ulteriore variabile. Wasmtime compila in JIT tramite il suo backend Cranelift quando il modulo viene caricato, oppure può precompilarlo in anticipo con wasmtime compile, che produce un file .cwasm già trasformato in codice macchina nativo. L’Early Compilation (AOT) rimuove lo step di compilazione dal percorso critico della richiesta: è proprio questa la leva che deve attivare un’architettura edge sensibile al cold start.

# Estratto effettivo dal repository Aurabase
# Tempo di esecuzione WASM
wasmtime = { version = "43", features = ["async", "cranelift"] }

Questa è una dipendenza di produzione, non di sviluppo: conferma che Wasmtime viene effettivamente eseguito sul percorso CLI delle funzioni edge di Aurabase. Tuttavia, non conferma alcun dato sulla latenza, il che rimane vero finché non viene pubblicato alcun benchmark datato.

In quest’area, la fonte più efficace è un documento di ricerca di settore, non un post su un blog di marketing. Firecracker, la tecnologia microVM leggera sviluppata da AWS e utilizzata in particolare per Lambda e Fargate, è stata presentata alla conferenza USENIX NSDI 2020 da Agache et al. nell'articolo "Petardo: virtualizzazione leggera per applicazioni serverless".

Questo documento documenta un tempo di avvio inferiore a 125 ms e un sovraccarico di memoria inferiore a 5 MiB per microVM, con la possibilità di eseguire migliaia di microVM sulla stessa macchina fisica. Si tratta di un dato datato (2020), ricavato da una pubblicazione accademica sottoposta a revisione paritaria e da allora ampiamente citato nella letteratura sull'isolamento serverless.

Un contenitore Docker standard è generalmente più elevato: da poche centinaia di millisecondi a diversi secondi a seconda della dimensione dell'immagine, della necessità di scaricarla e del tempo di avvio del runtime dell'applicazione incorporata. Qui non viene citata un'unica cifra universalmente valida, a differenza di Petardo: il risultato dipende troppo dall'immagine testata per un singolo valore per ottenere consenso.

Tre fonti, tre status diversi: un fornitore storico, un progetto sotto il governo della fondazione e un documento di ricerca.

Ha lanciato rapidamente Compute@Edge nel 2019 su Lucet, il proprio compilatore e runtime WASM di precompilazione. In occasione di questo lancio, l'azienda ha documentato tempi di istanziazione WASM inferiori al millisecondo, un ordine di grandezza che ha avuto un impatto duraturo sul discorso sull'avvio a freddo WASM nel settore. Nel 2021, Fastly ha cessato lo sviluppo autonomo di Lucet e ha reindirizzato i suoi sforzi verso Wasmtime, il cui backend di compilazione Cranelift ha ereditato parte di queste ottimizzazioni: questo è uno dei motivi per cui Wasmtime rimane oggi un riferimento per questo tipo di carico.

WasmEdge, un runtime WASM sotto la governance CNCF (originariamente SSVM, supportato da Second State), afferma nella sua documentazione ufficiale un avvio e un ingombro di memoria significativamente inferiori rispetto a un contenitore Docker equivalente, con un posizionamento esplicito sui carichi edge e IoT. Si tratta di un dato pubblicato dallo stesso editore del progetto, da leggere come tale: un reclamo sul prodotto, non un audit indipendente.

Dal punto di vista della ricerca accademica, Faasm (Shillaker & Pietzuch, USENIX ATC 2020, disponibile anche in pre-pubblicazione) costruisce una piattaforma serverless con stato basandosi sull'isolamento WebAssembly (tramite WAVM, non Wasmtime) proprio perché consente di istanziare una funzione a un costo molto inferiore rispetto all'isolamento per contenitore o per VM. L’articolo non riguarda specificamente Wasmtime, ma fornisce una convalida accademica indipendente all’argomentazione strutturale nella sezione precedente.

Confrontando questi tre runtime solo per nome si nasconde la vera variabile: il backend di compilazione scelto, che cambia radicalmente l'equilibrio tra velocità di avvio e prestazioni di esecuzione.

Singlepass, il backend di compilazione più veloce di Wasmer, esiste proprio perché il suo team ha identificato l'avvio a freddo come un asse distinto delle prestazioni di esecuzione a stato stazionario: un modulo compilato in Singlepass si avvia più velocemente, ma funziona più lentamente durante i picchi di carico rispetto allo stesso modulo compilato in LLVM. È un compromesso accettato, non un difetto nascosto.

Queste cinque righe non si leggono come un'unica classificazione: provengono da metodologie, date e generazioni di runtime diverse. Per una critica metodologica più approfondita dell'affidabilità di questo tipo di benchmark WASM, il nostro articolo sui limiti dei benchmark WebAssembly va oltre il presente confronto, che rimane focalizzato su ciò che ciascuna fonte asserisce concretamente.

Il vantaggio dell'avvio a freddo di WASM conta maggiormente sui carichi più sensibili alla latenza della prima richiesta, non su tutti i carichi allo stesso modo.

Pesa in particolare sul traffico edge molto irregolare (burst seguiti da silenzi), sull'isolamento per richiesta piuttosto che per contenitore condiviso tra più richieste, e su un'infrastruttura che di fatto scende a zero istanze tra due picchi invece di mantenere permanentemente un hot pool. Su un carico stabile e prevedibile, dove le istanze rimangono comunque calde, il divario di avvio a freddo ha strutturalmente meno importanza.

WebAssembly mantiene inoltre vincoli distinti dall'avvio a freddo: l'accesso al file system o alla rete passa attraverso WASI, un'interfaccia ancora in evoluzione a seconda dei runtime e delle loro versioni, e un modulo compilato per avviarsi rapidamente (Singlepass sul lato Wasmer, ad esempio) non è necessariamente il più veloce una volta stabilito sotto carico pesante. L'avvio a freddo e le prestazioni di picco di esecuzione rimangono due assi distinti, raramente ottimali contemporaneamente sullo stesso profilo di compilazione.

Per valutare la scelta dell'architettura edge in base a questo criterio, Aurabase ha incluso tre domande concrete da porre a qualsiasi fornitore: quale runtime esatto viene utilizzato, quale backend di compilazione (JIT o AOT) e il valore di avvio a freddo avanzato è stato misurato da una terza parte indipendente o solo dall'editore del runtime stesso.

Per il livello di database di questo stesso problema, vedere il nostro articolo sull'avvio a freddo di Postgres serverless.