Como usar o Amazon Aurora para aprimorar em 3 vezes melhorias de latência para o usuário final

Por Dana Ford, Diretora de Engenharia Sênior na InfoScout
Doug Flora, Gerente Sênior de Marketing de Produto do Amazon Relational Database Service (RDS) na AWS

Nascido na AWS

A InfoScout nasceu na AWS, acompanhando a caminhada desde a sua origem, em 2011. Tudo começou com uma única instância do Amazon EC2 para coletar recibos carregados por amigos e familiares. Sete anos depois, gerenciamos atualmente mais de 150 instâncias da AWS para oferecer suporte aos nossos aplicativos móveis, pipelines de dados, modelos de machine learning e à nossa plataforma de análise SaaS. Esta postagem fornece algumas informações detalhadas sobre nossos crescentes desafios da migração de infraestrutura e banco de dados.

O nosso negócio é simples Temos um portfólio de aplicativos móveis que permite aos consumidores diários capturarem fotos dos seus recibos de compras e enviá-las para a nuvem. Analisamos esses dados e, em seguida, fornecemos informações detalhadas a marcas, varejistas, agências e empresas de bens de consumo embalados (CPG) sobre os seus compradores. Tal abordagem centrada no consumidor para coletar dados em grande escala permite que as marcas finalmente respondam aos “porquês” de tantas perguntas. “Por que as vendas caíram 5% na minha categoria?” “Quais as mudanças dos consumidores da categoria estão direcionando as vendas para a minha marca?” “Quais segmentos de consumidores estão mudando as suas despesas para on-line?” Atualmente, captamos 1 em cada 500 compras nos EUA, o que resulta em um fluxo de 300.000 imagens de recibo por dia.

Para alimentar toda a nossa infraestrutura e aplicações na AWS, usamos muito o Amazon EC2, Amazon RDS, Amazon S3, Amazon VPC, e Route 53. Começamos com uma única VPC no norte da Califórnia em 2011, mas em 2016 expandimos a nossa presença na AWS para acompanhar nosso crescente pipeline de dados e as demandas dos clientes. Estávamos interessados no Amazon Aurora e no AWS Lambda, mas não estavam disponíveis em nossa região, então, a primeira etapa foi migrar a nossa infraestrutura para uma localização mais nova em Oregon.

Em novembro e dezembro de 2016, migramos mais de 100 servidores, incluindo diversos bancos de dados. Havia começado a fase 2 do nosso crescimento na AWS.

Dores do crescimento

Como muitas start-ups, enfrentamos desafios de escalabilidade, e nossa prioridade foi melhorar o throughput e o desempenho do banco de dados. Mesmo antes da mudança para Oregon, começávamos a enfrentar problemas de desempenho de banco de dados, à medida que os nossos negócios cresciam.

O banco de dados transacional principal da InfoScout foi configurado em uma instância do Amazon RDS for MySQL. Ele servia como o nosso banco de dados de clientes ao armazenar todos os dados de usuários móveis, de pesquisas, e de recibos. Nossa configuração incluía um único banco de dados primário e duas réplicas de leitura, usadas para alta disponibilidade e ETL. Escalávamos a instância verticalmente à medida que o banco de dados crescia; por fim, fizemos o upgrade para o maior tamanho de instância suportado pelo Amazon RDS for MySQL à época. Tal abordagem funcionou no início, mas como nosso banco de dados cresceu para vários TBs, vimos dois grandes problemas surgirem durante períodos de tráfego intenso.

Primeiro, o desempenho geral no tempo de execução de consultas era sofrível. Em momentos de pico, recebíamos muitas solicitações concorrentes e nossa fila de requisições do Amazon RDS crescia consideravelmente. Na métrica queue depth víamos valores como 50, 100 ou mesmo 125, o que indicava que tínhamos contenção de I/O. Isso causava lentidão nas operações de leitura, time out de páginas, e falhas em jobs. Segundo, o armazenamento estava tornando-se um problema. O Amazon RDS for MySQL possuía um limite de tamanho máximo de armazenamento de 6 TB à ocasião (atualmente suporta até 16 TB) e o nosso banco de dados já tinha 5 TB.

Por causa desses problemas de desempenho e de armazenamento, gastávamos tempo e recursos preciosos para cuidar do MySQL. Sempre que havia problemas durante períodos de tráfego intenso, tínhamos de desligar outros serviços que não fossem essenciais. Isso aliviava a carga sobre o banco de dados. Alertas constantes do Amazon CloudWatch afetavam nossas outras responsabilidades.

Avaliamos várias possibilidades para gerenciar o problema: fragmentação do nosso cluster de banco de dados, dividi-lo em microsserviços, arquivamento dos dados mais antigos, ou até a migração de volta para o MySQL no Amazon EC2. Tais opções, no entanto, pareciam muito complexas e insustentáveis, dada a nossa taxa de crescimento. Depois de algumas conversas com nossos gerentes de conta e arquitetos de soluções da AWS, começamos a investigar o Aurora com compatibilidade com o MySQL como um novo destino para o nosso banco de dados primário.

No início, estávamos apreensivos em relação ao Aurora. Era relativamente novo, a sua natureza proprietária não estava alinhada com os nossos outros componentes arquiteturais e tínhamos dúvidas de que ele realmente pudesse ser plug-and-play com um banco de dados MySQL. Fomos atraídos, contudo, pela escalabilidade e pelos conjuntos de recursos. Custos mais baixos, desempenho mais rápido, baixo atraso na replicação, e o seu armazenamento máximo de 64 TB significavam que não havia necessidade de fragmentar o nosso banco de dados tão cedo.

Migração para o Aurora

Antes de dar o salto do nosso banco de dados de produção para o Aurora, tivemos de resolver algumas verificações de compatibilidade adicionais, além de testar e preparar um ambiente de stage.

Das aproximadamente 250 tabelas em nosso back-end móvel, a maioria usava o mecanismo de armazenamento MySQL InnoDB. Mais ou menos uma dúzia estava no mecanismo de armazenamento MyISAM, mais antigo (para oferecer suporte a consultas legadas do tipo FULLTEXT). O Aurora é compatível com o InnoDB, mas não com o MyISAM, o que significava que tínhamos de migrar as nossas tabelas MyISAM para o InnoDB imediatamente – uma tarefa simples. Depois disso feito, migramos todo o ambiente de stage para o Aurora e descontinuamos nosso ambiente de stage do Amazon RDS for MySQL.

Nas 2 a 3 semanas seguintes, testamos, ajustamos, e monitoramos o desempenho do ambiente de stage no Aurora, e as coisas iam bem. Um ambiente de stage para testes internos obviamente não recebe o tráfego que um ambiente de produção recebe. Porém, do ponto de vista lógico e do SQL, tudo estava funcionando de ponta a ponta. As chamadas para o cluster do Aurora estavam funcionando conforme o esperado e os dados fluíam sem problemas. Agora tínhamos alta confiança no Aurora com a compatibilidade do MySQL.

Depois que o ambiente de stage recebeu luz verde durante o verão de 2017, fizemos a lista de verificação para a migração. Era mais ou menos assim:

• Criar duas réplicas de leitura do Aurora a partir do nosso Amazon RDS for MySQL Master DB
• Esperar pelo sincronismo das réplicas do Aurora, o que aconteceu rapidamente
• Desativar todo o tráfego dos consumidores e a nossa fila assíncrona do Python Celery
• Mudar a senha mestra do MySQL para confirmar que nenhum processo “rebelde” estivesse acessando o banco de dados MySQL
• Validar para que as tabelas do Aurora estavam em sincronia e que não havia operações de escrita na instância MySQL primária
• Promover uma das réplicas Aurora para nova instância primária
• Atualizar o registro DNS do Route 53 para apontar para o endpoint do banco de dados para o novo Aurora DB
• Reiniciar a aplicação, a fila do Celery, e outros serviços

Tínhamos muitos painéis do CloudWatch monitorando as consultas, o tempo de leitura e o tempo de escrita, o throughput, e o atraso de replicação. O cluster do Aurora começou a “esquentar” e todas as métricas do CloudWatch pareciam boas. A migração parecia um sucesso, embora estivesse no meio da noite e sem tráfego. Reconhecíamos que havia ainda uma chance de recebermos um alerta, depois que desconectássemos a migração. Quando fizemos a verificação na manhã seguinte, porém, tudo corria bem – podíamos perceber imediatamente que o Aurora tinha um alto desempenho.

Resultados

Abaixo, estão gráficos que destacam o tempo de execução e a latência antes e depois da transição – você pode ver a melhoria imediata no desempenho.

Somos grandes fãs do CloudWatch e temos cerca de duas dúzias de métricas definidas para monitorar o desempenho de nossa grande farm assíncrona do Celery. Depois da migração para o Aurora, notamos uma redução de 10x no tempo de uma etapa crítica de nossa máquina de estado do motor de recibos. Essa tarefa é responsável pela duplicação de imagens e validação de envios de recibos recentes. O gráfico a seguir mostra o tempo de execução de um trabalho assíncrono crítico no pipeline de recibos. Você pode ver uma redução de 10 vezes no tempo de execução de 4 segundos para 400 ms.

Além das ferramentas de monitoramento da AWS, usamos serviços de nível de produção como o New Relic para monitoramento de desempenho profundo. Extraímos esses relatórios e vimos uma melhoria de 3 vezes nos tempos de resposta logo de cara! Quando estávamos no Amazon RDS for MySQL, as chamadas de rede padrão feitas pelos clientes móveis ao nosso back-end levavam 600 ms para serem concluídas, quase todo tempo era gasto na consulta do MySQL. Depois da implantação no Aurora, essa latência foi reduzida para menos de 200 ms. Depois de ver essas métricas iniciais, nossa equipe de infraestrutura estava confiante de que havíamos encontrado um novo lar para o nosso cluster de dados transacionais de 6 TB. O gráfico a seguir mostra a latência antes e depois da migração. Você pode ver uma melhoria imediata no desempenho.

Um banco de dados para crescer

Quando avaliávamos nossas opções para migrar ou reconstruir nosso ambiente de banco de dados, consideramos vários fatores. Em última instância, não queríamos seguir o caminho de fragmentar ou construir nosso próprio cluster por causa das despesas operacionais e do gerenciamento de infraestrutura envolvidos. Estávamos preocupados de que o tempo gasto na administração e operações do banco de dados significava que não poderíamos trabalhar no desenvolvimento de recursos, engenharia, e ajudar a empresa a crescer. Isso acabaria prejudicando a velocidade dos nossos negócios.

Apesar de o Aurora parecer a opção mais sensata, a decisão de migrar não foi tomada no vazio. Tivemos uma conversa coletiva em equipe em relação a se a migração para o Aurora era a que fazia mais sentido. O MySQL é estável e robusto e existe há décadas – ainda acreditamos na tecnologia. Tínhamos, contudo, um grande banco de dados com mais de 20.000 consultas por minuto, e o MySQL não conseguia absorver a tensão.

Se você estiver pensando em uma migração por qualquer motivo que seja, não procure apenas a tecnologia mais avançada. Avalie e considere todas as suas opções, como uma equipe. Realize testes de estresse no ambiente de produção existente e documente cuidadosamente os problemas. E teste, teste, e teste no seu novo ambiente de stage mediante uma lista de verificação de requisitos. Tal abordagem valeu a pena para nós. Já crescemos desde a migração para o Aurora, e o nosso novo banco de dados continua funcionando e com alto desempenho. Estamos felizes com o Aurora como o nosso novo motor de banco de dados e confiantes de que ele pode se adaptar aos nossos negócios.

Falando em termos de escala, nas próximas semanas, esperamos comemorar o recibo de número 500 milhões! Louros à equipe da AWS por tornar tudo isso possível.

Arquitetura do aplicativo InfoScout

Este artigo foi traduzido do Blog da AWS em Inglês.

Sobre os autores

Dana Ford é diretora de engenharia senior na InfoScout que comanda produto e engenharia para aplicativos móveis de consumidor e equipes de plataforma. Está na empresa há 4 anos e ajudou a expandir a sua grande presença na AWS a fim de atender às necessidades crescentes dos clientes.

Doug Flora é gerente sênior de marketing de produto do Amazon Relational Database Service (RDS) na Amazon Web Services.

Sobre o revisor

Murilo Nascimento é um arquiteto de soluções da AWS que trabalha no desenvolvimento dos parcerios AWS. Especialista em tecnologias de bancos de dados, gosta muito de estudar sobre o tema e gosta mais ainda de compartilhar o que aprende com outras pessoas.