Laine Campbell et Chunqiang (CQ) Tang, respectivement directeur de l'ingénierie de production et directeur de l'ingénierie logicielle chez Meta, ont expliqué comment Meta a construit l'infrastructure informatique de Threads. Parmi les composants essentiels, ZippyDB, le magasin de données clé/valeur distribué, et Async, la plateforme de fonctions asynchrones sans serveur bien nommée.Le 5 juillet 2023, Meta a lancé Threads, le nouveau produit de sa famille d'applications, qui a connu un succès sans précédent avec plus de 100 millions d'inscriptions au cours des cinq premiers jours.
Une petite équipe d'ingénieurs a construit Threads en seulement cinq mois de travail technique. Alors que la mise en production de l'application était envisagée depuis un certain temps, l'entreprise a finalement pris la décision et a informé les équipes d'infrastructure de préparer le lancement avec seulement deux jours d'avance. La décision a été prise en toute confiance, les équipes d'infrastructure de Meta étant capables de tenir leurs promesses, compte tenu de leurs antécédents et de la maturité de l'infrastructure. Malgré les défis considérables à relever avec un délai minimal, les équipes d'infrastructure ont supporté la croissance rapide de l'application de manière exceptionnelle.
L'évolution transparente que les utilisateurs ont connue en s'inscrivant par millions est le fruit de plus d'une décennie de développement de l'infrastructure et du produit. Il ne s'agissait pas d'une infrastructure spécialement conçue pour Threads, mais d'une infrastructure construite au cours de la vie de Meta pour de nombreux produits. Elle avait déjà été construite pour l'échelle, la croissance, la performance et la fiabilité, et elle a réussi à dépasser les attentes alors que Threads se développait à un rythme que personne n'aurait pu prédire.
Une quantité énorme d'infrastructure est utilisée pour servir Threads. Voici des exemples de deux composants existants qui ont joué un rôle important : ZippyDB, le magasin de données clé/valeur distribué, et Async, la plateforme de fonctions asynchrones sans serveur bien nommée.
ZippyDB : mise à l'échelle des espaces clés pour Threads
Zoomons sur une partie de la couche de stockage, où ils ont exploité ZippyDB, une base de données clé/valeur distribuée qui fonctionne comme un service entièrement géré sur lequel les ingénieurs peuvent construire. ZippyDB a été conçue dès le départ pour tirer parti de l'infrastructure de Meta, et les espaces-clés qui y sont hébergés peuvent être augmentés ou réduits avec une relative facilité et placés de manière flexible dans n'importe quel nombre de centres de données. TAO, soutenu par MySQL, est utilisé pour le stockage du graphe social - on peut donc trouver les messages et les réponses de Threads directement dans cette pile. ZippyDB est la contrepartie clé/valeur de MySQL, la partie relationnelle de la pile de données en ligne, et est utilisé pour les compteurs, le classement/état des flux, et la recherche.
La vitesse à laquelle on peut augmenter la capacité d'un espace-clé est rendue possible par deux caractéristiques essentielles : Tout d'abord, le service fonctionne sur un pool commun de matériel et est intégré dans le cadre global de gestion de la capacité de Meta. Dès qu'une nouvelle capacité est allouée au service, les machines sont automatiquement ajoutées au pool du service et l'équilibreur de charge intervient pour déplacer les données vers les nouvelles machines. On peut absorber des milliers de nouvelles machines en l'espace de quelques heures une fois qu'elles sont ajoutées au service. Bien que cela soit formidable, ce n'est pas suffisant car le temps de bout en bout pour approuver la capacité, éventuellement la drainer d'autres services et l'ajouter à ZippyDB, peut encore être de l'ordre de quelques jours. On doit également être en mesure d'absorber une augmentation de capacité dans un délai plus court.
Pour permettre une absorption immédiate, les ingénieurs de Threads s'appuient sur la multi-location de l'architecture du service et sur ses fortes caractéristiques d'isolation. Cela permet à différents espaces-clés, dont les demandes de charge sont potentiellement complémentaires, de partager les hôtes sous-jacents sans s'inquiéter de l'impact sur leur niveau de service lorsque d'autres charges de travail fonctionnent à plein régime. Le pool d'hôtes dispose également d'une marge de manœuvre due à la capacité inutilisée des espaces clés individuels, ainsi que de tampons permettant de gérer les événements de reprise après sinistre. Ils peuvent actionner des leviers qui déplacent les allocations inutilisées entre les espaces-clés - en puisant dans les capacités inutilisées existantes et en laissant les hôtes fonctionner à un niveau d'utilisation plus élevé pour permettre à un espace-clé de monter en puissance presque immédiatement et de le maintenir sur un court intervalle (quelques jours). Il s'agit là de simples changements de configuration pour lesquels des outils et des automatismes ont été mis en place, car il s'agit d'opérations assez courantes au quotidien.
Les effets combinés d'une forte multi-location et de la capacité d'absorber du nouveau matériel permettent au service d'évoluer de manière plus ou moins transparente, même face à une nouvelle demande soudaine et importante.
Optimiser ZippyDB pour le lancement d'un produit
Le protocole de resharding de ZippyDB permet d'augmenter rapidement et de manière transparente le facteur de sharding (c'est-à-dire le facteur d'échelle horizontale) d'un cas d'utilisation de ZippyDB sans aucun temps d'arrêt pour les clients, tout en maintenant des garanties de cohérence et d'exactitude complètes. Cela permet d'étendre rapidement les cas d'utilisation sur le chemin critique du lancement d'un nouveau produit sans aucune interruption du lancement, même si sa charge est multipliée par 100.
Pour ce faire, on demande aux clients de hacher leurs clés dans des cartes logiques, qui sont ensuite mappées dans un ensemble de cartes physiques. Lorsqu'un cas d'utilisation se développe et nécessite un resharding, ils provisionnent un nouvel ensemble de shards physiques et installe un nouveau mappage de shard logique à shard physique chez les clients par le biais de changements de configuration en direct, sans temps d'arrêt. En utilisant des clés d'accès cachées sur le serveur lui-même, et une logique intelligente de migration des données dans les travailleurs de resharding de Threads, les ingénieurs sont alors en mesure de déplacer atomiquement une unité logique du mappage d'origine vers le nouveau mappage. Une fois que tous les blocs logiques ont été migrés, le resharding est terminé et ils suppriment le mappage d'origine.
L'extension des cas d'utilisation étant une opération critique pour le lancement de nouveaux produits, les ingénieurs ont beaucoup investi dans la pile de resharding afin de nous assurer que l'extension de ZippyDB ne bloque pas le lancement des produits. Plus précisément, ils ont conçu la pile de resharding dans un modèle coordinateur-employeur afin qu'elle soit évolutive horizontalement, ce qui permet d'augmenter la vitesse de resharding en cas de besoin, par exemple lors du lancement de Threads. En outre, ils ont développé un ensemble d'outils d'opérateur d'urgence pour faire face sans effort à une croissance soudaine des cas d'utilisation.
La combinaison de ces outils a permis à l'équipe de ZippyDB de répondre efficacement à la croissance rapide de Threads. Souvent, lorsque ils créent de nouveaux cas d'utilisation dans ZippyDB,ils commencent d'abord par une petite taille, puis ils redimensionnent au fur et à mesure de la croissance. Cette approche permet d'éviter le surprovisionnement et favorise une utilisation efficace de la capacité. Lorsque la croissance virale de Threads a commencé, il est devenu évident qu'on devait préparer Threads à une croissance de 100 fois en effectuant un resharding de manière proactive. Avec l'aide d'outils d'automatisation développés dans le passé, ils ont terminé le resharding juste à temps lorsque l'équipe de Threads a ouvert les vannes au trafic à minuit (heure britannique). Cela a permis aux utilisateurs de Threads de vivre une expérience agréable, alors même que le nombre d'utilisateurs montait en flèche.
Async : L'évolution de l'exécution de la charge de travail pour Threads
Async (également connu sous le nom de XFaaS) est une plateforme de fonctions sans serveur capable de reporter le calcul aux heures creuses, ce qui permet aux ingénieurs de Meta de réduire leur temps entre la conception de la solution et le déploiement de la production. Async traite actuellement des billions d'appels de fonctions par jour sur plus de 100 000 serveurs et peut prendre en charge plusieurs langages de programmation, notamment HackLang, Python, Haskell et Erlang.
La plateforme fait abstraction des détails du déploiement, de la mise en file d'attente, de la planification, de la mise à l'échelle, de la reprise après sinistre et de la préparation, de sorte que les développeurs peuvent se concentrer sur leur logique commerciale de base et décharger Async du reste des tâches lourdes. En intégrant leur code dans cette plateforme, ils héritent automatiquement des attributs hyperscale. L'évolutivité n'est pas la seule caractéristique clé d'Async. Le code téléchargé sur la plateforme hérite également de garanties d'exécution avec des tentatives configurables, des délais de livraison, des limites de taux et des responsabilités en matière de capacité.
Les charges de travail couramment exécutées sur Async sont celles qui ne nécessitent pas de bloquer l'expérience d'un utilisateur actif avec un produit et qui peuvent être exécutées de quelques secondes à plusieurs heures après l'action d'un utilisateur. Async a joué un rôle essentiel en offrant aux utilisateurs la possibilité de créer rapidement une communauté en choisissant de suivre sur Threads des personnes qu'ils suivent déjà sur Instagram. Plus précisément, lorsqu'un nouvel utilisateur rejoint Threads et choisit de suivre les mêmes personnes que celles qu'il suit sur Instagram, l'opération coûteuse en termes de calcul consistant à exécuter la demande de l'utilisateur de suivre le même graphe social dans Threads est effectuée via Async de manière évolutive, ce qui évite de bloquer ou d'avoir un impact négatif sur l'expérience d'accueil de l'utilisateur.
Réaliser cette opération pour 100 millions d'utilisateurs en cinq jours a nécessité une puissance de traitement considérable. En outre, de nombreuses célébrités ont rejoint Threads et, à ce moment-là, des millions de personnes ont pu être mises en file d'attente pour les suivre. Cette opération et les notifications correspondantes se sont également déroulées en mode asynchrone, ce qui a permis de réaliser des opérations évolutives face à un grand nombre d'utilisateurs.
Alors que le volume des tâches Async générées par l'intégration rapide des utilisateurs de Threads était supérieur de plusieurs ordres de grandeur aux attentes initiales, Async a gracieusement absorbé la charge accrue et les a mises en file d'attente en vue d'une exécution contrôlée. Plus précisément, l'exécution a été gérée dans des limites de taux, ce qui a permis d'envoyer des notifications et de permettre aux utilisateurs d'établir des connexions en temps voulu sans surcharger les services en aval qui reçoivent le trafic de ces travaux Async. Async a automatiquement ajusté le flux d'exécution en fonction de sa capacité et de celle des services dépendants, tels que la base de données de graphes sociaux, le tout sans intervention manuelle de la part des ingénieurs Threads ou des ingénieurs d'infrastructure.
Quand l'infrastructure et la culture se rencontrent
Le développement rapide de Threads en seulement cinq mois de travail technique souligne les forces de l'infrastructure et de la culture d'ingénierie de Meta. Les produits de Meta s'appuient sur une infrastructure partagée qui a résisté à l'épreuve du temps, permettant aux équipes de produits d'avancer rapidement et de mettre à l'échelle des produits réussis. L'infrastructure se targue d'un niveau élevé d'automatisation, garantissant que, à l'exception des efforts visant à obtenir une capacité à court terme, la redistribution automatique, l'équilibrage de la charge et la mise à l'échelle des charges de travail s'effectuent sans heurts et de manière transparente. Meta s'appuie sur une culture d'ingénierie rapide, dans laquelle les ingénieurs s'approprient fortement le projet et collaborent de manière transparente pour atteindre un objectif commun important, avec des processus efficaces qui prendraient des mois à être coordonnés par une organisation classique. Par exemple, la culture de gestion des incidents SEV a été un outil important pour les ingénieurs pour obtenir la bonne visibilité, l'attention et l'action dans les endroits où ils avaient tous besoin de coordonner et d'agir rapidement. Dans l'ensemble, ces facteurs se sont combinés pour assurer le succès du lancement de Threads.
Source : Laine Campbell et Chunqiang (CQ) Tang, Meta
Et vous ?
Quel est votre avis sur le sujet ?Voir aussi :
Threads a attiré plus de 30 millions d'utilisateurs en 24 heures qui y ont publié plus de 95 millions de messages, malgré des défauts de conception et des problèmes de confidentialité Threads, l'alternative à X, débarque enfin sur le web : cette version ne dispose pas encore de toutes les fonctionnalités sur mobile, comme éditer son profil ou envoyer un message privé Threads atteint les 100 millions d'utilisateurs en 5 jours, devenant l'application à la croissance la plus rapide de tous les temps. Il a fallu deux mois à ChatGPT pour atteindre ce cap 
