3½ 9 s (99,95 %) avec un temps de récupération compris entre 5 et 30 minutes

Cet objectif de disponibilité pour les applications nécessite très peu de temps d'arrêt et de très faibles pertes de données pendant des périodes spécifiques. Les applications avec cet objectif de disponibilité comprennent les applications dans les domaines suivants : services bancaires, investissements, services d'urgence et capture de données. Ces applications ont des temps de récupération et des points de récupération très courts.

Nous pouvons encore améliorer les temps de récupération en utilisant une Secours à chaud dans deux régions AWS. Nous déployons l’intégralité de la charge de travail pour les deux régions via notre site passif réduit et des données cohérentes à terme. Les deux déploiements seront statiquement stable au sein de leurs régions respectives. Les applications doivent être conçues à l'aide des modèles de résilience du système distribué. Nous allons devoir créer un composant de routage léger qui surveille à la fois l'état de l'application et toutes les dépendances régionales strictes que nous possédons.

Surveiller les ressources

Des alertes sont émises à chaque remplacement d'un serveur Web, lors du basculement de la base de données et du basculement de la région. Nous surveillons également la disponibilité du contenu statique sur Amazon S3 et envoyons une alerte en cas d'indisponibilité. Les logs sont regroupés pour faciliter la gestion et contribuer à l'analyse des causes racines dans chaque région.

Le composant de routage léger surveille à la fois l'état de l'application et toutes les dépendances régionales strictes que nous possédons.

s'adapter aux modifications de la demande ;

Identique au scénario 4 9s.

Implémentation de la modification

La fourniture des nouveaux logiciels se fait selon un calendrier fixe, toutes les deux à quatre semaines. Les mises à jour logicielles sont automatisées grâce aux modèles de déploiement Canary ou bleu/vert.

Les runbooks sont prévus pour le basculement de la région, pour les problèmes courants des clients qui se produisent au cours de ces événements, et pour les rapports courants.

Nous avons des playbooks pour les problèmes de base de données courants, les incidents liés à la sécurité, les échecs de déploiement, les problèmes inattendus des clients lors du basculement de la région et l'établissement de la cause racine des problèmes. Après l'identification de la cause racine, une association des équipes Opérations et Développement identifie la correction de l'erreur et la déploie après avoir développé le correctif.

Nous collaborons également avec AWS Support pour l'offre Infrastructure Event Management.

sauvegarder les données ;

À l'instar du scénario à quatre 9, nous réalisons des sauvegardes RDS automatiques et utilisons la gestion des versions S3. Les données sont automatiquement répliquées de manière asynchrone à partir du cluster Aurora RDS dans la région active vers des réplicas en lecture entre régions dans la région passive. La réplication entre régions S3 est utilisée pour déplacer automatiquement de manière asynchrone les données de la région active vers la région passive.

Conception de la résilience

Identique au scénario 4 9s, avec basculement régional possible. Cette opération est gérée manuellement. Pendant le basculement, nous acheminons les requêtes vers un site Web statique en utilisant le basculement DNS jusqu'à la récupération dans la seconde région.

tester la résilience ;

Identique au scénario 4 9s. Nous validerons également l'architecture au cours des tests de simulation des pannes à l'aide des runbooks. De plus, la correction RCA est prioritaire sur les versions de fonctions pour une implémentation et un déploiement immédiats

Planification de la reprise après sinistre

Le basculement régional est géré manuellement. Toutes les données sont répliquées de manière asynchrone. L'infrastructure de secours à chaud est mise à l'échelle. L'automatisation est possible via un flux de travail exécuté sur AWS Step Functions. AWS Systems Manager (SSM) facilite également cette automatisation, car vous pouvez créer des documents SSM qui mettent à jour les groupes Auto Scaling et redimensionnent les instances.

Objectif de la conception de la disponibilité

Nous supposons que certaines pannes nécessiteront une prise de décision manuelle pour exécuter la récupération, mais avec une bonne automatisation dans ce scénario, nous supposons que seulement deux événements par an exigeront cette décision. Nous prenons 20 minutes à décider d'exécuter la récupération, et supposons que la restauration est terminée dans un délai de 10 minutes. Cela signifie qu'il faut 30 minutes pour reprendre les activités après une défaillance. En supposant deux incidents par an, notre impact estimé pour l'année est de 60 minutes.

Cela signifie que la limite supérieure de disponibilité est de 99,95 %. La disponibilité réelle variera également selon le taux réel de défaillance, la durée des défaillances et la rapidité à laquelle chaque facteur récupère réellement. Pour cette architecture, nous supposons que l'application est en ligne continuellement par le biais de mises à jour. Par conséquent, nos objectif de la conception de la disponibilité est de 99,95 %.

Récapitulatif

Rubrique	Implémentation
Contrôler les ressources	Vérifications de l'état de santé au niveau de toutes les couches, y compris l'état du DNS au niveau de la région AWS et au niveau des indicateurs clés de performance ; alertes envoyées au déclenchement des alarmes configurées ; alerte à la moindre panne. Les réunions opérationnelles sont rigoureuses pour détecter les tendances et gérer les objectifs de conception.
s'adapter aux modifications de la demande ;	ELB pour le niveau d'application de mise à l'échelle Web et automatique ; mise à l'échelle automatique du stockage et réplicas en lecture dans plusieurs zones dans les régions actives et passives pour Aurora RDS. Données et infrastructure synchronisées entre les régions AWS pour garantir la stabilité statique.
Implémentation de la modification	Déploiement automatisé (Canary ou bleu/vert) et restauration automatique lorsque les indicateurs clés de performance ou les alertes indiquent des problèmes non détectés dans l'application. Les déploiements sont effectués vers une zone d'isolement dans une seule région AWS à la fois.
sauvegarder les données ;	Sauvegardes automatisées dans chaque région AWS via RDS pour respecter le RPO et la restauration automatisée pratiquée régulièrement au cours d'un test de simulation des pannes. Les données Aurora RDS et S3 sont répliquées automatiquement de manière asynchrone de la région active vers la région passive.
Conception de la résilience	Mise à l'échelle automatique pour assurer l'auto-régénération au niveau Web et application ; RDS multi-AZ ; basculement régional géré manuellement avec le site statique présenté lors du basculement.
tester la résilience ;	Intégration du test des pannes des composants et des zones d'isolation au pipeline et mise en œuvre régulière par le personnel opérationnel au cours d'un test de simulation de pannes ; playbooks pour diagnostiquer les problèmes inconnus ; processus d'analyse des causes racines avec acheminement des communications sur le type de problème, sa correction et sa prévention. La correction RCA est prioritaire sur les versions de fonctions pour une implémentation et un déploiement immédiats.
Planification de la reprise après sinistre	Secours à chaud déployé dans une autre région. L'infrastructure est mise à l'échelle au moyen de flux de travail exécutés via AWS Step Functions ou de documents d'AWS Systems Manager. Sauvegardes chiffrées via RDS. Réplicas en lecture entre régions entre deux régions AWS. Réplication entre régions des ressources statiques dans Amazon S3. La restauration s'adresse à la région AWS active actuelle. Elle est mise en pratique au cours d'un test de simulation des pannes et est coordonnée avec AWS.