L'infrastructure au service d'expériences exceptionnelles

La capacité de Roblox à s’adapter et à prendre en charge des dizaines de millions d’utilisateurs jouant ensemble à travers des millions d’expériences uniques n’est pas le fruit d’une seule innovation. C’est le résultat d’une culture d’innovation plus large et d’un millier de petites choses bien faites à tous les niveaux de l’entreprise. C’est ainsi que nous avons construit l’infrastructure qui prend actuellement en charge un trafic record vers de nombreuses expériences sur Roblox. L'une de ces expériences, Grow a Garden, a récemment battu le record du monde Guinness® du jeu vidéo le plus joué simultanément, avec 21,6 millions d'utilisateurs jouant en même temps. Et ce faisant, la plateforme Roblox a continué à battre de nouveaux records de concurrence maximale (comme elle le fait depuis près de deux décennies), dépassant récemment les 30 millions de joueurs simultanés.

Roblox est confronté à des défis uniques pour construire et maintenir une infrastructure capable de prendre en charge des millions d’expériences créées par des développeurs, notamment Dress to Impress, Adopt Me et Dead Rails, ce qui nécessite des méthodologies d’ingénierie innovantes. La plateforme prend en charge des dizaines de mises à jour toutes les heures et plus de 30 millions d'utilisateurs simultanés grâce à une infrastructure capable de s'adapter aux pics de trafic imprévus. Cette infrastructure doit pouvoir gérer des situations de « thundering herd » où plus de 21 millions d'utilisateurs rejoignent simultanément une même expérience (et où le code de mise à jour provient de créateurs indépendants). Les ingénieurs de Roblox innovent en remettant en question les idées reçues, avec des solutions inspirées par nos quatre valeurs fondamentales.

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

Conformément à notre valeur qui consiste à adopter une vision à long terme, nous prévoyons désormais 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 inclut l’acquisition de centres de données, le renouvellement du matériel serveur et la mise en place de réseaux physiques, avec de nouveaux centres de données comme celui du Brésil planifiés des années à l’avance. L’équipe réseau maintient également une capacité « en réserve » pour garantir un fonctionnement continu malgré des problèmes tels que des coupures de câbles réseau.

La capacité dont dispose Roblox aujourd’hui repose sur des prévisions établies il y a deux ans, à une époque où nous ne pouvions pas imaginer que certaines expériences passeraient de l’anonymat à une immense popularité en quelques semaines. Des jeux populaires tels que Dress to Impress et Grow a Garden, qui ont contribué à doubler le nombre maximal de joueurs simultanés de Roblox, passant de 13,9 millions en avril à 30,6 millions en juin 2025, n'existaient pas lorsque ces prévisions de capacité ont été établies. Par exemple, en mars 2025, Dead Rails a atteint un pic d'un million d'utilisateurs simultanés, utilisant toute la capacité CPU disponible. 

Tirant les leçons de ces pics de popularité, nous sommes passés à un cycle de planification plus agile. Afin de prendre en charge de manière constante les records de nombre de joueurs sur Roblox, l'équipe d'ingénierie suit un cycle hebdomadaire rigoureux de planification, de tests et d'ajustements de capacité. Le lundi est consacré à l'analyse des incidents, suivie de la planification de la capacité le mardi. Tout au long de la semaine, des tests de résistance sont effectués en continu. Le jeudi est consacré à l'examen de la capacité pour toute mise à jour majeure que nos créateurs nous ont signalée. Le vendredi, des ressources cloud supplémentaires sont provisionnées pour garantir que la plateforme soit prête à faire face aux 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. 

La limitation est un concept très répandu en informatique. Mais c'est aussi le levier le plus mal utilisé et le plus mal compris de l'informatique. Lorsque de nouveaux ingénieurs rejoignent Roblox, leurs premières solutions incluent souvent : « Si seulement on pouvait dire à nos créateurs de modifier cette configuration ou de ralentir leurs événements… ». Les ingénieurs chevronnés de Roblox leur expliquent alors gentiment notre valeur de respect de la communauté et le fait que nous ne disons pas à nos créateurs quoi faire. 

Par exemple, la plupart des systèmes de jeux proposent une solution simple pour le matchmaking lorsque des millions de joueurs cliquent simultanément sur « Jouer ». Ils limitent les connexions, font attendre les joueurs ou les envoient vers 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 accueillir des hordes de joueurs. En période de pointe, ce système évalue jusqu’à 4 milliards de combinaisons de connexion possibles par seconde. Il y a plusieurs années, nous nous sommes fixé l’objectif de 10 millions de connexions en 10 secondes, et nous continuons à itérer pour atteindre ce but.

Pour éviter toute limitation due à la capacité, nous expérimentons le cloud bursting dans le cadre de notre transition vers une infrastructure cellulaire, ce qui permet une évolutivité dynamique et efficace en termes de calcul. Cette architecture gère les pics de demande en affectant les utilisateurs à la fois à des cellules de centres de données sur site et à des cellules de centres de données périphériques dans le cloud. Nous travaillons à la mise en place d’un processus entièrement automatisé de déploiement et de démantèlement des centres de données périphériques basés sur le cloud, qui sont entièrement abstraits pour l’algorithme de mise en correspondance.

Un autre exemple est notre système de filtrage de texte, qui traite jusqu’à 250 000 requêtes par seconde en période de pointe. Il s’agit d’une inférence de modèle à grande échelle traitant 250 000 tokens avec des fenêtres de contexte en expansion constante. Et avec plus de 300 pipelines d’inférence IA en production, les responsables de services chez Roblox consacrent beaucoup de temps à trouver la combinaison idéale de profils d’inférence entre GPU et CPU. Même en période de pic de charge, les ingénieurs de Roblox respectent la communauté en donnant la priorité à la liberté des créateurs et à la sécurité des utilisateurs.

Grâce à notre planification, nous développons la capacité et les algorithmes nécessaires pour prendre en charge les mises à jour les plus passionnantes des créateurs. Mais nous devons nous assurer que ces systèmes peuvent résister même aux pics d'activité les plus importants ou à des pannes ponctuelles de services. Les informations recueillies lors des pics d'utilisation sur plus de 1 600 microservices nous aident à identifier les services à soumettre à des tests de résistance supplémentaires.

Fidèles à notre valeur qui consiste à faire avancer les choses, nous sélectionnons chaque jour quelques-uns de ces services et limitons leur capacité en production. Nous observons les caractéristiques, puis nous les corrigeons avant le week-end. Nous appelons cela les mardis « test actual capacity on » (TACO). Notre équipe de fiabilité gère également la « continuous capacity correctness » (C3). Chaque équipe d’ingénierie utilise un tableau de bord C3 pour prévoir et gérer la capacité CPU de ses services. Cela permet aux responsables de services de tirer continuellement des enseignements du dernier pic afin d’augmenter ou de réduire la capacité en vue du prochain pic. Nous avons également lancé un système qui suit les modèles d’appels dans le moteur central de Roblox pour les nouvelles versions. Cela nous aide à être mieux préparés lors d’une mise à jour. 

Malgré toute cette préparation, nous sommes encore parfois confrontés à des scénarios où la nature imprévisible des modèles de trafic pourrait entraîner la panne de la plateforme à cause d’un seul service ou flux de produit. Par exemple, le pipeline d’analyse de 2 000 milliards d’événements pourrait voir son trafic augmenter de 30 % en raison d’une mise à jour très 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 de reconnexion, entrent en action pour protéger la plateforme. Cette année, nous avons également mis en place une plateforme de tests de chaos afin de renforcer la résilience et l'évolutivité de notre infrastructure en injectant aléatoirement des défaillances, en épuisant les ressources et en interrompant de manière aléatoire des processus en production.

Nous passons toute la semaine à tester et à préparer ces mises à jour importantes du week-end. Mais lorsque le week-end arrive, nous avons encore du travail à faire. Avant les mises à jour du week-end, les ingénieurs de Roblox collaborent pour surveiller les changements à venir et estimer la capacité restante, en provisionnant des ressources cloud supplémentaires si nécessaire afin d’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 de la capacité supplémentaire avec des ressources cloud. Ce processus donne une orientation claire à notre équipe de cloud hybride pour qu'elle mette 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 sont opérationnels, mais après tous les tests, nous pouvons décider que nous avons besoin de centres de données périphériques supplémentaires. Il est impossible d’installer et d’empiler des serveurs en 12 heures, nous travaillons donc avec nos partenaires cloud pour mettre en place plusieurs centres de données périphériques virtuels. Nous les testons le vendredi, puis nous sommes prêts pour le week-end. 

Dans un véritable esprit de responsabilité, tout le monde, y compris nos cadres supérieurs, assure des permanences à tour de rôle, 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 ces alertes de manière préventive, ce qui nous permet de relever les défis lors d'une mise à jour majeure ou d'un pic d'activité sans précédent sur l'ensemble de la plateforme. 

Comme on attribue souvent à Léonard de Vinci la citation suivante : « L'apprentissage n'épuise jamais l'esprit. » Chaque pic de trafic 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 leurs contenus, et grâce à la magie d'une 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 pousser à repousser les limites de l'informatique.