L'infrastructure qui soutient des expériences record

La capacité de Roblox à évoluer et à prendre en charge des dizaines de millions d'utilisateurs jouant ensemble à travers des millions d'expériences uniques n'est pas le résultat d'une seule innovation. C'est la somme d'une culture plus large de l'innovation et d'un millier de petites choses bien faites dans toute l'entreprise. C'est ainsi que nous avons construit l'infrastructure qui permet actuellement d'atteindre un trafic record pour de nombreuses expériences sur Roblox. Une de ces expériences, Grow a Garden, a récemment battu le record Guinness World Records® du plus grand nombre de joueurs simultanés dans un jeu vidéo, avec 21,6 millions d'utilisateurs jouant en même temps. Et dans la foulée, la plateforme Roblox a continué à atteindre de nouveaux records de fréquentation (comme elle l'a fait pendant près de deux décennies), dépassant récemment les 30 millions de joueurs simultanés.

Roblox fait face à des défis uniques dans la construction et la maintenance d'infrastructures pour des millions d'expériences créées par des créateurs, y compris Dress to Impress, Adopt Me, et Dead Rails, nécessitant des méthodologies d'ingénierie innovantes. La plateforme prend en charge des dizaines de mises à jour horaires et plus de 30 millions d'utilisateurs simultanés avec une infrastructure qui s'échelonne lors de pics de trafic inattendus. Cette infrastructure doit supporter des situations de rassemblement tonitruant où plus de 21 millions d'utilisateurs rejoignent simultanément une même expérience (et le code de mise à jour provient de créateurs indépendants). Les ingénieurs de Roblox innovent des solutions en remettant en question la sagesse traditionnelle des solutions qui s'inspirent de nos quatre valeurs fondamentales.

Les ingénieurs de Roblox gèrent 24 centres de données périphériques dans le monde entier, qui font fonctionner les serveurs du jeu. Lorsqu'un utilisateur participe à une expérience, il est mis en relation avec le centre de données le plus proche et l'instance la plus appropriée au sein du centre afin de minimiser les temps de latence. Nous gérons également deux centres de données principaux, qui sont beaucoup plus grands et qui exploitent des services centralisés comme le site Web, les algorithmes de recommandation, les filtres de sécurité, l'économie virtuelle et la plateforme de publication, qui sont nécessaires au fonctionnement des centres de données périphériques. Un réseau privé mondial interconnecte tous les centres de données des bords aux centres de données principaux, avec des centres de données de bord servant de pare-feu pour protéger les services fonctionnant dans le centre de données central.

Dans un monde idéal, nos créateurs ne devraient jamais avoir à se soucier de la capacité - l'infrastructure devrait leur être invisible, travaillant en arrière-plan. Lorsqu'un créateur publie une expérience sur Roblox, notre travail consiste à soutenir la capacité nécessaire, quel que soit le nombre de joueurs qui se présentent. Au début, nous planifions la capacité une fois par an pour l'année ou les deux années à venir. Mais ces dernières années, des expériences réussies comme Dress to Impress, Fisch, Dead Rails, et Grow a Garden nous ont amenés à repenser notre cadre de planification des capacités.

Conformément à notre valeur de vision à long terme, nous prévoyons maintenant les besoins en capacité jusqu'à deux ans à l'avance, en équilibrant la demande des utilisateurs et l'utilisation efficace des serveurs. Notre cycle de planification comprend l'acquisition de centres de données, le rafraîchissement du matériel serveur et la mise en réseau physique, les nouveaux centres de données comme celui du Brésil étant planifiés des années à l'avance. L'équipe de mise en réseau maintient également une capacité « sombre » pour garantir un fonctionnement continu malgré des problèmes tels que des coupures de câbles réseau.

La capacité de Roblox aujourd'hui est basée sur des prévisions faites il y a deux ans, lorsque nous n'aurions pas pu prédire que des expériences passeraient d'un inconnu à une immense popularité en quelques semaines. Les jeux populaires comme Grow a Garden et Dress to Impress, qui ont plus que doublé le nombre de joueurs simultanés, passant de 13,9 millions en avril à 30,6 millions en juin 2025, n'existaient pas lorsque ces prévisions de capacité ont été faites. Par exemple, en mars 2025, Dead Rails a connu un pic à 1 million d'utilisateurs simultanés, utilisant toute la capacité disponible de l'unité centrale. ;

En apprenant de ces types de pics de popularité, nous sommes passés à un cycle de planification plus agile. Pour soutenir constamment le nombre record de joueurs sur Roblox, l'ingineering emploie un cycle hebdomadaire rigoureux de planification, de test et d'ajustement de la capacité. Le lundi est consacré à l'examen des incidents, suivi de la planification des capacités le mardi. Tout au long de la semaine, il y a un chaos continu des tests. Le jeudi est consacré à l'examen des capacités pour toute mise à jour importante à laquelle nos créateurs nous ont dit de nous attendre. Le vendredi, des ressources cloud supplémentaires sont provisionnées pour que la plateforme soit prête pour les pics d'utilisation du week-end. Tout au long de la semaine, nous continuons à déployer des fonctionnalités entièrement nouvelles, et nous ne bloquons pas le déploiement continu par tous les ingénieurs.

L'étranglement est un concept très accepté en informatique. Mais c'est le levier d'informatique le plus mal utilisé et mal compris. Lorsque de nouveaux ingénieurs rejoignent Roblox, leurs premières solutions incluent souvent : « Si nous pouvions juste dire à nos créateurs d'ajuster cette configuration ou de ralentir leurs événements… ». Les ingénieurs vétérans de Roblox expliquent ensuite calmement notre valeur de respecter la communauté et que nous ne disons pas à nos créateurs quoi faire.

Par exemple, la plupart des systèmes de jeux ont une solution simple pour le matchmaking lorsque des millions de joueurs cliquent sur jouer simultanément. Ils limitent les connexions, font attendre les joueurs, ou les envoient sur des serveurs aléatoires en contournant l'algorithme de matchmaking. Chez Roblox, nous faisons le contraire. Nous avons repensé l'ensemble de nos systèmes de matchmaking pour des troupeaux de joueurs tonitruants. En période de pointe, ce système évalue jusqu'à 4 milliards de combinaisons de jointures possibles par seconde. Il y a des années, nous avons fixé l'objectif de 10 millions de connexions en 10 secondes, et nous continuons à progresser pour atteindre cet objectif.

Pour éviter une saturation due à la capacité, nous expérimentons avec le déploiement en nuage dans le cadre de notre transition vers une infrastructure cellulaire, permettant un dimensionnement dynamique et efficace en termes de calcul. Cette architecture gère les pics de demande en faisant correspondre les utilisateurs aux cellules des centres de données sur site et en bordure de nuage. Nous travaillons à la mise en place et au démantèlement entièrement automatisés de centres de données périphériques basés sur le nuage qui sont entièrement abstraits pour l'algorithme de mise en correspondance.

Un autre exemple est notre système de filtrage de texte qui, en période de pointe, traite 250 000 demandes par seconde. C'est une grande inférence de modèle fonctionnant sur 250 000 tokens avec des fenêtres de contexte en constante expansion. Et avec plus de 300 pipelines d'inférence IA en production, les propriétaires de services Roblox investissent beaucoup de temps à trouver le mélange idéal de profils d'inférence entre GPU et CPU. Même sous des charges maximales, les ingénieurs de Roblox respectent la communauté en privilégiant la liberté des créateurs et la sécurité des utilisateurs.

Avec notre planification, nous développons la capacité et les algorithmes pour soutenir les mises à jour les plus excitantes des créateurs. Mais nous devons être certains que ces systèmes peuvent se maintenir sous les pics les plus importants ou des pannes de service uniques. Les informations recueillies lors des pics d'utilisation sur plus de 1 600 microservices permettent d'identifier les services à soumettre à des tests de stress plus poussés.

Fidèles à notre valeur de faire bouger les choses, nous prenons chaque jour quelques-uns de ces services et contraignons leur capacité de production. Nous observons les attributs, puis nous les corrigeons avant le week-end. Nous appelons cela les mardis “test de la capacité réelle” (TACO). Notre équipe de fiabilité est également en mesure de faire en sorte que la capacité soit correcte et continue (C3). Chaque équipe d'ingénieurs utilise un tableau de bord C3 pour prévoir et gérer la capacité de l'unité centrale de leurs services. Cela permet aux propriétaires de services de tirer continuellement des leçons du dernier pic afin d'augmenter ou de réduire la capacité pour le prochain pic. Nous avons également lancé un système qui suit les modèles d'appels dans le moteur principal de Roblox pour les nouvelles versions. Cela aide à garantir que nous sommes mieux préparés lors d'une mise à jour.

Même avec toute cette préparation, nous rencontrons encore de temps en temps des scénarios où la nature imprévisible des modèles de trafic pourrait faire en sorte qu'un seul service ou flux de produits fasse tomber la plateforme. Par exemple, le pipeline d'analyse d'événements de 2 trillions pourrait voir 30 % de trafic en plus en raison d'une mise à jour populaire. C'est là que nos mécanismes de résilience, tels que le contrôle adaptatif de la concurrence (ACC), le disjoncteur et la suppression des tentatives, sont lancés pour protéger la plateforme. Cette année, nous avons également construit une plateforme de tests de chaos pour renforcer la résilience et l'évolutivité de notre infrastructure en injectant aléatoirement des pannes, en épuisant des ressources et en terminant aléatoirement des processus en production.

Nous passons toute la semaine à tester et à nous préparer pour ces grandes mises à jour du week-end. Mais quand vient le week-end, il nous reste du travail à faire. Avant les mises à jour du week-end, les ingénieurs de Roblox collaborent pour surveiller les changements à venir et prédire la capacité restante, en provisionnant des ressources cloud supplémentaires si nécessaire pour accueillir des millions de joueurs supplémentaires via des centres de données virtuels en périphérie.

Le vendredi, nous décidons si nous devons ajouter une capacité supplémentaire avec des ressources dans le cloud. Ce processus donne une direction claire à notre équipe de cloud hybride pour mettre en place une capacité supplémentaire suffisante pour accueillir des millions de joueurs supplémentaires. À tout moment, nos 24 centres de données périphériques physiques fonctionnent, mais après tous les tests, nous pourrions décider que nous avons besoin de centres de données périphériques supplémentaires. Il n'y a aucun moyen de configurer et empiler des serveurs en 12 heures, donc nous travaillons avec nos partenaires cloud pour construire plusieurs centres de données virtuels en périphérie. Nous les testons vendredi, puis nous sommes prêts pour le week-end.

Dans le véritable esprit de prendre des responsabilités, tout le monde, y compris nos cadres supérieurs, effectue des rotations d'appel, même le week-end. L'afflux de millions d'utilisateurs le samedi peut souvent déclencher des centaines d'alertes. Les équipes résolvent préemptivement ces alertes, ce qui nous permet de gérer les défis lors d'une grande mise à jour ou d'un pic historique à l'échelle de la plateforme.

Comme Léonard de Vinci le disait souvent, « Apprendre n'épuise jamais l'esprit. » Chaque pic nous a inspirés à apprendre et à inventer de nouvelles techniques pour rendre notre infrastructure plus fiable et invisible. Nos créateurs publient ou mettent à jour, et par la magie de l'infrastructure invisible, des dizaines de millions d'utilisateurs commencent à profiter d'une expérience entièrement nouvelle presque immédiatement. Nous sommes éternellement reconnaissants envers nos créateurs et nos utilisateurs de nous avoir défiés à repousser les limites de l'informatique.