Meta indique qu'une « petite équipe » d'ingénieurs a suffi pour concevoir son réseau social Threads, en seulement cinq mois de travail. Sans donner encore trop de détails sur toutes les piles techniques qui ont été nécessaires pour sortir de terre ce concurrent de X, la maison mère de Facebook a cependant levé le voile sur deux piliers de son infrastructure, à savoir son data store ZippyDB ainsi que sa plateforme serverless Async.

ZippyDB est plus précisément une base de données clé/valeur distribuée fonctionnant comme un service entièrement managé sur lequel les ingénieurs peuvent s'appuyer, a expliqué Meta. Elle est conçue dès le départ pour tirer parti de son infrastructure 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 datacenters selon le groupe. « TAO, soutenu par MySQL, est utilisé pour le stockage de notre graphe social - vous pouvez donc trouver les messages et les réponses de Threads directement dans cette pile. ZippyDB est notre contrepartie clé/valeur de MySQL, la partie relationnelle de notre pile de données en ligne, et est utilisé pour les compteurs, le classement/état des flux, et la recherche », explique Meta.

La vitesse à laquelle Meta fait évoluer la capacité d'un espace-clé est rendue possible par deux caractéristiques : tout d'abord, le service fonctionne sur un pool commun de matériel et est intégré dans le framework de gestion capacitaire du groupe. « 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 », indique le fournisseur. « Nous pouvons absorber des milliers de nouvelles machines en l'espace de quelques heures une fois qu'elles sont ajoutées au service ». Cela n'est toutefois pas suffisant car le temps pour approuver la capacité, éventuellement la drainer à d'autres services et l'ajouter à ZippyDB, peut encore nécessiter quelques jours. « Nous devons également être en mesure d'absorber une surcharge dans un délai plus court », prévient Meta.

Data store Threads Meta

Avec son data store, le service peut évoluer de manière plus ou moins transparente, même face à une nouvelle demande soudaine et importante estime Meta concernant Threads. (crédit : Meta)

Pour que cette absorption soit immédiate, Meta s'appuie sur une architecture de service multi-tenant ayant de 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 craindre que leur niveau de service ne soit affecté lorsque d'autres charges de travail tournent à plein régime », poursuit Meta. « 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. Nous pouvons 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 ils sont relativement routiniers pour les opérations quotidiennes ». Résultat : le service peut évoluer de manière plus ou moins transparente, même face à une nouvelle demande soudaine et importante.

Async pour exécuter des workloads à l'échelle

Le deuxième pilier de l'infrastructure du réseau social de news et de discussions de Meta est Async. Egalement connu sous le nom de XFaaS, il s'agit d'une plateforme serverless capable de reporter le calcul aux heures creuses, donnant la possibilité aux ingénieurs de Meta de réduire leur temps entre la conception de la solution et le déploiement en production. « Async traite actuellement des milliards 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 », fait savoir Meta.

La plateforme fait ainsi 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 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é. D'après Meta, les workloads généralement exécutées sur Async sont ceux qui ne nécessitent pas de bloquer l'expérience d'un utilisateur actif avec un produit et peuvent être exécutées entre quelques secondes et 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 », poursuit l’entreprise. « 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 ».

Serverless

Async est capable d'absorber des workloads nombreux, les mettre en file d'attente et contrôler leur exécution. (crédit : Meta)

Alors que le volume des tâches Async générées par l'intégration rapide des utilisateurs de Threads était de plusieurs ordres de grandeur supérieur à nos attentes initiales, Async a été en capacité d'absorber la charge accrue et la mettre en file d'attente pour 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 », raconte Meta.