Le processus de modernisation vise à améliorer l’efficacité, l’agilité et la résilience de l’infrastructure, de l’architecture et des produits informatiques existants d’une organisation en mettant en œuvre les dernières technologies, méthodologies et modèles, tels que le cloud computing, le développement agile, l’automatisation et la conteneurisation.
Pour garantir le bon fonctionnement des opérations face aux charges de travail vitales pour la mission, il est essentiel de mettre en œuvre une stratégie de coexistence adaptée au cas d’utilisation spécifique et aux circonstances technologiques. Cet article se concentre sur une approche de synchronisation des données pour la coexistence, qui nécessite un déploiement progressif, et explique comment le service de migration de données AWS a été utilisé pour synchroniser en continu les données d’une base de données relationnelle sur site vers DynamoDB sur le cloud AWS. L’article couvre également les défis rencontrés et les leçons apprises au cours du processus de mise en œuvre.
Dans le cadre d’une importante initiative de transformation numérique, l’équipe de développement était responsable de la modernisation complète (réécriture) d’un système hérité existant composé de plusieurs charges de travail vitales pour la mission, critiques pour la mission, critiques pour l’entreprise et vitales pour l’entreprise.
Le terme « Mission Vital » est attribué à une charge de travail qui, dans la plupart des cas, maintient une disponibilité de 99,999 % tout en ayant un objectif de point de récupération (RPO) et un objectif de temps de récupération (RTO) proches de zéro. D’autre part, « Mission Critical » est utilisé pour décrire une charge de travail qui nécessite généralement une disponibilité de 99,95 %, avec un RPO proche de zéro et un RTO allant jusqu’à quatre heures.
L’ancienne solution utilisait une base de données relationnelle et prenait en charge plusieurs applications Web, adaptateurs et applications mobiles.
Afin d’atténuer les perturbations des applications existantes, nous avons effectué un déploiement Canary en introduisant la nouvelle application dans quelques sites pilotes avant sa sortie à grande échelle sur tous les sites.
Cependant, cette approche présentait un défi supplémentaire en termes de coexistence, car l’ancienne version de l’application continuait à mettre à jour le système sur site tandis que la nouvelle version interagissait avec le cloud pendant la période de transition.
De plus, divers processus en aval et en amont d’autres domaines commerciaux dépendaient de la base de données et des services sur site.
Par conséquent, le principal défi consistait à construire un système de coexistence robuste qui ne compromette pas la latence, les performances, la sécurité ou la fiabilité de la solution et de ses systèmes dépendants tout au long de la période de coexistence.
Après plusieurs considérations architecturales, il a été conclu d’établir une synchronisation des données unidirectionnelle pour décharger les appels de lecture de la base de données RDBMS source vers l’instance cloud DynamoDB.
Dans la synchronisation de données unidirectionnelle, les données sont transférées d’un système source vers un système cible, sans modifications ni mises à jour effectuées dans le système cible. Par conséquent, les données du système cible sont identiques aux données du système source et toute modification apportée au système cible n’est pas répercutée sur le système source. Il existe plusieurs méthodes pour implémenter la synchronisation unidirectionnelle, y compris les transferts de fichiers, les systèmes de messagerie ou la réplication de base de données. Dans cette solution spécifique, la réplication de base de données a été utilisée grâce à l’utilisation d’une technique de capture de données modifiées.
Figure 1 : Couche de coexistence
Comme expliqué dans la figure 1, pendant la période de coexistence, la version héritée de l’application mobile continuera à exploiter les solutions existantes tandis que la nouvelle version de l’application mobile exploitera les nouvelles API servant les données de la base de données DynamoDB pour la lecture et l’API sur site pour l’opération d’écriture comme passe-système.
L’article se concentre principalement sur la synchronisation unidirectionnelle et n’aborde pas les défis rencontrés pour mettre à jour les données sur site.
L’application dépendante lira les données de la base de données cloud et continuera à écrire dans la base de données sur site à l’aide de l’API wrapper sur le cloud.
Défis
Les principaux défis rencontrés lors de la migration des données du SGBDR sur site vers le cloud DynamoDB (NoSQL) sont :
- Contraintes de ressources sur le SGBDR sur site : Le SGBDR sur site manquait de ressources et ne pouvait pas être mis à l’échelle.
- Défis liés à la fusion et à la dénormalisation des données : DynamoDB est dénormalisé et ne prend pas en charge les jointures de table. Bien que les vues matérialisées puissent aider à joindre des tables, elles exercent une pression supplémentaire sur les ressources.
- Défis de transformation des données : Défis liés à la conversion des types de données et à la transformation des données nécessaires à la conception d’une table unique (conception de table unique Dynamo DB comme expliqué par Alex DeBrie « The What, Why, and When of Single-Table Design with DynamoDB. » Alex DeBrie, 22 octobre 2019).
- Problèmes de latence et de performances imposés par le réseau : L’emplacement du centre de données et la région AWS sélectionnée ont imposé différents problèmes de latence régionale.
- Sécurité des données en transit et au repos : La classification des données était confidentielle et doit donc être sécurisée pendant le transit et le repos et ne doit pas quitter le réseau du client.
- Échec et récupération de la tâche DMS : Les tâches DMS peuvent échouer pour diverses raisons, notamment la connectivité, et en raison de la nature vitale et critique de la charge de travail, la solution doit garantir une intervention manuelle minimale.
- La validation des données: DMS ne prend pas en charge la validation de données prête à l’emploi pour les données migrées de RDBMS vers des bases de données NOSQL.
- Implications financières : Étant donné que le système de coexistence peut durer plusieurs mois, la solution doit être rentable car nous devons conserver les données dans plusieurs bases de données.
Solution
Le service de migration de données AWS (AWS DMS) a été utilisé pour mettre en œuvre la solution. Lors du chargement initial, la tâche DMS récupère les données du SGBDR sur site et modifie l’instance DynamoDB basée sur le cloud en conséquence. Une fois le chargement complet terminé, toutes les modifications ultérieures apportées aux données sont capturées via le mécanisme RDBMS CDC.
Contraintes de ressources, transformation de données, fusion et dénormalisation
-
Vue matérialisée pour l’agrégation : Dans les situations où une simple conversion d’une table en une entité DynamoDB est nécessaire, nous pouvons utiliser la fonctionnalité de vue matérialisée, associée au mappeur d’objets de la tâche DMS, pour faciliter le mappage des colonnes à la structure prévue. Cependant, il est essentiel de noter que bien que les vues matérialisées puissent être utiles pour combiner des informations provenant de tables normalisées afin de créer une vue dénormalisée, cette approche peut avoir un impact sur les ressources CPU, de stockage et de mémoire de la base de données source.
Figure 2 : Synchronisation unidirectionnelle à l’aide d’une vue matérialisée pour l’agrégation.
Comme l’un des défis que nous avons rencontrés impliquait des contraintes de ressources sur le SGBDR sur site, l’approche de la vue matérialisée n’a donc pas pu être utilisée.
-
Transformation de données à l’aide du type de règle de transformation : Dans les scénarios qui impliquent une conversion simple d’une table en une entité DynamoDB, qui peut inclure des tâches telles que la conversion des formats de date, la modification des types de données et le mappage des colonnes, la solution a utilisé des tâches DMS qui ont été configurées avec des règles de transformation.
Figure 3 : Synchronisation unidirectionnelle à l’aide du type de règle de transformation de tâche DMS.
Supposons que la transformation des données soit plus complexe et implique la fusion, la dénormalisation et la transformation des données de plusieurs tables avant de les stocker dans une table DynamoDB. Dans ce cas, la solution utilise une table DynamoDB intermédiaire, ainsi qu’un flux DynamoDB et Lambda, comme illustré dans le diagramme ci-dessous.
Figure 3 : Synchronisation unidirectionnelle à l’aide de tables intermédiaires.
Bien que DynamoDB offre une option pour utiliser Kinesis Data Stream à cette fin, cela entraîne des coûts supplémentaires et la commande des données n’est pas garantie.
Problèmes de latence et de performances imposés par le réseau
La solution actuelle s’appuyait sur deux clusters de stratégie de déploiement actif/passif avec un RPO proche de zéro dans un centre de données.
La solution proposée consistait à tirer parti d’une stratégie de DR active/passive similaire, mais avec deux régions AWS différentes, la principale étant la région la plus proche du canter de données sur site.
Pour éviter la charge sur l’instance de base de données principale sur site, la solution a exploité le cluster de base de données passif.
La solution s’est appuyée sur AWS Direct Connect, Transit Gateway et Customer Gateway pour établir une connexion sécurisée entre le centre de données sur site et le compte AWS. Il utilise également les tables globales DynamoDB pour prendre en charge une stratégie de reprise après sinistre active/passive à 2 régions avec un RPO proche de zéro.
Figure 4 : 2 Région Active Passive DR stratégie.
Sécurité des données en transit et au repos
Les données stockées dans DynamoDB ont été chiffrées au repos à l’aide d’une clé gérée par le client AWS, tandis que les données en transit depuis AWS DMS ont été chiffrées à l’aide du chiffrement TLS v1.2. De plus, pour chiffrer les données en transit à partir d’une instance RDBMS source sur site, un certificat côté serveur a été utilisé.
AWS DMS utilise les clés de chiffrement AWS Key Management Service (AWS KMS) pour chiffrer le stockage utilisé par l’instance de réplication (calcul) et ses informations de connexion au point de terminaison.
De plus, étant donné qu’AWS DMS est un service géré qui nécessite des instances de calcul, la solution a associé la tâche DMS aux sous-réseaux au sein du VPC. Cela a permis à la solution d’utiliser l’architecture AWS Private Link pour se connecter en toute sécurité au point de terminaison privé du service DMS afin de créer des instances de réplication dans les sous-réseaux VPC.
Basculement avec récupération à partir du point de contrôle
Plusieurs facteurs peuvent entraîner l’échec des tâches AWS DMS, notamment une configuration incorrecte, des problèmes de connectivité, des problèmes d’autorisation, des incohérences de format de données, des erreurs de réplication, des ressources limitées et des problèmes logiciels. Pour éviter de tels problèmes, il est crucial d’assurer une configuration correcte de tous les paramètres nécessaires, d’établir une connectivité réseau fiable, de fournir des ressources suffisantes pour l’instance de réplication et de maintenir le logiciel DMS à jour. En outre, une surveillance continue et un dépannage rapide sont essentiels pour garantir un processus de migration fluide.
La solution a tiré parti de la stratégie DMS Multi Region Active – Passive DR avec Hot Standby avec tables globales DynamoDB.
Étant donné que la solution utilisait des tables globales Dynamo DB, le trafic d’API pris en charge sera…