Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

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 les AWS services utilisés, 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 l'une de l'autre. Pour ce faire, toutes les dépendances de la charge de travail doivent être examinées de près pour s'assurer qu'elles sont disponibles dans chaque région. Cela est nécessaire car une panne dans la région principale ne devrait pas avoir d'impact dans la région de secours. En outre, il est impératif de connaître le fonctionnement de la charge de travail lorsqu'une dépendance est dégradée ou totalement indisponible, afin que des solutions puissent être conçues pour gérer cette situation de manière appropriée.

3a : AWS services 

Lors de la conception d'une architecture multirégionale, il est nécessaire de comprendre les AWS services spécifiques qui seront utilisés. Le premier aspect consiste à comprendre les fonctionnalités dont dispose le service pour permettre l'utilisation de plusieurs régions, et si une solution doit être conçue pour atteindre les objectifs multirégionaux. Par exemple, avec Amazon Aurora et Amazon DynamoDB, il existe une fonctionnalité permettant de répliquer les données de manière asynchrone vers une région de secours. Toutes les dépendances de AWS service devront être disponibles dans toutes les régions à partir desquelles une charge de travail sera exécutée. Pour vous assurer que les services qui seront utilisés sont disponibles dans les régions souhaitées, consultez la liste de Région AWS tous les services. 

3b : Dépendances internes et tierces

En ce qui concerne les dépendances internes d'une charge de travail, assurez-vous qu'elle est disponible auprès des régions à partir desquelles la charge de travail fonctionnera. Par exemple, si la charge de travail est composée de nombreux microservices, connaissez tous les microservices qui constituent une fonctionnalité commerciale. À partir de là, assurez-vous que tous ces microservices sont déployés dans chaque région à partir de laquelle la charge de travail fonctionnera.

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 annule les avantages que vous essayez d'obtenir avec 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 impératif 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 veille est située plus loin de l'environnement sur site, l'augmentation de la latence aura un impact négatif.

Comprendre les solutions SaaS (Software as a Service), les kits de développement logiciel (SDK) et les autres dépendances entre 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 d'une application, qu'il s'agisse de la façon dont les secrets sont gérés en externe à l'aide d'AWS Secrets Manager ou d'une solution de coffre-fort tierce (telle que Hashicorp), ou de systèmes d'authentification dépendant d'IAM Identity Center pour les connexions fédérées.

La redondance en matière de dépendances peut contribuer à accroître la résilience. Il est également possible qu'une solution SaaS ou une dépendance tierce utilise le même primaire Région AWS que la charge de travail. Dans ce cas, vous devez travailler avec le fournisseur pour déterminer si sa posture de résilience correspond aux exigences de la 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.

3c : Mécanisme de basculement

Le système de noms de domaine (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 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 est également US-East-1. Si un autre mécanisme de basculement est utilisé, il est nécessaire de bien comprendre tout scénario dans lequel il ne fonctionnerait pas comme prévu. Une fois cette compréhension établie, planifiez les mesures d'urgence ou élaborez un nouveau mécanisme si nécessaire. Consultez la section Création de mécanismes de reprise après sinistre à l'aide d'Amazon Route 53 pour découvrir les approches que vous pouvez utiliser pour réussir le basculement sur incident.

Comme indiqué dans la section sur les dépendances internes, 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, les capacités de l'entreprise doivent basculer simultanément pour éliminer le risque d'appels interrégionaux. Par ailleurs, si les microservices basculent indépendamment, cela peut entraîner un comportement indésirable dans lequel les microservices peuvent effectuer des appels interrégionaux, ce qui entraîne une latence et peut entraîner l'indisponibilité de la charge de travail en cas d'expiration du délai d'attente du client.

3d : Dépendances de configuration

Les certificats, les clés, les secrets et les paramètres font partie de l'analyse de dépendance nécessaire lors de la conception pour plusieurs régions. Dans la mesure du possible, il est préférable de localiser ces composants dans chaque région afin qu'ils ne soient pas partagés entre les régions en ce qui concerne ces dépendances. Pour les certificats, l'expiration doit varier selon les régions et, si possible, dans chaque région, afin d'éviter qu'un certificat expirant (avec des alarmes configurées pour avertir à l'avance) 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