Migrando do Redshift DC2 para o RA3
O volume de dados sendo gerados e demandados no processo de tomada de decisão é cada vez maior, e com a Dafiti não é diferente. A necessidade crescente de espaço de armazenamento, para manter os dados das nossas mais de 90 fontes e as funcionalidade disponíveis nesta nova família de máquinas do Redshift, nos levou a migrar do DC2 para o RA3. Neste artigo, compartilhamos como foi o processo de migração e quais foram nossas impressões. Boa leitura!
Uma breve história do Redshift na Dafiti
O Redshift é o serviço de data warehouse totalmente gerenciado que é adotado pela Dafiti desde 2017 e, nestes anos de uso, tivemos a oportunidade de acompanhar muitas inovações e passamos por três famílias de máquinas diferentes. Iniciamos com 115 nodes dc2.large e com o lançamento do Redshift Spectrum e a migração dos nossos dados frios para o data lake, melhoramos consideravelmente nossa arquitetura e migramos para 4 nodes dc2.8xlarge; o RA3 introduziu muitas funcionalidades, permitiu escalar e pagar por computação e armazenamento de forma independente, o que resolve um dos maiores problemas que tínhamos com o DC2, no qual a capacidade de processamento atendia nossas necessidades, mas sofríamos com o gerenciamento do pouco espaço de armazenamento disponível e foi isso que nos trouxe até o momento atual, onde temos 8 nodes ra3.4xlarge no ambiente de produção e um cluster single node ra3.xlplus para desenvolvimento.
Nosso cenário de uso
O Redshift é amplamente adotado na Dafiti e suporta diariamente ≃100.000 queries entre as executadas por processos de ETL/ELT e queries ad-hoc realizadas por um dos nossos mais de 400 usuários distribuídos em três países. Falando em processos de ETL/ELT, são executados diariamente ≃2.500 processos únicos para recuperar dados de uma das ≃ 90 fontes de dados que temos atualmente e resultam na atualização de ≃ 2000 tabelas no data warehouse e ≃3000 tabelas externas em formato parquet, acessadas do data lake no S3 por meio do Redshift Spectrum.
O que motivou a migração para RA3?
Dado o nosso cenário, onde temos muitas fontes de dados e muito dado novo sendo gerado a cada instante, nos deparamos com um problema no qual os 10 TB que tínhamos disponíveis no nosso cluster ficou insuficiente para nossas necessidades. Embora a maior parte dos nossos dados esteja atualmente no data lake, se fez necessário mais espaço de armazenamento no data warehouse. No entanto, o problema era apenas armazenamento e não performance e justamente isso é resolvido pelo RA3, que trata computação e armazenamento de forma independente.
Como planejamos a migração?
Nosso primeiro passo para a migração foi entender como o novo cluster deveria ser dimensionado, e para isso a AWS fornece uma tabela de recomendação que pode ser consultada neste link: https://docs.aws.amazon.com/pt_br/redshift/latest/mgmt/rs-upgrading-to-ra3.html
Dada a configuração do nosso cluster, composto por 4 nodes dc2.8xlarge, a recomendação foi a seguinte:
Neste ponto, uma preocupação que tínhamos, era em relação a redução da quantidade de vCPU e memória. Enquanto no DC2 nossos 4 nodes nos garantiam um total de 128 vCPUs e 976 GiB; no RA3, mesmo com 8 nodes, estes valores foram reduzidos para 96 vCPUs e 768 GiB. Porém, isso não impactou de forma negativa nossa experiência.
Sobre a reserva de nodes do Redshift
A reserva de nodes do Redshift possibilita o pagamento de um valor reduzido em relação aos nodes on-demand, que são aqueles sem qualquer tipo de reserva. Na Dafiti, dado que o Redshift é uma ferramenta adotada há anos, optamos por manter os nossos nodes reservados em função da economia que isso proporciona. No entando, os nodes são reservados por tipo, ou seja, um node dc2.8xlarge não é automaticamente convertido para um ra3.4xlarge quando é realizada uma migração.
No nosso caso, decidimos realizar a migração para o RA3 faltando ainda alguns meses para o término da reserva dos nossos nodes; considerando que a reserva é um compromisso de médio/longo prazo com AWS, solicitamos a análise da possbilidade de cancelamento da reserva dos nossos nodes DC2 e contratação de nova reserva para nodes RA3 por meio de um case no Support Center, da seguinte forma:
No Support Center, clique em Create Case e selecione a opção Account and billing. Serão exibidas três caixas de seleção, na primeira, Service, selecione a opção General Info and Getting Started; na segunda, Category, selecione Reserved Instances e, por fim, informe a severidade da sua solicitação dentre uma das opções disponíveis em Severity.
Clique no botão Next step: Additional information e informe o assunto no campo Subject e a descrição detalhada da sua solicitação no campo Description, clique Contact us para finalizar a criação do case.
É muito importante acompanhar as interações no case para que esse processo de cancelamento e contratação de novas reservas aconteçam no tempo correto, de acordo com o calendário de migração estabelecido. Fique atento às condições para a realização do processo; isso evita possíveis dores de cabeça, como pagamento de duas reservas.
Caso fique com qualquer dúvida, entre em contato com o seu TAM (Technical Account Manager), esse suporte foi fundamental para esclarecer nossas dúvidas.
E como migramos?
A AWS oferece uma ferramenta interessante para validar se a configuração escolhida para o Redshift é a ideial para o seu workload, antes de efetivar a migração do ambiente de produção, esta ferramenta é o Redshift Test Drive.
Na Dafiti, dadas as particularidades do nosso workload, que nos dá alguma flexibilidade para alterações em janelas específicas sem afetar o negócio, não foi necessária a utilização do Redshift Test Drive e realizamos a migração da seguinte forma:
- Criamos um novo cluster com 8 nodes ra3.4xlarge a partir do snapshot do nosso cluster 4 nodes dc2.8xlarge. Este processo demorou cerca de 10 minutos para criar o novo cluster com 8.75 TB de dados.
- Desligamos o Hanger, nosso orquestrador de ETL/ELT, para impedir que nossos dados fossem atualizados durante o período de migração.
- Alteramos o DNS apontando para o novo cluster de forma transparente para os nossos usuários, neste ponto apenas as queries ad-hoc e as realizadas pelo QuickSight chegavam ao novo cluster.
- Finalizada a etapa de validação de queries de leitura e, satisfeitos com a performance, religamos nosso orquestrador para que as queries de transformação de dados fossem executadas no novo cluster.
- Removemos o cluster DC2 e com isso concluímos a migração.
Durante a migração, definimos alguns checkpoints nos quais seria realizado o rollback caso algo indesejado acontecesse. O primeiro checkpoint foi no passo 3, onde a redução de performance nas consultas dos usuários levaria a um rollback. O segundo, no passo 4, caso os processos de ETL/ELT apresentassem erros ou houvesse perda de performance em comparação com as métricas colhidas dos processos executados no DC2. Em ambos os casos, o rollback se daria simplesmente alterando o DNS para apontar para o DC2 novamente, uma vez que ainda seria possível reconstruir todos os processos dentro da janela de manutenção definida. Simples, não?
Conclusão
O RA3 introduziu muitas funcionalidades, permitiu escalar, pagar por computação e armazenamento de forma independente e isso mudou o jogo na Dafiti. Antes, tínhamos um cluster que performava dentro do esperado, mas nos limitava em termos de armazenamento, sendo necessário realizar manutenções diárias para manter o controle do espaço em disco.
A redução que tivemos de vCPU e memória, comparado com o que tínhamos no DC2, embora tenha sido uma grande preocupação no início, na prática não foi percebida. Tivemos ganho de performance e percebemos redução significativa no tempo de entrega dos nossos principais processos que ficou ainda mais acentuada alguns dias após a migração, provavelmente pela definição de cache, estatísticas, aplicação de recomendações (SVV_ALTER_TABLE_RECOMMENDATIONS) e por o Redshift ter aprendido o que era mais demandado no nosso workload. Em relação ao espaço de armazenamento, demos um salto de 10 TB para 1 PB, o que solucionou nosso principal problema.
O data sharing foi utilizado desde o momento da migração, para compartilhamento de dados entre o ambiente de produção e desenvolvimento, mas a evolução natural é habilitação do data mesh na Dafiti por meio deste recurso. O único problema que tivemos foi a necessidade de ativar o case sensitive, que é um pré requisito para o data sharing, e que nos forçou a alterar alguns processos que quebraram. Mas isso não foi nada comparado com os benefícios que estamos tendo com a migração para o RA3.
Me ajudaram a contar esta história a Flavia Lima, Fernando Saga e o Helio Leal. Quer saber mais sobre o que estamos fazendo na área de dados aqui na Dafiti?
Como tornamos o Amazon QuickSight a principal ferramenta de DataViz na Dafiti
Dafiti, habilitando uma Empresa Data Driven na AWS
Caso de sucesso: Dafiti reduz custos em 70% e otimiza tomadas de decisões com dados na nuvem da AWS
