XFaaS: la plataforma serverless de Meta que procesa billones de invocaciones cada día

• La plataforma FaaS que Meta usa internamente
• Procesa billones de invocaciones de funciones al día en más de 100,000 servidores distribuidos en decenas de regiones de centros de datos
• Afirma ser más eficiente que AWS Lambda y Azure Functions, y fue presentada mediante el artículo "XFaaS: Hyperscale and Low Cost Serverless Functions"

Estadísticas interesantes e implicaciones

• La idea central del artículo es que el rendimiento serverless puede mejorar optimizando el uso del hardware mediante software
• Meta identificó el desperdicio del overhead de arranque en Serverless Functions y buscó emular un Universal Worker en el que cualquier worker pueda ejecutar de inmediato cualquier función sin overhead de inicio
  • A esta escala, el costo del hardware es enorme, así que incluso porcentajes muy pequeños importan
• XFaaS solo se usa para funciones que no están de cara al usuario. Las funciones serverless tienen demasiada variabilidad en la latencia como para usarse de forma consistente en funcionalidades orientadas al usuario
• Los clientes de XFaaS ejecutan invocaciones de funciones con picos muy bruscos. La demanda máxima es 4.3 veces más alta que la demanda fuera de pico
  • En un caso, se enviaron 20 millones de invocaciones de funciones a XFaaS en menos de 15 minutos
  • Meta descubrió que incluso las funciones con aumentos repentinos tienen patrones, y aprovechó eso para volver más predecibles esas cargas de trabajo

¿Qué tan eficiente es XFaaS?

• Logra una utilización promedio diaria de CPU de 66%, muy por encima del promedio de la industria
• Distribuye la carga de forma eficiente usando tiempo (mediante la latencia de las funciones) y espacio (enviándolas a centros de datos menos cargados)

  Meta sigue migrando muchas funciones para que se programen en horarios de bajo uso, donde la carga y el costo pueden predecirse

• Al ser una nube interna, Meta puede aplicar varias optimizaciones únicas, como ejecutar funciones de múltiples usuarios dentro del mismo proceso
• La mayoría de las funciones se ejecutan en menos de 1 segundo, pero no todas

Problemas que resolvió XFaaS

• Problema: tiempos largos de cold start
  • Si el contenedor termina demasiado pronto, hay que reinicializar por completo el contenedor para la siguiente invocación
  • Si el contenedor termina demasiado tarde, queda inactivo y desperdicia valiosos recursos de cómputo
  • Solución: XFaaS usa métodos como compilación JIT para aproximar que todos los workers puedan ejecutar cualquier función de inmediato
• Problema: fuerte desbalanceo de carga
  • El sobreaprovisionamiento genera costos extra de hardware, y el subaprovisionamiento ralentiza el sistema
  • Solución: XFaaS retrasa funciones tolerantes a demoras hasta horarios de bajo uso y distribuye las invocaciones entre regiones de centros de datos en todo el mundo
• Problema: sobrecarga en servicios downstream
  • Ejemplo: un aumento repentino en invocaciones de funciones no orientadas al usuario llegó a interrumpir servicios en línea orientados al usuario
  • Solución: XFaaS regula la ejecución de funciones con un mecanismo similar al control de congestión de TCP

Comparación con FaaS general (AWS Lambda, Google Cloud Functions, Azure Functions)

• Mientras que los FaaS de nube pública limitan la ejecución de funciones a una sola región de centro de datos, XFaaS puede distribuir invocaciones globalmente y mejorar el balanceo de carga
• Las plataformas FaaS suelen priorizar primero reducir la latencia sin prestar suficiente atención a la utilización del hardware. XFaaS se enfoca en la utilización del hardware y el throughput de invocaciones
• Tecnologías de XFaaS que podrían ayudar a la nube pública
  • Permitir que quien invoca especifique la hora de inicio de ejecución de la función
  • Permitir que el dueño de la función defina objetivos de nivel de servicio (SLO) sobre la fecha límite de finalización; con SLO más bajos, la ejecución puede retrasarse para mejorar el tiempo de ejecución
  • Permitir que el dueño de la función asigne un nivel de prioridad a la función
• La nube pública no puede ejecutar funciones de múltiples usuarios dentro del mismo proceso como XFaaS, pero los grandes clientes de nube podrían adoptar este enfoque dentro de una virtual private cloud
• Un pequeño número de equipos de Meta consume una parte importante de la capacidad de XFaaS. Clientes de gran escala similares en la nube pública también podrían beneficiarse de la estrategia de XFaaS

Background: supuestos y requisitos

• Supuestos
  • La idea clave es que la mayoría de las funciones de XFaaS se activan mediante flujos de trabajo automatizados y pueden tolerar cierta latencia
  • Eso permite que XFaaS distribuya la carga en el tiempo (retrasando funciones) y en el espacio (enviándolas a centros de datos menos cargados)
  • XFaaS soporta runtimes de PHP, Python, Erlang y Haskell, además de un runtime general basado en contenedores para cualquier lenguaje
  • Las funciones tienen varios atributos configurables por desarrolladores, como nombre de la función, argumentos, runtime, prioridad, hora de inicio, fecha límite de finalización, cuota de recursos, límite de concurrencia y política de reintentos; la fecha límite de finalización puede configurarse desde segundos hasta 24 horas
  • XFaaS debe considerar que la capacidad de hardware varía según la región, por lo que el balanceo de carga debe tomarlo en cuenta
• Tipos de carga de trabajo
  • Meta soporta tres tipos de cargas de trabajo en XFaaS
    • Funciones activadas por colas
    • Funciones activadas por eventos (eventos de cambio de datos en sistemas de data warehouse y streams de datos)
    • Funciones activadas por temporizador (ejecución automática en horarios predefinidos)
  • XFaaS se usa para funciones no orientadas al usuario, como sistemas de recomendación asíncronos, logging, bots de productividad y notificaciones

Arquitectura completa

(Esta parte es demasiado larga y prácticamente traslada el contenido del artículo tal cual, así que se omite.)