Actualités / Jeux

Offrir une plate-forme fiable à grande échelle – Roblox Blog

Offrir une plate-forme fiable à grande échelle - Roblox Blog

L’exécution de n’importe quelle plate-forme distribuée évolutive exige un engagement envers la fiabilité, pour s’assurer que les clients disposent de ce dont ils ont besoin quand ils en ont besoin. Les dépendances pourraient être assez complexes, en particulier avec une plate-forme aussi grande que Roblox. La construction de services fiables signifie que, quels que soient la complexité et l’état des dépendances, un service donné ne sera pas interrompu (c’est-à-dire hautement disponible), fonctionnera sans bogue (c’est-à-dire qualité) et sans erreurs (c’est-à-dire tolérance aux pannes).

Pourquoi la fiabilité est importante

Notre équipe Account Identity s’engage à atteindre une plus grande fiabilité, car les services de conformité que nous avons créés sont des composants essentiels de la plate-forme. Une non-conformité peut avoir de graves conséquences. Le coût du blocage du fonctionnement naturel de Roblox est très élevé, avec des ressources supplémentaires nécessaires pour récupérer après une panne et une expérience utilisateur fragilisée.

L’approche typique de la fiabilité se concentre principalement sur la disponibilité, mais dans certains cas, les termes sont mélangés et mal utilisés. La plupart des mesures de disponibilité évaluent simplement si les services sont opérationnels, tandis que des aspects tels que la tolérance et la cohérence des partitions sont parfois oubliés ou mal compris.

Conformément au théorème CAP, tout système distribué ne peut garantir que deux de ces trois aspects. Nos services de conformité sacrifient donc une certaine cohérence afin d’être hautement disponibles et tolérants aux partitions. Néanmoins, nos services ont peu sacrifié et ont trouvé des mécanismes pour atteindre une bonne cohérence avec les changements architecturaux raisonnables expliqués ci-dessous.

Le processus pour atteindre une plus grande fiabilité est itératif, avec des mesures précises correspondant à un travail continu afin de prévenir, trouver, détecter et corriger les défauts avant que les incidents ne se produisent. Notre équipe a identifié une forte valeur dans les pratiques suivantes :

  • Mesure juste – Construire une observabilité complète sur la manière dont la qualité est fournie aux clients et sur la manière dont les dépendances nous fournissent la qualité.
  • Anticipation proactive – Effectuer des activités telles que des revues architecturales et des évaluations des risques de dépendance.
  • Prioriser la correction – Porter une plus grande attention à la résolution des rapports d’incidents pour le service et les dépendances liées à notre service.

Construire une plus grande fiabilité exige une culture de la qualité. Notre équipe investissait déjà dans le développement axé sur la performance et sait que le succès d’un processus dépend de son adoption. L’équipe a adopté ce processus dans son intégralité et a appliqué les pratiques comme une norme. Le schéma suivant met en évidence les composants du processus :

Le pouvoir de la bonne mesure

Avant de plonger plus profondément dans les métriques, il y a une clarification rapide à apporter concernant les mesures du niveau de service.

  • Le SLO (Service Level Objective) est l’objectif de fiabilité que notre équipe vise (soit 99,999%).
  • Le SLI (Service Level Indicator) est la fiabilité atteinte sur une période donnée (soit 99,975% en février dernier).
  • Le SLA (Service Level Agreement) est la fiabilité que nous nous engageons à délivrer et à laquelle nos consommateurs s’attendent dans un délai donné (soit 99,99% par semaine).

Le SLI doit refléter la disponibilité (pas de réponses non gérées ou manquantes), la tolérance aux pannes (pas d’erreurs de service) et la qualité atteinte (pas d’erreurs inattendues). Par conséquent, nous avons défini notre SLI comme le « taux de réussite » des réponses réussies par rapport au nombre total de requêtes envoyées à un service. Les réponses réussies sont les demandes qui ont été envoyées dans les délais et sous la forme, ce qui signifie qu’aucune

la connectivité, le service ou des erreurs inattendues se sont produites.

Ce SLI ou Success Ratio est recueilli du point de vue des consommateurs (c’est-à-dire des clients). L’intention est de mesurer l’expérience réelle de bout en bout offerte à nos consommateurs afin que nous soyons convaincus que les SLA sont respectés. Ne pas le faire créerait un faux sentiment de fiabilité qui ignorerait tous les problèmes d’infrastructure pour se connecter avec nos clients. Semblable au SLI consommateur, nous collectons le SLI de dépendance pour suivre tout risque potentiel. En pratique, tous les SLA de dépendance doivent s’aligner sur le SLA de service et il existe une dépendance directe avec eux. L’échec de l’un implique l’échec de tous. Nous suivons et rapportons également les mesures du service lui-même (c’est-à-dire le serveur), mais ce n’est pas la source pratique d’une fiabilité élevée.

En plus des SLI, chaque build collecte des métriques de qualité qui sont rapportées par notre flux de travail CI. Cette pratique permet de renforcer fortement les barrières de qualité (c’est-à-dire la couverture de code) et de signaler d’autres mesures significatives, telles que la conformité aux normes de codage et l’analyse de code statique. Ce sujet a déjà été traité dans un autre article, Créer des microservices axés sur la performance. Le respect assidu de la qualité s’ajoute à la fiabilité, car plus nous investissons pour atteindre d’excellents scores, plus nous sommes convaincus que le système ne tombera pas en panne dans des conditions défavorables.

Notre équipe dispose de deux tableaux de bord. One offre toute la visibilité sur le SLI des consommateurs et le SLI des dépendances. Le second montre toutes les métriques de qualité. Nous travaillons à tout fusionner dans un seul tableau de bord, afin que tous les aspects qui nous intéressent soient consolidés et prêts à être signalés à tout moment.

Anticiper l’échec

Action Examens architecturaux est un élément fondamental pour être fiable. Tout d’abord, nous déterminons si la redondance est présente et si le service a les moyens de survivre lorsque les dépendances diminuent. Au-delà des idées de réplication typiques, la plupart de nos services ont appliqué des techniques améliorées de double hydratation du cache, des stratégies de récupération double (telles que les files d’attente locales de basculement) ou des stratégies de perte de données (telles que le support transactionnel). Ces sujets sont suffisamment étendus pour justifier une autre entrée de blog, mais en fin de compte, la meilleure recommandation est de mettre en œuvre des idées qui tiennent compte des scénarios de catastrophe et de minimiser toute pénalité de performance.

Un autre aspect important à anticiper est tout ce qui pourrait améliorer la connectivité. Cela signifie être agressif sur la faible latence pour les clients et les préparer à un trafic très élevé en utilisant des techniques de contrôle du cache, des side-cars et des politiques performantes pour les délais d’attente, les disjoncteurs et les tentatives. Ces pratiques s’appliquent à tous les clients, y compris les caches, les magasins, les files d’attente et les clients interdépendants en HTTP et gRPC. Cela signifie également améliorer les signaux sains des services et comprendre que les contrôles de santé jouent un rôle important dans toute l’orchestration des conteneurs. La plupart de nos services émettent de meilleurs signaux de dégradation dans le cadre des commentaires sur la vérification de l’état et vérifient que tous les composants critiques sont fonctionnels avant d’envoyer des signaux sains.

La décomposition des services en éléments critiques et non critiques s’est avérée utile pour se concentrer sur la fonctionnalité qui compte le plus. Nous avions l’habitude d’avoir des points de terminaison réservés aux administrateurs dans le même service, et même s’ils n’étaient pas souvent utilisés, ils avaient un impact sur les mesures de latence globale. Les déplacer vers leur propre service a eu un impact positif sur chaque métrique.

Évaluation du risque de dépendance est un outil important pour identifier les problèmes potentiels de dépendances. Cela signifie que nous identifions les dépendances avec un faible SLI et demandons un alignement SLA. Ces dépendances nécessitent une attention particulière lors des étapes d’intégration. Nous consacrons donc plus de temps à évaluer et à tester si les nouvelles dépendances sont suffisamment matures pour nos plans. Un bon exemple est l’adoption précoce que nous avons eue pour Roblox Storage-as-a-Service. L’intégration avec ce service a nécessité le dépôt de tickets de bogue et des réunions de synchronisation périodiques pour communiquer les résultats et les commentaires. Tout ce travail utilise la balise « fiabilité » afin que nous puissions identifier rapidement sa source et ses priorités. La caractérisation se produisait souvent jusqu’à ce que nous ayons la certitude que la nouvelle dépendance était prête pour nous. Ce travail supplémentaire a permis d’amener la dépendance au niveau de fiabilité requis que nous nous attendons à fournir en agissant ensemble pour un objectif commun.

Structurez le chaos

Il n’est jamais souhaitable d’avoir des incidents. Mais lorsqu’ils se produisent, il existe des informations significatives à collecter et à exploiter pour être plus fiables. Notre équipe a un rapport d’incident d’équipe qui est créé au-delà du rapport typique à l’échelle de l’entreprise, nous nous concentrons donc sur tous les incidents, quelle que soit l’ampleur de leur impact. Nous appelons la cause profonde et priorisons tous les travaux pour l’atténuer à l’avenir. Dans le cadre de ce rapport, nous faisons appel à d’autres équipes pour résoudre les incidents de dépendance avec une priorité élevée, effectuer un suivi avec une résolution appropriée, effectuer une rétrospective et rechercher des modèles qui pourraient s’appliquer à nous.

L’équipe produit un Rapport de fiabilité mensuel par service cela inclut tous les SLI expliqués ici, tous les tickets que nous avons ouverts en raison de la fiabilité et tous les incidents possibles associés au service. Nous sommes tellement habitués à générer ces rapports que la prochaine étape naturelle consiste à automatiser leur extraction. Faire cette activité périodique est important, et c’est un rappel que la fiabilité est constamment suivie et prise en compte dans notre développement.

Notre instrumentation comprend des métriques personnalisées et des alertes améliorées afin que nous soyons avertis dès que possible lorsque des problèmes connus et attendus surviennent. Toutes les alertes, y compris les faux positifs, sont examinées chaque semaine. À ce stade, il est important de peaufiner toute la documentation afin que nos consommateurs sachent à quoi s’attendre lorsque des alertes se déclenchent et lorsque des erreurs se produisent, puis tout le monde sait quoi faire (par exemple, les playbooks et les directives d’intégration sont alignés et mis à jour souvent).

Finalement, l’adoption de la qualité dans notre culture est le facteur le plus critique et décisif pour atteindre une plus grande fiabilité. Nous pouvons observer comment ces pratiques appliquées à notre travail quotidien portent déjà leurs fruits. Notre équipe est obsédée par la fiabilité et c’est notre réalisation la plus importante. Nous avons accru notre prise de conscience de l’impact que les défauts potentiels pourraient avoir et du moment où ils pourraient être introduits. Les services qui ont mis en œuvre ces pratiques ont systématiquement atteint leurs SLO et SLA. Les rapports de fiabilité qui nous aident à suivre tout le travail que nous avons effectué témoignent du travail accompli par notre équipe et constituent des leçons inestimables pour informer et influencer les autres équipes. C’est ainsi que la culture de la fiabilité touche tous les composants de notre plateforme.

La route vers une plus grande fiabilité n’est pas facile, mais elle est nécessaire si vous souhaitez créer une plate-forme de confiance qui réinvente la façon dont les gens se rassemblent.


Alberto est ingénieur logiciel principal au sein de l’équipe Identité de compte chez Roblox. Il travaille depuis longtemps dans l’industrie du jeu, avec des crédits sur de nombreux titres de jeux AAA et des plateformes de médias sociaux avec un fort accent sur les architectures hautement évolutives. Maintenant, il aide Roblox à atteindre sa croissance et sa maturité en appliquant les meilleures pratiques de développement.