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...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
