Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Conception de systèmes distribués à haute disponibilité sur AWS
Les sections précédentes ont principalement porté sur la disponibilité théorique des charges de travail et sur ce qu'elles peuvent accomplir. Il s'agit d'un ensemble important de concepts à garder à l'esprit lorsque vous créez des systèmes distribués. Ils vous aideront à définir votre processus de sélection des dépendances et à mettre en œuvre la redondance.
Nous avons également examiné la relation entre MTTDMTTR, et avec MTBF la disponibilité. Cette section présentera des conseils pratiques basés sur la théorie précédente. En bref, les charges de travail d'ingénierie pour la haute disponibilité visent à augmenter MTBF et MTTR à réduire leMTTD.
L'idéal serait d'éliminer toutes les défaillances, mais ce n'est pas réaliste. Dans les grands systèmes distribués où les dépendances sont profondément empilées, des défaillances sont susceptibles de se produire. « Tout échoue tout le temps » (voir Werner Vogels, Amazon.comCTO, [10 leçons tirées de 10 ans d'Amazon Web Services](https://www.allthingsdistributed.com/2016/03/10-lessons-from-10-years-of-aws.html).) et « Vous ne pouvez pas légiférer contre l'échec [alors] concentrez-vous sur une détection et une réponse rapides ». (voir Chris Pinkham, membre fondateur de l'EC2équipe Amazon, [ARC335Designing for failure : Architecting Resilient Systems](https://d1.awsstatic.com/events/reinvent/2019/REPEAT_1_Designing_for_failure_Architecting_resilient_systems_on_AWS_ARC335-R1.pdf) on) AWS
Cela signifie que vous n'avez souvent aucun contrôle sur l'éventualité d'une défaillance. Ce que vous pouvez contrôler, c'est la rapidité avec laquelle vous détectez la panne et prenez des mesures pour y remédier. Ainsi, bien que l'augmentation MTBF reste un élément important de la haute disponibilité, les changements les plus importants que les clients peuvent contrôler sont la réduction MTTD etMTTR.
**Topics**
+ [Réduire MTTD](reducing-mttd.md)
+ [Réduire MTTR](reducing-mttr.md)
+ [En augmentation MTBF](increasing-mtbf.md)
# Réduire MTTD
Pour réduire le nombre MTTD de défaillances, il faut les découvrir le plus rapidement possible. Le raccourcissement MTTD est basé sur l'observabilité, c'est-à-dire sur la manière dont vous avez instrumenté votre charge de travail pour comprendre son état. Les clients doivent surveiller leurs indicateurs d'*expérience client* dans les sous-systèmes critiques de leur charge de travail afin d'identifier de manière proactive le moment où un problème survient (voir l'[annexe 1) MTTD et les indicateurs MTTR critiques](appendix-1-mttd-and-mttr-critical-metrics.md) pour plus d'informations sur ces indicateurs. ). Les clients peuvent utiliser [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) pour *créer* des canaris qui surveillent APIs votre expérience utilisateur et celle de vos consoles afin de mesurer de manière proactive l'expérience utilisateur. Il existe un certain nombre d'autres mécanismes de vérification de l'état qui peuvent être utilisés pour les minimiserMTTD, tels que les [contrôles de santé d'Elastic Load Balancing (ELB)](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-add-elb-healthcheck.html), les [contrôles de santé d'Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-types.html), etc. (Voir [Amazon Builders' Library — Implementation des bilans de santé.)](https://aws.amazon.com/builders-library/implementing-health-checks/)
Votre surveillance doit également être capable de détecter les défaillances partielles du système dans son ensemble et de vos sous-systèmes individuels. Vos indicateurs de disponibilité, de défaillance et de latence doivent utiliser la dimensionnalité de vos limites d'isolation des pannes comme [dimensions CloudWatch métriques](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Dimension). Par exemple, considérez une EC2 instance unique faisant partie d'une architecture basée sur des cellules, dans l'AZ use1-az1, dans la région us-east-1, qui fait partie de la mise à jour de la charge de travail qui fait partie de son sous-système de plan de contrôle. API Lorsque le serveur envoie ses métriques, il peut utiliser son identifiant d'instance, son AZ, sa région, son nom et API le nom du sous-système comme dimensions. Cela vous permet d'avoir de l'observabilité et de définir des alarmes pour chacune de ces dimensions afin de détecter les défaillances.
# Réduire MTTR
Après la découverte d'une défaillance, le reste du MTTR temps est consacré à la réparation effective ou à l'atténuation de l'impact. Pour réparer ou atténuer une panne, vous devez savoir ce qui ne va pas. Deux groupes clés de mesures fournissent des informations au cours de cette phase : 1/ les métriques *d'évaluation d'impact* et 2/ les métriques de *santé opérationnelle*. Le premier groupe indique l'ampleur de l'impact en cas de panne, en mesurant le nombre ou le pourcentage de clients, de ressources ou de charges de travail affectés. Le deuxième groupe aide à déterminer *pourquoi* il y a un impact. Une fois le pourquoi découvert, les opérateurs et l'automatisation peuvent réagir et résoudre la panne. Reportez-vous à [l'annexe 1 MTTD et MTTR aux mesures critiques](appendix-1-mttd-and-mttr-critical-metrics.md) pour plus d'informations sur ces mesures.
**Règle 9**
L'observabilité et l'instrumentation sont essentielles pour réduire MTTD etMTTR.
## Parcours pour contourner l'échec
L'approche la plus rapide pour atténuer l'impact consiste à utiliser des sous-systèmes rapides qui contournent les défaillances. Cette approche utilise la redondance pour réduire la charge de travail en MTTR transférant rapidement le travail d'un sous-système défaillant vers un sous-système de rechange. La redondance peut aller des processus logiciels aux EC2 instances, en passant par plusieurs ou plusieurs AZs régions.
Les sous-systèmes de rechange peuvent les MTTR réduire à presque zéro. Le temps de reprise correspond uniquement à ce qu'il faut pour réacheminer le travail vers le serveur de réserve. Cela se produit souvent avec une latence minimale et permet au travail de se terminer dans les délais définisSLA, tout en maintenant la disponibilité du système. MTTRsCela se traduit par des retards légers, voire imperceptibles, plutôt que par des périodes d'indisponibilité prolongées.
Par exemple, si votre service utilise des EC2 instances situées derrière un Application Load Balancer ALB (), vous pouvez configurer des contrôles de santé à un intervalle de cinq secondes seulement et n'exiger que deux tests de santé ayant échoué avant qu'une cible ne soit marquée comme non saine. Cela signifie qu'en 10 secondes, vous pouvez détecter une panne et arrêter d'envoyer du trafic vers l'hôte défaillant. Dans ce cas, MTTR c'est effectivement le même que le cas MTTD puisque dès que la panne est détectée, elle est également atténuée.
C'est ce que cherchent *à atteindre les charges de travail à haute disponibilité* ou *à disponibilité continue*. Nous voulons contourner rapidement les défaillances de la charge de travail en détectant rapidement les sous-systèmes défaillants, en les marquant comme défaillants, en cessant de leur envoyer du trafic et en envoyant le trafic vers un sous-système redondant.
Notez que l'utilisation de ce type de mécanisme de rapidité rend votre charge de travail très sensible aux erreurs transitoires. Dans l'exemple fourni, assurez-vous que les vérifications de l'état de votre équilibreur de charge ne portent que [https://aws.amazon.com/builders-library/implementing-health-checks/](https://aws.amazon.com/builders-library/implementing-health-checks/) non sur les dépendances ou les flux de travail (souvent appelées vérifications de santé *approfondies*). Cela permettra d'éviter le remplacement inutile d'instances lors d'erreurs transitoires affectant la charge de travail.
L'observabilité et la capacité à détecter les défaillances dans les sous-systèmes sont essentielles à la réussite du contournement des défaillances. Vous devez connaître l'ampleur de l'impact afin que les ressources affectées puissent être signalées comme étant défectueuses ou défaillantes et mises hors service afin de pouvoir être réacheminées. Par exemple, si le service d'une seule zone de disponibilité est partiellement perturbé, votre instrumentation devra être en mesure d'identifier l'existence d'un problème localisé dans la zone AZ pour acheminer toutes les ressources de cette zone jusqu'à ce qu'elle soit rétablie.
La capacité à contourner les défaillances peut également nécessiter un outillage supplémentaire en fonction de l'environnement. En utilisant l'exemple précédent avec des EC2 instances situées derrière unALB, imaginez que les instances d'une zone géographique passent avec succès les tests de santé locaux, mais qu'une déficience isolée de la zone Z les empêche de se connecter à leur base de données dans une autre zone. Dans ce cas, les contrôles de santé de l'équilibrage de charge ne mettront pas ces instances hors service. Un mécanisme automatisé différent serait nécessaire pour [supprimer l'AZ de l'équilibreur de charge](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-subnets.html) ou forcer les instances à échouer à leurs tests de santé, ce qui dépend de l'identification du fait que l'étendue de l'impact est une AZ. Pour les charges de travail qui n'utilisent pas d'équilibreur de charge, une méthode similaire serait nécessaire pour empêcher les ressources d'une zone de travail spécifique d'accepter des unités de travail ou de supprimer complètement de la capacité de la zone de gestion.
Dans certains cas, le transfert du travail vers un sous-système redondant ne peut pas être automatisé, comme le basculement d'une base de données principale vers une base de données secondaire lorsque la technologie ne fournit pas sa propre élection de leader. Il s'agit d'un scénario courant pour les [architectures AWS multirégionales](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/). Étant donné que ces types de basculement nécessitent un certain temps d'arrêt, ne peuvent pas être annulés immédiatement et laissent la charge de travail sans redondance pendant un certain temps, il est important de faire participer un humain au processus décisionnel.
Les charges de travail qui peuvent adopter un modèle de cohérence moins strict peuvent être réduites MTTRs en utilisant l'automatisation du basculement multirégional pour contourner les défaillances. Des fonctionnalités telles que [la réplication entre régions Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html) ou les tables globales [Amazon DynamoDB](https://aws.amazon.com/dynamodb/global-tables/) fournissent des fonctionnalités multirégionales grâce à une réplication finalement cohérente. De plus, l'utilisation d'un modèle de cohérence assoupli est bénéfique lorsque l'on considère le CAP théorème. Lors de pannes réseau qui ont un impact sur la connectivité aux sous-systèmes dynamiques, si la charge de travail choisit la disponibilité plutôt que la cohérence, elle peut toujours fournir des réponses sans erreur, ce qui constitue un autre moyen de contourner les défaillances.
Le routage en cas de défaillance peut être mis en œuvre à l'aide de deux stratégies différentes. La première stratégie consiste à implémenter la stabilité statique en préprovisionnant suffisamment de ressources pour gérer la charge complète du sous-système défaillant. Il peut s'agir d'une EC2 instance unique ou d'une capacité totale d'AZ. Tenter de provisionner de nouvelles ressources en cas de panne augmente le plan de contrôle MTTR et ajoute une dépendance à celui-ci dans votre chemin de restauration. Cependant, cela entraîne des frais supplémentaires.
La deuxième stratégie consiste à acheminer une partie du trafic du sous-système défaillant vers d'autres sous-systèmes et à [éliminer le trafic excédentaire](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload) qui ne peut pas être traité par la capacité restante. Au cours de cette période de dégradation, vous pouvez augmenter le volume de nouvelles ressources pour remplacer la capacité défaillante. Cette approche est plus longue MTTR et crée une dépendance à l'égard d'un plan de contrôle, mais elle coûte moins cher en réserve et en capacité de réserve.
## Retour à un état connu en bon état
Une autre approche courante pour atténuer les risques pendant la réparation consiste à remettre la charge de travail dans un état normal connu auparavant. Si une modification récente est susceptible d'être à l'origine de l'échec, l'annulation de cette modification est un moyen de revenir à l'état précédent.
Dans d'autres cas, des conditions transitoires peuvent être à l'origine de l'échec, auquel cas le redémarrage de la charge de travail peut atténuer l'impact. Examinons ces deux scénarios.
Lors d'un déploiement, la minimisation de la MTTD terre MTTR repose sur l'observabilité et l'automatisation. Votre processus de déploiement doit surveiller en permanence la charge de travail pour détecter toute augmentation des taux d'erreur, une latence accrue ou des anomalies. Une fois ceux-ci reconnus, le processus de déploiement doit être interrompu.
Il existe différentes [stratégies de déploiement](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/deployment-strategies.html), telles que les déploiements sur place, les déploiements bleu/vert et les déploiements progressifs. Chacun d'entre eux peut utiliser un mécanisme différent pour revenir à un état dont le fonctionnement a été vérifié. Il peut revenir automatiquement à l'état précédent, ramener le trafic vers l'environnement bleu ou nécessiter une intervention manuelle.
CloudFormation [offre la possibilité de revenir en arrière automatiquement dans](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-rollback-triggers.html) le cadre de ses opérations de création et de mise à jour de la pile, comme le fait [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html#deployments-rollback-and-redeploy-automatic-rollbacks). CodeDeploy prend également en charge les déploiements bleu/vert et les déploiements progressifs.
Pour tirer parti de ces fonctionnalités et minimiser les vôtresMTTR, envisagez d'automatiser l'ensemble de votre infrastructure et de vos déploiements de code par le biais de ces services. Dans les scénarios où vous ne pouvez pas utiliser ces services, envisagez d'implémenter le [modèle Saga](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-the-serverless-saga-pattern-by-using-aws-step-functions.html) AWS Step Functions pour annuler les déploiements ayant échoué.
Lorsque l'on envisage le *redémarrage*, il existe plusieurs approches différentes. Cela va du redémarrage d'un serveur, la tâche la plus longue, au redémarrage d'un thread, la tâche la plus courte. Voici un tableau qui décrit certaines des approches de redémarrage et les durées approximatives d'exécution (représentatives de la différence d'ordres de grandeur, elles ne sont pas exactes).
| Mécanisme de restauration en cas de panne | Estimé MTTR |
| --- | --- |
| Lancer et configurer un nouveau serveur virtuel | 15 minutes |
| Redéployez le logiciel | 10 minutes |
| Redémarrer le serveur | 5 minutes |
| Redémarrer ou lancer le conteneur | 2 secondes |
| Invoquer une nouvelle fonction sans serveur | 100 millisecondes |
| Processus de redémarrage | 10 millisecondes |
| Redémarrer le fil | 10 μs |
MTTREn examinant le tableau, l'utilisation de conteneurs et de fonctions sans serveur (comme [AWS Lambda](https://aws.amazon.com/lambda/)) présente des avantages évidents. Ils MTTR sont bien plus rapides que le redémarrage d'une machine virtuelle ou le lancement d'une nouvelle machine. Cependant, l'utilisation de l'isolation des défauts par le biais de la modularité logicielle est également avantageuse. Si vous pouvez contenir l'échec d'un seul processus ou thread, la reprise après cette défaillance est beaucoup plus rapide que le redémarrage d'un conteneur ou d'un serveur.
Comme approche générale de la restauration, vous pouvez passer de bas en haut : 1/Restart, 2/Reboot, 3/RE-image/Redeploy, 4/Replace. Cependant, une fois que vous avez atteint l'étape de redémarrage, le routage en cas d'échec est généralement une approche plus rapide (cela prend généralement 3 à 4 minutes au maximum). Ainsi, pour atténuer le plus rapidement possible l'impact d'une tentative de redémarrage, contournez la panne puis, en arrière-plan, poursuivez le processus de restauration pour rétablir la capacité de votre charge de travail.
**Règle 10**
Concentrez-vous sur l'atténuation des impacts et non sur la résolution des problèmes. Prenez le chemin le plus rapide pour revenir à un fonctionnement normal.
## Diagnostic des défaillances
Une partie du processus de réparation après la détection est la période de diagnostic. Il s'agit de la période pendant laquelle les opérateurs tentent de déterminer ce qui ne va pas. Ce processus peut impliquer d'interroger les journaux, de passer en revue les indicateurs de santé opérationnelle ou de se connecter aux hôtes pour résoudre les problèmes. Toutes ces actions prennent du temps. La création d'outils et de runbooks pour accélérer ces actions peut également contribuer à MTTR les réduire.
## Runbooks et automatisation
De même, une fois que vous avez déterminé ce qui ne va pas et quel plan d'action permettra de réparer la charge de travail, les opérateurs doivent généralement suivre un ensemble d'étapes pour y parvenir. Par exemple, après une panne, le moyen le plus rapide de réparer la charge de travail peut être de la redémarrer, ce qui peut impliquer plusieurs étapes ordonnées. L'utilisation d'un manuel qui automatise ces étapes ou fournit des instructions spécifiques à un opérateur accélérera le processus et contribuera à réduire le risque d'action involontaire.
# En augmentation MTBF
Le dernier élément pour améliorer la disponibilité consiste à augmenter leMTBF. Cela peut s'appliquer à la fois au logiciel et aux AWS services utilisés pour l'exécuter.
## Élargir le système distribué MTBF
L'un des moyens d'augmenter MTBF est de réduire les défauts du logiciel. Il existe plusieurs méthodes pour le faire. Les clients peuvent utiliser des outils tels qu'[Amazon CodeGuru Reviewer](https://aws.amazon.com/codeguru/) pour détecter et corriger les erreurs courantes. Vous devez également effectuer des révisions complètes du code par les pairs, des tests unitaires, des tests d'intégration, des tests de régression et des tests de charge sur le logiciel avant son déploiement en production. L'augmentation de la couverture du code dans les tests permettra de garantir que même les chemins d'exécution de code peu courants sont testés.
Le déploiement de modifications mineures peut également aider à éviter des résultats inattendus en réduisant la complexité des modifications. Chaque activité permet d'identifier et de corriger les défauts avant qu'ils ne puissent être invoqués.
Une autre approche pour prévenir les défaillances consiste à [effectuer des tests réguliers](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html). La mise en œuvre d'un programme d'ingénierie du chaos peut vous aider à tester les défaillances de votre charge de travail, à valider les procédures de reprise et à identifier et corriger les modes de défaillance avant qu'ils ne surviennent en production. Les clients peuvent utiliser le [simulateur d'injection de AWS défauts](https://aws.amazon.com/fis/) dans le cadre de leur ensemble d'outils d'expérimentation d'ingénierie du chaos.
La tolérance aux pannes est un autre moyen de prévenir les défaillances dans un système distribué. Les modules rapides, les nouvelles tentatives avec retard et instabilité exponentiels, les transactions et l'idempotencie sont autant de techniques qui contribuent à rendre les charges de travail tolérantes aux pannes.
Les transactions sont un groupe d'opérations qui respectent les ACID propriétés. Ce sont les suivants :
+ **Atomicité** — Soit toutes les actions se produisent, soit aucune d'entre elles ne se produira.
+ **Cohérence** — Chaque transaction laisse la charge de travail dans un état valide.
+ **Isolation** — Les transactions effectuées simultanément laissent la charge de travail dans le même état que si elles avaient été effectuées de manière séquentielle.
+ **Durabilité** — Une fois qu'une transaction est validée, tous ses effets sont préservés, même en cas de défaillance de la charge de travail.
Les nouvelles tentatives avec [retard et instabilité exponentiels](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) vous permettent de surmonter les défaillances transitoires causées par des Heisenbugs, une surcharge ou d'autres conditions. Lorsque les transactions sont idempotentes, elles peuvent être réessayées plusieurs fois sans effets secondaires.
Si nous prenons en compte l'effet d'un Heisenbug sur une configuration matérielle tolérante aux pannes, nous ne nous inquiétons guère, car la probabilité que le Heisenbug apparaisse à la fois sur le sous-système principal et sur le sous-système redondant est infiniment faible. (Voir Jim Gray, « [Pourquoi les ordinateurs s'arrêtent-ils et que peut-on faire pour y remédier ?](https://pages.cs.wisc.edu/~remzi/Classes/739/Fall2018/Papers/gray85-easy.pdf) », juin 1985, Rapport technique de Tandem 85.7.) Dans les systèmes distribués, nous voulons obtenir les mêmes résultats avec nos logiciels.
Lorsqu'un Heisenbug est invoqué, il est impératif que le logiciel détecte rapidement l'opération incorrecte et échoue afin de pouvoir réessayer. Ceci est réalisé grâce à une programmation défensive et à la validation des entrées, des résultats intermédiaires et des sorties. De plus, les processus sont isolés et ne partagent aucun état avec les autres processus.
Cette approche modulaire garantit que l'ampleur de l'impact en cas de panne est limitée. Les processus échouent indépendamment. Lorsqu'un processus échoue, le logiciel doit utiliser des « paires de processus » pour recommencer le travail, ce qui signifie qu'un nouveau processus peut assumer le travail d'un processus défaillant. Pour maintenir la fiabilité et l'intégrité de la charge de travail, chaque opération doit être traitée comme une ACID transaction.
Cela permet à un processus d'échouer sans altérer l'état de la charge de travail en annulant la transaction et en annulant les modifications apportées. Cela permet au processus de restauration de réessayer la transaction à partir d'un état dont le fonctionnement a été vérifié et de redémarrer correctement. C'est ainsi que le logiciel peut être tolérant aux pannes face aux Heisenbugs.
Cependant, vous ne devez pas viser à rendre le logiciel tolérant aux bohrbugs. Ces défauts doivent être détectés et corrigés avant que la charge de travail n'entre en production, car aucun niveau de redondance ne permettra d'obtenir un résultat correct. (Voir Jim Gray, « [Pourquoi les ordinateurs s'arrêtent-ils et que peut-on faire pour y remédier ?](https://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf) », juin 1985, Rapport technique de Tandem 85.7.)
La dernière méthode d'augmentation MTBF consiste à réduire la portée de l'impact d'une défaillance. L'utilisation de [l'isolation des pannes](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html) par modularisation pour créer des conteneurs de défaillances est un moyen principal d'y parvenir, comme indiqué précédemment dans *Tolérance aux pannes et isolation des pannes*. La réduction du taux de défaillance améliore la disponibilité. AWS utilise des techniques telles que la division des services en plans de contrôle et en plans de données, [l'indépendance des zones de disponibilité](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) (AZI), l'[isolation régionale](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/), les [architectures basées sur les cellules](https://www.youtube.com/watch?v=swQbA4zub20) et le [shuffle-sharding](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding) pour isoler les pannes. Ce sont également des modèles qui peuvent également être utilisés par les AWS clients.
Par exemple, examinons un scénario dans lequel une charge de travail plaçait les clients dans différents conteneurs de défaillances de son infrastructure desservant au plus 5 % du total des clients. L'un de ces conteneurs d'erreurs connaît un événement qui augmente la latence au-delà du délai d'expiration du client pour 10 % des demandes. Lors de cet événement, pour 95 % des clients, le service était disponible à 100 %. Pour les 5 % restants, le service semblait être disponible à 90 %. Cela se traduit par une disponibilité de 1 − (5 % *o* *f* *c* *u* *s* *t* *o* *m* *e* *r* *s* × 10 % *o* *f* *t* *h* *e* *i* *r *r** e *q* *u* **e** *s *t* *s**) = 99,5 % au lieu de 10 % des demandes échouées pour 100 % des clients (soit une disponibilité de 90 %).
**Règle 11**
L'isolation des défaillances réduit la portée de l'impact et augmente la charge MTBF de travail en réduisant le taux de défaillance global.
## Dépendance croissante MTBF
La première méthode pour augmenter votre AWS dépendance MTBF consiste à utiliser l'[isolation des pannes](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html). De nombreux AWS services offrent un certain niveau d'isolation au niveau de l'AZ, ce qui signifie qu'une panne dans un AZ n'affecte pas le service dans un AZ différent.
L'utilisation d'EC2instances redondantes dans plusieurs instances AZs augmente la disponibilité des sous-systèmes. AZIfournit une capacité d'épargne au sein d'une seule région, ce qui vous permet d'augmenter la disponibilité de vos AZI services.
Cependant, tous les AWS services ne fonctionnent pas au niveau AZ. Beaucoup d'autres offrent un isolement régional. Dans ce cas, lorsque la disponibilité prévue du service régional ne prend pas en charge la disponibilité globale requise pour votre charge de travail, vous pouvez envisager une approche multirégionale. Chaque région propose une instanciation isolée du service, ce qui équivaut à du sparing.
Il existe différents services qui facilitent la création d'un service multirégional. Par exemple :
+ [Base de données mondiale Amazon Aurora](https://aws.amazon.com/rds/aurora/global-database/)
+ [Tableaux globaux Amazon DynamoDB](https://aws.amazon.com/dynamodb/global-tables/)
+ [Amazon ElastiCache (RedisOSS) — Banque de données mondiale](https://aws.amazon.com/elasticache/redis/global-datastore/)
+ [AWS Accélérateur mondial](https://aws.amazon.com/global-accelerator/)
+ [Réplication entre régions Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)
+ [Contrôleur de restauration d'applications Amazon Route 53](https://aws.amazon.com/route53/application-recovery-controller/)
Ce document n'aborde pas les stratégies de création de charges de travail multirégionales, mais vous devez évaluer les avantages de disponibilité des architectures multirégionales avec les coûts supplémentaires, la complexité et les pratiques opérationnelles nécessaires pour atteindre les objectifs de disponibilité souhaités.
La méthode suivante pour augmenter la dépendance MTBF consiste à concevoir votre charge de travail de manière à ce qu'elle soit statiquement stable. Par exemple, vous avez une charge de travail qui fournit des informations sur les produits. Lorsque vos clients font une demande pour un produit, votre service adresse une demande à un service de métadonnées externe pour récupérer les détails du produit. Votre charge de travail renvoie ensuite toutes ces informations à l'utilisateur.
Toutefois, si le service de métadonnées n'est pas disponible, les demandes de vos clients échouent. Au lieu de cela, vous pouvez extraire ou transférer de manière asynchrone les métadonnées localement vers votre service afin de les utiliser pour répondre aux demandes. Cela élimine l'appel synchrone au service de métadonnées depuis votre chemin critique.
En outre, étant donné que votre service est toujours disponible même lorsque le service de métadonnées ne l'est pas, vous pouvez le supprimer en tant que dépendance dans votre calcul de disponibilité. Cet exemple repose sur l'hypothèse selon laquelle les métadonnées ne changent pas fréquemment et qu'il vaut mieux servir des métadonnées périmées que l'échec de la demande. Un autre exemple similaire est celui de [Serve-Stale](https://www.rfc-editor.org/rfc/rfc8767), DNS qui permet de conserver les données dans le cache au-delà de TTL leur expiration et de les utiliser pour les réponses lorsqu'une réponse actualisée n'est pas facilement disponible.
La dernière méthode pour augmenter la dépendance MTBF consiste à réduire la portée de l'impact d'une défaillance. Comme indiqué précédemment, l'échec n'est pas un événement binaire, il existe des degrés de défaillance. C'est l'effet de la modularisation ; l'échec est limité aux demandes ou aux utilisateurs desservis par ce conteneur.
Cela permet de réduire le nombre de défaillances lors d'un événement, ce qui augmente en fin de compte la disponibilité de la charge de travail globale en limitant l'étendue de l'impact.
## Réduire les sources d'impact communes
En 1985, Jim Gray a découvert, lors d'une étude menée par Tandem Computers, que les défaillances étaient principalement dues à deux facteurs : le logiciel et les opérations. (Voir Jim Gray, « [Pourquoi les ordinateurs s'arrêtent-ils et que peut-on faire pour y remédier ?](https://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf) », juin 1985, Rapport technique de Tandem 85.7.) Même 36 ans plus tard, cela continue d'être vrai. Malgré les avancées technologiques, il n'existe pas de solution facile à ces problèmes, et les principales causes de défaillance n'ont pas changé. La résolution des défaillances logicielles a été abordée au début de cette section. L'accent sera donc mis ici sur les opérations et la réduction de la fréquence des défaillances.
### Stabilité par rapport aux fonctionnalités
Si nous nous référons au graphique des taux d'échec du logiciel et du matériel dans la section[Disponibilité du système distribué](distributed-system-availability.md), nous pouvons remarquer que des défauts sont ajoutés dans chaque version logicielle. Cela signifie que toute modification de la charge de travail augmente le risque de défaillance. Ces modifications concernent généralement de nouvelles fonctionnalités, ce qui constitue un corollaire. Des charges de travail à disponibilité plus élevée favoriseront la stabilité par rapport aux nouvelles fonctionnalités. Ainsi, l'un des moyens les plus simples d'améliorer la disponibilité consiste à déployer moins souvent ou à proposer moins de fonctionnalités. Les charges de travail qui sont déployées plus fréquemment seront intrinsèquement moins disponibles que celles qui ne le sont pas. Cependant, les charges de travail qui n'ajoutent pas de fonctionnalités ne répondent pas à la demande des clients et peuvent devenir moins utiles au fil du temps.
Alors, comment continuer à innover et à publier des fonctionnalités en toute sécurité ? La réponse est la standardisation. Quelle est la bonne méthode de déploiement ? Comment commandez-vous des déploiements ? Quelles sont les normes de test ? Combien de temps attendez-vous entre les étapes ? Vos tests unitaires couvrent-ils une partie suffisante du code logiciel ? La normalisation répondra à ces questions et évitera les problèmes causés par des facteurs tels que l'absence de tests de charge, le fait de sauter des étapes de déploiement ou un déploiement trop rapide sur un trop grand nombre d'hôtes.
La façon dont vous implémentez la standardisation passe par l'automatisation. Cela réduit les risques d'erreurs humaines et permet aux ordinateurs de faire ce pour quoi ils sont doués, c'est-à-dire faire toujours la même chose de la même manière. La façon dont vous combinez standardisation et automatisation consiste à définir des objectifs. Des objectifs tels que l'absence de modifications manuelles, l'accès à l'hôte uniquement par le biais de systèmes d'autorisation conditionnelsAPI, l'écriture de tests de charge pour chacun, etc. L'excellence opérationnelle est une norme culturelle qui peut nécessiter des changements substantiels. L'établissement et le suivi des performances par rapport à un objectif contribuent à susciter un changement culturel qui aura un impact important sur la disponibilité de la charge de travail. Le pilier [AWS Well-Architected Operational Excellence fournit des meilleures pratiques complètes pour l'excellence opérationnelle](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html).
### Sécurité des opérateurs
L'autre facteur majeur qui contribue aux événements opérationnels qui entraînent des défaillances sont les personnes. Les humains commettent des erreurs. Ils peuvent utiliser des informations d'identification incorrectes, saisir la mauvaise commande, appuyer sur Entrée trop tôt ou manquer une étape critique. Toute action manuelle entraîne systématiquement des erreurs, ce qui entraîne un échec.
L'une des principales causes des erreurs des opérateurs réside dans les interfaces utilisateur confuses, peu intuitives ou incohérentes. Jim Gray a également noté dans son étude de 1985 que « les interfaces qui demandent des informations à l'opérateur ou lui demandent d'exécuter une fonction doivent être simples, cohérentes et tolérantes aux pannes de l'opérateur ». (Voir Jim Gray, « [Pourquoi les ordinateurs s'arrêtent-ils et que peut-on faire pour y remédier ?](https://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf) », juin 1985, Rapport technique de Tandem 85.7.) Cette idée est toujours vraie aujourd'hui. Au cours des trente dernières années, il existe de nombreux exemples dans l'industrie où une interface utilisateur confuse ou complexe, l'absence de confirmation ou d'instructions, ou même simplement un langage humain peu convivial ont incité un opérateur à faire le mauvais choix.
**Règle 12**
Permettez aux opérateurs de prendre facilement les bonnes décisions.
### Prévenir les surcharges
Le dernier contributeur commun à l'impact est constitué par vos clients, les véritables utilisateurs de votre charge de travail. Les charges de travail réussies ont tendance à s'habituer, dans une large mesure, mais cette utilisation dépasse parfois la capacité d'évolution de la charge de travail. De nombreuses choses peuvent se produire : les disques peuvent être saturés, les pools de threads peuvent être épuisés, la bande passante réseau peut être saturée ou les limites de connexion à la base de données peuvent être atteintes.
Il n'existe pas de méthode infaillible pour les éliminer, mais une surveillance proactive de la capacité et de l'utilisation par le biais de métriques Operational Health fournira des alertes précoces lorsque de telles défaillances pourraient survenir. Des techniques telles que le [délestage](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload), [les disjoncteurs](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-interactions-in-a-distributed-system-to-mitigate-or-withstand-failures.html) et les nouvelles [tentatives avec recul et instabilité exponentiels peuvent aider à minimiser l'impact et à augmenter le taux](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) de réussite, mais ces situations constituent tout de même un échec. La mise à l'échelle automatisée basée sur les indicateurs de santé opérationnelle peut aider à réduire la fréquence des pannes dues à une surcharge, mais risque de ne pas être en mesure de répondre assez rapidement aux changements d'utilisation.
Si vous devez garantir la disponibilité continue de la capacité pour les clients, vous devez faire des compromis en termes de disponibilité et de coût. L'un des moyens de garantir que le manque de capacité n'entraîne pas d'indisponibilité est de fournir un quota à chaque client et de veiller à ce que la capacité de votre charge de travail soit adaptée à 100 % des quotas alloués. Lorsque les clients dépassent leur quota, ils sont limités, ce qui n'est pas un échec et n'est pas pris en compte dans la disponibilité. Vous devrez également suivre de près votre clientèle et prévoir son utilisation future afin de maintenir une capacité suffisante. Cela garantit que votre charge de travail n'est pas entraînée par des scénarios de défaillance en raison d'une consommation excessive par vos clients.
+ [Amazon Builders' Library — Utiliser le délestage pour éviter les surcharges](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/)
+ [Amazon Builders' Library — Équité dans les systèmes multi-locataires](https://aws.amazon.com/builders-library/fairness-in-multi-tenant-systems)
Par exemple, examinons une charge de travail qui fournit un service de stockage. Chaque serveur de la charge de travail peut prendre en charge 100 téléchargements par seconde, les clients disposent d'un quota de 200 téléchargements par seconde, et il y a 500 clients. Pour pouvoir prendre en charge ce volume de clients, le service doit fournir une capacité de 100 000 téléchargements par seconde, ce qui nécessite 1 000 serveurs. Si un client dépasse son quota, il est limité, ce qui garantit une capacité suffisante pour tous les autres clients. Il s'agit d'un exemple simple d'une façon d'éviter la surcharge sans rejeter les unités de travail.