Principe fondamental 3 pour plusieurs régions : comprendre les dépendances de votre charge de travail

Une charge de travail spécifique peut avoir plusieurs dépendances dans une région, telles que l' Services AWS utilisation, les dépendances internes, les dépendances tierces, les dépendances réseau, les certificats, les clés, les secrets et les paramètres. Pour garantir le fonctionnement de la charge de travail en cas de panne, il ne doit y avoir aucune dépendance entre la région principale et la région de secours ; chacune doit pouvoir fonctionner indépendamment de l'autre. Pour ce faire, examinez toutes les dépendances de la charge de travail pour vous assurer qu'elles sont disponibles dans chaque région. Cela est nécessaire car une défaillance dans la région principale ne devrait pas affecter la région de secours. En outre, vous devez comprendre le fonctionnement de la charge de travail lorsqu'une dépendance est dégradée ou totalement indisponible, afin de pouvoir concevoir des solutions pour gérer cette situation de manière appropriée.

3.a : Services AWS

Lorsque vous concevez une architecture multirégionale, il est important de comprendre Services AWS ce qui sera utilisé, les fonctionnalités multirégionales de ces services et les solutions que vous devrez concevoir pour atteindre les objectifs multirégionaux. Par exemple, Amazon Aurora et Amazon DynamoDB peuvent répliquer des données de manière asynchrone vers une région de secours. Toutes les Service AWS dépendances devront être disponibles dans toutes les régions à partir desquelles une charge de travail sera exécutée. Pour vérifier que les services que vous utilisez sont disponibles dans les régions souhaitées, consultez la liste Services AWS par région.

3.b : Dépendances internes et tierces

Assurez-vous que les dépendances internes de chaque charge de travail sont disponibles dans les régions à partir desquelles elles opèrent. Par exemple, si la charge de travail est composée de nombreux microservices, identifiez tous les microservices qui constituent une capacité commerciale et vérifiez que tous ces microservices sont déployés dans chaque région à partir de laquelle la charge de travail fonctionne. Vous pouvez également définir une stratégie pour gérer avec élégance les microservices devenus indisponibles.

Les appels interrégionaux entre microservices au sein d'une même charge de travail ne sont pas conseillés, et l'isolement régional doit être maintenu. En effet, la création de dépendances entre régions augmente le risque de défaillance corrélée, ce qui compense les avantages des implémentations régionales isolées de la charge de travail. Les dépendances sur site peuvent également faire partie de la charge de travail. Il est donc important de comprendre comment les caractéristiques de ces intégrations pourraient changer si la région principale devait changer. Par exemple, si la région de secours est située plus loin de l'environnement sur site, l'augmentation de la latence peut avoir un impact négatif.

Comprendre les solutions logicielles en tant que service (SaaS), les kits de développement logiciel (SDKs) et les autres dépendances de produits tiers, et être en mesure de mettre en œuvre des scénarios dans lesquels ces dépendances sont dégradées ou indisponibles, permettra de mieux comprendre le fonctionnement et le comportement de la chaîne de systèmes en fonction des différents modes de défaillance. Ces dépendances peuvent se trouver dans le code de votre application, comme la gestion des secrets en externe à l'aide AWS Secrets Manager, ou elles peuvent impliquer une solution de coffre-fort tierce (telle que HashiCorp), ou des systèmes d'authentification dépendants AWS IAM Identity Centerdes connexions fédérées.

La redondance en matière de dépendances peut accroître la résilience. Si une solution SaaS ou une dépendance à un tiers utilise le même primaire Région AWS que la charge de travail, contactez le fournisseur pour déterminer si sa posture de résilience correspond à vos exigences en matière de charge de travail.

En outre, soyez conscient du destin partagé entre la charge de travail et ses dépendances, telles que les applications tierces. Si les dépendances ne sont pas disponibles dans (ou depuis) une région secondaire après un basculement, la charge de travail risque de ne pas être complètement rétablie.

3.c : Mécanisme de basculement

Le DNS est couramment utilisé comme mécanisme de basculement pour transférer le trafic de la région principale vers une région de secours. Passez en revue et examinez de manière critique toutes les dépendances prises par le mécanisme de basculement. Par exemple, si votre charge de travail utilise Amazon Route 53, comprendre que le plan de contrôle est hébergé dans cette région us-east-1 signifie que vous devenez dépendant du plan de contrôle de cette région spécifique. Cela n'est pas recommandé dans le cadre d'un mécanisme de basculement si la région principale l'est également, us-east-1 car cela crée un point de défaillance unique. Si vous utilisez un autre mécanisme de basculement, vous devez avoir une connaissance approfondie des scénarios dans lesquels le basculement ne fonctionnerait pas comme prévu, puis planifier les mesures d'urgence ou développer un nouveau mécanisme si nécessaire. Consultez le billet de blog Creating Disaster Recovery Mechanisms Using Amazon Route 53 pour découvrir les approches que vous pouvez utiliser pour réussir le basculement.

Comme indiqué dans la section précédente, tous les microservices faisant partie d'une capacité commerciale doivent être disponibles dans chaque région dans laquelle la charge de travail est déployée. Dans le cadre de la stratégie de basculement, tous les microservices faisant partie de la capacité commerciale doivent basculer ensemble afin d'éliminer le risque d'appels interrégionaux. Par ailleurs, si les microservices basculent indépendamment, il existe un risque de comportement indésirable, tel que des appels interrégionaux susceptibles de passer des microservices. Cela introduit de la latence et peut entraîner l'indisponibilité de la charge de travail pendant les délais d'expiration du client.

3.d : Dépendances de configuration

Les certificats, les clés, les secrets, les images Amazon Machine (AMIs), les images de conteneur et les paramètres font partie de l'analyse de dépendance nécessaire lors de la conception d'une architecture multirégionale. Dans la mesure du possible, il est préférable de localiser ces composants au sein de chaque région afin qu'ils ne partagent pas le même sort entre les régions en ce qui concerne ces dépendances. Par exemple, vous devez modifier les dates d'expiration des certificats afin d'éviter qu'un certificat expirant (avec des alarmes réglées pour « avertir à l'avance ») n'ait un impact sur plusieurs régions.

Les clés et les secrets de chiffrement doivent également être spécifiques à la région. Ainsi, en cas d'erreur lors de la rotation d'une clé ou d'un secret, l'impact est limité à une région spécifique.

Enfin, tous les paramètres de charge de travail doivent être stockés localement pour que la charge de travail puisse être récupérée dans la région spécifique.

Principaux conseils

• Une architecture multirégionale bénéficie de la séparation physique et logique entre les régions. L'introduction de dépendances entre régions au niveau de la couche d'application annule cet avantage. Évitez de telles dépendances.

• Les contrôles de basculement devraient fonctionner sans aucune dépendance vis-à-vis de la région principale.

• Le basculement doit être coordonné tout au long du parcours de l'utilisateur afin d'éliminer le risque d'augmentation de la latence et de la dépendance des appels interrégionaux.