Élément fondamental multirégional 4 : Préparation opérationnelle

L'exploitation d'une charge de travail multirégionale est une tâche complexe qui comporte des défis opérationnels spécifiques à une architecture multirégionale. Il s'agit notamment Compte AWS de la gestion, de la refonte des processus de déploiement, de la création d'une stratégie d'observabilité multirégionale, de la création et du test de processus de reprise, puis de la gestion des coûts. Un examen du niveau de préparation opérationnelle (ORR) peut aider les équipes à préparer une charge de travail pour la production, qu'elle soit exécutée dans une seule région ou dans plusieurs régions.

4.a : gestion Compte AWS

Pour déployer une charge de travail entre plusieurs régions Régions AWS, assurez-vous que tous les Service AWS quotas d'un compte sont égaux. Tout d'abord, identifiez tout Services AWS ce qui fait partie de l'architecture, examinez l'utilisation prévue dans les régions de secours, puis comparez l'utilisation prévue à l'utilisation actuelle. Dans certains cas, si la région de secours n'a jamais été utilisée auparavant, vous pouvez vous référer aux quotas de service par défaut pour comprendre le point de départ. Ensuite, pour tous les services qui seront utilisés, demandez une augmentation de quota à l'aide de la console Service Quotas (connexion requise) ou APIs.

Configurez les rôles AWS Identity and Access Management (IAM) dans chaque région pour attribuer aux opérateurs, les outils d'automatisation et Services AWS les autorisations appropriées aux ressources de la région de secours. Pour obtenir une isolation régionale pour les architectures multirégionales, isolez les rôles par région. Assurez-vous que les autorisations sont en place avant de passer en ligne avec une région en veille.

4.b : Pratiques de déploiement

Les fonctionnalités multirégionales peuvent compliquer le déploiement d'une charge de travail dans plusieurs régions. Vous devez vous assurer que vous déployez dans une région à la fois. Par exemple, si vous utilisez une approche active-passive, vous devez d'abord effectuer le déploiement dans la région principale, puis dans la région de secours. AWS CloudFormationvous aide à déployer l'infrastructure dans une ou plusieurs régions et peut être adaptée en fonction de vos besoins. AWS CodePipelinevous permet de créer un pipeline integration/continuous delivery (CI/CD (continu) comportant des actions interrégionales qui permettent le déploiement dans des régions différentes de la région dans laquelle se trouve le pipeline. Ceci, combiné à des stratégies de déploiement robustes telles que le bleu/vert, permet un déploiement de temps d'arrêt minimal, voire nul.

Toutefois, le déploiement de fonctionnalités dynamiques peut devenir plus complexe lorsque l'état de l'application ou des données n'est pas externalisé vers un magasin persistant. Dans ces situations, adaptez soigneusement le processus de déploiement à vos besoins. Concevez le pipeline et le processus de déploiement pour déployer dans une région à la fois au lieu de déployer simultanément dans plusieurs régions. Cela réduit le risque de défaillances corrélées entre les régions. Pour en savoir plus sur les techniques utilisées par Amazon pour automatiser les déploiements de logiciels, consultez l'article Automating safe and handoff deployments de la AWS Builders' Library.

4.c : Observabilité

Lorsque vous concevez pour plusieurs régions, réfléchissez à la manière dont vous allez surveiller l'état de tous les composants de chaque région afin d'obtenir une vision globale de la santé régionale. Cela peut inclure des mesures de surveillance du délai de réplication, ce qui n'est pas pris en compte pour une charge de travail à région unique.

Lorsque vous créez une architecture multirégionale, pensez également à observer les performances de la charge de travail depuis les régions de secours. Cela inclut un bilan de santé et des canaris (tests synthétiques) effectués depuis la région de réserve afin de fournir un aperçu extérieur de l'état de santé de la région principale. En outre, vous pouvez utiliser Amazon CloudWatch Internet Monitor pour comprendre l'état du réseau externe et les performances de vos charges de travail du point de vue de l'utilisateur final. La région principale doit disposer de la même observabilité pour surveiller la région de réserve.

Les canaris de la région d'attente doivent surveiller les indicateurs de l'expérience client afin de déterminer l'état général de la charge de travail. Cela est nécessaire car en cas de problème dans la région principale, l'observabilité dans la région principale pourrait être altérée et cela aurait un impact sur votre capacité à évaluer l'état de la charge de travail.

Dans ce cas, l'observation en dehors de cette région peut fournir des informations. Ces mesures doivent être regroupées dans des tableaux de bord disponibles dans chaque région et dans des alarmes créées dans chaque région. Comme il CloudWatchs'agit d'un service régional, il est obligatoire d'avoir des alarmes dans les deux régions. Ces données de surveillance seront utilisées pour faire basculer l'appel d'une région principale vers une région de secours.

4.d : Processus et procédures

C'est le meilleur moment pour répondre à la question : « Quand dois-je échouer ? » est bien avant que vous n'en ayez besoin. Définissez des plans de reprise qui incluent les personnes, les processus et les technologies bien avant la survenue d'un problème, et testez-les régulièrement. Décidez d'un cadre décisionnel en matière de recouvrement. S'il existe un processus de restauration bien rodé et que le délai de restauration est bien connu, vous pouvez choisir de démarrer le processus de restauration en utilisant un basculement qui répond à l'objectif du RTO. Ce moment peut être immédiatement après l'identification d'un problème avec l'application dans la région principale, ou il peut s'agir d'un événement ultérieur lorsque les options de restauration de l'application dans la région ont été épuisées.

L'action de basculement elle-même doit être automatisée à 100 %, mais la décision d'activer le basculement doit être prise par des humains, généralement un petit nombre de personnes prédéterminées au sein de l'organisation. Ces personnes devraient tenir compte de la perte de données et d'informations sur l'événement. En outre, les critères d'un basculement doivent être clairement définis et compris globalement au sein de l'organisation. Pour définir et exécuter ces processus, vous pouvez utiliser des AWS Systems Manager runbooks, qui permettent une end-to-end automatisation complète et garantissent la cohérence des processus exécutés pendant les tests et le basculement.

Ces runbooks doivent être disponibles dans les régions principale et de secours pour démarrer les processus de basculement ou de retour en arrière. Lorsque cette automatisation est en place, définissez et suivez une cadence de test régulière. Cela garantit que lorsqu'un événement se produit, la réponse suit un processus bien défini et mis en pratique dans lequel l'organisation a confiance. Il est également important de prendre en compte les tolérances établies pour les processus de rapprochement des données. Confirmez que le processus proposé répond aux exigences RPO/RTO établies.

4.e : Tests

Avoir une approche de rétablissement non testée équivaut à ne pas avoir d'approche de rétablissement. Un niveau de test de base consiste à exécuter une procédure de restauration pour changer de région d'exploitation pour votre application. C'est ce que l'on appelle parfois une approche de rotation des applications. Nous vous recommandons de développer la capacité de changer de région pour adopter votre position opérationnelle normale ; toutefois, ce test à lui seul ne suffit pas.

Les tests de résilience sont également essentiels pour valider l'approche de restauration d'une application. Cela implique d'injecter des scénarios de défaillance particuliers, de comprendre comment votre application et votre processus de restauration réagissent, puis de mettre en œuvre les mesures d'atténuation nécessaires si le test ne se déroule pas comme prévu. Le fait de tester votre procédure de restauration en l'absence d'erreur ne vous indiquera pas comment votre application se comporte dans son ensemble en cas de panne. Vous devez élaborer un plan pour tester votre reprise par rapport aux scénarios de défaillance attendus. AWS Fault Injection Servicefournit une liste croissante de scénarios pour vous aider à démarrer.

Cela est particulièrement important pour les applications à haute disponibilité, où des tests rigoureux sont nécessaires pour garantir que les objectifs de continuité des activités sont atteints. Le test proactif des capacités de restauration réduit le risque de défaillances en production, ce qui permet de s'assurer que l'application peut atteindre le temps de restauration limité souhaité. Des tests réguliers renforcent également l'expertise opérationnelle, ce qui permet à l'équipe de se remettre rapidement et de manière fiable en cas de panne lorsqu'elle survient. L'exercice de l'élément humain, ou du processus, de votre approche de rétablissement est tout aussi essentiel que les aspects techniques.

4.f : Coût et complexité

Les implications financières d'une architecture multirégionale dépendent de l'augmentation de l'utilisation de l'infrastructure, des frais opérationnels et du temps consacré aux ressources. Comme indiqué précédemment, le coût d'infrastructure dans une région de secours est similaire à celui d'une région principale lors du préprovisionnement, ce qui double votre coût total. Fournir une capacité suffisante pour les opérations quotidiennes tout en préservant une capacité tampon suffisante pour tolérer les pics de demande. Configurez ensuite les mêmes limites dans chaque région.

En outre, si vous adoptez une architecture active-active, vous devrez peut-être apporter des modifications au niveau de l'application pour exécuter correctement votre application dans une architecture multirégionale. La conception et l'exploitation de ces modifications peuvent nécessiter beaucoup de temps et de ressources. Au minimum, les entreprises doivent consacrer du temps à comprendre les dépendances techniques et commerciales de chaque région et à concevoir des processus de basculement et de reprise.

Les équipes devraient également effectuer des exercices de basculement et de retour en arrière normaux pour se sentir à l'aise avec les runbooks qui seraient utilisés lors d'un événement. Bien que ces exercices soient essentiels pour obtenir les résultats escomptés d'un investissement multirégional, ils représentent un coût d'opportunité et privent du temps et des ressources d'autres activités.

4.g : Stratégie organisationnelle de basculement multirégionale

Régions AWS fournir des limites d'isolation des défaillances qui empêchent les défaillances corrélées et limitent l'impact Service AWS des déficiences, lorsqu'elles se produisent, sur une seule région. Vous pouvez utiliser ces limites de défauts pour créer des applications multirégionales composées de répliques indépendantes isolées des défauts dans chaque région afin de limiter les scénarios de destin partagé. Cela vous permet de créer des applications multirégionales et d'utiliser une gamme d'approches (sauvegarde et restauration, pilote, active-active) pour implémenter votre architecture multirégionale. Cependant, les applications ne fonctionnent généralement pas de manière isolée. Par conséquent, considérez à la fois les composants que vous utiliserez et leurs dépendances dans le cadre de votre stratégie de basculement. En général, plusieurs applications fonctionnent ensemble pour soutenir une histoire utilisateur, une fonctionnalité spécifique proposée à un utilisateur final, telle que la publication d'une photo et d'une légende sur une application de réseau social ou le paiement sur un site de commerce électronique. Pour cette raison, vous devez développer une stratégie organisationnelle de basculement multirégionale qui assure la coordination et la cohérence nécessaires au succès de votre approche.

Il existe quatre stratégies de haut niveau parmi lesquelles les organisations peuvent choisir pour orienter une approche multirégionale. Elles sont répertoriées de l'approche la plus détaillée à la plus large :

• Basculement au niveau des composants

• Basculement d'une application individuelle

• Basculement du graphe de dépendances

• Basculement de l'ensemble du portefeuille d'applications

Chaque stratégie comporte des compromis et répond à différents défis, notamment la flexibilité de la prise de décision en cas de basculement, la capacité de tester les combinaisons de basculement, la présence d'un comportement modal et l'investissement organisationnel dans la planification et la mise en œuvre. Pour en savoir plus sur chaque stratégie, consultez le billet de AWS blog Création d'une stratégie de basculement multirégionale organisationnelle.

Principaux conseils

• Passez en revue tous les Service AWS quotas pour vous assurer qu'ils sont égaux dans toutes les régions dans lesquelles la charge de travail sera appliquée.

• Le processus de déploiement doit cibler une région à la fois au lieu d'impliquer plusieurs régions simultanément.

• Des mesures supplémentaires telles que le délai de réplication sont spécifiques aux scénarios multirégionaux et doivent être surveillées.

• Étendre la surveillance de la charge de travail au-delà de la région principale. Surveillez les indicateurs de l'expérience client pour chaque région et mesurez ces données en dehors de chaque région dans laquelle une charge de travail est exécutée.

• Testez régulièrement le failover et le failback. Implémentez un seul runbook pour les processus de basculement et de retour en arrière et utilisez-le à la fois pour les tests et les événements en direct. Les runbooks destinés aux tests et aux événements en direct ne devraient pas être différents.

• Comprenez les compromis liés aux stratégies de basculement. Implémentez un graphe de dépendances ou une stratégie de portefeuille d'applications complète.