Concevoir une architecture de données distribuée géographiquement
La dernière partie de la conception architecturale de l’application à prendre en compte est le niveau de stockage des données. Nous souhaitons nous assurer que les données sont pleinement accessibles en lecture et en écriture après une défaillance à l’échelle d’une région.
Dans le portail de suivi des expéditions, nous avons choisi d’utiliser Azure Front Door pour envoyer toutes les demandes à App Services dans la région USA Est. En cas de défaillance de la région USA Est, Front Door envoie les demandes aux composants App Services équivalents dans la région USA Ouest. Dans notre architecture monorégion d’origine, nous avons stocké les données relationnelles dans Azure SQL Database et les données semi-structurées dans Cosmos DB. À présent, nous souhaitons comprendre comment nous pouvons faire en sorte que les deux bases de données restent disponibles en cas de défaillance de la région USA Est.
Ici, nous apprenons à répliquer les données entre les régions et à garantir que le basculement peut se produire rapidement, si nécessaire.
Azure SQL Database
Pour créer une implémentation multirégion d’Azure SQL Database afin de stocker des données relationnelles, nous pouvons utiliser l’une des deux fonctionnalités suivantes :
- Géoréplication active
- Groupes de basculement automatique
Géoréplication active
Azure SQL Database peut répliquer automatiquement une base de données et toutes ses modifications vers une autre base de données à l’aide de la fonctionnalité de géoréplication active. Seul le serveur logique principal héberge une copie accessible en écriture de la base de données. Nous pouvons créer jusqu’à quatre autres serveurs logiques qui hébergent des copies en lecture seule de la base de données.
Pour le portail de suivi des expéditions, créez une base de données secondaire dans la région USA Ouest et configurez la géoréplication à partir de la région USA Est. En cas de défaillance régionale, Front Door redirige les demandes des utilisateurs vers App Services dans la région USA Ouest. App Services et Azure Functions peuvent accéder aux données relationnelles, car une copie a déjà été répliquée dans la région USA Ouest.
Cette modification est automatique, mais n’oubliez pas que la base de données secondaire dans la région USA Ouest est en lecture seule. Si un utilisateur tente de modifier des données, par exemple en créant une expédition, des erreurs peuvent se produire. Nous pouvons lancer manuellement un basculement vers la région USA Ouest dès que nous remarquons le problème dans le portail Azure. Si nous souhaitons automatiser ce processus, nos développeurs peuvent écrire du code qui appelle la méthode failover dans l’API REST d’Azure SQL Database.
Notes
Les instances managées d’Azure SQL Database ne prennent pas en charge la géoréplication active. Les instances managées sont conçues pour simplifier la migration des données à partir d’un serveur SQL local tout en gérant la sécurité. Si vous utilisez une instance managée, envisagez plutôt d’utiliser des groupes de basculement.
Groupes de basculement automatique
Un groupe de basculement automatique est un groupe de bases de données où les données sont répliquées automatiquement depuis un serveur principal vers un ou plusieurs serveurs secondaires. Similaire à la géoréplication active, cette conception utilise la même méthode de réplication des données. Toutefois, nous pouvons automatiser la réponse à une défaillance en définissant une stratégie.
Pour le portail d’expédition, nous allons créer une base de données secondaire dans la région USA Ouest. Nous ajoutons ensuite une stratégie qui bascule le réplica principal de la base de données vers la région USA Ouest si une défaillance catastrophique se produit dans la région USA Est. Si cela se produit, le réplica de la région USA Ouest devient automatiquement la base de données primaire accessible en écriture, et les fonctionnalités complètes sont conservées.
Envisagez d’utiliser un groupe de basculement automatique si vous souhaitez automatiser le basculement de la base de données accessible en écriture sans écrire de code personnalisé pour le déclencher. Utilisez également des groupes de basculement automatique si votre base de données s’exécute dans une instance managée d’Azure SQL Database.
Important
La réplication sous-jacente à la géoréplication active et aux groupes de basculement automatique est asynchrone. Un accusé de réception est envoyé au client quand une modification est appliquée au réplica principal. À ce stade, la transaction est considérée comme terminée et la réplication se produit. En cas de défaillance, les dernières modifications apportées à la base de données primaire n’ont peut-être pas été répliquées sur la base de données secondaire. Gardez à l’esprit qu’après un sinistre, les modifications les plus récentes de la base de données peuvent avoir été perdues.
Azure Cosmos DB
Notre configuration est moins complexe avec Azure Cosmos DB, car elle est conçue comme un système de base de données cloud multirégion. Cosmos DB est une base de données multimodèle, capable de stocker des données relationnelles, des données semi-structurées et d’autres formes de données. Même si nous exécutons Cosmos DB dans une seule région, les données sont répliquées sur plusieurs instances dans différents domaines d’erreur pour une disponibilité optimale.
Quand nous créons un compte Cosmos DB multirégion, nous pouvons choisir parmi les modes suivants :
Comptes multirégion avec plusieurs régions d’écriture.
Dans ce mode, toutes les copies de la base de données sont toujours accessibles en écriture. En cas de défaillance d’une région, aucun basculement n’est nécessaire.
Comptes multirégion avec une seule région d’écriture.
Dans ce mode, seule la région primaire contient des bases de données accessibles en écriture. Les données répliquées dans les régions secondaires sont en lecture seule. Les mises à jour sont désactivées par défaut en cas de défaillance de la région primaire. Toutefois, nous pouvons sélectionner Activer le basculement automatique afin que Cosmos DB bascule automatiquement la copie principale et accessible en écriture de la base de données vers une autre région.
Important
Dans Cosmos DB, la réplication des données est synchrone. Quand une modification est appliquée, la transaction n’est considérée comme terminée qu’une fois répliquée vers un quorum de réplicas. Un accusé de réception est ensuite envoyé au client. Quand une défaillance se produit, aucune modification récente n’est perdue, car la réplication a déjà eu lieu.