XFaaS : la plateforme serverless de Meta qui traite des billions d’appels chaque jour

• Une plateforme FaaS utilisée en interne par Meta
• Elle traite chaque jour des billions d’appels de fonctions sur plus de 100�000 serveurs répartis dans des dizaines de régions de datacenters
• Meta affirme qu’elle est plus efficace qu’AWS Lambda et Azure Functions, et l’a présentée dans l’article « XFaaS: Hyperscale and Low Cost Serverless Functions »

Statistiques intéressantes et enseignements

• Le point central de l’article est qu’il est possible d’améliorer les performances du serverless en optimisant l’utilisation du matériel par le logiciel
• Meta a identifié le gaspillage lié aux surcoûts de démarrage des Serverless Functions et vise à émuler un Universal Worker capable d’exécuter immédiatement toutes les fonctions sans surcoût de démarrage
  • À une telle échelle, les coûts matériels sont énormes, et même une très petite proportion compte
• XFaaS n’est utilisé que pour des fonctions non exposées aux utilisateurs. Les fonctions serverless présentent une variabilité de latence trop importante pour être utilisées de manière cohérente sur des fonctions orientées utilisateur
• Les clients de XFaaS déclenchent les appels de fonctions de façon très brutale. La demande de pointe est 4,3 fois plus élevée que la demande hors pointe
  • Par exemple, 20 millions d’appels de fonctions peuvent être soumis à XFaaS en moins de 15 minutes
  • Meta a constaté que même les hausses soudaines des fonctions suivent des motifs, et s’en sert pour rendre les pointes de charge plus prévisibles

Quelle est l’efficacité de XFaaS ?

• Un taux moyen quotidien d’utilisation CPU de 66 %, bien supérieur à la moyenne du secteur
• La charge est répartie efficacement dans le temps (via la latence des fonctions) et dans l’espace (en l’envoyant vers des datacenters moins chargés)

  Meta continue de déplacer de nombreuses fonctions — dont la charge et le coût peuvent être prédits — vers des créneaux de faible utilisation

• Comme il s’agit d’un cloud interne, Meta peut appliquer plusieurs optimisations spécifiques, comme l’exécution de fonctions de plusieurs utilisateurs dans un même processus
• La plupart des fonctions s’exécutent en moins d’une seconde, mais ce n’est pas le cas de toutes

Problèmes résolus par XFaaS

• Problème : temps de cold start trop long
  • Si un conteneur s’arrête trop tôt, il faut réinitialiser entièrement le conteneur pour l’appel suivant
  • S’il s’arrête trop tard, il reste inactif et gaspille de précieuses ressources de calcul
  • Solution : XFaaS s’en approche en utilisant des méthodes comme la compilation JIT afin que tous les workers puissent exécuter immédiatement toutes les fonctions
• Problème : forte inégalité de répartition de charge
  • Le surprovisionnement entraîne des coûts matériels supplémentaires, tandis qu’un sous-provisionnement ralentit le système
  • Solution : XFaaS reporte les exécutions de fonctions tolérantes au délai vers les périodes de faible utilisation et répartit les appels de fonctions entre les régions de datacenters du monde entier
• Problème : surcharge des services downstream
  • Exemple : une flambée d’appels à des fonctions non exposées aux utilisateurs a déjà provoqué l’interruption de services en ligne orientés utilisateur
  • Solution : XFaaS régule l’exécution des fonctions avec un mécanisme similaire au contrôle de congestion TCP

Comparaison avec le FaaS classique (AWS Lambda, Google Cloud Functions, Azure Functions)

• Les FaaS de cloud public limitent l’exécution d’une fonction à une seule région de datacenter, tandis que XFaaS peut répartir les appels de fonctions à l’échelle mondiale, ce qui améliore l’équilibrage de charge
• Les plateformes FaaS se concentrent d’abord sur la réduction de la latence, souvent sans tenir compte du taux d’utilisation du matériel. XFaaS met l’accent sur l’utilisation du matériel et le débit des appels de fonctions
• Technologies de XFaaS qui pourraient être utiles au cloud public
  • Autoriser l’appelant à spécifier l’heure de démarrage de l’exécution d’une fonction
  • Permettre au propriétaire d’une fonction de définir un objectif de niveau de service (SLO) concernant son échéance d’achèvement (un SLO plus souple permet plus de délai pour un meilleur temps d’exécution)
  • Autoriser le propriétaire d’une fonction à attribuer un niveau de priorité à la fonction
• Les clouds publics ne peuvent pas exécuter, comme XFaaS, les fonctions de plusieurs utilisateurs dans un même processus, mais les grands clients cloud pourraient adopter l’approche XFaaS dans un virtual private cloud
• Un petit nombre d’équipes Meta consomme une part importante de la capacité XFaaS. Des clients de cloud public de taille comparable pourraient eux aussi bénéficier de la stratégie XFaaS

Contexte : hypothèses et exigences

• Hypothèses
  • L’idée clé est que la plupart des fonctions XFaaS sont déclenchées par des workflows automatisés et tolèrent donc une certaine latence
  • Cela permet à XFaaS de répartir la charge dans le temps (en retardant les fonctions) et dans l’espace (en les envoyant vers des datacenters moins chargés)
  • XFaaS prend en charge les runtimes PHP, Python, Erlang, Haskell, ainsi qu’un runtime générique basé sur des conteneurs pour tous les langages
  • Les fonctions disposent de nombreux attributs configurables par les développeurs, comme le nom de la fonction, les arguments, le runtime, la priorité, l’heure de début d’exécution, l’échéance d’achèvement, le quota de ressources, la limite de concurrence ou la politique de retry, et l’échéance d’achèvement peut aller de quelques secondes à 24 heures
  • La capacité matérielle varie selon les régions, donc l’équilibrage de charge doit en tenir compte
• Types de workloads
  • Meta prend en charge trois types de workloads dans XFaaS
    • Fonctions déclenchées par file d’attente
    • Fonctions déclenchées par événement (événements de modification de données issus de systèmes de data warehouse et de flux de données)
    • Fonctions déclenchées par temporisateur (exécutées automatiquement à un horaire prédéfini)
  • XFaaS est utilisé pour des fonctions non exposées aux utilisateurs, comme les systèmes de recommandation asynchrones, la journalisation, les bots de productivité et les notifications

Architecture globale

(Cette partie est omise car elle est trop longue et reprend presque mot pour mot le contenu de l’article.)