Cold start: WASM vs contêineres, o que dizem os runtimes

A inicialização a frio refere-se à latência adicional paga por uma solicitação quando o ambiente de execução deve ser inicializado antes da execução do código do aplicativo. Numa função edge clássica ou sem servidor, isto está longe de ser um caso marginal: uma plataforma que chega a zero instâncias entre dois picos de tráfego, ou que distribui a sua execução por dezenas de nós edge geograficamente dispersos, paga este custo permanentemente, e não apenas na primeira implementação.

O assunto assumiu uma importância quase simbólica no ecossistema WASM desde uma frase de Solomon Hykes, cofundador do Docker, publicada no Twitter em março de 2019: “Se WASM+WASI existisse em 2008, não precisaríamos criar o Docker. É assim que é importante. WebAssembly no servidor é o futuro da computação. » Esta é uma opinião de um profissional reconhecido, não uma medição. Explica porque o assunto fascina, não substitui um figura de origem.

Aurabase oferece dois caminhos para suas funções de borda: o editor Studio, que executa código no tempo de execução Deno conforme documentado em nosso Guia de migração Supabase, e o aura functions deployCLI, que visa um caminho separado para funções escritas em Rust e compiladas para WASM no Wasmtime. É sobre este segundo caminho que este artigo esclarece, sem lhe dar um valor de arranque a frio que ainda não existe.

A diferença não vem de um tempo de execução mais rápido em termos absolutos: ela vem de uma pilha menor de etapas entre a consulta e o código da aplicação.

Iniciar um contêiner mobiliza o kernel do host: criar um novo processo, configurar os cgroups e namespaces que o isolam, montar as camadas da imagem e, em seguida, iniciar o tempo de execução do aplicativo interno (o Node.js e seu mecanismo V8, por exemplo, têm um custo de inicialização). Cada etapa adiciona chamadas de sistema e, para uma imagem nunca vista localmente, um download de rede antes mesmo de começar.

Um módulo WebAssembly é isolado no nível da linguagem da máquina virtual, não no nível do sistema operacional. Instanciar um módulo significa alocar sua memória linear, vincular suas importações e, em seguida, saltar para seu ponto de entrada, tudo dentro do processo já iniciado do tempo de execução do host. Sem novos processos, sem camadas de imagem, sem montagens de sistema de arquivos padrão.

A escolha do modo de compilação adiciona uma variável adicional. Wasmtime compila para JIT por meio de seu backend Cranelift quando o módulo é carregado, ou pode pré-compilá-lo antecipadamente com wasmtime compile, que produz um arquivo .cwasm já transformado em código de máquina nativo. A compilação antecipada (AOT) remove a etapa de compilação do caminho crítico da solicitação: esta é exatamente a alavanca que uma arquitetura de borda sensível à inicialização a frio deve ativar.

# Extrato real do repositório Aurabase
# Tempo de execução WASM
wasmtime = { version = "43", features = ["async", "cranelift"] }

Esta é uma dependência de produção, não de desenvolvimento: ela confirma que o Wasmtime realmente é executado no caminho CLI das funções de borda do Aurabase. No entanto, não confirma quaisquer números de latência, o que permanece verdadeiro desde que nenhum benchmark datado seja publicado.

Nessa área, a fonte mais forte é um artigo de pesquisa do setor, não uma postagem em um blog de marketing. Firecracker, a tecnologia microVM leve desenvolvida pela AWS e usada principalmente para Lambda e Fargate, foi apresentada na conferência USENIX NSDI 2020 por Agache et al. no artigo “Firecracker: Virtualização leve para aplicativos sem servidor”.

Este documento documenta um tempo de inicialização inferior a 125 ms e uma sobrecarga de memória inferior a 5 MiB por microVM, com a capacidade de executar milhares de microVMs na mesma máquina física. Este é um número datado (2020), proveniente de uma publicação acadêmica revisada por pares e amplamente citado desde então na literatura sobre isolamento sem servidor.

Um contêiner Docker padrão geralmente é maior: de algumas centenas de milissegundos a vários segundos, dependendo do tamanho da imagem, da necessidade de baixá-la e do tempo de inicialização do tempo de execução do aplicativo incorporado. Não há uma figura única universalmente citada aqui, ao contrário do Firecracker: o resultado depende muito da imagem testada para um único valor chegar a um consenso.

Três fontes, três status diferentes: um fornecedor histórico, um projeto sob governança da fundação e um artigo de pesquisa.

Lançou rapidamente o Compute@Edge em 2019 no Lucet, seu próprio compilador e tempo de execução WASM de pré-compilação. Neste lançamento, a empresa documentou tempos de instanciação do WASM abaixo de um milissegundo, uma ordem de magnitude que teve um impacto duradouro no discurso de inicialização a frio do WASM na indústria. Em 2021, a Fastly encerrou o desenvolvimento autônomo do Lucet e redirecionou seus esforços para o Wasmtime, cujo backend de compilação do Cranelift herdou parte dessas otimizações: esse é um dos motivos pelos quais o Wasmtime continua hoje sendo referência para esse tipo de carga.

WasmEdge, um tempo de execução WASM sob governança CNCF (originalmente SSVM, suportado pelo Second State), afirma em sua documentação oficial uma inicialização e consumo de memória significativamente menores do que um contêiner Docker equivalente, com um posicionamento explícito nas cargas de borda e IoT. Este é um número publicado pelo próprio editor do projeto, para ser lido como tal: uma declaração de produto, não uma auditoria independente.

Do lado da pesquisa acadêmica, Faasm (Shillaker & Pietzuch, USENIX ATC 2020, também disponível em pré-publicação) constrói uma plataforma stateful serverless baseada no isolamento WebAssembly (via WAVM, não Wasmtime) precisamente porque permite que uma função seja instanciada a um custo muito menor do que o isolamento por contêiner ou por VM. O artigo não é especificamente sobre Wasmtime, mas fornece validação acadêmica independente para o argumento estrutural da seção anterior.

Comparar esses três tempos de execução apenas pelo nome esconde a variável real: o backend de compilação escolhido, que muda radicalmente o equilíbrio entre velocidade de inicialização e desempenho de execução.

Singlepass, o back-end de compilação mais rápido do Wasmer, existe precisamente porque sua equipe identificou a inicialização a frio como um eixo distinto de desempenho de execução em estado estacionário: um módulo compilado em Singlepass inicia mais rápido, mas funciona mais lentamente durante o pico de carga do que o mesmo módulo compilado em LLVM. É um compromisso aceito, não uma falha oculta.

Essas cinco linhas não são interpretadas como uma classificação única: elas vêm de diferentes metodologias, datas e gerações de tempo de execução. Para uma crítica metodológica mais aprofundada sobre a confiabilidade deste tipo de benchmark WASM, nosso artigo sobre os limites dos benchmarks WebAssembly vai além da presente comparação, que permanece focada no que cada fonte afirma concretamente.

A vantagem da inicialização a frio do WASM conta mais com as cargas mais sensíveis à latência da primeira solicitação, e não com todas as cargas igualmente.

Pesa particularmente no tráfego de borda muito irregular (rajadas seguidas de silêncios), no isolamento por solicitação, em vez de por contêiner compartilhado entre várias solicitações, e em uma infraestrutura que na verdade cai para zero instâncias entre dois picos, em vez de manter um hot pool permanentemente. Em uma carga estável e previsível, onde as instâncias permanecem quentes de qualquer maneira, o intervalo de inicialização a frio é estruturalmente menos importante.

O WebAssembly também mantém restrições distintas da inicialização a frio: o acesso ao sistema de arquivos ou à rede passa por WASI, uma interface ainda em evolução dependendo dos tempos de execução e suas versões, e um módulo compilado para iniciar rapidamente (Singlepass no lado Wasmer, por exemplo) não é necessariamente o mais rápido uma vez estabelecido sob carga pesada. A inicialização a frio e o desempenho de pico de execução permanecem dois eixos distintos, raramente ideais simultaneamente no mesmo perfil de compilação.

Para avaliar a escolha da arquitetura de borda neste critério, três perguntas concretas a serem feitas a qualquer fornecedor, a Aurabase incluiu: qual tempo de execução exato é usado, qual back-end de compilação (JIT ou AOT) e se o valor avançado de inicialização a frio foi medido por um terceiro independente ou apenas pelo próprio editor de tempo de execução.

Para a camada de banco de dados deste mesmo problema, consulte nosso artigo sobre inicialização a frio do Postgres sem servidor.