Scénarios d’architectures résilientes et hautement disponibles

Scénario : Une entreprise exploite une application Web à deux niveaux (ALB → EC2 → RDS) et souhaite éliminer tout point de défaillance unique au sein de la AWS Region. Solution : Déployez des instances EC2 dans un groupe Auto Scaling couvrant au moins 2 Availability Zones, derrière un ALB (qui est intrinsèquement Multi-AZ). Activez RDS Multi-AZ pour une réplication synchrone vers une instance de secours. Configurez des vérifications d’état sur l’ALB afin de rediriger automatiquement le trafic loin des instances défaillantes. Avec cette architecture, la perte d’une seule AZ entraîne un basculement automatique à chaque niveau.

Scénario : L’instance RDS d’une application de commerce électronique atteint ses limites de CPU aux heures de pointe en raison de requêtes d’analyse principalement orientées lecture provenant de l’équipe de business intelligence. Solution : Créez des RDS Read Replicas et dirigez les requêtes de BI vers le point de terminaison de la réplique. Les Read Replicas utilisent une réplication asynchrone : un léger retard est acceptable pour les analyses. Cela décharge l’instance RDS principale du trafic de lecture, qui est réservée aux opérations d’écriture et aux lectures de l’application. Pour les charges de travail très fortement orientées lecture, ajoutez une couche ElastiCache devant RDS pour les données fréquemment consultées.

Scénario : Une API sans état s’exécute sur EC2 derrière un ALB. L’utilisation du CPU atteint 90 % pendant les heures de bureau et tombe presque à zéro la nuit. L’entreprise souhaite que son parc se mette automatiquement à l’échelle. Solution : Configurez un groupe Auto Scaling avec une politique de mise à l’échelle Target Tracking visant une utilisation moyenne du CPU de 60 %. ASG ajoute automatiquement des instances lorsque le CPU dépasse 60 % et en supprime lorsqu’il passe sous la cible. Ajoutez une action de mise à l’échelle planifiée pour préchauffer la capacité minimale avant le début des heures de bureau et éviter un ralentissement lors du pic de trafic matinal.

Scénario : Une entreprise exploite une application Web principale dans us-east-1 et souhaite basculer vers une page de maintenance statique hébergée sur S3 dans us-west-2 si l’application principale devient indisponible. Solution : Créez une vérification d’état Route 53 surveillant le point de terminaison de l’ALB principal. Créez deux enregistrements Route 53 avec une politique de routage par basculement : l’enregistrement Primary pointe vers l’ALB (associé à la vérification d’état) et l’enregistrement Secondary pointe vers le site statique S3. Si la vérification d’état échoue, Route 53 fournit automatiquement la réponse DNS de l’enregistrement secondaire.

Scénario : Un Backend de traitement des commandes écrit dans une Database, mais celle-ci devient parfois indisponible pendant les fenêtres de maintenance, ce qui entraîne la perte de commandes. Solution : Placez une Queue SQS entre le Frontend (qui accepte les commandes) et le Backend (qui les traite). Les commandes sont immédiatement placées dans la Queue, ce qui fournit une confirmation instantanée au client. Des workers en arrière-plan récupèrent les commandes dans la Queue et les traitent lorsque la Database est disponible. Pendant la maintenance, les commandes s’accumulent au lieu d’être supprimées, ce qui assure la résilience grâce au découplage asynchrone.

Scénario : Une entreprise a besoin d’une solution de reprise après sinistre avec un RPO de 1 heure et un RTO de 4 heures, pour un budget modéré. Solution : Mettez en œuvre une stratégie DR Pilot Light. Conservez la Database principale répliquée vers la DR Region à l’aide d’une RDS Cross-Region Read Replica. Les serveurs d’application ne fonctionnent pas dans la DR Region en fonctionnement normal : seul le « cœur » minimal (la Database) reste prêt. En cas de sinistre, promouvez la Read Replica en instance autonome et lancez les serveurs d’application à partir d’AMIs précréées avec CloudFormation. Le RTO se mesure en heures plutôt qu’en minutes, car les serveurs doivent être lancés.

Scénario : Les messages d’une Queue SQS échouent à plusieurs reprises lors de leur traitement en raison d’un bogue dans la fonction Lambda consommatrice. Les messages réapparaissent sans cesse et bloquent la Queue. Solution : Configurez une Dead-Letter Queue (DLQ) sur la Queue principale. Après l’échec du traitement d’un message un nombre configurable de fois (maxReceiveCount), SQS le déplace automatiquement vers la DLQ au lieu de le distribuer indéfiniment. Cela libère la Queue principale pour les messages valides. Définissez une alarme CloudWatch sur la métrique ApproximateNumberOfMessagesVisible de la DLQ afin d’alerter l’équipe d’ingénierie lorsque des messages s’y accumulent.

Scénario : Une entreprise exerce ses activités aux US et en Europe. Les utilisateurs européens subissent une latence élevée lors des lectures dans la Database, car RDS se trouve dans us-east-1. Solution : Utilisez Amazon Aurora Global Database. Le cluster principal se trouve dans us-east-1 ; un cluster secondaire en lecture seule est ajouté dans eu-west-1. Aurora réplique les données vers la Region secondaire avec une latence typique inférieure à 1 seconde grâce à une réplication au niveau du stockage. Les utilisateurs européens lisent les données depuis le cluster secondaire d’eu-west-1. En cas de sinistre régional, le cluster secondaire peut être promu au rôle de cluster principal en moins d’une minute, ce qui constitue le meilleur RTO parmi les options de bases de données AWS multi-régions.

Scénario : Un service d’API conteneurisé exécuté sur ECS Fargate doit se mettre à l’échelle en fonction de l’utilisation du CPU et résister aux défaillances d’AZ. Solution : Enregistrez le service ECS auprès d’un groupe cible d’Application Load Balancer afin de répartir le trafic entre les tâches en cours d’exécution. Placez les tâches dans plusieurs AZ en spécifiant plusieurs sous-réseaux dans la configuration du service. Configurez l’Auto Scaling du service ECS avec une politique Target Tracking basée sur l’utilisation du CPU du service ECS afin d’augmenter ou de réduire automatiquement le nombre de tâches. Si une AZ tombe en panne, ECS redémarre les tâches défaillantes dans des AZ saines.

Scénario : Une entreprise exploite deux instances EC2 dans des AZ différentes, qui servent le même domaine. Elle souhaite que Route 53 cesse automatiquement d’envoyer du trafic vers une instance indisponible. Solution : Utilisez le routage pondéré Route 53 avec des poids égaux (50/50) et associez une vérification d’état du point de terminaison à chaque enregistrement. Lorsque Route 53 détecte un point de terminaison indisponible, il retire cet enregistrement des réponses DNS et envoie 100 % du trafic vers le point de terminaison sain. Lorsque l’instance récupère et que les vérifications d’état réussissent à nouveau, Route 53 rééquilibre automatiquement le trafic : aucune modification DNS manuelle n’est nécessaire.

Scénario : Une application de jeu mobile doit permettre de lire et d’écrire les données des joueurs avec une faible latence depuis us-east-1 comme depuis ap-southeast-1. Une Table DynamoDB dans une seule Region entraîne une latence élevée pour les utilisateurs asiatiques. Solution : Activez DynamoDB Global Tables. Global Tables réplique automatiquement les données entre les Regions spécifiées grâce à une réplication multi-maître : chaque Region peut accepter des écritures. Les utilisateurs asiatiques écrivent et lisent depuis la Replica d’ap-southeast-1 avec une latence locale (environ 5 ms). Global Tables résout les conflits selon une stratégie « dernier écrivain gagnant », fondée sur les horodatages. Le RTO en cas de défaillance régionale complète est presque nul : le trafic est simplement dirigé vers la Region restante.

Vérifiez votre compréhension des concepts AWS Solutions Architect (SAA-C03) présentés dans cette leçon.

Dans cette leçon, vous avez étudié des scénarios portant sur un ASG Multi-AZ et RDS pour la HA au sein d’une Region, le routage par basculement Route 53 pour la DR inter-régions, une DLQ SQS pour isoler les messages en échec sans bloquer les Queues, ainsi qu’Aurora Global Database pour la mise à l’échelle des lectures inter-régions et le basculement avec un RTO inférieur à une minute. Nous allons maintenant aborder des scénarios d’architecture hautes performances et optimisée en termes de coûts.