XFaaS: a plataforma serverless da Meta que processa trilhões de chamadas por dia

• Plataforma FaaS usada internamente pela Meta
• Processa trilhões de invocações de funções por dia em mais de 100 mil servidores distribuídos por dezenas de regiões de datacenters
• Afirma ser mais eficiente que AWS Lambda e Azure Functions, e foi apresentada no artigo "XFaaS: Hyperscale and Low Cost Serverless Functions"

Estatísticas interessantes e implicações

• O ponto central do artigo é que é possível melhorar o desempenho serverless otimizando o uso de hardware por meio de software
• A Meta identificou o desperdício do overhead de inicialização nas Serverless Functions e buscou emular um Universal Worker, no qual todos os workers podem executar imediatamente qualquer função sem overhead de inicialização
  • Nessa escala, o custo de hardware é enorme, então até uma fração muito pequena faz diferença
• O XFaaS é usado apenas para funções que não ficam voltadas ao usuário. Funções serverless têm variação de latência grande demais para serem usadas de forma consistente em funcionalidades voltadas ao usuário
• Os clientes do XFaaS executam invocações de funções de forma muito abrupta. A demanda de pico é 4,3 vezes maior do que a demanda fora de pico
  • Em um exemplo, 20 milhões de chamadas de função foram submetidas ao XFaaS em menos de 15 minutos
  • A Meta descobriu que até funções com picos seguem padrões e aproveitou isso para tornar essas cargas de trabalho mais previsíveis

Quão eficiente é o XFaaS?

• Atinge utilização média diária de CPU de 66%, muito acima da média do setor
• Distribui a carga de forma eficiente usando tempo (via latência da função) e espaço (enviando para datacenters menos carregados)
  > A Meta continua migrando muitas funções para janelas de menor uso, nas quais carga e custo podem ser previstos
• Por ser uma nuvem interna, a Meta pode fazer várias otimizações exclusivas, como executar várias funções de vários usuários no mesmo processo
• A maioria das funções é executada em menos de 1 segundo, mas nem todas

Problemas resolvidos com o XFaaS

• Problema: tempo de cold start longo
  • Se o contêiner for encerrado cedo demais, ele precisa ser reinicializado por completo para a próxima invocação
  • Se o contêiner for encerrado tarde demais, ele fica ocioso e desperdiça recursos computacionais valiosos
  • Solução: o XFaaS usa métodos como compilação JIT para aproximar um cenário em que todos os workers podem executar imediatamente qualquer função
• Problema: forte desbalanceamento de carga
  • O overprovisioning gera custo extra de hardware, e o underprovisioning desacelera o sistema
  • Solução: o XFaaS adia execuções de funções tolerantes a atraso para horários de menor uso e distribui chamadas de função por regiões de datacenters no mundo todo
• Problema: sobrecarga em serviços downstream
  • Ex.: um pico de invocações de funções não voltadas ao usuário já causou interrupção de serviços online voltados ao usuário
  • Solução: o XFaaS regula a execução das funções com um mecanismo semelhante ao controle de congestionamento do TCP

Comparação com FaaS em geral (AWS Lambda, Google Cloud Functions, Azure Functions)

• Enquanto o FaaS de nuvem pública limita a execução de funções a uma única região de datacenter, o XFaaS pode distribuir chamadas de função globalmente, melhorando o balanceamento de carga
• Plataformas FaaS costumam priorizar a redução de latência sem dar atenção suficiente ao uso de hardware. O XFaaS foca na utilização de hardware e na vazão das invocações de função
• Tecnologias do XFaaS que poderiam ajudar a nuvem pública
  • Permitir que o chamador especifique o horário de início da execução da função
  • Permitir que o dono da função defina objetivos de nível de serviço (SLO) sobre o prazo de conclusão da execução (com SLO menor, é possível atrasar para obter melhor eficiência de execução)
  • Permitir que o dono da função atribua um nível de prioridade à função
• A nuvem pública não pode executar funções de vários usuários no mesmo processo como o XFaaS, mas grandes clientes de nuvem podem adotar a abordagem do XFaaS em uma nuvem privada virtual
• Um pequeno número de equipes da Meta consome uma parte significativa da capacidade do XFaaS. Clientes de grande porte semelhantes em nuvem pública também poderiam se beneficiar da estratégia do XFaaS

Background: premissas e requisitos

• Premissas
  • O insight principal é que a maioria das funções do XFaaS é acionada por workflows automatizados e tolera latência
  • Isso permite ao XFaaS distribuir a carga no tempo (atrasando funções) e no espaço (enviando para datacenters menos carregados)
  • O XFaaS oferece suporte a runtimes de PHP, Python, Erlang e Haskell, além de um runtime genérico baseado em contêiner para todas as linguagens
  • As funções têm vários atributos configuráveis pelo desenvolvedor, como nome da função, argumentos, runtime, prioridade, horário de início da execução, prazo de conclusão, cota de recursos, limite de concorrência e política de retry; o prazo de conclusão pode ser definido de segundos até 24 horas
  • Como a capacidade de hardware varia por região, o balanceamento de carga do XFaaS precisa levar isso em conta
• Tipos de workload
  • A Meta oferece suporte a três tipos de workload no XFaaS
    • Funções acionadas por fila
    • Funções acionadas por eventos (eventos de mudança de dados em data warehouses e sistemas de streaming de dados)
    • Funções acionadas por timer (execução automática em horários pré-configurados)
  • O XFaaS é usado para funcionalidades não voltadas ao usuário, como sistemas de recomendação assíncronos, logging, bots de produtividade e notificações

Arquitetura geral

(Esta parte é longa demais e reproduz quase literalmente o conteúdo do artigo, então foi omitida.)