Migração on-line da MuleSoft no DynamoDB

Migração on-line da MuleSoft no DynamoDB

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br


A migração do esquema de banco de dados é frequentemente um conceito intimidador para muitos engenheiros de software. Em um mundo ideal, os desenvolvedores começam com o esquema de banco de dados perfeito que pode ser dimensionado para lidar com milhões de solicitações ao seu serviço. Mas pode haver momentos em que você escolhe o armazenamento de dados errado ou um modelo de dados que precisa ser alterado após o produto estar nas mãos dos clientes.

Nossa equipe de engenharia da MuleSoft enfrentou esse desafio no ano passado. Uma das tabelas do DynamoDB usadas por um serviço crítico em produção excedeu a capacidade alocada, apesar do uso ser muito menor do que o alocado. No design inicial desta tabela, escolhemos um esquema parecido com este:

A chave de partição ‘composite_user_id’ era uma chave composta criada a partir de diferentes campos, específicos para um cliente específico.

Começamos a ver exceções de limitação em nosso serviço e os clientes começaram a relatar problemas. Mergulhando nos detalhes, descobrimos que a mesa tinha uma partição quente.

Para dar mais contexto às partições mais importantes, vamos falar um pouco sobre as partes internas desse banco de dados. O DynamoDB suporta dois tipos de chaves primárias – chave de partição (uma chave composta da chave de partição) e chave de classificação. Uma chave de partição serve como entrada para um algoritmo de hash que determina para qual “partição” o registro vai, onde partição se refere ao nó de armazenamento físico interno ao DynamoDB. Esse mecanismo de particionamento baseado em hash existe para escalar incrementalmente e dividir os dados no conjunto de nós especificado. Assim, todos os itens com a mesma chave de partição são armazenados juntos, classificados pela chave de classificação.

Imagine um aplicativo que use o DynamoDB para persistir algum tipo de dado do usuário. A chave de partição é um valor exclusivo para um usuário. Para simplificar, digamos que o user_id seja selecionado como chave de partição e o hash da chave de partição do usuário_1 esteja no intervalo da Partição 1 e o da chave de partição do usuário_2 seja mapeado para a Partição 2. Se o usuário_1 for um usuário mais ativo que o usuário_2 , A Partição 1 é acessada com mais freqüência que a Partição 2. Para o DynamoDB interno, o tráfego em uma chave de partição específica não deve exceder 3.000 unidades de capacidade de leitura e 1.000 unidades de capacidade de gravação, independentemente da capacidade geral provisionada na tabela. Portanto, com um usuário ativo e um esquema mal projetado para sua tabela, você tem uma “partição ativa” em mãos, mas o DynamoDB é otimizado para distribuição uniforme de itens entre partições. Esta postagem no blog da Amazon é uma leitura muito recomendada para entender a importância de selecionar a chave de partição correta e o problema das teclas de atalho.

Leia Também  Melhorando o UX: as plataformas corporativas de comércio eletrônico estão ganhando a corrida?

Esperávamos que nosso serviço fosse dimensionado linearmente com a capacidade provisionada no DynamoDB. Porém, as teclas de atalho em uma das partições das tabelas dificultaram nossa visão de dimensionar nosso serviço para atender à maior demanda dos clientes. Para resolver as teclas de atalho, precisamos alterar a composição da chave primária desta tabela. Isso nos deu a tarefa de criar uma nova tabela com uma chave primária exclusiva e migrar todos os registros para essa nova tabela.

Solução

Uma maneira simples de resolver esse problema seria limitar as chamadas à API, mas para manter nosso serviço verdadeiramente escalável, decidimos usar o sharding de gravação. Precisávamos de uma estratégia aleatória para as chaves da partição, para obter uma distribuição mais uniforme dos itens nas partições do DynamoDB. Adicionamos um sufixo à chave da partição, que era um número gerado aleatoriamente a partir de um intervalo predeterminado. Isso garantiu que os itens do mesmo usuário fossem divididos uniformemente nos nós internos fornecidos no DynamoDB. Este é o novo esquema que desejamos para a tabela:

Um desafio dessa solução foi que exigia alterações significativas no nível do aplicativo. Além disso, o intervalo de sufixos pode afetar o desempenho das consultas, caso seja necessário verificar a tabela inteira. Existem dois critérios que influenciaram nossa decisão sobre o intervalo de sufixo – o destino de escalabilidade que tínhamos em nosso back-end que afetava o número de partições Dynamodb e o desempenho da consulta afetado pelo intervalo de sufixo. Após alguns testes, decidimos por uma série de sufixos que nos proporcionavam uma boa troca entre eficiência de varredura e sharding uniforme.

A plataforma MuleSoft suporta bilhões de solicitações de API diariamente e queríamos garantir que essa correção no nível do banco de dados não afetasse os SLAs de serviço. Um dos requisitos para esse processo era que o serviço não tivesse nenhum tempo de inatividade. Para manter a alta disponibilidade e a consistência do nosso serviço, decidimos fazer uma migração online – portanto, a migração era realizada enquanto o tráfego ainda existia no aplicativo.

Leia Também  Mapeamento externo com objetos personalizados do Salesforce
cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br

Etapas na migração

Etapa 0: pré-migração

Antes do início da migração, o aplicativo direcionava todas as leituras e gravações para a tabela antiga.

Etapa 1: gravações de garfo

A primeira etapa da migração foi forçar gravações na nova tabela. Os registros permaneceram os mesmos, exceto pela chave de partição na nova tabela anexada a um sufixo aleatório. Todas as novas gravações não foram bloqueadas e não afetaram a disponibilidade e a taxa de transferência existentes do serviço.

Etapa 2: adicionar medidas de observabilidade

Depois que as gravações foram bifurcadas, tivemos que garantir que a integridade dos dados fosse preservada quando eles foram bifurcados na nova tabela. Para isso, usamos as solicitações de leitura para o aplicativo para executar uma validação da integridade dos dados. Um módulo de verificação de integridade foi incorporado à camada do aplicativo, que comparou os itens lidos em tabelas antigas e novas e registrou quaisquer discrepâncias. Essa fase da migração foi crítica, pois poderíamos fazer várias iterações para evitar dados malformados com a combinação de gravações bifurcadas e verificações de integridade.

As solicitações com falha para novas falhas de tabela e verificação de integridade foram monitoradas de perto e corrigidas durante esta etapa da migração. Este modo foi ativado por 30 dias porque os dados na tabela que desejávamos migrar tinham um TTL de 30 dias. Isso simplificou significativamente nossa declaração do problema. Freqüentemente, a migração online deve ser apoiada por uma migração offline, quando há registros a serem migrados que não são acessados ​​com frequência. A equipe de engenharia do Tinder descreve uma iniciativa que eles fizeram aqui na AWS Reinvent.

Etapa 3: alternar caminhos de leitura

Mantendo os garfos de gravação e a validação on-line, trocamos os caminhos de leitura para a nova tabela. Uma vez que estávamos confiantes nos novos caminhos de dados e nenhuma regressão foi relatada, nos livramos das tabelas antigas e da camada de verificação de integridade.

Pós-migração

Observabilidade

Observabilidade são as diferentes maneiras de monitorar seu sistema. Nossos serviços já foram monitorados no nível da máquina e no nível do aplicativo. A observância no nível da máquina incluiu o monitoramento de métricas do sistema, como uso da CPU, métricas de rede e utilização de armazenamento. No nível do aplicativo, monitoramos a taxa de erros, os encadeamentos disponíveis no pool de encadeamentos, o uso de memória de pilha e assim por diante.

Leia Também  Comentários sobre a documentação do MuleSoft | MuleSoft Blog

Medidas de observabilidade mais granulares foram necessárias durante a fase de migração. Ativamos os rastreamentos de transações no nível do banco de dados para monitorar o desempenho dos caminhos de dados para novas tabelas. Também era importante que pudéssemos ver como as verificações de integridade estavam progredindo ao longo do tempo, quantas transações do DynamoDB falharam, quantas solicitações de leitura / gravação foram para a nova tabela etc. Porque não pudemos usar diretamente as ferramentas DynamoDB ou AWS para ver quão bem nossa migração estava progredindo, contamos bastante com o recurso de instrumentação personalizada na New Relic. Utilizamos os painéis do New Relic Insights para fornecer visualização de como a migração estava progredindo ao longo do tempo.

O gráfico acima do New Relic Insights mostra como o número de erros, que é o número de diferenças entre tabelas antigas e novas, caiu para zero ao longo do tempo. No início da migração, existiam menos chaves na nova tabela, o que resultou em muitas falhas na verificação de integridade. À medida que mais solicitações de gravação chegavam às tabelas, os dados na nova tabela se tornavam mais semelhantes à tabela antiga, reduzindo assim os erros de verificação de integridade.

Conclusão

Com um processo de várias etapas que durou quatro a cinco meses, o projeto foi encerrado com êxito – alteramos o esquema em uma tabela, tornamos o serviço mais escalável, causamos zero problemas de clientes durante o processo! ENORME SUCESSO!!

Algumas sugestões deste projeto:

  • O padrão de acesso do DynamoDB deve decidir seu padrão de design. Encontrar a chave de partição composta correta desempenha um papel importante na forma como seu serviço pode ser dimensionado. Modificar um esquema existente será uma operação cara.
  • Observabilidade é um salvador. Investir tempo em alguns painéis e alertas úteis remove muitas validações manuais repetidas de seus ombros.
  • O ferramental é uma consideração importante do design quando você escolhe seu armazenamento de dados. Operações como renomear uma tabela ou alterar o esquema não são tão diretas no DynamoDB quanto nos bancos de dados relacionais.

Para mais conteúdo de engenharia da MuleSoft, consulte a seção “Engenharia” do nosso blog.


cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br
Luiz Presso
Luiz Presso