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 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 vous passez à Amazon Keyspaces en tant que magasin de données principal. Cela signifie que vous passez votre application à la lecture et à l'écriture directement depuis et vers Amazon Keyspaces. Afin de perturber le moins possible 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 de coupure bleu-vert et la stratégie de coupure canari. Les sections suivantes décrivent ces stratégies de manière plus détaillée.
Stratégie bleu-vert — En utilisant cette approche, vous pouvez changer 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. Pour ce faire, utilisez un indicateur de AWS AppConfig fonctionnalité pour contrôler le choix des magasins de données principaux et secondaires sur l'instance de l'application. Pour plus d'informations sur les indicateurs de fonctionnalités, voir Création d'un profil de configuration d'indicateur de fonctionnalité dans AWS AppConfig.
Après avoir fait d'Amazon Keyspaces le magasin de données principal, vous surveillez le comportement et les performances de l'application, afin de vous assurer qu'Amazon Keyspaces répond à vos exigences et que la migration est réussie.
Par exemple, si vous avez implémenté des lectures doubles 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 sur la validation des données 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 magasin de données principal. Vous ne pouvez passer à 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.
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 minutieusement la version migrée avec un 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 magasin de données principal 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 magasin de données principal pour le segment de trafic concerné. Vous ne pouvez passer à 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.
