As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Migração on-line para o Amazon Keyspaces: estratégias e melhores práticas
Se precisar manter a disponibilidade do aplicativo durante uma migração do Apache Cassandra para o Amazon Keyspaces, você pode preparar uma estratégia de migração on-line personalizada implementando os principais componentes discutidos neste tópico. Ao seguir essas melhores práticas para migrações on-line, você pode garantir que a disponibilidade e a read-after-write consistência dos aplicativos sejam mantidas durante todo o processo de migração, minimizando o impacto sobre seus usuários.
Ao criar uma estratégia de migração on-line do Apache Cassandra para o Amazon Keyspaces, você precisa considerar as seguintes etapas principais.
1. **Escrever novos dados**
+ Proxy **ZDM Dual Write para migração do Amazon Keyspaces — Use o proxy** ZDM Dual Write disponível no [Github para realizar a migração sem tempo de inatividade do Apache Cassandra](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) para o Amazon Keyspaces. O ZDM Proxy executa gravações duplas sem a necessidade de refatorar aplicativos existentes e executa leituras duplas para validação da consulta.
+ Gravações duplas em aplicativos: você pode implementar gravações duplas em seu aplicativo usando bibliotecas e drivers de cliente do Cassandra existentes. Designe um banco de dados como líder e o outro como seguidor. As falhas de gravação no banco de dados de seguidores são registradas em uma [fila de mensagens não entregues (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) para análise.
+ Gravações duplas no nível de mensagens: como alternativa, você pode configurar sua plataforma de mensagens existente para enviar gravações para o Cassandra e para o Amazon Keyspaces usando um consumidor adicional. Eventualmente, isso cria visualizações consistentes em ambos os bancos de dados.
1. **Migração de dados históricos**
+ Copiar dados históricos: você pode migrar dados históricos do Cassandra para o Amazon Keyspaces usando AWS Glue ou scripts personalizados de extração, transformação e carregamento (ETL). Gerencie a resolução de conflitos entre gravações duplas e cargas em massa usando técnicas como transações leves ou registros de data e hora.
+ Uso Time-To-Live (TTL): Para períodos mais curtos de retenção de dados, você pode usar o TTL no Cassandra e no Amazon Keyspaces para evitar o upload de dados históricos desnecessários. À medida que os dados antigos expiram no Cassandra e os novos dados são gravados por meio de gravações duplas, o Amazon Keyspaces acaba se atualizando.
1. **Validando dados**
+ Leituras duplas: implemente leituras duplas dos bancos de dados Cassandra (primário) e Amazon Keyspaces (secundário), comparando os resultados de forma assíncrona. As diferenças são registradas ou enviadas para uma DLQ.
+ Leituras de amostra: use as funções λ para amostrar e comparar dados periodicamente em ambos os sistemas, registrando quaisquer discrepâncias em um DLQ.
1. **Migrando o aplicativo**
+ Estratégia azul e verde: mude seu aplicativo para tratar o Amazon Keyspaces como o principal e o Cassandra como o armazenamento de dados secundário em uma única etapa. Monitore o desempenho e reverta se surgirem problemas.
+ Implantação canário: implemente gradualmente a migração primeiro para um subconjunto de usuários, aumentando incrementalmente o tráfego para o Amazon Keyspaces como principal até a migração completa.
1. **Desativação do Cassandra**
Depois que seu aplicativo for totalmente migrado para o Amazon Keyspaces e a consistência dos dados for validada, você poderá planejar a desativação do seu cluster Cassandra com base nas políticas de retenção de dados.
Ao planejar uma estratégia de migração on-line com esses componentes, você pode fazer a transição sem problemas para o serviço Amazon Keyspaces totalmente gerenciado com o mínimo de tempo de inatividade ou interrupção. As seções a seguir discutem esse componente em mais detalhes.
**Topics**
+ [Escrever novos dados durante uma migração on-line](migration-online-dw.md)
+ [Carregando dados históricos durante uma migração on-line](migration-online-historical.md)
+ [Validando a consistência dos dados durante uma migração on-line](migration-online-validation.md)
+ [Migrando o aplicativo durante uma migração on-line](migration-online-app-migration.md)
+ [Desativação do Cassandra após uma migração on-line](migration-online-decommission.md)
# Escrever novos dados durante uma migração on-line
A primeira etapa em um plano de migração on-line é garantir que todos os novos dados gravados pelo aplicativo sejam armazenados nos dois bancos de dados, em seu cluster Cassandra existente e no Amazon Keyspaces. O objetivo é fornecer uma visão consistente dos dois armazenamentos de dados. Você pode fazer isso aplicando todas as novas gravações nos dois bancos de dados. Para implementar gravações duplas, considere uma das três opções a seguir.
+ Proxy **ZDM Dual Write para migração do Amazon Keyspaces — Usando o proxy** ZDM para Amazon Keyspaces disponível no Github, você pode migrar suas cargas de trabalho do Apache [Cassandra](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) para o Amazon Keyspaces sem tempo de inatividade do aplicativo. Essa solução aprimorada implementa as AWS melhores práticas e amplia os recursos oficiais do ZDM Proxy.
+ Execute migrações on-line entre o Apache Cassandra e o Amazon Keyspaces.
+ Grave dados nas tabelas de origem e de destino simultaneamente sem refatorar os aplicativos.
+ Valide consultas por meio de operações de leitura dupla.
A solução oferece os seguintes aprimoramentos para trabalhar com o Amazon Keyspaces e com o AWS Amazon Keyspaces.
+ **Implantação de contêiner** — Use uma imagem Docker pré-configurada do Amazon Elastic Container Registry (Amazon ECR) para implantações acessíveis por VPC.
+ **Infraestrutura como código** — implante usando AWS CloudFormation modelos para configuração automáticaAWS Fargate.
+ **Compatibilidade com Amazon Keyspaces** — Acesse tabelas do sistema com adaptações personalizadas para o Amazon Keyspaces.
A solução é executada no Amazon ECS com o Fargate, fornecendo escalabilidade sem servidor com base em suas demandas de carga de trabalho. Um balanceador de carga de rede distribui o tráfego de entrada do aplicativo em várias tarefas do Amazon ECS para obter alta disponibilidade.
![\[Implementação do proxy de gravação dupla ZDM para migrar dados do Apache Cassandra para o Amazon Keyspaces.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/online-migration-zdm.png)
+ **Gravações duplas do aplicativo**: você pode implementar gravações duplas com o mínimo de alterações no código do aplicativo, aproveitando as bibliotecas e os drivers existentes do cliente Cassandra. Você pode implementar gravações duplas em seu aplicativo existente ou criar uma nova camada na arquitetura para lidar com gravações duplas. Para obter mais informações e um estudo de caso de um cliente que mostra como as gravações duplas foram implementadas em um aplicativo existente, consulte o estudo de [caso de migração do Cassandra](https://aws.amazon.com/solutions/case-studies/intuit-apache-migration-case-study/).
Ao implementar gravações duplas, você pode designar um banco de dados como líder e o outro banco de dados como seguidor. Isso permite que você continue gravando no banco de dados original ou principal sem permitir que falhas de gravação no banco de dados seguidor ou no banco de dados de destino interrompam o caminho crítico do seu aplicativo.
Em vez de tentar novamente gravações com falha no seguidor, você pode usar o Amazon Simple Queue Service para registrar gravações com falha em uma [fila de mensagens não entregues (DLQ](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)). O DLQ permite que você analise as gravações com falha no seguidor e determine por que o processamento não foi bem-sucedido no banco de dados de destino.
Para uma implementação de gravação dupla mais sofisticada, você pode seguir as AWS melhores práticas para criar uma sequência de transações locais usando o [padrão de saga](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/saga.html). Um padrão saga certifica que, se uma transação falhar, a saga executa transações compensatórias para reverter as alterações do banco de dados feitas pelas transações anteriores.
Ao usar gravações duplas para uma migração on-line, você pode configurar as gravações duplas seguindo o padrão da saga para que cada gravação seja uma transação local para garantir operações atômicas em bancos de dados heterogêneos. Para obter mais informações sobre como projetar aplicativos distribuídos usando os padrões de design recomendados para oNuvem AWS, consulte [Padrões de design, arquiteturas e implementações de nuvem](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/introduction).
![\[Implementando gravações duplas na camada do aplicativo ao migrar do Apache Cassandra para o Amazon Keyspaces.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/online-migration-dual-writes.png)
+ **Gravações duplas no nível de mensagens**: em vez de implementar gravações duplas na camada do aplicativo, você pode usar seu nível de mensagens existente para realizar gravações duplas no Cassandra e no Amazon Keyspaces.
Para fazer isso, você pode configurar um consumidor adicional em sua plataforma de mensagens para enviar gravações para os dois armazenamentos de dados. Essa abordagem fornece uma estratégia simples de baixo código usando a camada de mensagens para criar duas visualizações em ambos os bancos de dados que acabam sendo consistentes.
# Carregando dados históricos durante uma migração on-line
Depois de implementar gravações duplas para garantir que novos dados sejam gravados em ambos os armazenamentos de dados em tempo real, a próxima etapa do plano de migração é avaliar quantos dados históricos você precisa copiar ou carregar em massa do Cassandra para o Amazon Keyspaces. Isso garante que tanto os novos dados quanto os dados históricos estejam disponíveis no novo banco de dados do Amazon Keyspaces antes de você migrar o aplicativo.
Dependendo dos requisitos de retenção de dados, por exemplo, quantos dados históricos você precisa preservar com base nas políticas da sua organização, você pode considerar uma das duas opções a seguir.
+ **Upload em massa de dados históricos** — A migração de dados históricos de sua implantação atual do Cassandra para o Amazon Keyspaces pode ser realizada por meio de várias técnicas, por exemplo, usando AWS Glue scripts personalizados para extrair, transformar e carregar (ETL) os dados. Para obter mais informações sobre como usar AWS Glue para carregar dados históricos, consulte[Processo de migração off-line: Apache Cassandra para Amazon Keyspaces](migrating-offline.md).
Ao planejar o upload em massa de dados históricos, você precisa considerar como resolver conflitos que podem ocorrer quando novas gravações estão tentando atualizar os mesmos dados que estão sendo carregados. Espera-se que o upload em massa seja eventualmente consistente, o que significa que os dados chegarão a todos os nós eventualmente.
Se uma atualização dos mesmos dados ocorrer ao mesmo tempo devido a uma nova gravação, você deve garantir que ela não seja substituída pelo upload de dados históricos. Para garantir que você preserve as atualizações mais recentes de seus dados mesmo durante a importação em massa, você deve adicionar a resolução de conflitos nos scripts de upload em massa ou na lógica do aplicativo para gravações duplas.
Por exemplo, você pode usar [Transações leves](functional-differences.md#functional-differences.light-transactions) (LWT) para comparar e definir operações. Para fazer isso, você pode adicionar um campo adicional ao seu modelo de dados que represente a hora da modificação ou o estado.
Além disso, o Amazon Keyspaces oferece suporte à função de timestamp do Cassandra`WRITETIME`. Você pode usar os timestamps do lado do cliente do Amazon Keyspaces para preservar os timestamps do banco de dados de origem e implementar a resolução de conflitos. last-writer-wins Para obter mais informações, consulte [Carimbos de data/hora do lado do cliente no Amazon Keyspaces](client-side-timestamps.md).
+ **Usando Time-to-Live (TTL)** — Para períodos de retenção de dados menores que 30, 60 ou 90 dias, você pode usar o TTL no Cassandra e no Amazon Keyspaces durante a migração para evitar o upload de dados históricos desnecessários para o Amazon Keyspaces. O TTL permite definir um período de tempo após o qual os dados são removidos automaticamente do banco de dados.
Durante a fase de migração, em vez de copiar dados históricos para o Amazon Keyspaces, você pode definir as configurações de TTL para permitir que os dados históricos expirem automaticamente no sistema antigo (Cassandra), aplicando somente as novas gravações no Amazon Keyspaces usando o método de gravação dupla. Com o tempo, com os dados antigos expirando continuamente no cluster do Cassandra e os novos dados gravados usando o método de gravação dupla, o Amazon Keyspaces automaticamente se atualiza para conter os mesmos dados do Cassandra.
Essa abordagem pode reduzir significativamente a quantidade de dados a serem migrados, resultando em um processo de migração mais eficiente e simplificado. Você pode considerar essa abordagem ao lidar com grandes conjuntos de dados com diferentes requisitos de retenção de dados. Para obter mais informações sobre a TTL, consulte [Dados expirados com vida útil (TTL) para Amazon Keyspaces (para Apache Cassandra)](TTL.md).
Considere o exemplo a seguir de uma migração do Cassandra para o Amazon Keyspaces usando a expiração de dados TTL. Neste exemplo, definimos o TTL para ambos os bancos de dados para 60 dias e mostramos como o processo de migração progride em um período de 90 dias. Ambos os bancos de dados recebem os mesmos dados recém-gravados durante esse período usando o método de gravação dupla. Vamos analisar três fases diferentes da migração, cada fase dura 30 dias.
O funcionamento do processo de migração em cada fase é mostrado nas imagens a seguir.
![\[Usando TTL para expirar dados históricos ao migrar do Apache Cassandra para o Amazon Keyspaces.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/online-migration-TTL.png)
1. Após os primeiros 30 dias, o cluster Cassandra e o Amazon Keyspaces estão recebendo novas gravações. O cluster Cassandra também contém dados históricos que ainda não atingiram 60 dias de retenção, o que representa 50% dos dados no cluster.
Os dados com mais de 60 dias estão sendo excluídos automaticamente no cluster do Cassandra usando TTL. Nesse ponto, o Amazon Keyspaces contém 50% dos dados armazenados no cluster Cassandra, que é composto pelas novas gravações menos os dados históricos.
1. Depois de 60 dias, tanto o cluster Cassandra quanto o Amazon Keyspaces contêm os mesmos dados gravados nos últimos 60 dias.
1. Em 90 dias, tanto o Cassandra quanto o Amazon Keyspaces contêm os mesmos dados e estão expirando os dados na mesma taxa.
Este exemplo ilustra como evitar a etapa de carregamento de dados históricos usando TTL com uma data de expiração definida como 60 dias.
# Validando a consistência dos dados durante uma migração on-line
A próxima etapa do processo de migração on-line é a validação de dados. As gravações duplas estão adicionando novos dados ao seu banco de dados do Amazon Keyspaces e você concluiu a migração dos dados históricos usando upload em massa ou expiração de dados com TTL.
Agora você pode usar a fase de validação para confirmar se os dois armazenamentos de dados contêm, de fato, os mesmos dados e retornam os mesmos resultados de leitura. Você pode escolher uma das duas opções a seguir para validar se os dois bancos de dados contêm dados idênticos.
+ **Leituras duplas**: para validar se o banco de dados de origem e o banco de dados de destino contêm o mesmo conjunto de dados históricos e recém-gravados, você pode implementar leituras duplas. Para fazer isso, você lê o Cassandra principal e o banco de dados secundário do Amazon Keyspaces de forma semelhante ao método de gravação dupla e compara os resultados de forma assíncrona.
Os resultados do banco de dados primário são retornados ao cliente e os resultados do banco de dados secundário são usados para validar em relação ao conjunto de resultados primário. As diferenças encontradas podem ser registradas ou enviadas para uma [fila de mensagens não entregues (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) para posterior reconciliação.
No diagrama a seguir, o aplicativo está realizando uma leitura síncrona do Cassandra (que é o armazenamento de dados primário) e uma leitura assíncrona do Amazon Keyspaces, que é o armazenamento de dados secundário.
![\[Usando leituras duplas para validar a consistência dos dados durante uma migração on-line do Apache Cassandra para o Amazon Keyspaces.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/online-migration-dual-reads.png)
+ **Exemplos de leituras** — Uma solução alternativa que não exige alterações no código do aplicativo é usar AWS Lambda funções para obter amostras periódicas e aleatórias de dados do cluster Cassandra de origem e do banco de dados Amazon Keyspaces de destino.
Essas funções do Lambda podem ser configuradas para serem executadas em intervalos regulares. A função do Lambda recupera um subconjunto aleatório de dados dos sistemas de origem e destino e, em seguida, realiza uma comparação dos dados amostrados. Quaisquer discrepâncias ou incompatibilidades entre os dois conjuntos de dados podem ser registradas e enviadas para uma [fila de mensagens não entregues (DLQ](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)) dedicada para posterior reconciliação.
Esse processo é ilustrado no diagrama a seguir.
![\[Usando leituras de amostra para validar a consistência dos dados durante a migração on-line do Apache Cassandra para o Amazon Keyspaces.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/online-migration-sample-reads.png)
# Migrando o aplicativo durante uma migração on-line
Na quarta fase de uma migração on-line, você está migrando seu aplicativo e fazendo a transição para o Amazon Keyspaces como armazenamento de dados primário. Isso significa que você alterna seu aplicativo para ler e gravar diretamente de e para o Amazon Keyspaces. Para garantir o mínimo de interrupção para seus usuários, esse deve ser um processo bem planejado e coordenado.
Duas soluções diferentes recomendadas para migração de aplicativos estão disponíveis: a estratégia de recorte azul esverdeado e a estratégia de corte canário. As seções a seguir descrevem essas estratégias em mais detalhes.
+ **Estratégia azul e verde**: usando essa abordagem, você muda seu aplicativo para tratar o Amazon Keyspaces como o armazenamento de dados primário e o Cassandra como o armazenamento de dados secundário em uma única etapa. Você pode fazer isso usando um sinalizador de AWS AppConfig recurso para controlar a eleição dos armazenamentos de dados primários e secundários na instância do aplicativo. Para obter mais informações sobre sinalizadores de atributos, consulte [Creating a feature flag configuration profile in AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-creating-configuration-and-profile-feature-flags.html).
Depois de tornar o Amazon Keyspaces o armazenamento de dados principal, você monitora o comportamento e o desempenho do aplicativo, garantindo que o Amazon Keyspaces atenda aos seus requisitos e que a migração seja bem-sucedida.
Por exemplo, se você implementou leituras duplas para seu aplicativo, durante a fase de migração do aplicativo, você faz a transição das leituras primárias do Cassandra para o Amazon Keyspaces e as leituras secundárias do Amazon Keyspaces para o Cassandra. Após a transição, você continua monitorando e comparando os resultados conforme descrito na seção de [validação de dados](migration-online-validation.md) para garantir a consistência em ambos os bancos de dados antes de desativar o Cassandra.
Se você detectar algum problema, poderá reverter rapidamente para o estado anterior revertendo para o Cassandra como o armazenamento de dados primário. Você só prossegue para a fase de descomissionamento da migração se o Amazon Keyspaces estiver atendendo a todas as suas necessidades como armazenamento de dados primário.
![\[Usando a estratégia azul e verde para migrar um aplicativo do Apache Cassandra para o Amazon Keyspaces.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/online-migration-switch.png)
+ **Estratégia canário**: nessa abordagem, você gradualmente implementa a migração para um subconjunto de seus usuários ou tráfego. Inicialmente, uma pequena porcentagem do tráfego do seu aplicativo, por exemplo, 5% de todo o tráfego é roteado para a versão usando o Amazon Keyspaces como armazenamento de dados primário, enquanto o restante do tráfego continua usando o Cassandra como armazenamento de dados primário.
Isso permite que você teste minuciosamente a versão migrada com tráfego real e monitore seu desempenho, estabilidade e investigue possíveis problemas. Se você não detectar nenhum problema, poderá aumentar incrementalmente a porcentagem de tráfego roteado para o Amazon Keyspaces até que ele se torne o armazenamento de dados principal para todos os usuários e tráfego.
Essa implantação gradual minimiza o risco de interrupções generalizadas no serviço e permite um processo de migração mais controlado. Se surgirem problemas críticos durante a implantação canário, você poderá reverter rapidamente para a versão anterior usando o Cassandra como armazenamento de dados primário para o segmento de tráfego afetado. Você só prossegue para a fase de descomissionamento da migração depois de validar que o Amazon Keyspaces processa 100% dos seus usuários e tráfego conforme o esperado.
O diagrama a seguir ilustra as etapas individuais da estratégia canário.
![\[Usando a estratégia canário para migrar um aplicativo do Apache Cassandra para o Amazon Keyspaces.\]](http://docs.aws.amazon.com/pt_br/keyspaces/latest/devguide/images/migration/online-migration-canary.png)
# Desativação do Cassandra após uma migração on-line
Depois que a migração do aplicativo estiver concluída, seu aplicativo estiver totalmente em execução no Amazon Keyspaces e você tiver validado a consistência dos dados por um período de tempo, você poderá planejar a desativação do seu cluster Cassandra. Durante essa fase, você pode avaliar se os dados restantes em seu cluster do Cassandra precisam ser arquivados ou podem ser excluídos. Isso depende das políticas da sua organização para tratamento e retenção de dados.
Ao seguir essa estratégia e considerar as melhores práticas recomendadas descritas neste tópico ao planejar sua migração on-line do Cassandra para o Amazon Keyspaces, você pode garantir uma transição perfeita para o Amazon Keyspaces e, ao mesmo tempo, read-after-write manter a consistência e a disponibilidade do seu aplicativo.
A migração do Apache Cassandra para o Amazon Keyspaces pode oferecer vários benefícios, incluindo redução da sobrecarga operacional, ajuste de escala automático, segurança aprimorada e uma estrutura que ajuda você a atingir suas metas de conformidade. Ao planejar uma estratégia de migração on-line com gravações duplas, upload de dados históricos, validação de dados e implantação gradual, você pode garantir uma transição tranquila com o mínimo de interrupção para seu aplicativo e seus usuários.
A implementação da estratégia de migração on-line discutida neste tópico permite que você valide os resultados da migração, identifique e resolva quaisquer problemas e, por fim, desative sua implantação atual do Cassandra em favor do serviço Amazon Keyspaces totalmente gerenciado.