Modernisez et migrez progressivement votre modèle de données de SQL vers NoSQL

Cet article a été rédigé par AWS Sr. Specialist SA Alexander Schueren et publié avec autorisation.

Nous aimons tous construire de nouveaux systèmes, mais il y a trop de systèmes critiques qui doivent être améliorés. Ainsi, l’architecture système en constante évolution reste un défi majeur pour les équipes d’ingénierie. La décomposition du monolithe n’est pas un sujet nouveau. Des stratégies et des techniques telles que la conception axée sur le domaine et les modèles d’étrangleur ont façonné la pratique de modernisation de l’industrie. Les bases de données NoSQL sont devenues populaires pour les projets de modernisation. De meilleures performances, des schémas flexibles et la rentabilité sont les principales raisons de l’adoption. Elles évoluent mieux et sont plus résilientes que les bases de données SQL traditionnelles. L’utilisation d’une solution gérée et la réduction des frais généraux opérationnels sont un gros plus. Mais déplacer des données est différent : c’est désordonné et il y a beaucoup d’inconnues. Comment concevez-vous le schéma, maintenez-vous la cohérence des données, gérez-vous les échecs ou annulez-vous ? Dans cet article, nous discuterons de deux stratégies qui peuvent faciliter la transition de SQL vers NoSQL : modifier la capture de données et les doubles écritures.

Migration continue des données

Grâce au développement logiciel agile, nous expédions désormais de petits lots de fonctionnalités chaque semaine au lieu d’avoir des événements de déploiement deux fois par an, suivis de correctifs et de restaurations fragiles. Cependant, avec les migrations de données, il y a une tendance à migrer toutes les données en même temps. Eh bien, la plupart des migrations de données sont homogènes (SQL vers SQL), donc la structure des données reste compatible. Ainsi, de nombreux outils commerciaux peuvent convertir le schéma et répliquer les données. Mais la migration de SQL vers NoSQL est différente. Cela nécessite une analyse approfondie du cas d’utilisation et du modèle d’accès pour concevoir un nouveau modèle de données. Une fois que nous l’avons, le défi consiste à migrer les données en continu et à détecter et récupérer les pannes. Et si nous pouvions migrer un seul enregistrement client, ou dix clients d’une région spécifique, ou d’une catégorie de produit spécifique ? Pour éviter les temps d’arrêt, nous pouvons migrer les données en continu en appliquant le mécanisme de migration à un petit sous-ensemble de données. Au fil du temps, nous gagnons en confiance, affinons le mécanisme et élargissons à un ensemble de données plus large. Cela garantira la stabilité et nous pourrons également capitaliser sur les meilleures performances ou les coûts réduits beaucoup plus tôt.

Modifier la capture de données

La capture de données modifiées (CDC) est une méthode bien établie et largement utilisée. La plupart des systèmes de gestion de bases de données relationnelles (RDBMS) disposent d’un mécanisme de stockage interne pour collecter les modifications de données, souvent appelés journaux de transactions. Chaque fois que vous écrivez, mettez à jour ou supprimez des données, le système capture ces informations. Ceci est utile si vous souhaitez revenir à un état antérieur, remonter dans le temps ou répliquer des données. Nous pouvons nous connecter au journal des transactions et transmettre les modifications de données à un autre système. Lors du déplacement de données de SQL vers des services de base de données AWS, tels qu’Amazon RDS, AWS Database Migration Service (AWS DMS) est un choix populaire. En combinaison avec l’outil de conversion de schéma, vous pouvez passer d’un serveur Microsoft SQL ou Oracle à une base de données open source, telle que PostgreSQL ou MySQL. Mais avec DMS, nous pouvons également passer des bases de données SQL aux bases de données NoSQL, telles qu’Amazon DynamoDB, S3, Neptune, Kinesis, Kafka, OpenSearch, Redis et bien d’autres.

Voici comment cela fonctionne :

Définissez les points de terminaison source et cible avec le bon ensemble d’autorisations pour les opérations de lecture et d’écriture.
Créez une définition de tâche spécifiant le processus de migration CDC.
Ajouter un mappage de table avec le type de règle object-mapping pour spécifier la clé de partition et les attributs de votre table DynamoDB.

Voici un exemple de règle de mappage dans AWS DMS :

{
  "rules": [
    {
      "rule-type": "object-mapping",
      "rule-id": "1",
      "rule-name": "TransformToDDB",
      "object-locator": {
        "schema-name": "source-schema",
        "table-name": "customer"
      },
      "rule-action": "map-record-to-record",
      "target-table-name": "customer",
      "mapping-parameters": [
        {
          "partition-key-name": "CustomerName",
          "attribute-type": "scalar",
          "attribute-sub-type": "string",
          "value": "${FIRST_NAME},${LAST_NAME}"
        },
        {
          "target-attribute-name": "ContactDetails",
          "attribute-type": "document",
          "attribute-sub-type": "dynamodb-map",
          "value": "..."
        }
      ]
    }
  ]
}

Cette règle de mappage copiera les données de la table des clients et combinera FIRST_NAME et LAST_NAME à une clé de hachage composite, et ajoutez ContactDetails colonne avec une structure de carte DynamoDB. Pour plus d’informations, vous pouvez voir d’autres exemples de mappage d’objets dans la documentation.

L’un des principaux avantages de l’utilisation de CDC est qu’il permet de modifier les données atomiques. Toutes les modifications apportées à une base de données, telles que les insertions, les mises à jour et les suppressions, sont capturées en une seule transaction. Cela garantit que la réplication des données est cohérente et, avec une annulation de transaction, CDC propagera également ces modifications au nouveau système.

Un autre avantage de CDC est qu’il ne nécessite aucune modification du code d’application. Il peut y avoir des situations où l’équipe d’ingénierie ne peut pas modifier facilement le code hérité ; par exemple, avec un processus de libération lent ou un manque de tests pour assurer la stabilité. De nombreux moteurs de base de données prennent en charge CDC, notamment MySQL, Oracle, SQL Server, etc. Cela signifie que vous n’avez pas besoin d’écrire une solution personnalisée pour lire les journaux de transactions.

Enfin, avec AWS DMS, vous pouvez mettre à l’échelle vos instances de réplication pour gérer plus de volume de données, là encore sans modifications de code supplémentaires.

AWS DMS et CDC sont utiles pour la réplication et la migration de bases de données, mais présentent certains inconvénients. La principale préoccupation est la complexité et les coûts plus élevés de configuration et de gestion d’un système de réplication. Vous passerez un peu de temps à affiner les paramètres de configuration DMS pour obtenir les meilleures performances. Cela nécessite également une bonne compréhension des bases de données sous-jacentes, et il est difficile de résoudre les erreurs ou les problèmes de performances, en particulier pour ceux qui ne sont pas familiarisés avec les détails subtils du moteur de base de données, du mécanisme de réplication et des journaux de transactions.

Double écriture

La double écriture est une autre approche populaire pour migrer les données en continu. L’idée est d’écrire les données sur les deux systèmes en parallèle dans votre code d’application. Une fois les données entièrement répliquées, nous passons entièrement au nouveau système. Cela garantit que les données sont disponibles dans le nouveau système avant le basculement, et cela permet également de garder la porte ouverte pour revenir à l’ancien système. Avec les doubles écritures, nous opérons au niveau de l’application, par opposition au niveau de la base de données avec CDC ; ainsi, nous utilisons plus de ressources de calcul et avons besoin d’un processus de livraison robuste pour modifier et publier le code. Voici comment cela fonctionne :

Les applications continuent d’écrire des données dans le système SQL existant comme elles le feraient.
Un processus distinct, souvent appelé « écrivain double », obtient une copie des données qui ont été écrites sur le système basé sur SQL et les écrit dans DynamoDB après la transaction.
Le double écrivain garantit que nous écrivons les données sur les deux systèmes dans le même format et avec les mêmes contraintes, telles que des contraintes de clé unique.
Une fois le processus de double écriture terminé, nous basculons pour lire et écrire sur le système DynamoDB.

Nous pouvons contrôler la migration des données et appliquer des écritures doubles à certaines données en utilisant des indicateurs de fonctionnalité. Par exemple, nous pouvons basculer la réplication des données ou appliquer uniquement à un sous-ensemble spécifique. Il peut s’agir d’une région géographique, d’une taille de client, d’un type de produit ou d’un client unique.

Étant donné que les écritures doubles sont instrumentées au niveau de l’application, nous n’exécutons pas de requêtes directement sur la base de données. Nous travaillons au niveau objet dans notre code. Cela nous permet d’avoir une transformation, une validation ou un enrichissement supplémentaire des données.

Mais il y a aussi des inconvénients, la complexité du code, la cohérence et la gestion des pannes. L’utilisation d’indicateurs de fonctionnalité aide à contrôler le flux, mais nous devons encore écrire du code, ajouter des tests, déployer des modifications et disposer d’un magasin d’indicateurs de fonctionnalité. Si vous utilisez déjà des indicateurs de fonctionnalité, cela peut être négligeable ; sinon, c’est une bonne occasion d’introduire des indicateurs de fonctionnalité dans votre système. La cohérence des données et la gestion des pannes sont les principales bêtes à apprivoiser. Étant donné que nous copions les données après la transaction de la base de données, il peut y avoir des cas de restauration, et avec la double écriture, vous pouvez manquer ce cas. Pour contrer cela, vous devez collecter des mesures opérationnelles et commerciales pour suivre les opérations de lecture et d’écriture sur chaque système, ce qui augmentera la confiance au fil du temps.

Conclusion

La modernisation est inévitable et l’amélioration des systèmes existants deviendra plus courante à l’avenir. Au fil des années, nous avons appris à découpler les systèmes monolithiques et avec de nombreuses solutions de base de données NoSQL, nous pouvons améliorer les produits avec de meilleures performances et des coûts réduits. CDC et les écritures doubles sont des mécanismes solides pour migrer les modèles de données de SQL vers NoSQL. Alors que CDC est plus lourd en termes de base de données et d’infrastructure, avec les écritures doubles, nous opérons au niveau du code avec plus de contrôle sur la segmentation des données, mais avec une complexité de code plus élevée. Ainsi, il est crucial de comprendre le cas d’utilisation et les exigences lors du choix du mécanisme à mettre en œuvre. Le déplacement continu des données entre les systèmes ne devrait pas être difficile, nous devons donc investir davantage et apprendre à ajuster notre modèle de données plus facilement et en toute sécurité. Il y a de fortes chances que ce ne soit pas la dernière initiative de réarchitecture que vous entrepreniez, et le développement de ces capacités sera utile à l’avenir.

Aimez-vous les tutoriels vidéo ?

Si vous êtes plutôt une personne visuelle qui aime suivre les étapes pour construire quelque chose avec un joli tutoriel enregistré, je vous encourage à vous abonner à la chaîne YouTube Build On AWS. C’est l’endroit où vous devriez aller pour plonger dans le code et l’architecture, avec des personnes de la communauté AWS partageant leur expertise de manière visuelle et divertissante.