Estando no negócio de moving data, a Safe Software está sempre trabalhando para suportar tecnologia de banco de dados de ponta. Esse foco, naturalmente, levou-nos a tomarmos conhecimento do Amazon Aurora.

Além de alavancar o potencial da AWS e do Aurora para nossos clientes, nós também avaliamos novas tecnologias a partir da perspectiva de melhorar os nossos processos internos. Quando o Aurora foi lançado em beta, nós imediatamente pensamos em migrar dos nossos próprios sistemas para ele. Essa decisão provou valer a pena. A mudança para o Aurora aumentou a nossa produtividade, proporcionando uma redução anual de custos de 40% com sistemas.

Agora que completamos a migração, gostaríamos de compartilhar algumas dicas e insights para aqueles que consideram fazer o mesmo. Eu bem que gostaria de incluir os detalhes sobre a migração, mas não há muito o que dizer, uma vez que só houve o clique de um botão. Em vez disso, vou compartilhar o que tentamos em primeiro lugar, como nós preparamos e otimizamos nossos sistemas ainda mais, já que eles estavam operando no Aurora.

Por que precisávamos da nuvem?

Para garantir a alta qualidade da nossa tecnologia de transformação de dados espaciais, FME, nós executamos um conjunto severo de testes automatizados. A plataforma suporta mais de 365 formatos de dados e transformações ilimitadas, tornando o teste diário automático exigente: 15.000 testes x 4 sistemas operacionais x 3 produtos, sendo executados 24/7.

O problema: nós não poderíamos manter o provisionamento do hardware para manter o sistema feliz – não com a nossa expectativa de um tempo de resposta de 1 segundo.

Nosso banco de dados de produção interna é executado em um sistema de tráfego elevado, com mais de 140 tabelas contendo cerca de 100 milhões de linhas de dados. É o repositório operacional principal para os nossos sistemas de construção e teste, bem como a nossa intranet interna e estrutura de informação, apoiando nossas fazendas de servidores acima de 150 máquinas. Mais de 100 usuários contam com esse sistema.

O que tentamos antes do Aurora

Nós inicialmente tentamos mover tudo para o MySQL no RDS, mas descobrimos que precisávamos executar uma réplica de leitura em uma instância de tamanho considerável para gerenciar a carga. Mesmo assim, fomos nos agrupando contra o teto de produtividade para o número de conexões que poderíamos lidar com a maioria das consultas. Temos lutado para cumprir os tempos de resposta necessários. Essa solução também tinha dobrado imediatamente nossos custos.

Nós tínhamos gastado tanto tempo nos aperfeiçoando no MySQL que a ideia de ter de reaprender tudo isso em um novo sistema foi doloroso. Ter algo que você tratar como uma aplicação é muito melhor.

Preparações à prova de falhas e migração

Ouvimos que o Aurora espelha a experiência do MySQL, então nós achamos que valeria a pena tentar. Para garantir que não tínhamos nada a perder, decidimos manter o sistema de produção em execução na sua forma atual, enquanto testávamos o Aurora.

Um dos benefícios da mudança para um sistema de maior desempenho é que você tem uma boa oportunidade para reavaliar um sistema que remonta anos. Durante essa migração, fizemos algumas tarefas domésticas. Nós olhamos índices, estruturas de tabela e muitos outros aspectos relacionais do banco de dados. Fomos capazes de combinar vários esquemas em apenas dois para uma lógica mais simples.

Mover, de fato, para o Aurora era trivial. Dentro do painel de controle da Amazon, escolhemos migrar – clicando em um botão. Aconteceu em segundo plano e terminamos com uma cópia no Aurora do que tínhamos executado no MySQL! Era tão simples!

Gerir a transição é uma grande questão em termos de programação, para se certificar de que não estamos afetando as operações e enquanto isso capturar uma imagem do estado atual dos dados. Estávamos preocupados com que as coisas pudessem ficar fora de sincronia, que até o momento em que a migração terminasse as datas de leitura pudessem estar desatualizadas. Sabíamos que demoraria algumas horas para migrar o sistema de produção que ainda estava em operação e, durante esse tempo, os dados poderiam mudar.

Escolhemos fazer a migração durante a noite no sistema ao vivo, enquanto ele ainda estava rodando. Seguimos com o nosso próprio produto FME para capturar as mudanças nas tabelas voláteis durante a migração (cerca de 2-3% de nossos dados), e portá-los.

Nossa equipe de construção e liberação foi capaz, ela própria, de gerir a migração, e só envolveu o departamento de TI para configurar a identidade e o gerenciamento de acesso e, em seguida, mudar o DNS na nossa rede, uma vez que tínhamos verificado que tudo estava indo bem.

Nós tínhamos verificado alguns exemplos como garantia, mas era uma espécie de um salto no escuro, porque fomos os primeiros a adotar. Mas sabíamos que poderíamos simplesmente reverter para o antigo sistema, se necessário.

Otimizar a experiência pós-migração

Nós testamos exaustivamente todos os nossos processos depois. Houve alguma dor de cabeça após os primeiros dias de monitoramento; tivemos manchas de carga da CPU pesada e lentidão no Aurora durante algumas operações que tinham executado normalmente no MySQL.

Nós rastreamos essas operações em um conjunto de consultas ineficientes usando SELECTs profundamente aninhadas que não eram facilmente modificáveis. Resolvemos essas questões com algumas alterações de esquema simples, e conservamos algumas das relações mais complexas usando o nosso próprio produto, o FME. Conclusão: o projeto do esquema ainda é importante.

Nenhuma outra questão ocorreu durante ou depois, e ajustar essas consultas e índices acabou por ser bastante benéfico. Agora temos operações em escala empresarial com as interfaces familiares a que estamos habituados.

Para quase todas as operações, o Aurora se provou mais rápido, e isso nos dá mais escalabilidade. Estamos executando uma configuração relativamente modesta agora, sabendo que podemos expandir, e isso está nos economizando cerca de US$ 8.000 por ano (60% mais barato). Na verdade, poderíamos dobrar nosso desempenho usando o Aurora e ainda seria menos do que pagamos no ano passado. Economizamos outros US$ 2.000, reservando a instância para as operações anuais.

A gestão da operação é uma coisa muito importante, por isso é um alívio não se preocupar com backups ou falhas dos bancos de dados. A base de dados gerida nos isenta de um monte de dores de cabeça. Para atingir esse desempenho, seria necessário um enorme investimento em hardware e pessoal.

Com o Aurora, podemos criar nosso produto FME ainda melhor, mais rápido e teremos os resultados do teste mais rapidamente, o que, em última análise, significa que podemos fornecer um produto de maior qualidade.