Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Migration en ligne vers Amazon Keyspaces : stratégies et meilleures pratiques
Si vous devez maintenir la disponibilité des applications lors d'une migration d'Apache Cassandra vers Amazon Keyspaces, vous pouvez préparer une stratégie de migration en ligne personnalisée en implémentant les composants clés décrits dans cette rubrique. En suivant ces bonnes pratiques pour les migrations en ligne, vous pouvez garantir la disponibilité et la read-after-write cohérence des applications tout au long du processus de migration, minimisant ainsi l'impact sur vos utilisateurs.
Lorsque vous concevez une stratégie de migration en ligne d'Apache Cassandra vers Amazon Keyspaces, vous devez prendre en compte les étapes clés suivantes.
1. **Écrire de nouvelles données**
+ Proxy **ZDM Dual Write pour la migration d'Amazon Keyspaces — Utilisez le proxy** ZDM Dual Write disponible [sur](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) Github pour effectuer une migration sans interruption d'Apache Cassandra vers Amazon Keyspaces. Le proxy ZDM effectue deux écritures sans qu'il soit nécessaire de refactoriser les applications existantes et effectue des lectures doubles pour la validation des requêtes.
+ Deux écritures d'application : vous pouvez implémenter des écritures doubles dans votre application à l'aide des bibliothèques clientes et des pilotes Cassandra existants. Désignez une base de données comme leader et l'autre comme suiveuse. Les échecs d'écriture dans la base de données des abonnés sont enregistrés dans une [file d'attente de lettres mortes (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) à des fins d'analyse.
+ Deux écritures au niveau de messagerie : vous pouvez également configurer votre plateforme de messagerie existante pour envoyer des écritures à Cassandra et à Amazon Keyspaces en utilisant un consommateur supplémentaire. Cela crée finalement des vues cohérentes entre les deux bases de données.
1. **Migration des données historiques**
+ Copier les données historiques : vous pouvez migrer les données historiques de Cassandra vers Amazon Keyspaces à AWS Glue l'aide ou de scripts d'extraction, de transformation et de chargement (ETL) personnalisés. Gérez la résolution des conflits entre les écritures doubles et les chargements groupés à l'aide de techniques telles que les transactions légères ou les horodatages.
+ Utilisation Time-To-Live (TTL) : pour des périodes de conservation des données plus courtes, vous pouvez utiliser le TTL dans Cassandra et Amazon Keyspaces afin d'éviter de télécharger des données historiques inutiles. Lorsque les anciennes données expirent dans Cassandra et que les nouvelles données sont écrites par double écriture, Amazon Keyspaces finit par rattraper son retard.
1. **Validation des données**
+ Lectures doubles : implémentez des lectures doubles à partir des bases de données Cassandra (principale) et Amazon Keyspaces (secondaire), en comparant les résultats de manière asynchrone. Les différences sont enregistrées ou envoyées à un DLQ.
+ Exemples de lectures : utilisez les fonctions λ pour échantillonner et comparer périodiquement les données des deux systèmes, en enregistrant toute anomalie dans un DLQ.
1. **Migration de l'application**
+ Stratégie bleu-vert : changez d'application pour traiter Amazon Keyspaces comme le magasin de données principal et Cassandra comme le magasin de données secondaire en une seule étape. Surveillez les performances et revenez en arrière en cas de problème.
+ Déploiement de Canary : déployez d'abord progressivement la migration vers un sous-ensemble d'utilisateurs, en augmentant progressivement le trafic vers Amazon Keyspaces en tant que principal utilisateur jusqu'à la migration complète.
1. **Démantèlement de Cassandra**
Une fois que votre application est entièrement migrée vers Amazon Keyspaces et que la cohérence des données est validée, vous pouvez planifier la mise hors service de votre cluster Cassandra en fonction des politiques de conservation des données.
En planifiant une stratégie de migration en ligne à l'aide de ces composants, vous pouvez passer en douceur au service Amazon Keyspaces entièrement géré avec un minimum de temps d'arrêt ou d'interruption. Les sections suivantes abordent chaque composant de manière plus détaillée.
**Topics**
+ [Écrire de nouvelles données lors d'une migration en ligne](migration-online-dw.md)
+ [Téléchargement de données historiques lors d'une migration en ligne](migration-online-historical.md)
+ [Validation de la cohérence des données lors d'une migration en ligne](migration-online-validation.md)
+ [Migration de l'application lors d'une migration en ligne](migration-online-app-migration.md)
+ [Mise hors service de Cassandra après une migration en ligne](migration-online-decommission.md)
# Écrire de nouvelles données lors d'une migration en ligne
La première étape d'un plan de migration en ligne consiste à s'assurer que toutes les nouvelles données écrites par l'application sont stockées dans les deux bases de données, dans votre cluster Cassandra existant et dans Amazon Keyspaces. L'objectif est de fournir une vue cohérente des deux magasins de données. Vous pouvez le faire en appliquant toutes les nouvelles écritures aux deux bases de données. Pour implémenter les écritures doubles, considérez l'une des trois options suivantes.
+ **Proxy ZDM à double écriture pour la migration vers Amazon Keyspaces** — À l'aide du proxy ZDM pour Amazon Keyspaces disponible [sur](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) Github, vous pouvez migrer vos charges de travail Apache Cassandra vers Amazon Keyspaces sans interruption des applications. Cette solution améliorée met en œuvre les AWS meilleures pratiques et étend les fonctionnalités officielles du proxy ZDM.
+ Effectuez des migrations en ligne entre Apache Cassandra et Amazon Keyspaces.
+ Écrivez des données simultanément dans les tables source et cible sans refactoriser les applications.
+ Validez les requêtes par le biais d'opérations de double lecture.
La solution propose les améliorations suivantes pour fonctionner avec Amazon Keyspaces AWS et Amazon Keyspaces.
+ **Déploiement de conteneurs** : utilisez une image Docker préconfigurée provenant d'Amazon Elastic Container Registry (Amazon ECR) pour les déploiements accessibles par VPC.
+ **Infrastructure sous forme de code** — Déployez à l'aide de AWS CloudFormation modèles pour une configuration automatisée surAWS Fargate.
+ **Compatibilité avec Amazon Keyspaces :** accédez aux tables du système avec des adaptations personnalisées pour Amazon Keyspaces.
La solution s'exécute sur Amazon ECS avec Fargate, offrant une évolutivité sans serveur en fonction des exigences de votre charge de travail. Un équilibreur de charge réseau répartit le trafic applicatif entrant entre plusieurs tâches Amazon ECS pour garantir une haute disponibilité.
![\[Implémentation du proxy à double écriture ZDM pour la migration des données d'Apache Cassandra vers Amazon Keyspaces.\]](http://docs.aws.amazon.com/fr_fr/keyspaces/latest/devguide/images/migration/online-migration-zdm.png)
+ **Deux écritures d'application** : vous pouvez implémenter des écritures doubles en modifiant le moins possible le code de votre application en exploitant les bibliothèques et les pilotes clients Cassandra existants. Vous pouvez soit implémenter les écritures doubles dans votre application existante, soit créer une nouvelle couche dans l'architecture pour gérer les écritures doubles. Pour plus d'informations et une étude de cas client qui montre comment les écritures doubles ont été mises en œuvre dans une application existante, consultez l'[étude de cas sur la migration de Cassandra](https://aws.amazon.com/solutions/case-studies/intuit-apache-migration-case-study/).
Lorsque vous implémentez les écritures doubles, vous pouvez désigner une base de données comme leader et l'autre comme suiveuse. Cela vous permet de continuer à écrire dans votre base de données source d'origine, ou base de données principale, sans que les échecs d'écriture dans la base de données suiveuse ou dans la base de données de destination perturbent le chemin critique de votre application.
Au lieu de réessayer les écritures échouées sur l'abonné, vous pouvez utiliser Amazon Simple Queue Service pour enregistrer les échecs d'écriture dans une file d'[attente de lettres mortes (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html). Le DLQ vous permet d'analyser les écritures échouées sur le suiveur et de déterminer pourquoi le traitement a échoué dans la base de données de destination.
Pour une implémentation à double écriture plus sophistiquée, vous pouvez suivre les AWS meilleures pratiques pour concevoir une séquence de transactions locales à l'aide du [modèle saga](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/saga.html). Un modèle de saga garantit qu'en cas d'échec d'une transaction, la saga exécute des transactions de compensation pour annuler les modifications de base de données apportées par les transactions précédentes.
Lorsque vous utilisez des écritures doubles pour une migration en ligne, vous pouvez configurer les écritures doubles selon le modèle Saga afin que chaque écriture soit une transaction locale afin de garantir les opérations atomiques sur des bases de données hétérogènes. Pour plus d'informations sur la conception d'applications distribuées à l'aide de modèles de conception recommandés pour leAWS Cloud, voir [Modèles de conception, architectures et implémentations dans le cloud](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/introduction).
![\[Implémentation de deux écritures au niveau de la couche application lors de la migration d'Apache Cassandra vers Amazon Keyspaces.\]](http://docs.aws.amazon.com/fr_fr/keyspaces/latest/devguide/images/migration/online-migration-dual-writes.png)
+ **Deux écritures au niveau de la messagerie** : au lieu d'implémenter des écritures doubles au niveau de la couche application, vous pouvez utiliser votre niveau de messagerie existant pour effectuer des écritures doubles sur Cassandra et Amazon Keyspaces.
Pour ce faire, vous pouvez configurer un consommateur supplémentaire sur votre plateforme de messagerie pour envoyer des écritures aux deux magasins de données. Cette approche fournit une stratégie simple à faible code utilisant le niveau de messagerie pour créer deux vues cohérentes entre les deux bases de données.
# Téléchargement de données historiques lors d'une migration en ligne
Après avoir implémenté les écritures doubles pour garantir que les nouvelles données sont écrites dans les deux magasins de données en temps réel, l'étape suivante du plan de migration consiste à évaluer la quantité de données historiques que vous devez copier ou télécharger en masse depuis Cassandra vers Amazon Keyspaces. Cela garantit que les nouvelles données et les données historiques seront disponibles dans la nouvelle base de données Amazon Keyspaces avant la migration de l'application.
En fonction de vos exigences en matière de conservation des données, par exemple la quantité de données historiques que vous devez conserver en fonction des politiques de votre entreprise, vous pouvez envisager l'une des deux options suivantes.
+ **Téléchargement groupé de données historiques** : la migration des données historiques de votre déploiement Cassandra existant vers Amazon Keyspaces peut être réalisée à l'aide de diverses techniques, par exemple AWS Glue en utilisant des scripts personnalisés pour extraire, transformer et charger (ETL) les données. Pour plus d'informations sur l'utilisation AWS Glue du téléchargement de données historiques, consultez[Processus de migration hors ligne : Apache Cassandra vers Amazon Keyspaces](migrating-offline.md).
Lorsque vous planifiez le téléchargement groupé de données historiques, vous devez réfléchir à la manière de résoudre les conflits qui peuvent survenir lorsque de nouvelles écritures tentent de mettre à jour les mêmes données que celles en cours de téléchargement. Le téléchargement groupé devrait finalement être cohérent, ce qui signifie que les données finiront par atteindre tous les nœuds.
Si les mêmes données sont mises à jour en même temps en raison d'une nouvelle écriture, vous devez vous assurer qu'elles ne seront pas remplacées par le téléchargement des données historiques. Pour garantir que vous conservez les dernières mises à jour de vos données, même pendant l'importation en bloc, vous devez ajouter la résolution des conflits soit dans les scripts de téléchargement en bloc, soit dans la logique de l'application pour les écritures doubles.
Par exemple, vous pouvez utiliser [Transactions légères](functional-differences.md#functional-differences.light-transactions) (LWT) pour comparer et définir des opérations. Pour ce faire, vous pouvez ajouter un champ supplémentaire à votre modèle de données qui représente l'heure de modification ou l'état.
En outre, Amazon Keyspaces prend en charge la fonction d'horodatage Cassandra`WRITETIME`. Vous pouvez utiliser les horodatages côté client d'Amazon Keyspaces pour préserver les horodatages de la base de données source et implémenter la résolution des conflits. last-writer-wins Pour de plus amples informations, veuillez consulter [Horodatages côté client dans Amazon Keyspaces](client-side-timestamps.md).
+ **Utilisation Time-to-Live (TTL)** — Pour les périodes de conservation des données inférieures à 30, 60 ou 90 jours, vous pouvez utiliser le TTL dans Cassandra et Amazon Keyspaces pendant la migration afin d'éviter de télécharger des données historiques inutiles sur Amazon Keyspaces. Le TTL vous permet de définir une période après laquelle les données sont automatiquement supprimées de la base de données.
Pendant la phase de migration, au lieu de copier les données historiques vers Amazon Keyspaces, vous pouvez configurer les paramètres TTL pour laisser les données historiques expirer automatiquement dans l'ancien système (Cassandra) tout en appliquant les nouvelles écritures à Amazon Keyspaces uniquement à l'aide de la méthode d'écriture double. Au fil du temps, alors que les anciennes données expirent continuellement dans le cluster Cassandra et que les nouvelles données sont écrites à l'aide de la méthode à double écriture, Amazon Keyspaces les rattrapent automatiquement pour contenir les mêmes données que Cassandra.
Cette approche permet de réduire considérablement la quantité de données à migrer, ce qui se traduit par un processus de migration plus efficace et rationalisé. Vous pouvez envisager cette approche lorsque vous traitez de grands ensembles de données soumis à des exigences différentes en matière de conservation des données. Pour plus d’informations sur TTL, consultez [Expirer les données avec Time to Live (TTL) pour Amazon Keyspaces (pour Apache Cassandra)](TTL.md).
Prenons l'exemple suivant de migration de Cassandra vers Amazon Keyspaces à l'aide de l'expiration des données TTL. Dans cet exemple, nous avons défini le TTL pour les deux bases de données sur 60 jours et nous montrons comment le processus de migration progresse sur une période de 90 jours. Les deux bases de données reçoivent les mêmes données nouvellement écrites au cours de cette période en utilisant la méthode des écritures doubles. Nous allons examiner trois phases différentes de la migration, chacune d'entre elles étant d'une durée de 30 jours.
Le fonctionnement du processus de migration pour chaque phase est illustré dans les images suivantes.
![\[Utilisation du TTL pour faire expirer les données historiques lors de la migration d'Apache Cassandra vers Amazon Keyspaces.\]](http://docs.aws.amazon.com/fr_fr/keyspaces/latest/devguide/images/migration/online-migration-TTL.png)
1. Après les 30 premiers jours, le cluster Cassandra et Amazon Keyspaces ont reçu de nouvelles écritures. Le cluster Cassandra contient également des données historiques qui n'ont pas encore atteint 60 jours de rétention, soit 50 % des données du cluster.
Les données datant de plus de 60 jours sont automatiquement supprimées dans le cluster Cassandra à l'aide du protocole TTL. À ce stade, Amazon Keyspaces contient 50 % des données stockées dans le cluster Cassandra, qui est composé des nouvelles écritures moins les données historiques.
1. Après 60 jours, le cluster Cassandra et Amazon Keyspaces contiennent les mêmes données écrites au cours des 60 derniers jours.
1. Dans les 90 jours, Cassandra et Amazon Keyspaces contiennent les mêmes données et expirent au même rythme.
Cet exemple montre comment éviter de télécharger des données historiques en utilisant le protocole TTL avec une date d'expiration fixée à 60 jours.
# Validation de la cohérence des données lors d'une migration en ligne
La prochaine étape du processus de migration en ligne est la validation des données. Les écritures doubles ajoutent de nouvelles données à votre base de données Amazon Keyspaces et vous avez terminé la migration des données historiques par téléchargement groupé ou par expiration des données avec TTL.
Vous pouvez maintenant utiliser la phase de validation pour confirmer que les deux magasins de données contiennent en fait les mêmes données et renvoient les mêmes résultats de lecture. Vous pouvez choisir l'une des deux options suivantes pour vérifier que vos deux bases de données contiennent des données identiques.
+ **Lectures doubles** : pour vérifier que la base de données source et la base de données de destination contiennent le même ensemble de données nouvellement écrites et historiques, vous pouvez implémenter des lectures doubles. Pour ce faire, vous pouvez lire à la fois dans votre base de données Cassandra principale et dans votre base de données Amazon Keyspaces secondaire de la même manière que la méthode à double écriture et vous comparez les résultats de manière asynchrone.
Les résultats de la base de données principale sont renvoyés au client, et les résultats de la base de données secondaire sont utilisés pour être validés par rapport au jeu de résultats principal. Les différences détectées peuvent être enregistrées ou envoyées dans une [file d'attente de lettres mortes (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) pour un rapprochement ultérieur.
Dans le schéma suivant, l'application effectue une lecture synchrone depuis Cassandra (qui est le magasin de données principal) et une lecture asynchrone depuis Amazon Keyspaces, qui est le magasin de données secondaire.
![\[Utilisation de deux lectures pour valider la cohérence des données lors d'une migration en ligne d'Apache Cassandra vers Amazon Keyspaces.\]](http://docs.aws.amazon.com/fr_fr/keyspaces/latest/devguide/images/migration/online-migration-dual-reads.png)
+ **Exemples de lectures** — Une solution alternative qui ne nécessite pas de modification du code de l'application consiste à utiliser des AWS Lambda fonctions pour échantillonner périodiquement et aléatoirement les données du cluster Cassandra source et de la base de données Amazon Keyspaces de destination.
Ces fonctions Lambda peuvent être configurées pour s'exécuter à intervalles réguliers. La fonction Lambda extrait un sous-ensemble aléatoire de données des systèmes source et de destination, puis effectue une comparaison des données échantillonnées. Toute divergence ou inadéquation entre les deux ensembles de données peut être enregistrée et envoyée à une [file d'attente dédiée (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) pour un rapprochement ultérieur.
Ce processus est illustré dans le diagramme suivant.
![\[Utilisation d'exemples de lecture pour valider la cohérence des données lors de la migration en ligne d'Apache Cassandra vers Amazon Keyspaces.\]](http://docs.aws.amazon.com/fr_fr/keyspaces/latest/devguide/images/migration/online-migration-sample-reads.png)
# Migration de l'application lors d'une migration en ligne
Au cours de la quatrième phase d'une migration en ligne, vous migrez votre application et passez à Amazon Keyspaces en tant que banque de données principale. Cela signifie que vous basculez votre application pour lire et écrire directement depuis et vers Amazon Keyspaces. Pour garantir un minimum de perturbations à vos utilisateurs, ce processus doit être bien planifié et coordonné.
Deux solutions différentes recommandées pour la migration des applications sont disponibles : la stratégie blue green cut over et la stratégie canari cut over. Les sections suivantes décrivent ces stratégies de manière plus détaillée.
+ **Stratégie bleu-vert** — En utilisant cette approche, vous changez d'application pour traiter Amazon Keyspaces comme le magasin de données principal et Cassandra comme le magasin de données secondaire en une seule étape. Vous pouvez le faire à l'aide d'un indicateur de AWS AppConfig fonctionnalité pour contrôler le choix des magasins de données principaux et secondaires dans l'instance de l'application. Pour plus d'informations sur les indicateurs de fonctionnalité, consultez la section [Création d'un profil de configuration d'indicateurs de fonctionnalité dans AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-creating-configuration-and-profile-feature-flags.html).
Après avoir fait d'Amazon Keyspaces le principal magasin de données, vous surveillez le comportement et les performances de l'application pour vous assurer qu'Amazon Keyspaces répond à vos exigences et que la migration est réussie.
Par exemple, si vous avez implémenté la double lecture pour votre application, pendant la phase de migration de l'application, vous transférez les lectures principales de Cassandra vers Amazon Keyspaces et les lectures secondaires d'Amazon Keyspaces vers Cassandra. Après la transition, vous continuez à surveiller et à comparer les résultats comme décrit dans la section de [validation des données](migration-online-validation.md) afin de garantir la cohérence entre les deux bases de données avant de mettre Cassandra hors service.
Si vous détectez des problèmes, vous pouvez rapidement revenir à l'état précédent en reprenant Cassandra comme banque de données principale. Vous ne passez à la phase de mise hors service de la migration que si Amazon Keyspaces répond à tous vos besoins en tant que magasin de données principal.
![\[Utilisation de la stratégie bleu-vert pour migrer une application d'Apache Cassandra vers Amazon Keyspaces.\]](http://docs.aws.amazon.com/fr_fr/keyspaces/latest/devguide/images/migration/online-migration-switch.png)
+ **Stratégie Canary** — Dans cette approche, vous déployez progressivement la migration vers un sous-ensemble de vos utilisateurs ou de votre trafic. Au départ, un faible pourcentage du trafic de votre application, par exemple 5 % de l'ensemble du trafic, est acheminé vers la version utilisant Amazon Keyspaces comme magasin de données principal, tandis que le reste du trafic continue d'utiliser Cassandra comme magasin de données principal.
Cela vous permet de tester de manière approfondie la version migrée avec le trafic réel, de surveiller ses performances, sa stabilité et d'étudier les problèmes potentiels. Si vous ne détectez aucun problème, vous pouvez augmenter progressivement le pourcentage de trafic acheminé vers Amazon Keyspaces jusqu'à ce qu'il devienne le principal magasin de données pour tous les utilisateurs et le trafic.
Ce déploiement par étapes minimise le risque d'interruptions de service généralisées et permet un processus de migration plus contrôlé. Si des problèmes critiques surviennent lors du déploiement de Canary, vous pouvez rapidement revenir à la version précédente en utilisant Cassandra comme base de données principale pour le segment de trafic concerné. Vous ne passez à la phase de mise hors service de la migration qu'après avoir vérifié qu'Amazon Keyspaces traite 100 % de vos utilisateurs et de votre trafic comme prévu.
Le schéma suivant illustre les différentes étapes de la stratégie Canary.
![\[Utilisation de la stratégie Canary pour migrer une application d'Apache Cassandra vers Amazon Keyspaces.\]](http://docs.aws.amazon.com/fr_fr/keyspaces/latest/devguide/images/migration/online-migration-canary.png)
# Mise hors service de Cassandra après une migration en ligne
Une fois que la migration de l'application est terminée, que votre application est entièrement exécutée sur Amazon Keyspaces et que vous avez validé la cohérence des données sur une certaine période, vous pouvez planifier de mettre hors service votre cluster Cassandra. Au cours de cette phase, vous pouvez évaluer si les données restantes dans votre cluster Cassandra doivent être archivées ou peuvent être supprimées. Cela dépend des politiques de votre organisation en matière de traitement et de conservation des données.
En suivant cette stratégie et en tenant compte des meilleures pratiques recommandées décrites dans cette rubrique lors de la planification de votre migration en ligne de Cassandra vers Amazon Keyspaces, vous pouvez garantir une transition fluide vers Amazon Keyspaces tout en read-after-write préservant la cohérence et la disponibilité de votre application.
La migration d'Apache Cassandra vers Amazon Keyspaces peut apporter de nombreux avantages, notamment une réduction des coûts opérationnels, une mise à l'échelle automatique, une sécurité améliorée et un cadre qui vous aide à atteindre vos objectifs de conformité. En planifiant une stratégie de migration en ligne comprenant deux écritures, le téléchargement des données historiques, la validation des données et un déploiement progressif, vous pouvez garantir une transition fluide avec un minimum de perturbations pour votre application et ses utilisateurs.
La mise en œuvre de la stratégie de migration en ligne décrite dans cette rubrique vous permet de valider les résultats de la migration, d'identifier et de résoudre les problèmes éventuels, puis de mettre hors service votre déploiement Cassandra existant au profit du service Amazon Keyspaces entièrement géré.