3.2 - Améliorer la fiabilité et la tolérance aux pannes
L'objectif 3.2 de l'AWS Solutions Architect Professional couvre le renforcement de la fiabilité et de la tolérance aux pannes d'un système existant. Tu insères une file SQS entre un service de commandes et une couche de facturation surchargée pour que les requêtes se tamponnent au lieu de tomber, et tu stoppes les tempêtes de retries synchronisés avec un backoff exponentiel et du jitter qui étale les retries clients. Le routage failover Route 53 avec un contrôle de santé sur le primaire envoie le trafic vers un secours seulement quand le primaire est défaillant, un circuit breaker à court timeout empêche une dépendance non critique lente de cascader en panne, et Systems Manager Patch Manager avec patch baselines et maintenance windows remplace le patch SSH ad hoc, avec des baselines et fenêtres séparées par environnement. Une dead-letter queue avec un redrive policy maxReceiveCount isole les messages toxiques, Cost Explorer trouve la dépense par service et tag, et tu récupères de la valeur des engagements sous-utilisés en vendant des RI Standard sur le Marketplace ou en échangeant des RI Convertible. Attends-toi à des mises en situation sur les tempêtes de retries, la dégradation gracieuse ou le patch contrôlé, et à choisir le bon motif de résilience.
Tamponner les requêtes pendant un pic aval = insérer une file SQS. Stopper les tempêtes de retries synchronisés = backoff exponentiel avec jitter. Une dépendance non critique lente ne doit pas cascader = circuit breaker à court timeout.
Questions d'entraînement
1. Une chaîne synchrone de microservices échoue entièrement dès que le service de facturation en aval est brièvement surchargé, perdant des commandes. L'architecte veut conserver les commandes durant les pics sans les perdre. Quel changement améliore le mieux la résilience ?
- Augmenter le timeout du client HTTP du service commande pour que chaque appel attende simplement bien plus longtemps avant d'échouer
- Insérer une file SQS entre le service commande et la facturation pour tamponner et découpler (bonne réponse)
- Placer les deux services sur une seule instance plus grande pour rester sur le même hôte
- Ajouter une seconde tentative synchrone juste après le premier appel de facturation échoué
Une file SQS découple le producteur du consommateur : les commandes sont tamponnées durablement et la facturation les traite à son rythme, donc les pics ne perdent plus de commandes. Des timeouts plus longs et des retries immédiats surchargent encore le service, et colocaliser les services n'ajoute ni tampon ni isolation des pannes.
2. Une base RDS PostgreSQL de production est en Single-AZ, et un incident de zone a causé une heure d'indisponibilité. L'équipe veut un basculement automatique sans repenser l'application. Que doivent-ils activer ?
- Des snapshots quotidiens automatiques copiés vers une seconde Région pour restauration manuelle
- Un déploiement Multi-AZ avec un standby synchrone qui bascule automatiquement (bonne réponse)
- Deux réplicas de lecture indépendants que l'application promeut elle-même au besoin
- Une classe d'instance plus grande pour que la base unique absorbe plus de charge simultanée
Le Multi-AZ maintient un standby synchrone dans une autre AZ et RDS y bascule automatiquement via un changement DNS, sans repenser l'application. Les snapshots cross-Région exigent une restauration manuelle, des réplicas auto-promus demandent de la logique applicative et sont asynchrones, et une instance plus grande ne fait rien contre une panne de zone.
3. Un tier web sans état derrière un ALB envoie parfois du trafic vers des instances figées mais non plantées, et le parc ne grandit pas sous charge. Quelles DEUX modifications améliorent la disponibilité ? (Choisissez DEUX réponses.)
- Attribuer à chaque instance sa propre Elastic IP fixe pour que les clients se reconnectent toujours directement au même hôte exact
- Configurer des health checks ALB sur un endpoint applicatif pour retirer les cibles malsaines (bonne réponse)
- Activer une politique Auto Scaling qui ajoute des instances quand une métrique de charge monte (bonne réponse)
- Augmenter le timeout d'inactivité de l'ALB pour que les requêtes figées attendent plus longtemps
Des health checks ALB au niveau applicatif détectent une instance figée et cessent de la router jusqu'à sa reprise, tandis qu'une politique Auto Scaling ajoute de la capacité quand la charge monte. Des Elastic IP fixes épinglent les clients à des hôtes et nuisent à l'élasticité, et un timeout d'inactivité plus long garde les requêtes bloquées vivantes.
4. Les consommateurs d'une file SQS rencontrent parfois un message malformé qui échoue sans cesse, est retenté indéfiniment et bloque la progression tout en gonflant le coût de traitement. Quelle est la correction standard ?
- Supprimer chaque message qui échoue une fois pour que la file ne se bloque jamais
- Augmenter le visibility timeout à une valeur extrêmement élevée sur la file principale pour chaque message reçu sans exception
- Configurer une dead-letter queue avec un maxReceiveCount pour isoler les messages empoisonnés (bonne réponse)
- Passer la file de standard à FIFO pour que l'ordre empêche les échecs
Une dead-letter queue avec redrive policy écarte un message après maxReceiveCount réceptions échouées, isolant les messages empoisonnés pour analyse pendant que le traitement sain continue. Supprimer au premier échec perd des messages récupérables, un énorme visibility timeout ne fait que bloquer, et l'ordre FIFO ne corrige pas une charge malformée.
5. Durant une brève panne en aval, des milliers de clients retentent une API défaillante en même temps, et les retries synchronisés martèlent le service juste au moment où il tente de récupérer, prolongeant la panne. Quel motif côté client empêche le mieux cela ?
- Retenter immédiatement sans délai pour réussir dès que le service répond
- Retenter un nombre fixe de fois espacées d'exactement une seconde sur chaque client
- Backoff exponentiel avec jitter pour étaler et espacer les tentatives de retry (bonne réponse)
- Donner à chaque client un budget de retry illimité pour n'abandonner aucune requête
Le backoff exponentiel augmente l'attente entre les tentatives et le jitter la rend aléatoire, donc les retries s'étalent au lieu d'arriver en vagues synchronisées qui submergent un service en reprise. Des retries immédiats ou à intervalle fixe restent synchronisés et amplifient la charge, et des retries illimités retirent la contre-pression nécessaire à la reprise.
6. Une application web mono-Région doit survivre à une panne régionale complète avec un RTO de quelques minutes, en servant depuis une seconde Région automatiquement. Les données sont déjà répliquées entre Régions. Quels DEUX composants complètent un basculement automatique ? (Choisissez DEUX réponses.)
- Un unique enregistrement Route 53 épinglé seulement au load balancer de la Région primaire
- Des health checks Route 53 avec une politique de routage failover entre les deux Régions (bonne réponse)
- Une pile de secours pré-déployée dans la seconde Région prête à prendre le trafic (bonne réponse)
- Un runbook manuel que l'ingénieur d'astreinte suit pour repointer le DNS pendant la panne
Des health checks Route 53 avec une politique de routage failover détectent la Région primaire comme malsaine et basculent automatiquement le DNS vers la seconde Région, et une pile de secours pré-déployée peut y accepter le trafic en quelques minutes. Un enregistrement épinglé unique n'a pas de cible de bascule, et un runbook DNS manuel n'est pas automatique et rate le RTO sous pression.