Scénario à cinq 9 (99,999 %) ou supérieur avec un temps de récupération inférieur à 1 minute

Cet objectif de disponibilité pour les applications exige des temps d'arrêt et des pertes de données quasi-nuls pour les périodes spécifiques. Les applications qui pourraient avoir cet objectif de disponibilité comprennent, par exemple, certaines applications bancaires, d'investissement, financières, gouvernementales, et des applications commerciales critiques qui représentent l'activité principale d'une entreprise générant des revenus extrêmement élevés. L'objectif est d'atteindre des magasins de données ayant une cohérence forte et une redondance complète sur toutes les couches. Nous avons sélectionné un magasin de données SQL. Toutefois, dans certains scénarios, il est difficile d'atteindre un très petit RPO. Si vous pouvez partitionner les données, il est possible de n'avoir aucune perte de données. Pour cela, il peut être nécessaire d'ajouter la logique d'application et la latence afin de garantir la cohérence des données entre les emplacements géographiques, ainsi que la capacité de déplacer ou de copier des données entre les partitions. L'exécution de ce partitionnement peut être plus facile si vous utilisez une base de données NoSQL.

Nous pouvons améliorer davantage la disponibilité en utilisant une Actif-actif sur plusieurs régions AWS. La charge de travail sera déployée dans toutes les régions souhaitées qui sont statiquement stable parmi les régions (afin que les régions restantes puissent gérer la charge avec la perte d'une région). Un routage dirige le trafic vers des emplacements géographiques sains et modifie automatiquement la destination lorsqu'un emplacement est défectueux tout en arrêtant temporairement les couches de réplication de données. Amazon Route 53 permet des vérifications de l'état à des intervalles de 10 secondes, et une durée de vie (TTL) sur vos ensembles d'enregistrements atteignant seulement une seconde.

Contrôler les ressources

Identique au scénario 3½ 9 s, plus une alerte lorsqu'une région est détectée comme étant défectueuse ; le trafic est alors acheminé en dehors de celle-ci.

s'adapter aux modifications de la demande ;

Identique au scénario 3½ 9 s.

Implémentation de la modification

Le pipeline de déploiement dispose d'une suite de tests complète, y compris les tests de performance, de charge et de provocation de pannes. Nous déployons les mises à jour en utilisant les modèles de déploiement Canary ou bleu/vert dans une zone d'isolation à la fois, une région après l'autre. Au cours du déploiement, les anciennes versions continueront à exécuter les instances afin de faciliter une restauration plus rapide. Elles sont entièrement automatisées, et permettent une restauration à un état antérieur si les indicateurs de performance clé indiquent un problème. La surveillance inclut des indicateurs de réussite ainsi que des alertes en cas de problème.

Les runbooks sont prévus pour les exigences de rapport strictes et le suivi des performances. Si des opérations fructueuses tendent vers un non-respect des objectifs de performance ou de disponibilité, un playbook est utilisé pour établir la cause de cette tendance. Les playbooks sont prévus pour les modes d'échec non découverts et les incidents de sécurité. Des playbooks sont également prévus pour établir la cause racine des défaillances.

L'équipe qui crée le site Web exploite également ce dernier. Cette équipe identifie la correction d'erreur de toute défaillance inattendue et hiérarchise le correctif à déployer une fois qu'il est mis en œuvre. Nous collaborons également avec AWS Support pour l'offre Infrastructure Event Management.

sauvegarder les données ;

Identique au scénario 3½ 9 s.

Conception de la résilience

Les applications doivent être créées à l'aide des modèles de résilience de logiciel/application. Il est possible que de nombreuses autres couches de routage soient requises pour mettre en œuvre la disponibilité nécessaire. Il ne faut pas sous-estimer la complexité de cette implémentation supplémentaire. L'application sera mise en œuvre dans les zones d'isolation des défaillances de déploiement, et partitionnée et déployée de façon à ce que même un événement à l'échelle de la région n'affecte pas tous les clients.

tester la résilience ;

Nous validons l'architecture par des jeux de rôle en utilisant les runbooks afin de nous assurer que nous pouvons effectuer les tâches sans nous écarter des procédures.

Planification de la reprise après sinistre

Actif-actif Déploiement multirégion actif-actif avec une infrastructure de charge de travail complète et des données dans plusieurs régions. Dans le cadre d'une stratégie globale en lecture locale et en écriture, une région constitue la base de données principale de toutes les écritures et les données sont répliquées pour les lectures vers d'autres régions. Si la région de base de données principale échoue, une nouvelle base de données doit être promue. Dans un système de lecture local et d’écriture globale, les utilisateurs sont affectés à une région d'origine dans laquelle les écritures de base de données sont gérées. Cela permet aux utilisateurs de lire ou d'écrire à partir de n'importe quelle région. Ce système requiert toutefois une logique complexe de gestion des conflits de données potentiels entre les écritures dans différentes régions.

Lorsqu'une région est détectée comme défectueuse, la couche de routage achemine automatiquement le trafic vers les régions saines restantes. Aucune intervention manuelle n'est requise.

Les magasins de données doivent être répliqués entre les régions d'une manière permettant de résoudre les conflits potentiels. Il est nécessaire de créer des outils et processus automatisés pour copier ou déplacer les données entre les partitions pour les raisons de latence et pour équilibrer les requêtes ou les volumes de données dans chaque partition. La correction de la résolution des conflits de données nécessite également des runbooks opérationnels supplémentaires.

Objectif de la conception de la disponibilité

Nous supposons que d'importants investissements sont effectués pour automatiser toutes les restaurations, et que la récupération peut être terminée dans un délai d'une minute. Nous ne supposons aucune récupération déclenchée manuellement, mais au maximum une action de récupération automatisée par trimestre. Cela correspond à quatre minutes par an pour récupérer. 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,999 %.

Résumé

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	Implémentation de zones d'isolation des pannes pour l'application ; Auto Scaling pour fournir un niveau d'application et Web auto-régénérant ; RDS multi-AZ ; basculement régional automatisé.
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	Fonctionnalité active-active déployée dans au moins deux régions. L'infrastructure est entièrement mise à l'échelle et statistiquement stable d'une région à l'autre. Les données sont partitionnées et synchronisées entre les régions. Sauvegardes chiffrées via RDS. La défaillance d'une région est testée au cours d'un test de simulation des pannes et coordonnée avec AWS. Pendant la restauration, il peut être nécessaire de promouvoir une nouvelle base de données principale.