Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Migración online a Amazon Keyspaces: estrategias y prácticas recomendadas
Si necesita mantener la disponibilidad de las aplicaciones durante una migración de Apache Cassandra a Amazon Keyspaces, puede preparar una estrategia de migración en línea personalizada mediante la implementación de los componentes clave que se describen en este tema. Si sigue estas prácticas recomendadas para las migraciones en línea, puede garantizar que la disponibilidad y la read-after-write coherencia de las aplicaciones se mantengan durante todo el proceso de migración, lo que minimiza el impacto en los usuarios.
Al diseñar una estrategia de migración en línea de Apache Cassandra a Amazon Keyspaces, debe tener en cuenta los siguientes pasos clave.
1. **Escritura de nuevos datos**
+ Proxy de **escritura doble de ZDM para la migración de Amazon Keyspaces: utilice el proxy** de escritura doble de ZDM disponible [en](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) Github para realizar una migración sin tiempo de inactividad de Apache Cassandra a Amazon Keyspaces. El proxy ZDM realiza escrituras duales sin necesidad de refactorizar las aplicaciones existentes y realiza lecturas duales para validar las consultas.
+ Escrituras duales de aplicación: puede implementar escrituras duales en su aplicación utilizando las bibliotecas de clientes y los controladores existentes de Cassandra. Designe una base de datos como líder y la otra como seguidora. Los errores de escritura en la base de datos seguidora se registran en una [cola de mensajes fallidos (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) para su análisis.
+ Escrituras duales en el nivel de mensajería: también puede configurar su plataforma de mensajería existente para enviar escrituras tanto a Cassandra como a Amazon Keyspaces con un consumidor adicional. Con el tiempo, esto crea vistas coherentes en ambas bases de datos.
1. **Migración de datos históricos**
+ Copia de datos históricos: puede migrar datos históricos de Cassandra a Amazon Keyspaces con AWS Glue o mediante scripts de extracción, transformación y carga (ETL) personalizados. Administre la resolución de conflictos entre escrituras duales y cargas en lotes mediante técnicas como las transacciones simplificadas o las marcas de tiempo.
+ Uso Time-To-Live (TTL): para períodos de retención de datos más cortos, puede usar TTL tanto en Cassandra como en Amazon Keyspaces para evitar cargar datos históricos innecesarios. A medida que los datos antiguos caducan en Cassandra y se escriben datos nuevos mediante escrituras duales, Amazon Keyspaces acaba poniéndose al día.
1. **Validación de los datos**
+ Lecturas duales: implemente lecturas duales tanto desde las bases de datos de Cassandra (principal) como desde las de Amazon Keyspaces (secundaria) y compare los resultados de forma asíncrona. Las diferencias se registran o se envían a una DLQ.
+ Lecturas de ejemplo: utilice funciones λ para muestrear y comparar periódicamente los datos entre ambos sistemas y registrar cualquier discrepancia en una DLQ.
1. **Migración de la aplicación**
+ Estrategia azul-verde: modifique su aplicación para que trate Amazon Keyspaces como el almacén de datos principal y Cassandra como el almacén de datos secundario en un solo paso. Supervise el rendimiento y deshaga esas modificaciones en caso de que surjan problemas.
+ Implementación canario: primero implemente gradualmente la migración a un subconjunto de usuarios, aumentando gradualmente el tráfico a Amazon Keyspaces como principal hasta que se migre por completo.
1. **Retirada de Cassandra**
Una vez que su aplicación se haya migrado por completo a Amazon Keyspaces y se haya validado la coherencia de datos, puede planificar la retirada del clúster de Cassandra en función de las políticas de retención de datos.
Si planifica una estrategia de migración en línea con estos componentes, podrá realizar una transición fluida al servicio de Amazon Keyspaces totalmente administrado con un tiempo de inactividad o interrupción mínimos. En las siguientes secciones se aborda cada componente de manera detallada.
**Topics**
+ [Escritura de nuevos datos durante una migración en línea](migration-online-dw.md)
+ [Carga de datos históricos durante una migración en línea](migration-online-historical.md)
+ [Validación de la coherencia de datos durante una migración en línea](migration-online-validation.md)
+ [Migración de la aplicación durante una migración en línea](migration-online-app-migration.md)
+ [Retirada de Cassandra tras una migración en línea](migration-online-decommission.md)
# Escritura de nuevos datos durante una migración en línea
El primer paso de un plan de migración en línea consiste en garantizar que cualquier dato nuevo que escriba la aplicación se almacene en ambas bases de datos, en el clúster de Cassandra existente y en Amazon Keyspaces. El objetivo es proporcionar una visión coherente de los dos almacenes de datos. Para ello, aplique todas las escrituras nuevas a ambas bases de datos. Para implementar escrituras duales, considere una de las tres opciones siguientes.
+ Migración de **proxy de escritura doble de ZDM para Amazon Keyspaces**: con el proxy de ZDM para Amazon Keyspaces disponible [en](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) Github, puede migrar sus cargas de trabajo de Apache Cassandra a Amazon Keyspaces sin tiempo de inactividad de la aplicación. Esta solución mejorada implementa las AWS mejores prácticas y amplía las capacidades oficiales del proxy de ZDM.
+ Realice migraciones en línea entre Apache Cassandra y Amazon Keyspaces.
+ Escriba datos en las tablas de origen y destino simultáneamente sin refactorizar las aplicaciones.
+ Valide las consultas mediante operaciones de doble lectura.
La solución ofrece las siguientes mejoras para trabajar con AWS Amazon Keyspaces.
+ **Despliegue de contenedores**: utilice una imagen de Docker preconfigurada de Amazon Elastic Container Registry (Amazon ECR) para las implementaciones accesibles mediante VPC.
+ **Infraestructura como código**: impleméntela mediante AWS CloudFormation plantillas para una configuración automática. AWS Fargate
+ **Compatibilidad con Amazon Keyspaces**: acceda a las tablas del sistema con adaptaciones personalizadas para Amazon Keyspaces.
La solución se ejecuta en Amazon ECS con Fargate, lo que proporciona escalabilidad sin servidor en función de sus demandas de carga de trabajo. Un balanceador de carga de red distribuye el tráfico entrante de las aplicaciones entre varias tareas de Amazon ECS para lograr una alta disponibilidad.
![\[Implementación del proxy de escritura dual ZDM para migrar datos de Apache Cassandra a Amazon Keyspaces.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/online-migration-zdm.png)
+ **Escrituras duales de aplicación**: puede implementar escrituras duales con cambios mínimos en el código de su aplicación aprovechando las bibliotecas de clientes y los controladores existentes de Cassandra. Puede implementar escrituras duales en su aplicación existente o crear una nueva capa en la arquitectura para administrar las escrituras duales. Para obtener más información y un caso práctico de un cliente que demuestra cómo se implementaron las escrituras duales en una aplicación existente, consulte este [caso práctico de migración de Cassandra](https://aws.amazon.com/solutions/case-studies/intuit-apache-migration-case-study/).
Al implementar escrituras duales, puede designar una base de datos como líder y la otra base de datos como seguidora. Esto le permite seguir escribiendo en la base de datos original (o líder) evitando que los errores de escritura en la base de datos de destino (o seguidora) interrumpan la ruta crítica de la aplicación.
En lugar de volver a intentar las escrituras fallidas en la seguidora, puede utilizar Amazon Simple Queue Service para registrar las escrituras fallidas en una [cola de mensajes fallidos (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html). La DLQ le permite analizar las escrituras fallidas en la seguidora y determinar por qué no se ha realizado correctamente el procesamiento en la base de datos de destino.
[Para una implementación de escritura doble más sofisticada, puede seguir las AWS mejores prácticas para diseñar una secuencia de transacciones locales utilizando el patrón saga.](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/saga.html) Un patrón saga asegura que, si se produce un error en una transacción, la saga ejecuta transacciones de compensación para revertir los cambios en la base de datos realizados por las transacciones anteriores.
Si utiliza escrituras duales para una migración en línea, puede configurar las escrituras duales para que sigan el patrón saga, de modo que cada escritura sea una transacción local que garantice las operaciones atómicas en bases de datos heterogéneas. Para obtener más información sobre cómo diseñar aplicaciones distribuidas utilizando los patrones de diseño recomendados para ellasNube de AWS, consulte [Patrones de diseño, arquitecturas e implementaciones en la nube](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/introduction).
![\[Implementación de escrituras duales en la capa de aplicación al migrar de Apache Cassandra a Amazon Keyspaces.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/online-migration-dual-writes.png)
+ **Escrituras duales en el nivel de mensajería**: en lugar de implementar escrituras duales en la capa de aplicación, puede usar el nivel de mensajería existente para realizar escrituras duales en Cassandra y Amazon Keyspaces.
Para ello, puede configurar un consumidor adicional para su plataforma de mensajería de modo que envíe las escrituras a ambos almacenes de datos. Este enfoque proporciona una estrategia sencilla y con poco código que utiliza el nivel de mensajería para crear dos vistas en ambas bases de datos que, en última instancia, sean coherentes.
# Carga de datos históricos durante una migración en línea
Tras implementar la escritura dual para garantizar que los nuevos datos se escriban en ambos almacenes de datos en tiempo real, el siguiente paso del plan de migración consiste en evaluar la cantidad de datos históricos que necesita copiar o cargar por lotes de Cassandra a Amazon Keyspaces. Esto garantiza que tanto los datos nuevos como los históricos estén disponibles en la nueva base de datos de Amazon Keyspaces antes de migrar la aplicación.
En función de sus requisitos de retención de datos, por ejemplo, de la cantidad de datos históricos que necesite conservar en función de las políticas de su organización, puede considerar una de las dos opciones siguientes.
+ **Carga masiva de datos históricos**: la migración de los datos históricos de su implementación actual de Cassandra a Amazon Keyspaces se puede realizar mediante diversas técnicas, por ejemplo, el AWS Glue uso de scripts personalizados para extraer, transformar y cargar (ETL) los datos. Para obtener más información acerca del uso de AWS Glue para cargar datos históricos, consulte [Proceso de migración sin conexión: de Apache Cassandra a Amazon Keyspaces](migrating-offline.md).
Al planificar la carga masiva de datos históricos, hay que tener en cuenta cómo resolver los conflictos que pueden producirse cuando se intenta actualizar con nuevas escrituras los mismos datos que se están cargando. Cabe esperar que la carga por lotes acabe siendo coherente, lo que significa que los datos llegarán a todos los nodos al final.
Si se produce una actualización de los mismos datos al mismo tiempo debido a una nueva escritura, debe asegurarse de que la carga de los datos históricos no los sobrescriba. Para asegurarse de conservar las últimas actualizaciones de sus datos incluso durante la importación por lotes, debe incorporar la solución de conflictos a los scripts de carga por lotes o a la lógica de la aplicación para las escrituras duales.
Por ejemplo, puede usar [Transacciones ligeras](functional-differences.md#functional-differences.light-transactions) (LWT) para comparar y configurar las operaciones. Para ello, puede agregar un campo adicional a su modelo de datos que represente el momento de la modificación o el estado.
Además, Amazon Keyspaces admite la función de marca de tiempo `WRITETIME` de Cassandra. Puede utilizar las marcas de tiempo del lado del cliente de Amazon Keyspaces para conservar las marcas de tiempo de la base de datos de origen e implementar la resolución de conflictos. last-writer-wins Para obtener más información, consulte [Marcas de tiempo del cliente en Amazon Keyspaces](client-side-timestamps.md).
+ **Uso de Time-to-Live (TTL)**: para períodos de retención de datos inferiores a 30, 60 o 90 días, puede usar TTL en Cassandra y Amazon Keyspaces durante la migración para evitar cargar datos históricos innecesarios en Amazon Keyspaces. El TTL le permite establecer un período de tiempo tras el cual se quitan automáticamente los datos de la base de datos.
Durante la fase de migración, en lugar de copiar los datos históricos a Amazon Keyspaces, puede configurar los ajustes del TTL para permitir que los datos históricos caduquen automáticamente en el sistema anterior (Cassandra) y aplicar únicamente las nuevas escrituras a Amazon Keyspaces mediante el método de escritura dual. Con el paso del tiempo, y dado que los datos antiguos caducan continuamente en el clúster de Cassandra y los nuevos se escriben con el método de escritura dual, Amazon Keyspaces se pone al día automáticamente para contener los mismos datos que Cassandra.
Este enfoque puede reducir considerablemente la cantidad de datos que se van a migrar, lo que se traduce en un proceso de migración más eficiente y optimizado. Puede plantearse este enfoque cuando se enfrente a conjuntos de datos grandes con requisitos de retención de datos variables. Para obtener más información sobre e TTL, consulte [Caducidad de datos con período de vida (TTL) para Amazon Keyspaces (para Apache Cassandra)](TTL.md).
Plantéese el siguiente ejemplo de una migración de Cassandra a Amazon Keyspaces mediante la caducidad de datos con TTL. En este ejemplo, establecemos el TTL de ambas bases de datos en 60 días y mostramos cómo progresa el proceso de migración durante un período de 90 días. Ambas bases de datos reciben los mismos datos recién escritos durante este período mediante el método de escritura dual. Vamos a analizar tres fases diferentes de la migración, cada una de las cuales dura 30 días.
En las siguientes imágenes se muestra cómo funciona el proceso de migración para cada fase.
![\[Uso del TTL para hacer caducar los datos históricos al migrar de Apache Cassandra a Amazon Keyspaces.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/online-migration-TTL.png)
1. Tras los primeros 30 días, el clúster de Cassandra y Amazon Keyspaces han estado recibiendo nuevas escrituras. El clúster de Cassandra también contiene datos históricos que aún no han alcanzado los 60 días de retención, lo que representa el 50 % de los datos del clúster.
Los datos que tienen más de 60 días se eliminan automáticamente en el clúster de Cassandra mediante TTL. En este punto, Amazon Keyspaces contiene el 50 % de los datos almacenados en el clúster de Cassandra, que se compone de las nuevas escrituras menos los datos históricos.
1. Transcurridos 60 días, tanto el clúster de Cassandra como Amazon Keyspaces contienen los mismos datos escritos en los últimos 60 días.
1. En un plazo de 90 días, tanto Cassandra como Amazon Keyspaces contienen los mismos datos y los datos caducan al mismo ritmo.
Este ejemplo ilustra cómo evitar el paso de cargar datos históricos mediante el uso del TTL con una fecha de caducidad establecida en 60 días.
# Validación de la coherencia de datos durante una migración en línea
El siguiente paso del proceso de migración en línea es la validación de los datos. Las escrituras duales añaden nuevos datos a su base de datos de Amazon Keyspaces y ha completado la migración de los datos históricos mediante la carga por lotes o la caducidad de los datos con TTL.
Ahora puede utilizar la fase de validación para confirmar que ambos almacenes de datos contienen realmente los mismos datos y devuelven los mismos resultados de lectura. Puede elegir una de las dos opciones siguientes para validar que ambas bases de datos contengan datos idénticos.
+ **Lecturas duales**: para validar que tanto la base de datos de origen como la de destino contengan el mismo conjunto de datos históricos y recién escritos, puede implementar lecturas duales. Para ello, debe leer tanto la base de datos principal de Cassandra como la base de datos secundaria de Amazon Keyspaces, de forma similar al método de escritura dual, y comparar los resultados de forma asíncrona.
Los resultados de la base de datos principal se devuelven al cliente y los resultados de la base de datos secundaria se utilizan para validarlos con el conjunto de resultados principal. Las diferencias detectadas se pueden registrar o enviar a una [cola de mensajes fallidos (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) para su posterior conciliación.
En el siguiente diagrama, la aplicación realiza una lectura sincrónica desde Cassandra (que es el almacén de datos principal) y una lectura asincrónica desde Amazon Keyspaces, que es el almacén de datos secundario.
![\[Uso de lecturas duales para validar la coherencia de datos durante una migración en línea de Apache Cassandra a Amazon Keyspaces.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/online-migration-dual-reads.png)
+ **Lecturas de muestra**: una solución alternativa que no requiere cambios en el código de la aplicación consiste en utilizar AWS Lambda funciones para muestrear de forma periódica y aleatoria los datos del clúster Cassandra de origen y de la base de datos Amazon Keyspaces de destino.
Estas funciones de Lambda se pueden configurar para que se ejecuten a intervalos regulares. La función de Lambda recupera un subconjunto aleatorio de datos de los sistemas de origen y destino y, a continuación, realiza una comparación de los datos muestreados. Cualquier discrepancia o discordancia entre los dos conjuntos de datos se puede registrar y enviar a una [cola de mensajes fallidos (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) específica para su posterior conciliación.
Este proceso se ilustra en el siguiente diagrama.
![\[Uso de lecturas de muestra para validar la coherencia de datos durante una migración en línea de Apache Cassandra a Amazon Keyspaces.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/online-migration-sample-reads.png)
# Migración de la aplicación durante una migración en línea
En la cuarta fase de una migración en línea, migrará su aplicación y realizará la transición a Amazon Keyspaces como almacén de datos principal. Esto significa que puede cambiar la aplicación para que lea y escriba directamente desde y hacia Amazon Keyspaces. Para garantizar una interrupción mínima para sus usuarios, debe ser un proceso bien planificado y coordinado.
Hay disponibles dos soluciones recomendadas diferentes para la migración de aplicaciones: la estrategia de transición azul-verde y la estrategia de transición canario. En las siguientes secciones se describen estas estrategias con más detalle.
+ **Estrategia azul-verde**: mediante el uso de este enfoque, modifica su aplicación para que trate Amazon Keyspaces como el almacén de datos principal y Cassandra como el almacén de datos secundario en un solo paso. Para ello, utilice un indicador de AWS AppConfig función para controlar la elección de los almacenes de datos principales y secundarios en la instancia de la aplicación. Para obtener más información sobre marcas de características, consulte [Creación de un perfil de configuración de marcas de características en AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-creating-configuration-and-profile-feature-flags.html).
Tras convertir Amazon Keyspaces en el almacén de datos principal, debe supervisar el comportamiento y el rendimiento de la aplicación para garantizar que Amazon Keyspaces cumpla sus requisitos y que la migración se realice correctamente.
Por ejemplo, si ha implementado lecturas duales para su aplicación, durante la fase de migración de la aplicación, pasará las lecturas principales de Cassandra a Amazon Keyspaces y las lecturas secundarias de Amazon Keyspaces a Cassandra. Tras la transición, debe seguir supervisando y comparando los resultados tal y como se describe en la sección de [validación de datos](migration-online-validation.md) para garantizar la coherencia en ambas bases de datos antes de retirar Cassandra del servicio.
Si detecta algún problema, puede volver rápidamente al estado anterior recuperando Cassandra como almacén de datos principal. Solo pasará a la fase de retirada de la migración si Amazon Keyspaces satisface todas sus necesidades como almacén de datos principal.
![\[Uso de la estrategia azul-verde para migrar una aplicación de Apache Cassandra a Amazon Keyspaces.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/online-migration-switch.png)
+ **Estrategia canario**: con este enfoque, se lleva a cabo gradualmente la migración para un subconjunto de los usuarios o del tráfico. Inicialmente, un pequeño porcentaje del tráfico de la aplicación (por ejemplo, el 5 % de todo el tráfico) se redirige a la versión que utiliza Amazon Keyspaces como almacén de datos principal, mientras que el resto del tráfico sigue utilizando Cassandra como almacén de datos principal.
Esto le permite probar exhaustivamente la versión migrada con tráfico real, supervisar su rendimiento y estabilidad e investigar los posibles problemas. Si no detecta ningún problema, puede aumentar gradualmente el porcentaje de tráfico que se dirige a Amazon Keyspaces hasta que se convierta en el almacén de datos principal para todos los usuarios y todo el tráfico.
Esta implementación por etapas minimiza el riesgo de interrupciones generalizadas del servicio y permite un proceso de migración más controlado. Si surge algún problema grave durante la implementación canario, puede volver rápidamente a la versión anterior utilizando Cassandra como almacén de datos principal para el segmento de tráfico afectado. Solo pasará a la fase de retirada de la migración después de haber validado que Amazon Keyspaces procesa el 100 % de los usuarios y el tráfico según lo previsto.
El siguiente diagrama ilustra los pasos individuales de la estrategia canario.
![\[Uso de la estrategia canario para migrar una aplicación de Apache Cassandra a Amazon Keyspaces.\]](http://docs.aws.amazon.com/es_es/keyspaces/latest/devguide/images/migration/online-migration-canary.png)
# Retirada de Cassandra tras una migración en línea
Una vez finalizada la migración de la aplicación, cuando la aplicación se esté ejecutando completamente en Amazon Keyspaces y se haya validado la coherencia de datos durante un período de tiempo, puede planificar la retirada del clúster de Cassandra. Durante esta fase, puede evaluar si los datos que quedan en su clúster de Cassandra deben archivarse o si se pueden eliminar. Esto depende de las políticas de su organización en materia de tratamiento y retención de datos.
Si sigue esta estrategia y tiene en cuenta las mejores prácticas recomendadas que se describen en este tema al planificar la migración en línea de Cassandra a Amazon Keyspaces, puede garantizar una transición fluida a Amazon Keyspaces y, al mismo tiempo, read-after-write mantener la coherencia y la disponibilidad de su aplicación.
La migración de Apache Cassandra a Amazon Keyspaces puede ofrecer numerosas ventajas, como la reducción de los gastos operativos, el escalado automático, la mejora de la seguridad y un marco que le ayude a alcanzar sus objetivos de conformidad normativa. Al planificar una estrategia de migración en línea con escrituras duales, carga de datos históricos, validación de datos e implementación gradual, puede garantizar una transición fluida con una interrupción mínima para su aplicación y sus usuarios.
La implementación de la estrategia de migración en línea que se analiza en este tema le permite validar los resultados de la migración, identificar y abordar cualquier problema y, en última instancia, retirar su implementación actual de Cassandra en favor del servicio de Amazon Keyspaces totalmente administrado.