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...
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.
