Crie um plano de migração para migrar do Apache Cassandra para o Amazon Keyspaces

Para uma migração bem-sucedida do Apache Cassandra para o Amazon Keyspaces, recomendamos uma análise dos conceitos e das melhores práticas de migração aplicáveis, bem como uma comparação das opções disponíveis. Este tópico descreve como o processo de migração funciona, apresentando vários conceitos-chave e as ferramentas e técnicas disponíveis para você. Você pode avaliar as diferentes estratégias de migração para selecionar a que melhor atenda às suas necessidades.

Tópicos

• Compatibilidade funcional
• Estime os preços do Amazon Keyspaces
• Escolher uma estratégia de migração
• Migração on-line para o Amazon Keyspaces: estratégias e melhores práticas
• Processo de migração offline: Apache Cassandra para Amazon Keyspaces
• Usando uma solução de migração híbrida: Apache Cassandra para Amazon Keyspaces

Compatibilidade funcional

Considere cuidadosamente as diferenças funcionais entre o Apache Cassandra e o Amazon Keyspaces antes da migração. O Amazon Keyspaces oferece suporte a todas as operações de plano de dados do Cassandra comumente usadas, como criar espaços de chaves e tabelas, ler dados e gravar dados. No entanto, existem algumas Cassandra que o APIs Amazon Keyspaces não suporta. Para obter mais informações sobre o suporteAPIs, consulteAPIs, operações, funções e tipos de dados compatíveis do Cassandra. Para uma visão geral de todas as diferenças funcionais entre o Amazon Keyspaces e o Apache Cassandra, consulte. Diferenças funcionais: Amazon Keyspaces versus Apache Cassandra

Para comparar o Cassandra APIs e o esquema que você está usando com a funcionalidade compatível no Amazon Keyspaces, você pode executar um script de compatibilidade disponível no kit de ferramentas do Amazon Keyspaces em. GitHub

Como usar o script de compatibilidade

1. Baixe o script de compatibilidade do Python GitHube mova-o para um local que tenha acesso ao seu cluster Apache Cassandra existente.

2. O script de compatibilidade usa parâmetros semelhantes aosCQLSH. --portInsira --host e insira o endereço IP e a porta que você usa para se conectar e executar consultas em um dos nós do Cassandra em seu cluster. Se seu cluster Cassandra usa autenticação, você também precisa fornecer e. -username -password Para executar o script de compatibilidade, você pode usar o comando a seguir.

   python toolkit-compat-tool.py --host hostname or IP -u "username" -p "password" --port native transport port

Estime os preços do Amazon Keyspaces

Esta seção fornece uma visão geral das informações que você precisa coletar das tabelas do Apache Cassandra para calcular o custo estimado do Amazon Keyspaces. Cada uma de suas tabelas exige tipos de dados diferentes, precisa oferecer suporte a CQL consultas diferentes e manter um tráfego de leitura/gravação distinto. Pensar em seus requisitos com base em tabelas se alinha aos modos de isolamento de recursos em nível de tabela e capacidade de taxa de transferência de leitura/gravação do Amazon Keyspaces. Com o Amazon Keyspaces, você pode definir a capacidade de leitura/gravação e as políticas de escalabilidade automática para tabelas de forma independente. Compreender os requisitos das tabelas ajuda você a priorizar tabelas para migração com base na funcionalidade, no custo e no esforço de migração.

Colete as seguintes métricas da tabela do Cassandra antes de uma migração. Essas informações ajudam a estimar o custo da sua carga de trabalho no Amazon Keyspaces.

• Nome da tabela — O nome do espaço de teclas totalmente qualificado e o nome da tabela.

• Descrição — Uma descrição da tabela, por exemplo, como ela é usada ou que tipo de dados são armazenados nela.

• Média de leituras por segundo — O número médio de leituras em nível de coordenadas na tabela em um grande intervalo de tempo.

• Média de gravações por segundo — O número médio de gravações em nível de coordenadas na tabela em um grande intervalo de tempo.

• Tamanho médio da linha em bytes — O tamanho médio da linha em bytes.

• Tamanho de armazenamento em GBs — O tamanho bruto de armazenamento de uma tabela.

• Detalhamento da consistência de leitura — A porcentagem de leituras que usam consistência eventual (LOCAL_ONEouONE) versus consistência forte (LOCAL_QUORUM).

Esta tabela mostra um exemplo das informações sobre suas tabelas que você precisa reunir ao planejar uma migração.

Nome da tabela	Descrição	Média de leituras por segundo	Média de gravações por segundo	Tamanho médio da linha em bytes	Tamanho de armazenamento em GBs	Detalhamento da consistência de leitura
mykeyspace.mytable	Usado para armazenar o histórico do carrinho de compras	10.000	5.000	2.200	2.000	100% LOCAL_ONE
mykeyspace.mytable2	Usado para armazenar as informações mais recentes do perfil	20.000	1.000	850	1.000	25% LOCAL_QUORUM 75% LOCAL_ONE

Como coletar métricas de tabela

Esta seção fornece instruções passo a passo sobre como coletar as métricas de tabela necessárias do seu cluster Cassandra existente. Essas métricas incluem tamanho da linha, tamanho da tabela e solicitações de leitura/gravação por segundo ()RPS. Eles permitem que você avalie os requisitos de capacidade de processamento de uma tabela do Amazon Keyspaces e estime os preços.

Como coletar métricas de tabela na tabela de origem do Cassandra

1. Determine o tamanho da linha

   O tamanho da linha é importante para determinar a capacidade de leitura e a utilização da capacidade de gravação no Amazon Keyspaces. O diagrama a seguir mostra a distribuição típica de dados em um intervalo de tokens do Cassandra.

   

   Você pode usar um script de amostragem de tamanho de linha disponível GitHubpara coletar métricas de tamanho de linha para cada tabela em seu cluster do Cassandra. O script exporta dados da tabela do Apache Cassandra usando cqlsh e calculando o mínimo, o máximo, awk a média e o desvio padrão do tamanho da linha em um conjunto de amostra configurável de dados da tabela. O amostrador de tamanho de linha passa os argumentos paracqlsh, portanto, os mesmos parâmetros podem ser usados para se conectar e ler do seu cluster do Cassandra.

   A instrução a seguir é um exemplo disso.

   ./row-size-sampler.sh 10.22.33.44 9142 \\
      -u "username" -p "password" --ssl

   Para obter mais informações sobre como o tamanho da linha é calculado no Amazon Keyspaces, consulte. Como calcular o tamanho da linha no Amazon Keyspaces

2. Determine o tamanho da tabela

   Com o Amazon Keyspaces, você não precisa provisionar o armazenamento com antecedência. O Amazon Keyspaces monitora continuamente o tamanho faturável de suas tabelas para determinar suas cobranças de armazenamento. O armazenamento é cobrado por GB por mês. O tamanho da tabela do Amazon Keyspaces é baseado no tamanho bruto (não compactado) de uma única réplica. Para monitorar o tamanho da tabela no Amazon Keyspaces, você pode usar a métricaBillableTableSizeInBytes, que é exibida para cada tabela no. AWS Management Console

   Para estimar o tamanho faturável da sua tabela do Amazon Keyspaces, você pode usar um desses dois métodos:

   • Use o tamanho médio da linha e multiplique pelo número ou linhas.

     Você pode estimar o tamanho da tabela Amazon Keyspaces multiplicando o tamanho médio da linha pelo número de linhas da tabela de origem do Cassandra. Use o script de amostra de tamanho de linha da seção anterior para capturar o tamanho médio da linha. Para capturar a contagem de linhas, você pode usar ferramentas como dsbulk count determinar o número total de linhas na tabela de origem.

   • Use o nodetool para coletar os metadados da tabela.

     Nodetoolé uma ferramenta administrativa fornecida na distribuição Apache Cassandra que fornece uma visão sobre o estado do processo do Cassandra e retorna os metadados da tabela. Você pode usar nodetool para amostrar metadados sobre o tamanho da tabela e, com isso, extrapolar o tamanho da tabela no Amazon Keyspaces. O comando a ser usado énodetool tablestats. Tablestats retorna o tamanho e a taxa de compactação da tabela. O tamanho da tabela é armazenado como tablelivespace o da tabela e você pode dividi-lo pelocompression ratio. Em seguida, multiplique esse valor de tamanho pelo número de nós. Por fim, divida pelo fator de replicação (normalmente três). Essa é a fórmula completa do cálculo que você pode usar para avaliar o tamanho da tabela.

     ((tablelivespace / compression ratio) * (total number of nodes))/ (replication factor)

     Vamos supor que seu cluster do Cassandra tenha 12 nós. A execução do nodetool tablestats comando retorna um tablelivespace de 200 GB e um compression ratio de 0,5. O keyspace tem um fator de replicação de três. É assim que o cálculo desse exemplo se parece.

     (200 GB / 0.5) * (12 nodes)/ (replication factor of 3)
                             = 4,800 GB / 3
                             = 1,600 GB is the table size estimate for Amazon Keyspaces

3. Capture o número de leituras e gravações

   Para determinar os requisitos de capacidade e escalabilidade para suas tabelas do Amazon Keyspaces, capture a taxa de solicitação de leitura e gravação de suas tabelas do Cassandra antes da migração.

   O Amazon Keyspaces não tem servidor e você paga somente pelo que usa. Em geral, o preço da taxa de transferência de leitura/gravação no Amazon Keyspaces é baseado no número e no tamanho das solicitações. Há dois modos de capacidade no Amazon Keyspaces: o modo de capacidade sob demanda e o modo de capacidade provisionada. O modo de capacidade sob demanda é uma opção de cobrança flexível capaz de atender a milhares de solicitações por segundo sem a necessidade de planejamento de capacidade. Essa opção oferece pay-per-request preços para solicitações de leitura e gravação, de forma que você pague somente pelo que usar. Se você selecionar o modo de capacidade de throughput provisionada, especifique o número de leituras e gravações por segundo necessárias para seu aplicativo. Isso o ajuda a gerenciar seu uso do Amazon Keyspaces para permanecer em ou abaixo de uma taxa de solicitação definida para otimizar o preço e manter a previsibilidade. O modo provisionado oferece escalabilidade automática para ajustar automaticamente sua taxa provisionada para aumentar ou diminuir a escala para melhorar a eficiência operacional. Para obter mais informações sobre o gerenciamento de recursos sem servidor, consulte. Gerenciamento de recursos de tecnologia sem servidor no Amazon Keyspaces (para Apache Cassandra)

   Como você provisiona a capacidade de taxa de transferência de leitura e gravação no Amazon Keyspaces separadamente, você precisa medir a taxa de solicitação de leituras e gravações em suas tabelas existentes de forma independente.

   Para reunir as métricas de utilização mais precisas do seu cluster Cassandra existente, capture a média de solicitações por segundo (RPS) para operações de leitura e gravação em nível de coordenador durante um longo período de tempo para uma tabela agregada em todos os nós em um único data center. Capturar a média em um RPS período de pelo menos várias semanas capturará picos e vales em seus padrões de tráfego, conforme mostrado no diagrama a seguir.

   

   Você tem duas opções para determinar a taxa de solicitações de leitura e gravação da sua tabela do Cassandra.

   • Use o monitoramento existente do Cassandra

     Você pode usar as métricas mostradas na tabela a seguir para observar as solicitações de leitura e gravação. Observe que os nomes das métricas podem mudar com base na ferramenta de monitoramento que você está usando.

     Dimensão	Métrica Cassandra JMX
     Escreve	org.apache.cassandra.metrics:type=ClientRequest, scope=Write,name=Latency#Count
     Lê	org.apache.cassandra.metrics:type=ClientRequest, scope=Read,name=Latency#Count

   • Usar a nodetool

     Use nodetool tablestats e nodetool info para capturar a média de operações de leitura e gravação da tabela. tablestatsretorna a contagem total de leituras e gravações a partir do momento em que o nó foi iniciado. nodetool infofornece o tempo de atividade de um nó em segundos. Para receber a média de leituras e gravações por segundo, divida a contagem de leitura e gravação pelo tempo de atividade do nó em segundos. Em seguida, para leituras, você divide pelo nível de consistência e, para gravações, divide pelo fator de replicação. Esses cálculos são expressos nas fórmulas a seguir.

     Fórmula para leituras médias por segundo:

     ((number of reads * number of nodes in cluster) / read consistency quorum (2)) / uptime

     Fórmula para a média de gravações por segundo:

     ((number of writes * number of nodes in cluster) / replication factor of 3) / uptime

     Vamos supor que temos um cluster de 12 nós que está ativo há 4 semanas. nodetool inforetorna 2.419.200 segundos de tempo de atividade e nodetool tablestats retorna 1 bilhão de gravações e 2 bilhões de leituras. Esse exemplo resultaria no cálculo a seguir.

     ((2 billion reads * 12 in cluster) / read consistency quorum (2)) / 2,419,200 seconds
     =  12 billion reads / 2,419,200 seconds
     =  4,960 read request per second
                             ((1 billion writes * 12 in cluster) / replication factor of 3) / 2,419,200 seconds
     =  4 billion writes / 2,419,200 seconds
     =  1,653 write request per second

4. Determine a utilização da capacidade da tabela

   Para estimar a utilização média da capacidade, comece com as taxas médias de solicitação e o tamanho médio da linha da tabela de origem do Cassandra.

   O Amazon Keyspaces usa unidades de capacidade de leitura (RCUs) e unidades de capacidade de gravação (WCUs) para medir a capacidade de transferência provisionada para leituras e gravações em tabelas. Para essa estimativa, usamos essas unidades para calcular as necessidades de capacidade de leitura e gravação da nova tabela do Amazon Keyspaces após a migração. Posteriormente neste tópico, discutiremos como a escolha entre o modo de capacidade provisionada e sob demanda afeta o faturamento. Mas, para a estimativa da utilização da capacidade, presumimos que a tabela esteja no modo provisionado.

   Um RCU representa uma solicitação de LOCAL_QUORUM leitura, ou duas solicitações de LOCAL_ONE leitura, para uma linha de até 4 KB de tamanho. Se você precisar ler uma linha maior que 4 KB, a operação de leitura usará maisRCUs. O número total RCUs necessário depende do tamanho da linha e se você deseja usar LOCAL_QUORUM ou LOCAL_ONE ler a consistência. Por exemplo, ler uma linha de 8 KB requer 2 RCUs usando consistência de LOCAL_QUORUM leitura e 1 RCU se você escolher consistência de LOCAL_ONE leitura.

   Um WCU representa uma gravação para uma linha de até 1 KB de tamanho. Todas as gravações estão usando LOCAL_QUORUM consistência e não há cobrança adicional pelo uso de transações leves (LWTs). Se você precisar gravar uma linha maior que 1 KB, a operação de gravação usa maisWCUs. O número total WCUs necessário depende do tamanho da linha. Por exemplo, se o tamanho da linha for de 2 KB, você precisará de 2 WCUs para realizar uma solicitação de gravação.

   A fórmula a seguir pode ser usada para estimar o necessário RCUs WCUs e. A capacidade de leitura em RCUs pode ser determinada multiplicando as leituras por segundo pelo número de linhas lidas por leitura multiplicado pelo tamanho médio da linha dividido por 4 KB e arredondado para o número inteiro mais próximo.

   A capacidade de gravação em WCUs pode ser determinada multiplicando o número de solicitações pelo tamanho médio da linha dividido por 1 KB e arredondado para o número inteiro mais próximo. Isso é expresso nas fórmulas a seguir.

   Read requests per second * ROUNDUP((Average Row Size)/4096 per unit) =  RCUs per second
                   
   Write requests per second * ROUNDUP(Average Row Size/1024 per unit) = WCUs per second

   Por exemplo, se você estiver realizando 4.960 solicitações de leitura com um tamanho de linha de 2,5 KB em sua tabela do Cassandra, precisará de 4.960 no Amazon Keyspaces. RCUs Se você está realizando atualmente 1.653 solicitações de gravação por segundo com um tamanho de linha de 2,5 KB em sua tabela do Cassandra, você precisa de 4.959 por WCUs segundo no Amazon Keyspaces. Esse exemplo é expresso nas fórmulas a seguir.

   4,960 read requests per second * ROUNDUP( 2.5KB /4KB bytes per unit)
   = 4,960 read requests per second * 1 RCU
   = 4,960 RCUs
                   
   1,653 write requests per second * ROUNDUP(2.5KB/1KB per unit) 
   = 1,653 requests per second * 3 WCUs
   = 4,959 WCUs

   eventual consistencyO uso permite que você economize até metade da capacidade de taxa de transferência em cada solicitação de leitura. Cada leitura eventualmente consistente pode consumir até 8 KB. Você pode calcular eventuais leituras consistentes multiplicando o cálculo anterior por 0,5, conforme mostrado na fórmula a seguir.

   4,960 read requests per second * ROUNDUP( 2.5KB /4KB per unit) * .5 
   = 2,480 read request per second * 1 RCU
   = 2,480 RCUs

5. Calcule a estimativa de preço mensal para o Amazon Keyspaces

   Para estimar o faturamento mensal da tabela com base na taxa de transferência da capacidade de leitura/gravação, você pode calcular os preços para o modo sob demanda e para o modo provisionado usando fórmulas diferentes e comparar as opções da sua tabela.

   Modo provisionado — o consumo de capacidade de leitura e gravação é cobrado em uma taxa horária com base nas unidades de capacidade por segundo. Primeiro, divida essa taxa por 0,7 para representar a meta de utilização padrão de escalonamento automático de 70%. Em seguida, multiplique por 30 dias corridos, 24 horas por dia e preços tarifários regionais. Esse cálculo está resumido nas fórmulas a seguir.

   (read capacity per second / .7) * 24 hours * 30 days * regional rate
                   (write capacity per second / .7) * 24 hours * 30 days * regional rate

   Modo sob demanda — a capacidade de leitura e gravação é cobrada de acordo com uma taxa por solicitação. Primeiro, multiplique a taxa de solicitações por 30 dias corridos e 24 horas por dia. Em seguida, divida por um milhão de unidades de solicitação. Por fim, multiplique pela taxa regional. Esse cálculo está resumido nas fórmulas a seguir.

   ((read capacity per second * 30 * 24 * 60 * 60) / 1 Million read request units) * regional rate
                   ((write capacity per second * 30 * 24 * 60 * 60) / 1 Million write request units) * regional rate

Escolher uma estratégia de migração

Você pode escolher entre as seguintes estratégias de migração ao migrar do Apache Cassandra para o Amazon Keyspaces:

• On-line — Essa é uma migração ao vivo usando gravações duplas para começar a gravar novos dados no Amazon Keyspaces e no cluster Cassandra simultaneamente. Esse tipo de migração é recomendado para aplicativos que exigem zero tempo de inatividade durante a migração e consistência de leitura após gravação. Para obter mais informações sobre como planejar e implementar uma estratégia de migração on-line, consulteMigração on-line para o Amazon Keyspaces: estratégias e melhores práticas.

• Off-line — Essa técnica de migração envolve a cópia de um conjunto de dados do Cassandra para o Amazon Keyspaces durante uma janela de inatividade. A migração off-line pode simplificar o processo de migração, pois não exige alterações em seu aplicativo ou resolução de conflitos entre dados históricos e novas gravações. Para obter mais informações sobre como planejar uma migração off-line, consulteProcesso de migração offline: Apache Cassandra para Amazon Keyspaces.

• Híbrida — Essa técnica de migração permite que as alterações sejam replicadas para o Amazon Keyspaces quase em tempo real, mas sem consistência de leitura após gravação.

Depois de analisar as técnicas de migração e as melhores práticas discutidas neste tópico, você pode colocar as opções disponíveis em uma árvore decisória para criar uma estratégia de migração com base em seus requisitos e recursos disponíveis.