Menu Fermer

Assurer la fiabilité des plates-formes à grande échelle

L’exploitation de toute plate-forme distribuée évolutive exige un engagement en matière de fiabilité, afin de garantir que les clients disposent de ce dont ils ont besoin quand ils en ont besoin. Les dépendances peuvent être assez complexes, surtout avec une plateforme aussi grande que Roblox. Construire des services fiables signifie que, indépendamment de la complexité et de l’état des dépendances, un service donné ne sera pas interrompu (c’est-à-dire hautement disponible), fonctionnera sans bogue (c’est-à-dire de haute qualité) et sans erreur (c’est-à-dire tolérance aux pannes).

Pourquoi la fiabilité est importante

Notre équipe chargée de l’identité des comptes s’est engagée à atteindre une plus grande fiabilité, car les services de conformité que nous avons créés sont des éléments essentiels de la plateforme. Un défaut de 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 se rétablir après une défaillance et une expérience utilisateur affaiblie.

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 la disponibilité se contentent d’évaluer si les services sont opérationnels, tandis que des aspects tels que la tolérance de partition et la cohérence 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 sacrifié peu de choses et ont trouvé des mécanismes pour atteindre une bonne cohérence avec des changements architecturaux raisonnables expliqués ci-dessous.

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

Mesure correcte – Établir une observabilité complète de la manière dont la qualité est fournie aux clients et dont les dépendances nous fournissent la qualité.
Anticipation proactive – Réaliser des activités telles que des revues d’architecture et des évaluations des risques liés aux dépendances.
Priorité à la correction – Accordez une plus grande attention à la résolution des rapports d’incidents pour le service et les dépendances qui sont liées à notre service.

L’amélioration de la 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 composantes du processus :

Le pouvoir de la mesure juste

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

SLO (Service Level Objective) est l’objectif de fiabilité que notre équipe vise (par exemple 99,999%).
SLI (Service Level Indicator) est la fiabilité atteinte dans un délai donné (par exemple 99,975% en février dernier).
SLA (Service Level Agreement) est la fiabilité convenue et attendue par nos clients à un moment donné (par exemple 99,99% par semaine).

Le SLI doit refléter la disponibilité (aucune réponse non traitée ou manquante), la tolérance aux pannes (aucune erreur de service) et la qualité atteinte (aucune erreur inattendue). Nous avons donc défini notre ISL comme le “taux de réussite” des réponses réussies par rapport au nombre total de demandes envoyées à un service. Les réponses réussies sont les demandes qui ont été envoyées en temps et en forme, ce qui signifie qu’il n’y a pas eu d’erreur de connectivité, de service ou d’erreur inattendue.

Ce SLI ou taux de réussite est collecté du point de vue des consommateurs (c’est-à-dire des clients). L’objectif est de mesurer l’expérience réelle de bout en bout offerte à nos clients afin que nous soyons certains que les accords de niveau de service 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. Comme pour le SLI du consommateur, nous recueillons 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 entre eux. La défaillance de l’un implique la défaillance de tous. Nous suivons et rapportons également les métriques du service lui-même (c’est-à-dire le serveur) mais ce n’est pas la source pratique pour une fiabilité élevée.

En plus des SLI, chaque build collecte des mesures de qualité qui sont rapportées par notre workflow CI. Cette pratique permet de renforcer les barrières de qualité (c’est-à-dire la couverture du code) et de signaler d’autres mesures significatives, telles que la conformité aux normes de codage et l’analyse statique du code. Ce sujet a déjà été abordé dans un autre article, Building Microservices Driven by Performance. Le respect scrupuleux de la qualité est un atout supplémentaire lorsqu’on parle de fiabilité, car plus nous investissons pour atteindre d’excellents résultats, plus nous sommes sûrs que le système ne tombera pas en panne dans des conditions défavorables.

Notre équipe dispose de deux tableaux de bord. Le premier fournit toute la visibilité sur le SLI des consommateurs et le SLI des dépendances. Le second présente toutes les mesures de qualité. Nous nous efforçons de tout fusionner en 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

La réalisation de revues d’architecture est un élément fondamental de la fiabilité. 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 tombent en panne. Au-delà des idées typiques de réplication, la plupart de nos services ont appliqué des techniques améliorées d’hydratation de double 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 vastes pour justifier un autre article de blog, mais en fin de compte, la meilleure recommandation est de mettre en œuvre des idées qui envisagent des scénarios de catastrophe et minimisent toute pénalité de performance.

Un autre aspect important à anticiper est tout ce qui peut améliorer la connectivité. Cela signifie qu’il faut être agressif en matière de faible latence pour les clients et les préparer à un trafic très élevé en utilisant des techniques de contrôle de cache, des sidecars et des politiques performantes en matière de délais d’attente, de coupe-circuits et de tentatives. Ces pratiques s’appliquent à tous les clients, y compris les caches, les magasins, les files d’attente et les clients interdépendants dans HTTP et gRPC. Il faut également améliorer les signaux de santé des services et comprendre que les contrôles de santé jouent un rôle important dans toute orchestration de conteneurs. La plupart de nos services améliorent les signaux de dégradation dans le cadre du retour d’information des contrôles de santé 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 d’extrémité réservés aux administrateurs dans le même service, et bien qu’ils ne soient pas utilisés souvent, ils avaient un impact sur les mesures de latence globales. Le fait de les déplacer vers leur propre service a eu un impact positif sur toutes les mesures.

L’évaluation des risques liés aux dépendances est un outil important pour identifier les problèmes potentiels liés aux dépendances. Cela signifie que nous identifions les dépendances avec un faible SLI et demandons l’alignement des SLA. Ces dépendances doivent faire l’objet d’une attention particulière lors des étapes d’intégration. Nous consacrons donc du temps supplémentaire à l’évaluation et au test des nouvelles dépendances afin de déterminer si elles sont suffisamment matures pour nos plans. Un bon exemple est l’adoption précoce que nous avons eue pour le Roblox Storage-as-a-Service. L’intégration de 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 le retour d’information. Tout ce travail utilise la balise “fiabilité” afin que nous puissions rapidement identifier sa source et ses priorités. La caractérisation a eu lieu 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 attendons en agissant ensemble pour un objectif commun.

Donner une structure au chaos

Il n’est jamais souhaitable d’avoir des incidents. Mais lorsqu’ils se produisent, il y a des informations significatives à collecter et à exploiter afin d’être plus fiable. Notre équipe dispose d’un rapport d’incident d’équipe qui est créé en plus du rapport typique de l’ensemble de l’entreprise, de sorte que nous nous concentrons sur tous les incidents, quelle que soit l’ampleur de leur impact. Nous nous concentrons sur tous les incidents, quelle que soit l’ampleur de leur impact. Nous indiquons la cause profonde et donnons la priorité à tous les travaux visant à 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 à haute priorité, nous assurons le suivi de la résolution appropriée, nous effectuons une rétrospective et nous recherchons des modèles qui pourraient s’appliquer à nous.

L’équipe produit un rapport mensuel de fiabilité par service qui inclut tous les SLI expliqués ici, tous les tickets que nous avons ouverts à cause 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 est d’automatiser leur extraction. Cette activité périodique est importante et nous rappelle que la fiabilité est constamment suivie et prise en compte dans notre développement.

Notre instrumentation comprend des mesures personnalisées et des alertes améliorées afin que nous soyons avertis dès que possible lorsque des problèmes connus et attendus se produisent. 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 que des erreurs se produisent, et que chacun sache ce qu’il doit faire (par exemple, les manuels de jeu et les directives d’intégration sont alignés et mis à jour fréquemment).

En définitive, l’adoption de la qualité dans notre culture est le facteur le plus critique et le plus 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é, qui est notre principale réalisation. Nous avons pris davantage conscience de l’impact que peuvent avoir les défauts potentiels et du moment où ils peuvent être introduits. Les services qui ont mis en œuvre ces pratiques ont régulièrement atteint leurs objectifs de niveau de service et de niveau d’engagement. Les rapports de fiabilité qui nous aident à suivre tout le travail accompli témoignent du travail de 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.

Le chemin vers une plus grande fiabilité n’est pas facile, mais il est nécessaire si vous voulez construire une plateforme de confiance qui réimagine la façon dont les gens se réunissent.

Alberto est ingénieur logiciel principal au sein de l’équipe chargée de l’identité des comptes chez Roblox. Il travaille depuis longtemps dans l’industrie du jeu, avec des crédits sur de nombreux titres de jeux AAA et des plates-formes de médias sociaux avec un fort accent sur les architectures hautement évolutives. Aujourd’hui, il aide Roblox à atteindre la croissance et la maturité en appliquant les meilleures pratiques de développement.

Le message Delivering Large-Scale Platform Reliability est apparu en premier sur Roblox Blog.