Comprendre les SLOs dans Elastic : vers une observabilité orientée fiabilité
Dans un contexte où les services numériques sont au cœur des activités critiques des entreprises, les concepts de SLA, SLO et SLI sont devenus indispensables pour piloter la fiabilité et les engagements de performance. Cet article propose de faire le point sur ces notions à travers un cas concret d’intégration dans la suite Elastic (Kibana, Elasticsearch, etc.).
SLA, SLO, SLI : les différences essentielles
Prenons l’exemple de l’une des applications de l’un de nos clients. Ces derniers s’attendent à ce que leurs requêtes soient exécutées à temps, de manière fiable, et que le service soit disponible dans chaque région. Dans cette analogie :
Le SLA est un contrat formel avec les clients : « Nous nous engageons à ce que 95 % de leurs requêtes soient exécutées à temps. »
Le SLO est l’objectif interne : « Nous visons 98 % de requêtes exécutées à temps pour garantir le respect du SLA. »
Le SLI est la mesure réelle : « Ce mois-ci, 96,5 % des requêtes ont été exécutées à temps. »
En d’autres termes, on peut dire que :
- le SLI est une mesure quantifiable de la fiabilité de notre service.
- le SLO, quant à lui, représente l’objectif de fiabilité défini pour ce SLI.
- le SLA est un contrat formel basé sur les SLOs, qui définit les engagements et les pénalités.
Approfondir les métriques SLO
Les SLOs sont construits à partir des SLIs et définissent le niveau cible de fiabilité ou de performance. Les métriques sont la base des SLOs, et le choix des bonnes métriques est crucial.
Prenons un exemple concret avec une application développée en interne qui intègre un moteur de recherche. L’objectif de l’application est de garantir à ses utilisateurs des résultats de recherche rapides et fiables.
Pour y parvenir, le chef de projet définit ses SLOs en se basant sur trois types de métriques :
la latence
la disponibilité
le taux d’erreur
Types de métriques SLO
Il existe plusieurs types de métriques utilisées pour définir des SLOs :
SLOs basés sur la disponibilité
SLOs basés sur la latence
SLOs basés sur le taux d’erreurs
SLOs basés sur le débit (throughput)
SLOs composites
SLOs orientés disponibilité
Ces SLOs mesurent le pourcentage de temps pendant lequel un service est accessible et opérationnel, afin de répondre aux attentes des utilisateurs en matière de disponibilité (uptime).
De nombreux aspects peuvent être pris en compte, tels que :
| Aspect | Cas d’usage | Exemple |
|---|---|---|
| Disponibilité générale du service | Garantir un accès constant des utilisateurs au service | S'assurer que les serveurs et services sont accessibles en permanence |
| Disponibilité de l’API | Garantir la disponibilité des fonctions critiques | Vérifier que les endpoints (ex : recherche) sont disponibles et répondent |
| Disponibilité de la base de données | Assurer le bon fonctionnement des traitements backend | S'assurer que la base Elasticsearch répond aux vérifications d'état |
| Disponibilité géographique | Garantir la fiabilité selon les régions | Vérifier que le service est opérationnel dans chaque région disponible |
Par exemple, pour notre application métier, nous avons :
Dans cet exemple de SLO, nous pouvons vérifier la disponibilité du service Elastic dans toutes les régions disponibles pour notre application métier.
SLOs orientés sur la latence
Ces SLOs mesurent le temps que met un service à répondre à une requête ou à exécuter une transaction, afin de garantir des performances rapides pour les utilisateurs.
| Aspect | Cas d’usage / Objectif |
|---|---|
| Temps de chargement d’une page web | Garantir une expérience utilisateur fluide, sans interruption |
| Temps de réponse d’une API | Assurer une interaction fluide entre microservices, sans latence excessive |
| Latence des requêtes en base de données | Fournir une réponse en temps réel lors de l’accès aux données |
| Latence géographique | Atteindre les objectifs de performance spécifiques à chaque zone géographique |
Dans notre exemple, un objectif de niveau de service (SLO) est défini pour une fonctionnalité de recherche critique, afin de garantir que chaque requête ne dépasse pas 250 millisecondes, dans l’ensemble des régions géographiques desservies.
SLOs orientés taux d'erreur
Les SLOs pilotés par le taux d’erreur mesurent le pourcentage de réponses échouées ou incorrectes émises par un service.
Ils ont pour objectif de réduire au minimum les interruptions et les erreurs qui ont un impact direct sur l’expérience utilisateur.
Dans ce cas, le SLO garantit que le taux d’erreur reste faible dans tous les aspects évoqués précédemment (latence, disponibilité, etc.).
Ce que nous avons mis en place
Dans notre cas, nous nous sommes concentrés uniquement sur :
SLOs de latence : Ils mesurent la rapidité de réponse d’un service.
Par exemple : « 95 % des requêtes concernant le moteur de recherche doivent répondre en moins de 300 ms sur une période de 30 jours. »
SLOs de disponibilité : Ils mesurent le temps de bon fonctionnement (uptime) d’un service.
Par exemple : « Le service de recherche doit être disponible 99,9 % du temps. »
SLOs de taux d’erreurs : Ils surveillent la fréquence des requêtes échouées.
Par exemple : « Moins de 0,1 % des requêtes de recherche doivent entraîner une erreur. »
Mécanique du SLO : seuil, fenêtre et méthode de calcul
Pour mieux comprendre cet objectif de niveau de service, examinons comment avons-nous fixé les paramètres qui le définissent. Le seuil est fixé à 250 ms pour définir la latence dans notre contexte, et les paramètres suivants structurent l’évaluation…
| Paramètre | Valeur | Explication |
|---|---|---|
| Durée | 7 jours (glissants) | Le SLO est évalué en continu sur les 7 derniers jours, permettant une vision à court terme de la performance. |
| Méthode de budgétisation | Timeslices (tranches de temps) | La performance est mesurée dans de petites fenêtres temporelles, et non sur l’ensemble des transactions. Cette approche est plus stricte et centrée sur l’expérience utilisateur. |
| Objectif par tranche de temps | 95% | Dans chaque tranche d'une minute, au moins 95 % des transactions doivent respecter le seuil de latence défini (ex. : < 250 ms). |
| Fenêtre temporelle (timeslice) | 1 minute | Chaque tranche dure 1 minute. Chaque minute est évaluée indépendamment. |
| Objectif global (SLO) | 95% | Sur l’ensemble des 7 jours, 95 % des tranches de 1 minute doivent être considérées comme « bonnes » pour que l’objectif soit respecté. |
En résumé :
Chaque minute, le système (via Kibana) vérifie si au moins 95 % des transactions liées à la recherche sont effectuées en moins de 250 ms.
Si cette condition est remplie, la minute est considérée comme “bonne”.
Sur les 7 derniers jours glissants, au moins 95 % de l’ensemble des minutes doivent être “bonnes” pour que le SLO soit respecté.
Surveiller vos engagements contractuelles
Le budget d’erreur définit combien d’erreurs un service peut tolérer sans violer ses objectifs contractuels.
C’est un indicateur de pilotage qui permet de décider quand continuer à déployer et quand se concentrer sur la correction des problèmes avant pénalités contractuelles.
Exemple
Prenons l’exemple d’un service avec un engagement contractuel de disponibilité (SLA) de 99,95 %.
Cela signifie que vous acceptez une indisponibilité maximale de 0,05 % sur une période donnée (le SLO window).
Si la période de référence est mensuelle (30 jours), cela représente :
30 jours × 24 heures × 60 minutes = 43 200 minutes au total.
0,05 % de 43 200 minutes = 21,6 minutes.
Le budget d’erreur est donc de 21,6 minutes d’indisponibilité tolérée par mois.
Au-delà de ce seuil, le SLA est violé, et vous devenez contractuellement redevable de pénalités prévues dans l’accord (réductions, remboursements, etc.)
Cas client
Dans Elastic, il existe deux approches principales pour la budgétisation des SLOs : par tranche de temps (timeslice) et basée sur les occurrences.
SLO par tranche de temps (Timeslice SLO) :
Cette méthode évalue la performance dans des intervalles de temps fixes.
Par exemple : « Dans chaque fenêtre de 5 minutes, au moins 95 % des requêtes doivent respecter le seuil de latence. »
Cela permet d’assurer une performance constante tout au long de la journée.
SLO basé sur les occurrences (Occurrence-Based SLO) :
Cette méthode examine le nombre total d’événements réussis ou échoués sur l’ensemble de la période.
Par exemple : « Sur les 30 derniers jours, 95 % de toutes les requêtes de recherche doivent respecter le seuil de latence. »
Nous prenons deux exemples de SLO de latence appliqués à une fonctionnalité critique d’un service de l’un de nos clients :
le premier utilise une méthode de budgétisation par tranches de temps (timeslicing),
le second repose sur une méthode basée sur les occurrences.
- Commençons par le cas du timeslicing, pour lequel les résultats suivants ont été observés :
Ce que cela mesure :
Le pourcentage de tranches de temps (fenêtres d’1 minute) durant lesquelles au moins 95 % des transactions ont été rapides.
Pourquoi cette valeur peut être élevée :
Même si certaines transactions sont lentes, chaque tranche d’une minute est considérée comme “bonne” dès lors que la majorité des transactions respecte le seuil de latence.
En revanche, l’utilisation de la méthode basée sur les occurrences donne les résultats suivants :
Ce que cela mesure :
Le pourcentage de transactions individuelles qui respectent le seuil de latence défini.
Pourquoi cette valeur peut être faible :
Parce qu’un grand nombre de transactions lentes ont été enregistrées.
Même si elles sont réparties dans le temps, chaque requête lente est comptabilisée individuellement comme une erreur dans le calcul du SLI.
Et ensuite ?
La définition de SLOs clairs, appuyés par une méthode de budgétisation adaptée (par tranches de temps ou par occurrences), permet de mesurer objectivement la performance d’un service et d’anticiper les risques avant qu’ils n’impactent les utilisateurs.
Ces objectifs sont directement liés aux engagements contractuels (SLAs) et s’inscrivent dans une démarche de pilotage de la fiabilité via le budget d’erreur.
Ce dernier définit la marge de tolérance aux défaillances et agit comme un indicateur d’alerte en cas de dérive.
Lorsqu’il est épuisé, il devient essentiel de ralentir les évolutions pour se concentrer sur la stabilité et la qualité de service.
Si vous souhaitez mettre en place des SLOs adaptés à votre environnement ou optimiser ceux déjà en place, n’hésitez pas à nous contacter.