Dans ce chapitre, vous allez découvrir le métier de Site Reliability Engineer, qui consiste à maintenir en conditions opérationnelles vos applications. Vous verrez comment mettre en place ce qu’on appelle les quatre signaux dorés et comment vérifier les niveaux de service de vos applications.
Découvrez le nouveau métier de SRE
Avec la migration dans le cloud et l’avènement des microservices, les environnements sont de plus en plus scalables et dynamiques, grossissant et se réduisant selon la demande. Gérer des applications distribuées sur des environnements dynamiques est de plus en plus complexe. Traditionnellement, une personne pouvait gérer entre 10 et 100 serveurs manuellement. Dans le cas d’environnements dynamiques, où les serveurs peuvent scaler automatiquement jusqu’à plusieurs centaines, voire plusieurs milliers, une personne seule ne peut pas gérer tous ces serveurs. Elle doit alors se reposer drastiquement sur l’automatisation afin de pouvoir manager tous ces serveurs.
C’est dans ce contexte qu’est né le métier de Site Reliability Engineer, ou SRE. Né en 2003 chez Google, avant que le terme DevOps ne soit inventé, ce métier a vu le jour lorsque Ben Treynor a mis en place la première équipe SRE dans l’entreprise. Selon lui, le Site Reliability Engineering est “ce qui se passe quand un ingénieur logiciel est chargé de ce qu’on appelle les opérations”.
Le SRE consacre jusqu’à 50 % de son temps à des tâches liées aux “opérations” telles que les problèmes, les astreintes et les interventions manuelles. Comme on s’attend à ce que le système logiciel supervisé par un SRE soit hautement automatique et autoréparable, le SRE devrait consacrer l’autre moitié de son temps aux tâches de développement comme les nouvelles fonctionnalités, l’évolution ou l’automatisation.
Le métier de SRE se repose sur quatre signaux dorés, ainsi que des niveaux de services que nous allons détailler dans la suite de ce chapitre.
Mettez en place les quatre signaux dorés
Afin de gérer efficacement les applications supervisées, il est nécessaire de mettre en place des métriques à surveiller. Généralement, les métriques traditionnelles mises en place sont CPU, RAM et stockage. Mais ces métriques, bien que nécessaires, ne sont pas suffisantes. C’est pourquoi le SRE a défini quatre métriques supplémentaires plus génériques et applicables à n’importe quels composants de l’application : serveur web, file de messages, ou encore base de données.
Ces quatre métriques sont :
la latence ;
le trafic ;
l’erreur ;
la saturation.
Mesurez la latence
La latence est le temps qu’il faut pour traiter une demande. Il est important de faire la distinction entre la latence des demandes réussies et la latence des demandes échouées. Par exemple, une erreur HTTP 500 déclenchée en raison d’une perte de connexion à une base de données ou à un autre backend critique peut être traitée très rapidement. Cependant, comme une erreur HTTP 500 indique l’échec d’une demande, la prise en compte des 500 dans votre latence globale peut donner lieu à des calculs trompeurs. D’autre part, une erreur lente est encore pire qu’une erreur rapide ! Il est donc important de suivre la latence des erreurs, plutôt que de se contenter de les filtrer.
Mesurez le trafic
Le trafic est une mesure de la quantité de demandes imposées à votre système, mesurée dans une métrique de haut niveau spécifique au système. Pour un service web, cette mesure correspond généralement aux demandes HTTP par seconde, éventuellement ventilées selon la nature des demandes (par exemple, contenu statique ou dynamique). Pour un système de streaming audio, cette mesure peut se concentrer sur le taux d’entrées/sorties du réseau ou sur les sessions simultanées. Pour un système de stockage de valeurs-clés, cette mesure peut être les transactions et les extractions par seconde.
Comptez le nombre d’erreurs
L’erreur correspond au taux de demandes qui échouent :
soit explicitement : par exemple, HTTP 500 ;
soit implicitement : par exemple, une réponse HTTP 200 réussie, mais associée à un contenu erroné ;
soit par politique : par exemple, “Si vous vous êtes engagé à respecter un temps de réponse d’une seconde, toute demande supérieure à une seconde est une erreur”.
Lorsque les codes de réponse des protocoles sont insuffisants pour exprimer toutes les conditions d’échec, des protocoles secondaires (internes) peuvent être nécessaires pour suivre les modes d’échec partiel. La surveillance de ces cas peut être radicalement différente : la capture des HTTP 500 au niveau de votre équilibreur de charge peut faire un travail décent pour attraper toutes les requêtes qui ont complètement échoué, alors que seuls les tests système de bout en bout peuvent détecter que vous servez le mauvais contenu.
Mesurez la saturation
Enfin, la saturation est le degré de “remplissage” de votre service ; une mesure de la fraction de votre système, en mettant l’accent sur les ressources qui sont les plus contraintes. Par exemple, dans un système avec des contraintes de mémoire, cela correspond à montrer la mémoire ; dans un système avec des contraintes d’E/S, cela correspond à montrer les E/S. Notez que de nombreux systèmes voient leurs performances se dégrader avant d’atteindre une utilisation de 100 %, il est donc essentiel d’avoir un objectif d’utilisation.
Dans les systèmes complexes, la saturation peut être complétée par une mesure de charge de plus haut niveau : votre service peut-il correctement gérer le double du trafic, gérer seulement 10 % de trafic en plus, ou gérer encore moins de trafic que ce qu’il reçoit actuellement ? Pour les services très simples qui n’ont pas de paramètres modifiant la complexité de la demande (par exemple “Donnez-moi un nonce” ou “J’ai besoin d’un entier monotone globalement unique”) et dont la configuration change rarement, une valeur statique provenant d’un test de charge peut être adéquate. Cependant, comme nous l’avons vu dans le paragraphe précédent, la plupart des services ont besoin d’utiliser des signaux indirects comme l’utilisation du CPU ou la bande passante du réseau, dont la limite supérieure est connue. Les augmentations de latence sont souvent un indicateur avancé de la saturation. La mesure du 99e percentile du temps de réponse sur une petite fenêtre (par exemple, une minute) peut donner un signal très précoce de saturation.
La saturation concerne également les prédictions de saturation imminente, telles que “Il semble que votre base de données va remplir son disque dur dans 4 heures”.
Si vous mesurez les quatre signaux dorés et que vous appelez quelqu’un lorsqu’un signal est problématique (ou, dans le cas de la saturation, presque problématique), votre service sera au moins décemment couvert par le monitoring.
Contrôlez vos niveaux de service
Une fois les quatre signaux dorés mis en place, il est temps de définir des indicateurs, des objectifs et de respecter vos accords de service.
Mettez en place le Service Level Indicator (SLI)
Un Service Level Indicator (SLI) est un indicateur de niveau de service : une mesure quantitative, soigneusement définie, d’un aspect du niveau de service fourni.
La plupart des services considèrent le temps de latence des demandes, c’est-à-dire le temps qu’il faut pour renvoyer une réponse à une demande, comme un indicateur-clé. Parmi les autres indicateurs courants figurent le taux d’erreur, souvent exprimé en tant que fraction de toutes les demandes reçues, et le débit du système, généralement mesuré en demandes par seconde. Les mesures sont souvent agrégées, c’est-à-dire que les données brutes sont collectées sur une fenêtre de mesure, puis transformées en taux, moyenne ou percentile.
Idéalement, le SLI mesure directement un niveau de service d’intérêt, mais parfois seul un proxy est disponible car la mesure souhaitée peut être difficile à obtenir ou à interpréter. Par exemple, la latence côté client est souvent la mesure la plus pertinente pour l’utilisateur, mais il se peut qu’il ne soit possible de mesurer la latence qu’au niveau du serveur.
Un autre type de SLI important pour le SRE est la disponibilité, ou la fraction du temps pendant laquelle un service est utilisable. Elle est souvent définie en termes de fraction de demandes bien formées qui aboutissent, parfois appelée rendement.
Bien qu’une disponibilité de 100 % soit impossible, une disponibilité proche de 100 % est souvent facilement réalisable et l’industrie exprime généralement les valeurs de haute disponibilité en termes de nombre de “neuf” dans le pourcentage de disponibilité. Par exemple, des disponibilités de 99 % et de 99,999 % peuvent être désignées respectivement par les termes “2 neuf” et “5 neuf”.
Vérifiez le Service Level Objective (SLO)
Un Service Level Objective (SLO) est un objectif de niveau de service : une valeur cible ou une plage de valeurs pour un niveau de service qui est mesuré par un SLI. Une structure naturelle pour les SLO est donc SLI ≤ cible, ou limite inférieure ≤ SLI ≤ limite supérieure.
Le choix d’un SLO approprié est complexe. Tout d’abord, vous ne pouvez pas toujours choisir sa valeur. Pour les requêtes HTTP entrantes du monde extérieur vers votre service, la mesure des requêtes par seconde (RPS) est essentiellement déterminée par les désirs de vos utilisateurs et vous ne pouvez pas vraiment définir un SLO pour cela.
En revanche, vous pouvez dire que vous voulez que la latence moyenne par requête soit inférieure à 100 millisecondes et fixer un tel objectif pourrait vous inciter à écrire votre frontend avec des comportements à faible latence de différents types ou à acheter certains types d’équipements à faible latence.
Là encore, c’est plus subtil qu’il n’y paraît à première vue, dans la mesure où ces deux SLI, RPS et latence, peuvent être liés en coulisses : un RPS plus élevé entraîne souvent des latences plus importantes et il est courant que les services aient un seuil de performance au-delà d’un certain seuil de charge.
Respectez le Service Level Agreement (SLA)
Les Service Level Agreements (SLA) sont des accords de niveau de service : des contrats explicites ou implicites avec vos utilisateurs qui incluent les conséquences du respect (ou de l’absence) des SLO qu’ils contiennent. Les conséquences sont plus facilement reconnaissables lorsqu’elles sont financières (un rabais ou une pénalité), mais elles peuvent prendre d’autres formes.
Un moyen facile de faire la différence entre un SLO et un SLA est de demander :
Que se passe-t-il si les SLO ne sont pas atteints ?
S’il n’y a pas de conséquence explicite, il s’agit presque certainement d’un SLO.
Le SRE ne participe généralement pas à l’élaboration des SLA, car ceux-ci sont étroitement liés aux décisions relatives aux métiers et aux produits. Le SRE s’implique toutefois pour éviter de déclencher les conséquences de SLO non respectés. Ils peuvent également aider à définir les SLI : il faut évidemment qu’il y ait un moyen objectif de mesurer les SLO dans l’accord, sinon des désaccords apparaîtront.
En résumé
Le SRE (Site Reliability Engineering) est une discipline qui intègre des aspects de l’ingénierie logicielle et les applique aux problèmes d’infrastructure et d’exploitation.
Les quatre signaux dorés servent de base aux indicateurs de niveaux de service.
La latence est le temps qu’il faut pour traiter une demande.
L’erreur correspond au taux de demandes qui échouent.
Le trafic est une mesure de la quantité de demandes imposées à votre système.
La saturation est le degré de “remplissage” de votre service.
Des indicateurs permettent de surveiller les niveaux de service.
Dans le prochain chapitre, vous verrez comment superviser votre application en production et comment mettre en place des notifications d’alerte sur Slack en cas de problème.
