Aperçu et enseignements sur l’infrastructure hyperscale de Meta

• La culture d’ingénierie de Meta met l’accent sur l’exécution rapide, l’ouverture technologique, la recherche en production et l’infrastructure partagée
• Pour améliorer la productivité des développeurs, l’entreprise a adopté le déploiement continu et permet à davantage de développeurs d’écrire des fonctions serverless plutôt que du code de service traditionnel
• Pour réduire les coûts matériels, elle s’appuie sur la co-conception matériel-logiciel à l’échelle des data centers et optimise automatiquement l’allocation des ressources entre les data centers du monde entier, sans se limiter à des clusters individuels
• La stratégie IA de Meta repose sur la co-conception de l’ensemble de la stack, de PyTorch aux accélérateurs IA, aux réseaux et aux modèles de ML comme Llama

# [Culture d’ingénierie]

Exécuter vite (Move Fast)

• Meta maintient une culture du « move fast » qui met l’accent sur l’agilité et les itérations rapides
• L’entreprise soutient fortement le déploiement continu (Continuous Deployment) afin de mettre en production le code le plus récent aussi vite que possible
• Les ingénieurs produit écrivent des fonctions serverless stateless dans des langages comme PHP, Python et Erlang
• Les priorités peuvent être modifiées sans long processus de planification, et les problèmes incertains sont résolus par une exécution itérative
• Cette approche permet une réponse rapide au marché et des lancements de produits accélérés

Ouverture technologique (Technology Openness)

• Ouverture interne : l’entreprise utilise une approche monorepo pour stocker le code de tous les projets dans un dépôt unique
  • Cela facilite la recherche de code, sa réutilisation et la collaboration entre équipes
  • Dans la plupart des projets, il n’existe pas de restrictions strictes de propriété du code, ce qui permet aux développeurs de contribuer librement
• Ouverture externe : Meta partage activement des projets open source matériels et logiciels
  • L’entreprise publie ses designs matériels via l’Open Compute Project
  • Elle maintient divers projets logiciels open source comme PyTorch, Llama, Presto, RocksDB et Cassandra
  • Elle partage également ses technologies d’infrastructure à travers des articles de recherche

Recherche en production (Research in Production)

• Meta mène ses recherches dans l’environnement réel d’exploitation, sans laboratoire systèmes dédié
• Les équipes qui développent les systèmes de production rédigent elles-mêmes les articles de recherche afin de résoudre des problèmes réels et de proposer des solutions validées dans des environnements opérationnels à grande échelle
• Cette approche est pragmatique et répond aux critères fondamentaux d’une recherche systèmes réussie

Infrastructure commune (Common Infrastructure)

• Plutôt que de laisser chaque équipe choisir librement sa stack technologique, Meta privilégie la standardisation et l’optimisation globale
• Matériel :
  • Tous les serveurs sont alloués à partir d’un pool de serveurs partagé
  • Pour les workloads de calcul non IA, un seul type de serveur est proposé (par défaut 1 CPU, 256 Go de DRAM), ce qui réduit la complexité des types de serveurs
• Logiciel :
  • L’entreprise utilisait auparavant divers stores clé-valeur comme Cassandra, HBase et ZippyDB, mais a désormais convergé vers ZippyDB
  • Le déploiement logiciel, la gestion de configuration, le service mesh, les tests de performance, etc. sont unifiés au sein d’outils communs
• Préférence pour les composants réutilisables :
  • Meta a construit une chaîne de réutilisation de composants composée de Tectonic (système de fichiers) → ZippyDB (stockage des métadonnées) → Shard Manager (gestion du sharding des données) → ServiceRouter (découverte des shards et routage des requêtes) → Delos (store de données hautement fiable)
  • Au lieu de systèmes monolithiques comme HDFS, l’entreprise utilise des composants modulaires et réutilisables pour maximiser la scalabilité

Étude de cas culturelle : développement de l’app Threads (Culture Case Study: The Threads App)

• Le cas du développement de Threads illustre bien la culture d’ingénierie de Meta
• Les travaux techniques ont été achevés en à peine cinq mois, et après une préannonce faite deux jours avant, l’équipe infrastructure a finalisé la préparation du déploiement en production
• Dans la plupart des grandes entreprises, il est déjà difficile de rédiger un document de plan projet en deux jours. Mais chez Meta, une war room a été mise en place pour résoudre les problèmes en temps réel et permettre une réponse rapide
• Résultat : 100 millions d’utilisateurs en cinq jours après le lancement, faisant de Threads l’application à la croissance la plus rapide de l’histoire
• Threads a pu monter en charge rapidement en réutilisant l’infrastructure existante :
  • Le backend Python d’Instagram
  • L’infrastructure partagée de Meta (base de données du graphe social, store clé-valeur, plateforme serverless, plateforme ML, gestion de configuration des apps mobiles, etc.)
• Ouverture interne : l’utilisation du monorepo a permis de réutiliser une partie du code d’Instagram et d’accélérer le développement
• Ouverture externe : l’application vise l’interopérabilité avec d’autres apps grâce à ActivityPub
• Partage de l’expérience de développement : Meta a partagé publiquement son expérience de développement et de déploiement rapide

# [Flux de requête utilisateur de bout en bout (End-to-End User Request Flow)]

• Pour examiner en profondeur les technologies d’infrastructure de Meta, le document explique l’ensemble du processus de traitement d’une requête utilisateur
• Les produits de Meta s’appuient sur une infrastructure de services partagée, qui comprend divers composants clés

Routage des requêtes (Request Routing)

• Mappage DNS dynamique (Dynamic DNS Mapping)
  • Lorsqu’un utilisateur accède à facebook.com, le serveur DNS de Meta renvoie dynamiquement l’adresse IP du PoP (Point of Presence) le plus proche
  • Un PoP est un mini data center edge qui répartit la charge réseau à proximité des utilisateurs
  • Le PoP maintient des connexions TCP longue durée avec les data centers de Meta, ce qui réduit le temps d’établissement des connexions TCP et améliore les performances réseau
  • Des centaines de PoP sont déployés dans le monde, offrant à la plupart des utilisateurs une faible latence réseau
• Mise en cache du contenu statique (Static-Content Caching)
  • Les contenus statiques, comme les images et les vidéos, sont mis en cache au niveau du PoP et peuvent être servis directement
  • Meta exploite également un CDN (Content Delivery Network) et collabore avec des FAI (fournisseurs d’accès à Internet) pour déployer des sites CDN
  • Si la requête d’un utilisateur est facebook.com/image.jpg, Meta la réécrit en CDN109.meta.com/image.jpg afin de servir le contenu depuis le site CDN le plus proche
  • Si le contenu n’est pas présent dans le CDN, la requête est transmise selon le chemin PoP → load balancer du data center → système de stockage
• Routage des requêtes de contenu dynamique (Dynamic-Content Request Routing)
  • Les requêtes de contenu dynamique, comme le fil d’actualité, sont transmises du PoP vers un data center
  • Des outils de traffic engineering sélectionnent le data center optimal en tenant compte de la capacité du data center et de la latence réseau
  • Le trafic entre le PoP et le data center est transmis via le WAN privé (réseau étendu) de Meta
  • Le trafic entre data centers est bien plus important que le trafic utilisateur-PoP, en raison de la réplication des données et des interactions entre microservices

Topologie de l’infrastructure (Infrastructure Topology)

• L’infrastructure mondiale de Meta est composée de plusieurs couches de composants d’infrastructure
• Chaque composant remplit un rôle spécifique et fonctionne à l’échelle suivante :
  • Régions de datacenters (Region) : il existe environ 10 régions de datacenters dans le monde, et chaque région peut exploiter jusqu’à 1 million de serveurs
  • PoP (Point of Presence, datacenter edge) : il existe plus de 100 PoP, chacun comprenant généralement 100 à 1 000 serveurs. Ils traitent le trafic à proximité des utilisateurs afin de réduire la latence
  • Sites CDN : il existe plus de 1 000 sites CDN, comprenant généralement au moins 10 serveurs, et certains grands sites exploitent plus de 100 serveurs. Ils mettent en cache les contenus statiques (images, vidéos, etc.) afin de les fournir rapidement
  • Datacenter : chaque région de datacenters comprend plusieurs datacenters, et chaque datacenter peut exploiter environ plus de 100 000 serveurs
  • MSB (Main Switchboard) : un datacenter peut compter jusqu’à 12 MSB, et chaque MSB prend en charge 10 000 à 20 000 serveurs. Ils assurent la distribution électrique et constituent un domaine majeur de panne dans le datacenter. Si un MSB tombe en panne, jusqu’à 20 000 serveurs peuvent être arrêtés
• Réseau edge :
  • Les PoP sont connectés à plusieurs systèmes autonomes (AS) Internet et utilisent BGP (Border Gateway Protocol) pour sélectionner le meilleur chemin
• Réseau de datacenter :
  • Les serveurs sont connectés via une topologie Clos à 3 niveaux
  • Le réseau est conçu pour éviter la congestion et fournir une bande passante maximale entre les serveurs
• Réseau régional :
  • Les datacenters sont reliés par des fabric aggregators, ce qui leur permet de communiquer avec le WAN
  • Utilise une topologie Fat-Tree pour permettre une montée en charge progressive

Traitement des requêtes (Request Processing)

• Traitement en ligne (Online Processing)
  • Les requêtes des utilisateurs sont réparties par des load balancers vers des dizaines de milliers de fonctions frontend serverless (FrontFaaS)
  • Les fonctions frontend peuvent appeler plusieurs services backend, y compris des services d’inférence ML (par exemple, les recommandations publicitaires et les recommandations de contenu du fil d’actualité)
  • Pendant l’exécution, les fonctions frontend ajoutent des événements à une file d’événements, afin que des fonctions serverless pilotées par événements (XFaaS) s’exécutent de manière asynchrone
  • Le ratio de serveurs entre les fonctions frontend et les fonctions pilotées par événements est d’environ 5:1
• Traitement hors ligne (Offline Processing)
  • Le système de traitement hors ligne complète le système en ligne en réalisant l’analyse de données et l’entraînement de modèles de machine learning
  • Les fonctions frontend et les services backend stockent divers journaux de données dans le data warehouse
    • Entraînement ML : les données de logs sont utilisées pour mettre à jour les modèles de machine learning
    • Traitement de flux : met à jour les sujets les plus discutés sur le site et les stocke dans les bases de données et les caches
    • Analyse batch : utilise Spark et Presto pour mettre à jour le système de recommandation d’amis
    • Exécution de fonctions serverless pilotées par événements : les mises à jour de données servent de déclencheurs d’événements et lancent automatiquement les fonctions serverless

# [Améliorer la productivité des développeurs (Boosting Developer Productivity)]

• L’infrastructure partagée de Meta vise à maximiser la productivité des développeurs
• Pour cela, l’entreprise pousse le déploiement continu (Continuous Deployment) et les fonctions serverless (Serverless Functions) à l’extrême

Déploiement continu (Continuous Deployment)

• Meta est optimisée pour déployer rapidement les changements de code et de configuration (Configuration)
• Les nouvelles fonctionnalités et les correctifs sont déployés immédiatement, ce qui permet un retour rapide et des améliorations itératives
• Modifications de configuration (Configuration Changes)
  • L’outil de gestion de configuration de Meta déploie chaque jour plus de 100 000 changements en temps réel en production
  • La configuration est automatiquement mise à jour sur plus de 10 000 services et des millions de serveurs
  • Diverses opérations sont automatisées, notamment le load balancing, le déploiement progressif de fonctionnalités, les tests A/B et la prévention de surcharge
  • Les changements de configuration sont revus comme des changements de code puis commités dans le dépôt de code, et les changements sont propagés à l’ensemble du système en quelques secondes
• Changements de code (Code Changes)
  • L’outil de déploiement de Meta exploite plus de 30 000 pipelines de déploiement pour gérer les mises à jour logicielles
  • 97 % des services ont adopté des déploiements entièrement automatisés, sans intervention manuelle :
    • 55 % utilisent le déploiement continu complet (CD), où les changements de code sont automatiquement appliqués en production
    • 42 % sont déployés automatiquement selon un calendrier fixe (quotidien ou hebdomadaire)
  • Les fonctions frontend serverless (FrontFaaS) s’exécutent sur plus de 500 000 serveurs, et plus de 10 000 développeurs effectuent chaque jour des milliers de commits de code
  • Même dans un environnement aussi dynamique, de nouvelles versions de toutes les fonctions serverless sont déployées en production toutes les 3 heures
• Mises à jour des logiciels réseau et d’infrastructure
  • Le WAN privé (Private WAN) de Meta maintient plusieurs plans réseau parallèles, ce qui permet de tester indépendamment de nouveaux algorithmes réseau
  • Le logiciel des switchs réseau est lui aussi fréquemment mis à jour, et grâce à la fonctionnalité "Warm Boot" des switchs, le logiciel peut être mis à jour sans interrompre le trafic réseau
  • Comme les changements fréquents de code et de configuration augmentent le risque de pannes de site, Meta investit massivement dans les tests, les déploiements progressifs et les health checks
    • Une campagne interne a été menée pour faire passer l’automatisation des déploiements de code de 12 % à 97 %
    • Des tests Canary automatiques sont réalisés pour chaque changement de configuration afin de garantir la stabilité

Fonctions serverless (Serverless Functions)

• Les fonctions serverless (ou FaaS, Function-as-a-Service) constituent un autre élément clé pour améliorer la productivité des développeurs
• Contrairement aux services backend traditionnels, les fonctions serverless n’enregistrent pas d’état et implémentent une simple interface de fonction
• Chaque invocation de fonction s’exécute de manière indépendante, et l’état est géré via des bases de données externes ou des systèmes de cache
• Avantages des fonctions serverless
  • Les développeurs n’ont qu’à écrire la logique produit sans gérer l’infrastructure
  • Le déploiement du code et l’auto-scaling en fonction des variations de charge sont effectués automatiquement
  • Elles évitent le gaspillage matériel et dispensent les développeurs de surallouer des ressources
• La plateforme serverless de Meta
  • Chez Meta, parmi plus de 10 000 développeurs, ceux qui écrivent des fonctions serverless sont 50 % plus nombreux que ceux qui écrivent du code de services traditionnels
  • L’environnement de développement serverless (IDE) de Meta facilite l’accès à la base de données du graphe social et à divers systèmes backend, et fournit des tests d’intégration continue (CI) pour permettre un feedback rapide
• La plateforme serverless de Meta : FrontFaaS et XFaaS
  • FrontFaaS : fonctions serverless frontend basées sur PHP, exécutées sur plus de 500 000 serveurs
    • En maintenant en permanence le runtime PHP, elles peuvent traiter immédiatement les requêtes sans problème de cold start
    • Lorsque la charge serveur est faible, l’auto-scaling libère une partie des serveurs afin de les réaffecter à d’autres tâches
  • XFaaS : fonctions serverless événementielles exécutées de manière asynchrone
    • Elles gèrent les tâches de fond qui ne nécessitent pas de réponse immédiate
    • Afin d’éviter les tâches à forte charge, elles peuvent retarder l’exécution ou appliquer un équilibrage de charge global et un throttling basé sur des quotas
• Les innovations serverless de Meta
  • Depuis la fin des années 2000, Meta utilise l’approche serverless comme paradigme de développement par défaut
  • Différences avec les plateformes serverless de cloud public :
    • Les clouds publics utilisent une machine virtuelle par fonction afin d’assurer une forte isolation
    • À l’inverse, Meta a conçu son système pour permettre l’exécution simultanée de plusieurs fonctions dans un même processus Linux, afin de maximiser l’efficacité matérielle

# [Réduction des coûts matériels (Reducing Hardware Costs)]

• L’infrastructure partagée de Meta joue un rôle important non seulement pour améliorer la productivité des développeurs, mais aussi pour réduire les coûts matériels
• Pour cela, Meta utilise une stratégie consistant à maximiser l’efficacité matérielle grâce à l’optimisation logicielle

Exploiter tous les datacenters mondiaux comme un seul ordinateur (All Global Datacenters as a Computer)

• Dans les environnements cloud traditionnels, les utilisateurs devaient eux-mêmes configurer le nombre de réplicas de service, les régions de déploiement, etc.
• Cette gestion manuelle entraînait des problèmes tels que le gaspillage de ressources, le déséquilibre de charge et le manque de migrations entre datacenters
• Meta a fait évoluer son approche initiale consistant à « exploiter un datacenter comme un ordinateur » (DaaC, Datacenter as a Computer) pour mettre en œuvre Global-DaaC, c’est-à-dire « exploiter les datacenters du monde entier comme un seul ordinateur »
• Principales caractéristiques de Global-DaaC :
  • Il suffit à l’utilisateur de demander un déploiement global, et l’infrastructure détermine automatiquement le nombre optimal de réplicas, les régions de déploiement, le type de matériel et le routage du trafic
  • L’infrastructure peut modifier l’emplacement des services selon les besoins et s’adapter aux variations d’offre comme de charge
  • Contrairement au cloud public, Meta exploite elle-même toutes ses applications, ce qui lui permet de déplacer les workloads avec davantage de flexibilité
• Méthode de mise en œuvre de Global-DaaC
  • Automatisation de l’allocation des ressources aux niveaux global, régional et du serveur individuel :
    • Outil global de gestion de capacité : analyse les dépendances entre services à l’aide du traçage RPC et détermine la répartition optimale de capacité via la programmation linéaire en nombres entiers mixtes (MIP)
    • Outil régional de gestion de capacité : alloue les ressources serveurs de chaque datacenter pour former des clusters virtuels (Virtual Cluster)
    • Outil de gestion des conteneurs : place les conteneurs dans les clusters virtuels et les répartit sur plusieurs datacenters afin d’assurer la tolérance aux pannes (fault tolerance)
    • Techniques de gestion du noyau : partagent et isolent de manière appropriée les ressources mémoire et I/O entre conteneurs
• Cas d’usage de Global-DaaC
  • Bases de données et services avec état :
    • Chaque conteneur héberge plusieurs shards de données afin de maximiser l’efficacité
    • Global Service Placer (GSP) détermine le nombre optimal de réplicas de shard ainsi que les régions de placement
    • Le framework de sharding s’appuie ensuite sur cela pour attribuer les shards aux conteneurs et les migrer dynamiquement
  • Workloads de machine learning (ML) :
    • Les tâches d’inférence ML gèrent les réplicas de modèles comme des shards de données
    • Pour l’entraînement ML, les données et les GPU doivent être placés dans le même datacenter
    • Après attribution de la capacité GPU mondiale, le scheduler d’entraînement ML réalise la réplication optimale des données et le placement des GPU

Co-conception matériel-logiciel (Hardware and Software Co-Design)

• Appliquer la co-conception matériel-logiciel (Co-Design) à l’échelle d’un serveur unique est courant, mais Meta l’a étendue à l’échelle mondiale pour surmonter les limites d’un matériel à bas coût grâce à l’optimisation logicielle
• Tolérance aux pannes à bas coût (Low-Cost Fault Tolerance)
  • Les clouds publics fournissent un matériel à haute disponibilité, mais Meta a adopté une approche consistant à surmonter les pannes par le logiciel, ce qui permet d’utiliser du matériel moins coûteux
  • Principales différences :
    • Les racks serveur des clouds publics utilisent une double alimentation et des commutateurs ToR (Top-of-Rack) redondants, tandis que Meta utilise une alimentation unique et un seul commutateur ToR
    • Les machines virtuelles (VM) des clouds publics utilisent un stockage bloc connecté au réseau, ce qui permet la migration à chaud, alors que les conteneurs de Meta utilisent des SSD locaux à bas coût
  • Stratégies logicielles de gestion des pannes :
    • Outils d’allocation de ressources : ils répartissent les conteneurs d’un service et les shards de données sur différents domaines de panne au sein du datacenter
    • Protocoles de coordination : ils permettent aux applications d’intervenir dans la gestion du cycle de vie des conteneurs afin de protéger les répliques de shards de données contre des interruptions simultanées
    • Garantie de durabilité multi-datacenter : le système est conçu pour maintenir le service même si une région entière tombe en panne, avec des tests en conditions réelles effectués régulièrement pour valider la fiabilité
• Réduction du coût des proxys de routage (Eliminating Routing Proxy Costs)
  • Les service meshes traditionnels utilisent des proxys sidecar (Sidecar Proxy) pour router les requêtes RPC, mais Meta traite 99 % des requêtes RPC via un routage direct client-serveur
  • Cette méthode permet d’économiser environ 100 000 serveurs proxy
  • Cela pose toutefois le défi de compiler et déployer la bibliothèque de routage dans plus de 10 000 services, mais Meta le résout grâce à ses outils de déploiement logiciel et de gestion de configuration
• Stockage hiérarchisé et usage des SSD locaux (Tiered Storage and Local SSDs)
  • Le stockage est différencié selon la fréquence d’accès aux données et les exigences de latence afin de maximiser l’efficacité des coûts :
    • Données chaudes (Hot Data) : stockées en mémoire et sur SSD (ex. : base de données du graphe social)
    • Données tièdes (Warm Data) : stockées dans un système de fichiers distribué basé sur HDD (ex. : vidéos, images, données de logs)
    • Données froides (Cold Data) : stockées sur des serveurs HDD de grande capacité (ex. : anciennes vidéos haute résolution)
      • Maintenues en mode basse consommation pour réduire les coûts
  • Utilisation de SSD locaux :
    • Pour certaines charges de travail, les SSD locaux offrent de meilleures performances qu’un stockage distant partagé (Remote Storage)
    • Mais il existe un risque de faible taux d’utilisation des SSD en raison d’une répartition déséquilibrée de la charge
    • Meta utilise son framework commun de sharding pour résoudre ce problème de déséquilibre et maximiser l’efficacité des SSD

Conception matérielle interne (In-House Hardware Design)

• Meta conçoit en interne ses datacenters, serveurs, commutateurs réseau et puces d’IA pour des raisons de coût et d’efficacité énergétique
• Comme l’électricité est la ressource la plus contrainte dans un datacenter, l’entreprise exploite des outils d’automatisation pour optimiser la consommation électrique
• La co-conception matériel-logiciel permet de réduire les coûts et la consommation d’énergie :
  • Optimisation de l’usage de la SRAM sur les puces d’IA
  • Suppression des équipements de refroidissement à compression dans les datacenters
• Meta développe également ses propres commutateurs réseau et logiciels, ce qui permet des mises à jour régulières, et partage en open source la plupart de ses conceptions matérielles via l’Open Compute Project

# [Concevoir des systèmes scalables (Designing Scalable Systems)]

• Dans une infrastructure hyperscale, la conception de systèmes scalables est un élément central
• Les systèmes distribués conçus pour l’environnement Internet (BGP, BitTorrent, DHT, etc.) offrent une excellente scalabilité, mais dans un environnement de datacenter, des contrôleurs centralisés peuvent fournir une meilleure scalabilité et une plus grande efficacité

Abandon des contrôleurs décentralisés (Deprecating Decentralized Controllers)

• Meta a choisi de passer de contrôleurs décentralisés existants à des contrôleurs centralisés
• À l’exception des commutateurs réseau, qui conservent BGP, le système est conçu pour qu’un contrôleur central puisse redéfinir les routes en cas de congestion du trafic ou de panne de lien
• Les contrôleurs centralisés permettent un meilleur équilibrage de charge et une réponse plus rapide aux pannes, ce qui les rend plus adaptés à l’environnement des datacenters

Exemples de transition de systèmes distribués existants vers une architecture centralisée

• WAN privé (Private WAN)
  • Le système utilisait auparavant RSVP-TE (établissement de routes distribué), mais a été remplacé par un système fondé sur un contrôleur central
  • Celui-ci calcule automatiquement les chemins de trafic optimaux et préconfigure des chemins de secours en cas de panne, permettant une restauration rapide
• Magasin clé-valeur (Key-Value Store)
  • Le système est passé d’un routage multi-sauts fondé sur une DHT (table de hachage distribuée) à un framework de sharding piloté par contrôleur central
  • Le contrôleur central ajuste dynamiquement le repositionnement des shards pour optimiser l’équilibrage de charge
• Distribution de données à grande échelle
  • Le système utilisait auparavant BitTorrent (téléchargement P2P distribué), mais a migré vers Owl, le système de distribution centralisé de Meta
  • Le choix centralisé des chemins de téléchargement permet des vitesses de téléchargement nettement supérieures
• Distribution de métadonnées de petite taille
  • Au départ, une structure arborescente distribuée à trois niveaux (basée sur Java) était utilisée, puis, en raison de problèmes de scalabilité, elle a été remplacée par une structure en arbre fondée sur le P2P
  • Mais les performances instables de certains nœuds dégradaient les performances globales, ce qui a finalement conduit à un retour vers une architecture de serveurs proxy centralisés haute performance en C++

Étude de cas : un service mesh scalable (Scalable Service Mesh)

Meta exploite son propre service mesh appelé ServiceRouter,
et ce système démontre l’efficacité d’une architecture centralisée scalable.

• Problèmes de l’architecture de service mesh existante
  • Dans un service mesh classique, chaque processus de service route les requêtes RPC via un proxy sidecar L7 (Sidecar Proxy)
  • Mais dans un environnement hyperscale, il est inefficace pour un contrôleur central de gérer directement des millions de proxys sidecar
  • Meta a donc remplacé l’approche par proxy sidecar par une architecture dans laquelle le service lui-même gère le routage
• Architecture ServiceRouter de Meta
  • Les métadonnées de routage sont générées par le contrôleur central, mais chaque routeur L7 construit lui-même sa table de routage
  • Une base de données fondée sur Paxos (RIB, Routing Information Base) est utilisée pour garantir la scalabilité
    • Les contrôleurs sont shardés pour répartir la charge, et plusieurs contrôleurs peuvent calculer en parallèle les tables de routage d’un service donné
  • La couche de distribution (Distribution Layer) s’appuie sur des milliers de réplicas du RIB pour traiter les requêtes de lecture provenant de millions de routeurs L7
  • Au final, chaque routeur L7 peut être configuré de manière autonome sans intervention directe du contrôleur central
• Comment ServiceRouter atteint la scalabilité
  1. Adoption de contrôleurs stateless : les contrôleurs ne gèrent pas directement des routeurs spécifiques, ils maintiennent simplement des informations de routage globales
  2. Sharding des contrôleurs : plusieurs contrôleurs fonctionnent indépendamment les uns des autres et peuvent traiter en parallèle les informations de routage de services différents
  3. Suppression des fonctions non essentielles : les fonctions de gestion des routeurs L7 individuels ont été retirées du contrôleur, chaque routeur étant conçu pour se gérer lui-même
• Résultats et enseignements
  • Une architecture combinant contrôleur centralisé et data plane distribué offre une scalabilité optimale
  • La suppression des proxys sidecar inutiles permet d’optimiser les coûts d’exploitation et les performances
  • Un sharding stratégique et une conception stateless permettent de gérer efficacement le routage de millions de services

# [Perspectives d’avenir (Future Directions)]

• L’infrastructure hyperscale de Meta est extrêmement complexe, mais ce document en propose un résumé des principaux enseignements techniques
• Enfin, il partage des perspectives sur les tendances futures de l’infrastructure hyperscale

IA (intelligence artificielle)

• Les workloads d’IA sont désormais les workloads les plus importants dans les datacenters
• D’ici 2030, plus de la moitié de la consommation électrique des datacenters devrait être consacrée aux workloads d’IA
• En raison de réseaux hautes performances et d’une consommation élevée de ressources, l’IA est susceptible de transformer en profondeur les architectures d’infrastructure existantes
• Par le passé, l’infrastructure hyperscale a évolué selon une approche scale-out (déploiement massif de serveurs à faible coût), mais
  les futurs clusters d’IA pourraient évoluer vers une approche scale-up (architecture de supercalculateur)
  • Exemple : utilisation de réseaux Ethernet basés sur RDMA (Remote Direct Memory Access), optimisés pour l’entraînement de machine learning (ML) à grande échelle
• Meta travaille actuellement sur une co-conception full stack, allant de PyTorch → modèles de ML → puces IA → réseau → datacenter → serveurs → stockage → alimentation électrique et refroidissement

Matériel spécialisé par domaine (Domain-Specific Hardware)

• Dans les années 2000, le matériel est devenu de plus en plus standardisé, mais
  à l’avenir, on devrait voir se multiplier les matériels spécialisés pour l’entraînement/l’inférence IA, la virtualisation, l’encodage vidéo, le chiffrement, la compression, la mémoire hiérarchique, etc.
• Les entreprises hyperscale peuvent concevoir et déployer du matériel sur mesure de manière économiquement viable grâce à la production de masse
• Cependant, cette diversification accrue du matériel augmentera la complexité de la stack logicielle et posera de nouveaux défis pour gérer des environnements hétérogènes

Datacenters en périphérie (Edge Datacenters)

• Avec la montée du métavers (Metaverse) et des applications IoT, une expansion des datacenters en périphérie est attendue
• Le cloud gaming effectue le rendu graphique non pas sur l’appareil de l’utilisateur, mais sur des serveurs GPU situés dans des datacenters en périphérie, et
  une faible latence réseau inférieure à 25 ms est indispensable
• Avec la hausse des applications où la réactivité en temps réel est cruciale, le nombre et la taille des datacenters en périphérie pourraient fortement augmenter
• Pour les exploiter efficacement, il sera nécessaire d’étendre le concept de Global-DaaC (opérer les datacenters du monde entier comme un seul ordinateur) afin d’optimiser l’infrastructure de sorte que les développeurs n’aient pas à se soucier de sa complexité

Amélioration de la productivité des développeurs (Developer Productivity)

• Au cours des 20 dernières années, les outils d’automatisation ont fortement amélioré la productivité des administrateurs système, augmentant rapidement le nombre de serveurs gérés par administrateur
• Cependant, le développement logiciel reste largement intensif en main-d’œuvre et les gains de productivité y progressent lentement
• À l’avenir, la productivité des développeurs devrait augmenter fortement sous l’effet de deux facteurs :
  1. le progrès des outils de génération de code et de débogage basés sur l’IA
  2. l’émergence de paradigmes de programmation serverless entièrement intégrés et spécialisés par domaine
• Le FrontFaaS de Meta est un exemple de cette approche serverless, et
  de nouveaux paradigmes de programmation optimisés pour certains secteurs (par exemple la finance, la santé, etc.) devraient apparaître à l’avenir

Conclusion

• L’innovation en matière d’infrastructure, portée par l’IA, va progresser rapidement au cours des dix prochaines années
• Les entreprises hyperscale doivent partager leurs enseignements afin de permettre à l’ensemble de la communauté de progresser plus vite

[secret3056]

Ce PoP, c’est du BGP4 ou du TCP anycast, et il n’y a probablement aucun moyen pour un particulier de l’utiliser, si ?.. snif

[pribess]

Je ne comprends pas très bien ce que signifie exactement l’affirmation selon laquelle le PoP serait du BGP4 ou du TCP anycast, mais si la question est de savoir s’ils exploitent leur propre AS, alors oui.
En général, les services multi-région classiques utilisent plus souvent un équilibrage basé sur la géolocalisation, en complément d’un DNS anycast.
Non, il n’y en a pas à l’heure actuelle. Si vous avez besoin d’un PoP multi-région, il faudra utiliser un autre fournisseur.

[GN⁺]

Commentaire Hacker News

• Après le développement de Threads, l’équipe infrastructure n’a reçu que deux jours de préavis pour se préparer au lancement. Dans la plupart des grandes organisations, il faut plus de deux jours rien que pour rédiger un plan de projet impliquant des dizaines d’équipes interdépendantes. Chez Meta, ils ont pourtant rapidement mis en place des war rooms sur des sites distribués afin que les équipes infrastructure et produit résolvent les problèmes en temps réel. L’application a atteint 100 millions d’utilisateurs cinq jours après son lancement, devenant l’application à la croissance la plus rapide de l’histoire

• Il est impressionnant qu’ils parviennent à conserver cette capacité à lancer des produits rapidement. Cela demande beaucoup d’efforts pour éviter que la bureaucratie n’augmente et que l’équipe juridique ou d’autres services n’instaurent des barrières d’approbation. Ou alors il faut être capable de faire avancer les choses très vite grâce à des war rooms

• Quand j’étais chez FB, j’ai constaté à quel point l’infrastructure était puissante. Les ingénieurs produit construisaient des projets massifs en quelques jours. J’ai travaillé comme tech lead dans plusieurs équipes, dont certaines mentionnées ici, comme les équipes HBase et ZippyDB

• C’est génial de voir ZippyDB mentionné publiquement pour la première fois. C’est aussi très cool que l’amélioration de l’efficacité des développeurs soit évoquée. Chaque jour, 10 000 services sont déployés ou chaque commit est intégré

• Après avoir quitté FB, je n’ai rien trouvé de comparable. Alors je construis, dans ma startup, l’infrastructure dont j’avais besoin. Batteries Included

• Je trouve dommage qu’il y ait autant de cynisme et de réactions négatives dans ces commentaires. Beaucoup de gens détestent Meta, mais l’article lui-même m’inspire de l’émerveillement. Je ne réalisais pas à quel point l’infrastructure qui soutient le monde numérique moderne est vaste et complexe. Lire cet article et voir cette échelle est stupéfiant

• L’entreprise peut être mauvaise à bien des égards, mais tout ce qui figure dans l’article m’émerveille

• Je ne suis pas ingénieur comme vous, donc cet article est peut-être de vieilles nouvelles pour vous, mais je n’ai pas pu m’empêcher de dire « wow »

• Si on montrait cet article aux auteurs de science-fiction du passé, je pense qu’eux aussi seraient émerveillés

• C’est stupéfiant. Toute cette technologie incroyable et impressionnante, ainsi que les meilleurs ingénieurs du monde, sont utilisés uniquement pour mettre encore plus de publicités sous les yeux des gens. Soupir

• Il est intéressant de décrire le frontend web en PHP comme une architecture « serverless » ou « function as a service ». C’est probablement une question de point de vue. C’est un service avec une base de code unique déployant de nombreux endpoints. Du point de vue des mainteneurs de ces endpoints, cela peut être « serverless », mais comme toutes les abstractions, il y a des fuites

• Dans un environnement de datacenter, je préfère les contrôleurs centralisés en raison de leur simplicité et de leur capacité à produire des décisions de haute qualité. Dans de nombreux cas, une approche hybride combinant un plan de contrôle centralisé et un plan de données distribué est la plus optimale

• Cette approche semble être l’une des conceptions les plus optimales pour le réseau logiciel (service mesh) et le stockage (opérations de base de données) dans les organisations disposant d’un très grand nombre de serveurs. Il est étonnant que le réseau IP suive le même modèle sans dépendre principalement de BGP

• On peut s’attendre à ce que l’utilisation du cache local réduise la charge sur les routeurs L7 et améliore la latence des requêtes de base de données. Les clients peuvent invalider le cache et interroger de nouveau le service mesh après un délai d’expiration raisonnable

• Des fonctions serverless développées rapidement combinées à un déploiement continu, avec la possibilité pour tout le monde de modifier l’ensemble de la base de code, cela ressemble à un cauchemar dystopique. Le volume de logs nécessaire pour déboguer et trouver les bugs doit être extrême

• Utiliser Erlang pour écrire des fonctions serverless semble éviter tous les grands avantages que BEAM peut apporter

• Les ingénieurs produit écrivent principalement du code en PHP, Python et Erlang sous forme de fonctions serverless sans état. Cela présente des avantages en matière de simplicité, de productivité et de vitesse d’itération

• Pour accroître la productivité des développeurs, Meta a adopté le déploiement continu de manière généralisée et permet à davantage de développeurs d’écrire des fonctions serverless plutôt que du code de service traditionnel

• Pour les charges de calcul non liées à l’IA, ils ne proposent qu’un seul type de serveur, avec un seul CPU et la même quantité de DRAM (64 Go auparavant, 256 Go aujourd’hui). Je me demande si c’est courant dans l’ensemble du secteur ou seulement chez Meta

• Lorsqu’une image n’est pas en cache sur CDN109 et qu’un utilisateur la demande, CDN109 transmet la requête à un PoP voisin. Le PoP transmet la requête au load balancer de la région du datacenter, et le load balancer récupère l’image depuis le système de stockage

• Lorsqu’on demande une image de 1 Mo, ne serait-il pas plus rapide, sur une connexion lente avec 100 ms de latence, de servir directement cette image de 1 Mo plutôt que de multiplier les allers-retours et d’augmenter encore la latence ?

• En supposant qu’on fasse la requête via les systèmes de Meta, qu’on finisse de toute façon dans le même datacenter, et en supposant qu’il n’existe pas de technologie FTL

• La comparaison explicite avec les hyperscalers est particulièrement intéressante. Je me demande s’ils se préparent à lancer leur propre cloud public. J’aimerais que quelqu’un de chez Meta donne son avis