Services zonaux

L'indépendance de la zone de disponibilité (AZI) permet AWS de proposer des services zonaux, tels qu'Amazon EC2 et Amazon EBS. Un service zonal est un service qui permet de spécifier dans quelle zone de disponibilité les ressources sont déployées. Ces services fonctionnent indépendamment dans chaque zone de disponibilité d'une région et, plus important encore, échouent également indépendamment dans chaque zone de disponibilité. Cela signifie que les composants d'un service dans une zone de disponibilité ne dépendent pas des composants d'autres zones de disponibilité. Nous pouvons le faire parce qu'un service zonal possède des plans de données zonaux. Dans certains cas, comme avec EC2, le service inclut également des plans de contrôle zonaux pour les opérations alignées par zone, telles que le lancement d'une instance EC2. Pour ces services, fournit AWS également un point de terminaison du plan de contrôle régional pour faciliter l'interaction avec le service. Le plan de contrôle régional fournit également des fonctionnalités à portée régionale et sert de couche d'agrégation et de routage au-dessus des plans de contrôle zonaux. Cela est illustré dans la figure suivante.

Un service zonal avec des plans de contrôle et des plans de données isolés par zone

Les zones de disponibilité permettent aux clients de gérer des charges de travail de production plus hautement disponibles, tolérantes aux pannes et évolutives que ce qui serait possible à partir d'un seul centre de données. Lorsqu'une charge de travail utilise plusieurs zones de disponibilité, les clients sont mieux isolés et protégés contre les problèmes qui affectent l'infrastructure physique d'une seule zone de disponibilité. Cela permet aux clients de créer des services redondants dans toutes les zones de disponibilité et, s'ils sont correctement architecturés, de rester opérationnels même en cas de défaillance d'une zone de disponibilité. Les clients peuvent tirer parti d'AZI pour créer des charges de travail hautement disponibles et résilientes. La mise en œuvre d'AZI dans votre architecture vous permet de récupérer rapidement après une défaillance isolée d'une zone de disponibilité, car vos ressources dans une zone de disponibilité minimisent ou éliminent l'interaction avec les ressources des autres zones de disponibilité. Cela permet de supprimer les dépendances entre les zones de disponibilité, ce qui simplifie l'évacuation des zones de disponibilité. Reportez-vous à la section Modèles de résilience multi-AZ avancés pour plus de détails sur la création de mécanismes d'évacuation des zones de disponibilité. En outre, vous pouvez tirer davantage parti des zones de disponibilité en suivant certaines des meilleures pratiques AWS utilisées pour ses propres services, telles que le déploiement des modifications sur une seule zone de disponibilité à la fois ou la suppression d'une zone de disponibilité du service si une modification de cette zone de disponibilité se passe mal.

La stabilité statique est également un concept important pour les architectures de zones de disponibilité multiple. L'un des modes de défaillance que vous devez prévoir avec les architectures à zones de disponibilité multiples est la perte d'une zone de disponibilité, qui peut entraîner la perte de capacité d'une zone de disponibilité. Si vous n'avez pas préprovisionné suffisamment de capacité pour faire face à la perte d'une zone de disponibilité, votre capacité restante peut être submergée par la charge actuelle. En outre, vous devrez vous fier aux plans de contrôle des services zonaux que vous utilisez pour remplacer cette capacité perdue, ce qui peut être moins fiable qu'une conception statiquement stable. Dans ce cas, le pré-provisionnement d'une capacité supplémentaire suffisante peut vous aider à rester statiquement stable face à la perte d'un domaine de défaillance, tel qu'une zone de disponibilité, en étant en mesure de poursuivre vos opérations normales sans avoir besoin de modifications dynamiques.

Vous pouvez choisir d'utiliser un groupe d'instances EC2 à dimensionnement automatique déployées dans plusieurs zones de disponibilité pour effectuer une mise à l'échelle interne et descendante de manière dynamique, en fonction des besoins de votre charge de travail. La mise à l'échelle automatique fonctionne bien pour les changements graduels d'utilisation qui se produisent au fil des minutes, voire des dizaines de minutes. Cependant, le lancement de nouvelles instances EC2 prend du temps, en particulier si vos instances nécessitent un amorçage (par exemple, l'installation d'agents, de fichiers binaires d'applications ou de fichiers de configuration). Pendant ce temps, votre capacité restante pourrait être dépassée par la charge actuelle. En outre, le déploiement de nouvelles instances par le biais de l'autoscaling repose sur le plan de contrôle EC2. Cela présente un inconvénient : pour être statiquement stable face à la perte d'une seule zone de disponibilité, vous devez préapprovisionner suffisamment d'instances EC2 dans les autres zones de disponibilité pour gérer la charge qui a été transférée hors de la zone de disponibilité affectée, au lieu de vous fier à l'autoscaling pour approvisionner de nouvelles instances. Toutefois, le pré-provisionnement en capacité supplémentaire peut entraîner des coûts supplémentaires.

Par exemple, en fonctionnement normal, supposons que votre charge de travail nécessite six instances pour traiter le trafic client dans trois zones de disponibilité. Pour garantir une stabilité statique en cas de défaillance d'une seule zone de disponibilité, vous devez déployer trois instances dans chaque zone de disponibilité, pour un total de neuf. Si une seule instance correspondant à une zone de disponibilité tombait en panne, il vous en resterait six et vous pourriez continuer à traiter le trafic de vos clients sans avoir à approvisionner et à configurer de nouvelles instances en cas de panne. La stabilité statique de votre capacité EC2 entraîne un coût supplémentaire, car dans ce cas, vous exécutez 50 % d'instances supplémentaires. Tous les services pour lesquels vous pouvez préprovisionner des ressources n'entraîneront pas de coûts supplémentaires, tels que le préprovisionnement d'un compartiment S3 ou d'un utilisateur. Vous devrez évaluer les inconvénients liés à la mise en œuvre de la stabilité statique par rapport au risque de dépassement du temps de restauration souhaité pour votre charge de travail.

AWS Les Zones Locales et les Outposts rapprochent le plan de données de certains AWS services des utilisateurs finaux. Les plans de contrôle de ces services se trouvent dans la région parent. Votre instance de zone locale ou d'Outposts comportera des dépendances de plan de contrôle pour les services zonaux tels que EC2 et EBS sur la zone de disponibilité dans laquelle vous avez créé votre zone locale ou votre sous-réseau Outposts. Ils dépendront également des plans de contrôle régionaux pour les services régionaux tels qu'Elastic Load Balancing (ELB), les groupes de sécurité et le plan de contrôle Kubernetes géré par Amazon Elastic Kubernetes Service (Amazon EKS) (si vous utilisez EKS). Pour plus d'informations spécifiques à Outposts, reportez-vous à la documentation et aux FAQ sur le support et la maintenance. Mettez en œuvre la stabilité statique lorsque vous utilisez des Zones Locales ou des Outposts pour améliorer la résilience en cas de défaillance du plan de contrôle ou d'interruption de la connectivité réseau avec la région parent.