Les configurations cloud multirégionales sont populaires pour de bonnes raisons. Le plus important d’entre eux est la nécessité d’une gestion du basculement qui garantit la disponibilité, accélère la reprise après sinistre et évite la perte de données en cas d’incidents majeurs ou de pannes régionales. Nous savons tous que les régions peuvent tomber en panne et qu’un cloud multizone ne suffit pas toujours à éviter des temps d’arrêt prolongés.
Un autre facteur déterminant est le désir de offrir une latence plus faible pour les utilisateurs finaux. Cela est particulièrement vrai si vous disposez d’une base de clients mondiale ou si vous utilisez votre réseau cloud pour exécuter des services sensibles au décalage comme les jeux, le streaming multimédia riche à la demande ou la vidéoconférence. Moins souvent, vous choisirez un cloud multirégional pour vous conformer aux réglementations en matière de traitement des données, bien que cela gagne en importance à mesure que les réglementations se multiplient.
Dans cet article, je partagerai les conseils que j’ai retenus pour optimiser votre architecture cloud multirégionale. Oui, certains seront plus pertinents pour les environnements actifs-actifs, et d’autres seront mieux adaptés pour les environnements actif-passif, mais quel que soit votre cas d’utilisation sous-jacent, vous trouverez de précieux conseils.
1) Restez aussi SEC que possible
Malheureusement, lorsque les équipes DevOps configurent un cloud multirégional, leur engagement envers les principes Don’t Repeat Yourself (DRY) peut s’envoler. Il n’est pas nécessaire de réécrire chaque ensemble de codes pour chaque région.
Plutôt, utiliser une variable de carte Terraformqui est une structure de données dans Terraform et OpenTofu pour stocker les paires clé-valeur. Vous pouvez définir différents types de valeurs à l’aide d’étiquettes de type, telles que « map(string) » ou « map(objects) ».
Par exemple, vous pouvez spécifier une variable nommée « region_map » comme type « map(string) ». Vous pouvez ensuite stocker les ID Amazon Machine Image (AMI) pour différentes régions et clés (régions) sous forme de chaînes. Vous pouvez désormais ajuster les configurations en fonction de la région sans répéter l’intégralité du code Terraform.
2) Centraliser l’approvisionnement dans toutes les régions
Multi-région configurations cloud cela devient très compliqué très rapidement, en particulier pour les environnements actifs-actifs où vous répliquez constamment des données. Les applications conteneurisées basées sur des microservices permettent des temps de démarrage plus rapides, mais elles augmentent également le nombre de ressources dont vous aurez besoin.
Même les environnements actifs-passifs destinés aux cas d’utilisation de sauvegarde et de restauration à froid sont gourmands en ressources. Vous aurez toujours besoin de beaucoup d’instances, d’ID AMI, d’instantanés et bien plus encore pour obtenir un délai de reprise après sinistre raisonnable.
Pour savoir où toutes vos ressources sont provisionnées, utilisez un tableau de bord centralisé tel que la vue globale d’Amazon Elastic Compute Cloud (EC2). Il regroupe toutes vos ressources Amazon EC2 telles que les cloud privés virtuels (VPC), les groupes de sécurité, les instances, les sous-réseaux et les volumes. Une autre alternative est AWS Organizations avec Control Tower, qui offre une gouvernance centralisée dans vos régions actives.
3) Gérer les données avec le géo-partitionnement
Les lois sur la souveraineté et la gestion des données peuvent constituer un véritable casse-tête lorsque vous configurez un cloud multirégional. Vous devez vous conformer aux réglementations locales concernant le stockage des données, le traitement des données, la minimisation, l’accès, etc.
Vous ne voulez pas avoir à imposer des exigences strictes du RGPD sur les données dont vous avez besoin pour votre cloud américain, vous pourriez donc être tenté de configurer des bases de données distinctes pour chaque région. Mais cela peut ajouter des frictions en matière de réplication, ralentissant ainsi la vitesse de récupération des données. Le maintien d’une seule base de données multirégionale prend en charge l’évolutivité horizontale pour une distribution efficace des données et des performances optimales.
Recherchez une base de données multirégionale qui permet le géopartitionnement afin de pouvoir diviser une seule base de données en partitions basées sur les régions géographiques. Le sous-ensemble de données de chaque partition est stocké et traité localement, réduisant ainsi la latence au minimum et simplifiant la conformité aux réglementations locales. Créez simplement des partitions pour des lignes spécifiques et configurez des politiques de placement pour chacune d’entre elles, conformément aux exigences réglementaires.
4) Choisissez judicieusement votre tactique de réplication de données
Le Théorème du CAP vous oblige à choisir seulement deux des trois options : cohérence, disponibilité et tolérance de partition. Puisque nous configurons pour plusieurs régions, la tolérance de partition n’est pas négociable, ce qui laisse une bataille entre disponibilité et cohérence. Oui, vous pouvez conserver les deux, mais vous entraînerez des coûts élevés et une charge de gestion démesurée.
Si vous exécutez des environnements actifs-passifs, optez pour la cohérence plutôt que la disponibilité. Cela vous permet d’utiliser des solutions Platform-as-a-Service (PaaS) pour répliquer votre base de données dans votre région passive. Mais les environnements actifs-actifs donnent presque toujours la priorité à la disponibilité, ce qui constitue un défi plus important.
La meilleure option consiste à adopter des systèmes asynchrones et la réplication pour une cohérence éventuelle. La plupart des systèmes utilisent l’approche de réconciliation « dernière victoire en écriture », ce qui vous oblige à concevoir vos applications avec soin pour des interfaces non bloquantes. Toutes les interactions utilisateur doivent être résolues de manière asynchrone et sans réponse backend obligatoire. Le découplage des requêtes adressées au serveur depuis l’interface utilisateur masque la latence du réseau et parfois même les pannes du réseau.
5) Gardez vos options de routage ouvertes
Pour les environnements actifs-passifs, le routage n’est pas un problème sérieux. Vous utiliserez le routage global prioritaire par défaut pour prendre en charge la gestion du basculement, point final. Mais pour les environnements actifs-actifs, vous aurez besoin de politiques de routage différentes en fonction de la situation dans cette région.
Dans ces cas, vous ne souhaitez pas non plus configurer un service de routage DNS distinct pour chaque région. Utilisez plutôt Amazon Route 53 pour prendre en charge diverses stratégies de routage des flux de trafic avec basculement DNS.
Par exemple, sélectionnez le routage de latence pour acheminer le trafic en fonction de la ressource ayant la latence la plus faible ; routage pondéré pour spécifier les proportions de plusieurs ressources ; routage par géolocalisation pour donner la priorité à l’emplacement des utilisateurs ; et un routage de géoproximité pour prioriser l’emplacement des ressources. Vous voyez l’idée.
Un dernier mot sur l’optimisation des configurations cloud multi-régions
J’ai partagé des conseils sur les scénarios qui laissent le plus souvent les équipes DevOps se demander quoi faire ensuite. Mais la configuration cloud multirégionale sera toujours une entreprise complexe, en particulier pour les environnements actifs-actifs. Vous devrez toujours réfléchir à vos objectifs principaux et décider de ce que vous prioriserez et de ce que vous déprioriserez pour éviter de dépenser du temps, de l’argent et de l’énergie.
