REL 10: Comment utilisez-vous l'isolation des pannes pour protéger votre charge de travail ?

Les limites isolées pour les défaillances limitent l'effet d'une défaillance au sein d'une charge de travail à un nombre limité de composants. Les composants en dehors de la limite ne sont pas affectés par la défaillance. En utilisant plusieurs limites isolées par défaut, vous pouvez limiter l'impact sur votre charge de travail.

Ressources

AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)
Shuffle-sharding: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)
AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (ARC338)
AWS re:Invent 2019: Innovation and operation of the AWS global network infrastructure (NET339)
What is AWS Outposts?
Global Tables: Multi-Region Replication with DynamoDB
AWS Local Zones FAQ
AWS Global Infrastructure
The Amazon Builders' Library: Workload isolation using shuffle-sharding

Bonnes pratiques:

• Déploiement de la charge de travail sur plusieurs emplacements: Distribuez les données et les ressources de charge de travail sur plusieurs zones de disponibilité ou, si nécessaire, entre régions AWS. Ces emplacements peuvent être aussi variés que nécessaire.

• Automatisation de la récupération pour les composants limités à un seul emplacement: Si les composants de la charge de travail ne peuvent s'exécuter que dans une seule zone de disponibilité ou un centre de données sur site, vous devez implémenter la capacité permettant d'effectuer une reconstruction complète de la charge de travail dans le cadre de vos objectifs de récupération définis.

• Utilisation des architectures cloisonnées: À l'instar des cloisons d'un navire, ce modèle garantit qu'une défaillance reste limitée à un petit sous-ensemble de requêtes/utilisateurs afin que le nombre de requêtes compromises soit limité et que la plupart puissent continuer sans erreur. Les cloisons des données sont généralement appelées partitions, tandis que les cloisons des services sont appelées cellules.

Plan d'amélioration

Déploiement de la charge de travail sur plusieurs emplacements

Utilisation de plusieurs zones de disponibilité et régions AWS: Distribuez les données et les ressources de charge de travail sur plusieurs zones de disponibilité ou, si nécessaire, entre régions AWS. Ces emplacements peuvent être aussi variés que nécessaire.

• Les services régionaux sont, par nature, déployés entre les zones de disponibilité.
  • Cela inclut Amazon S3, Amazon DynamoDB et AWS Lambda (lorsqu'il n'est pas connecté à un VPC).
• Déployez votre conteneur, votre instance et vos charges de travail basées sur des fonctions dans plusieurs zones de disponibilité. Utilisation des magasins de données multi-AZ, y compris les caches.: Utilisez les fonctions d'EC2 Auto Scaling, le placement de tâches ECS, la configuration de fonctions AWS Lambda lors de l'exécution de votre VPC et les clusters ElastiCache.
  • Utilisez les sous-réseaux situés dans des zones de disponibilité distinctes lorsque vous déployez des groupes Auto Scaling.
    Example: Distributing instances across Availability Zones
    Amazon ECS task placement strategies
    Configuring an AWS Lambda function to access resources in an Amazon VPC
    Choosing Regions and Availability Zones
  • Utilisez des sous-réseaux situés dans des zones de disponibilité distinctes lorsque vous déployez des groupes Auto Scaling.
    Example: Distributing instances across Availability Zones
  • Utilisez les paramètres de placement des tâches ECS, en spécifiant des groupes de sous-réseaux DB.
    Amazon ECS task placement strategies
  • Utilisez des sous-réseaux dans plusieurs zones de disponibilité lorsque vous configurez une fonction à exécuter dans votre VPC.
    Configuring an AWS Lambda function to access resources in an Amazon VPC
  • Utilisez plusieurs zones de disponibilité avec des clusters ElastiCache.
    Choosing Regions and Availability Zones

Choisissez une stratégie à plusieurs régions si votre charge de travail doit être déployée dans plusieurs régions.: La plupart des besoins de fiabilité peuvent être satisfaits au sein d'une même région AWS à l'aide d'une stratégie à plusieurs zones de disponibilité. Utilisez une stratégie sur plusieurs régions si nécessaire pour répondre aux besoins de votre entreprise.
AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)

• La sauvegarde dans une autre région AWS peut rassurer davantage que les données seront disponibles lorsque cela est nécessaire.
• Il existe, pour certaines charges de travail, des exigences réglementaires qui imposent l'utilisation d'une stratégie à plusieurs régions

Évaluation d'AWS Outposts en fonction de votre charge de travail: Si votre charge de travail nécessite une faible latence de connexion à votre centre de données sur site ou si elle a des exigences locales en matière de traitement des données, Exécutez l'infrastructure et les services AWS sur site à l'aide d'AWS Outposts
What is AWS Outposts?

Déterminez si les zones locales AWS vous aident à fournir un service à vos utilisateurs: o Si vous avez des exigences de faible latence, vérifiez si les zones locales AWS sont situées près de vos utilisateurs. Si oui, utilisez-les pour déployer des charges de travail plus près de ces utilisateurs.
AWS Local Zones FAQ

Automatisation de la récupération pour les composants limités à un seul emplacement

Implémentation de l'autorégénération: Dans la mesure du possible, déployez vos instances ou vos conteneurs en utilisant la mise à l'échelle automatique. Si vous ne pouvez pas utiliser la mise à l'échelle automatique, utilisez la récupération automatique pour les instances EC2 ou mettez en place un mécanisme d'autoréparation basé sur Amazon EC2 ou des événements de cycle de vie de conteneur ECS.

• Utilisez les groupes Auto Scaling pour les instances et les charges de travail de conteneur qui n'ont aucune exigence en matière d'adresse IP d'instance, d'adresse IP privée, d'adresse IP Elastic et de métadonnées d'instance.
  What Is EC2 Auto Scaling?
  Service automatic scaling
  • Les données utilisateur de la configuration de lancement peuvent être utilisées pour mettre en place un mécanisme permettant la récupération automatique de la plupart des charges de travail.
• Utilisez la récupération automatique des instances EC2 pour les charges de travail nécessitant un seul ID d'instance, une seule adresse IP privée, une seule adresse IP Elastic, et des métadonnées d'instance.
  Recover your instance.
  • La récupération automatique envoie des alertes de statut de récupération à une rubrique SNS lorsque la défaillance de l'instance est détectée.
• Utilisez les événements du cycle de vie de l'instance EC2 ou les événements ECS pour automatiser l'autoréparation lorsque la mise à l'échelle automatique ou la récupération de votre instance EC2 ne peuvent pas être utilisées.
  EC2 Auto Scaling lifecycle hooks
  Amazon ECS events
  • Utilisez les événements pour appeler le mécanisme vous permettant de réparer votre composant selon la logique de processus dont vous avez besoin.

Utilisez la récupération automatique des instances EC2 pour les charges de travail nécessitant un seul ID d'instance, une seule adresse IP privée, une seule adresse IP Elastic, et des métadonnées d'instance.
Recover your instance.

• La récupération automatique envoie des alertes de statut de récupération à une rubrique SNS lorsque la défaillance de l'instance est détectée.

Utilisez les événements du cycle de vie de l'instance EC2 ou les événements ECS pour automatiser l'autoréparation lorsque la mise à l'échelle automatique ou la récupération de votre instance EC2 ne peuvent pas être utilisées.
EC2 Auto Scaling lifecycle hooks
Amazon ECS events

• Utilisez les événements pour appeler le mécanisme vous permettant de réparer votre composant selon la logique de processus dont vous avez besoin.

Utilisation des architectures cloisonnées

Utilisation des architectures cloisonnées: À l'instar des cloisons d'un navire, ce modèle garantit qu'une défaillance reste limitée à un petit sous-ensemble de requêtes/utilisateurs afin que le nombre de requêtes compromises soit limité et que la plupart continuent sans erreur. Les cloisons des données sont généralement appelées partitions, tandis que les cloisons des services sont appelées cellules.
Shuffle-sharding: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)
AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (ARC338)

Évaluation de l'architecture basée sur les cellules pour votre charge de travail: Dans une architecture basée sur les cellules, chaque cellule est une instance complète et indépendante du service et a une taille maximale fixe. Les charges de travail augmentent en même temps que la charge par l'ajout de cellules. Une clé de partition est utilisée sur le trafic entrant pour déterminer la cellule qui traitera la requête. Toute défaillance est contenue dans la seule cellule dans laquelle elle se produit, de sorte que le nombre de requêtes compromises soit limité et que les autres puissent continuer sans erreur. Il est important de choisir la bonne clé de partition afin de minimiser les interactions entre cellules et d'éviter d'avoir à utiliser des services de mappage complexes pour chaque requête. Les services qui nécessitent un mappage complexe ne font finalement que déplacer le problème vers les services de mappage, tandis que les services qui nécessitent des interactions entre cellules réduisent l'indépendance des cellules (et, par conséquent, les améliorations de disponibilité présumées qui en découlent).

• Dans son billet de blog AWS, Colm MacCarthaigh explique comment Amazon Route 53 utilise le concept de partitionnement aléatoire pour isoler les demandes des clients en partitions
  Shuffle Sharding: Massive and Magical Fault Isolation