Como a Autodesk aumentou a escabilidade do banco de dados e reduziu o atraso de replicação com o Amazon Aurora

Por Piyush Patel, Consultor Sênior de Big Data na AWS Professional Services
Akm Raziul Islam, Consultor com Ênfase em Banco de Dados e Análise na AWS
Chayan Biswas, Gerente de Produtos na AWS
Krishna Kumar, Gerente Sênior de Engenharia na Autodesk

A Autodesk é líder em software de projeto, engenharia e entretenimento 3D. A Autodesk faz software para pessoas que realizam as coisas. Se você já dirigiu um carro de alto desempenho, admirou um arranha-céu imponente, usou um smartphone ou assistiu a um ótimo filme, é provável que tenha experimentado o que milhões de clientes da Autodesk estão fazendo com o software deles.

A Autodesk fez a migração com sucesso para o Amazon Aurora, tanto de bancos de dados MySQL gerenciados no Amazon RDS quanto de bancos de dados MySQL que rodavam no Amazon EC2. Esta postagem do blog resume a experiência e abrange:

• Fatores que influenciaram a decisão da Autodesk de mudar para o Amazon Aurora
• Benefícios específicos da migração
• Melhores práticas e lições aprendidas para migração e otimização

Começamos analisando o caminho da migração da aplicação Access Control Management (ACM) da Autodesk, que nasceu na nuvem. Escolhemos o Amazon RDS for MySQL no início e migramos para o Aurora para melhorar a escalabilidade, a disponibilidade, e o desempenho. O sucesso do ACM com a migração motivou várias outras aplicações da Autodesk a migrarem para o Aurora. Discutimos o BIM 360 Field Classic como um exemplo a seguir de migração de banco de dados auto-gerenciado MySQL hospedado em EC2 para o Amazon Aurora.

Arquitetura da aplicação ACM e desafios com o MySQL

O diagrama a seguir fornece um esquema de alto nível da arquitetura inicial do ACM. A camada de aplicação consiste em instâncias EC2 distribuídas em várias Zonas de Disponibilidade a fim de manter a alta disponibilidade. O tráfego é distribuído com o uso do serviço Elastic Load Balancing. Além disso, o EC2 Auto Scaling é empregado para ajustar o número de instâncias EC2 para suportar picos de tráfego na aplicação.

Embora tal arquitetura permitisse que a Autodesk pudesse escalar e balancear a carga na camada da aplicação, o gargalo logo mudou para o banco de dados. A aplicação se conectava a uma única instância do banco de dados RDS MySQL, limitando as opções de dimensionamento disponíveis. Uma abordagem foi aumentar o tamanho da instância do banco de dados. Essa abordagem ainda estava restrita pelo tamanho máximo de instâncias de banco de dados que poderiam ser provisionadas. O ACM rapidamente ultrapassou os limites de capacidade da maior instância disponível.

A opção seguinte foi escalar horizontalmente a capacidade do banco de dados com a adição de instâncias de réplica de leitura do RDS a fim de descarregar leituras da instância principal. A Autodesk queria manter o atraso de replicação abaixo de um segundo a fim de fornecer uma experiência consistente a todos os usuários do ACM. O atraso de replicação associado às réplicas de leitura depende da pressão da carga de trabalho na instância primária e na réplica de leitura. (Atraso de replicação representa aqui o tempo necessário para que os efeitos de uma operação de gravação se tornem visíveis na réplica de leitura.)

Após esta reformulação do ACM, dividindo os dados entre vários bancos de dados MySQL, a Autodesk precisou regular a aplicação para limitar a carga direcionada ao banco de dados a fim de minimizar o atraso de replicação. Tal abordagem não era sustentável, porque a adoção do ACM era severamente reduzida pelos limites impostos. Esse resultado levou a Autodesk a avaliar alternativas, como o Amazon Aurora.

Amazon Aurora ao resgate!

Algumas das principais prioridades à medida que a Autodesk começava a avaliar o Aurora foram as seguintes:

• Melhoria de desempenho
• Baixo atraso de replicação para escala de leitura
• Compatibilidade total com o MySQL (migração lift-and-shift)
• Escalabilidade de armazenamento automatizada

O Aurora oferece um desempenho até cinco vezes maior que o banco de dados MySQL padrão. Tal aumento de desempenho significava que a Autodesk poderia remover as restrições de limite de carga introduzidas no MySQL sem alterar a aplicação e ainda ter espaço suficiente para crescimento futuro. O sistema de armazenamento distribuído, tolerante a falhas e autorreparável que o Aurora fornece escala automaticamente até 64 terabytes e elimina a necessidade de dimensionar manualmente o armazenamento de banco de dados. Até 15 réplicas do Aurora de baixa latência melhoram a disponibilidade e permitem escalar as cargas de leitura com atraso de replicação típico abaixo de 100 milissegundos.

A Autodesk usou as réplicas do Aurora para remover as cargas de leituras da instância principal e escalar as leituras horizontalmente. Além disso, com clonagem rápida, recuperação point-in-time, backup contínuo no Amazon S3 e replicação através de três zonas de disponibilidade, o Aurora permitiu à Autodesk reduzir ainda mais as despesas operacionais.

O diagrama a seguir mostra a arquitetura da aplicação ACM após a migração para o Aurora.

Nessa arquitetura, o cluster do Aurora inclui uma instância primária (leituras e escritas) e até quatro réplicas de leitura. O Aurora Auto Scaling foi ativado para ajustar automaticamente o número de réplicas do Aurora com base na utilização da CPU.

O desempenho do banco de dados superou as expectativas após a migração para o Aurora. A Autodesk observou uma melhoria de 20x na escalabilidade da aplicação, o tempo de resposta da aplicação foi aprimorado em 2x, e o Aurora suportou 7x mais conexões com o banco de dados. O destaque da migração foi a redução em 10x na utilização da CPU em uma instância de banco de dados de tamanho semelhante, deixando espaço suficiente para o banco de dados crescer à medida que o ACM é escalado. Captamos alguns gráficos comparativos entre o MySQL e o Amazon Aurora antes e depois da migração que destacam tais melhorias.

A Autodesk obteve uma redução de 10x na utilização da CPU, de picos chegando a 100% no MySQL a menos de 10% no Amazon Aurora. Os gráficos a seguir mostram o antes e o depois da utilização da CPU.

Consumo de CPU do Aurora

Consumo de CPU do MySQL

Os gráficos a seguir mostram o antes e o depois dos tempos de resposta da aplicação.

A Autodesk obteve uma melhoria de 2x no tempo de resposta.

Consumo de CPU do Aurora

Consumo de CPU do MySQL

Vamos nos aprofundar no processo de migração e nas lições aprendidas.

Melhores práticas e lições aprendidas de migração

A Autodesk acionou o AWS Professional Services para suportar a migração para o Amazon Aurora. A seguir, é apresentado um resumo de todas as considerações e práticas recomendadas, categorizadas pelos cinco pilares do AWS Well-Architected framework:

Confiabilidade

• Testar e verificar: realizamos testes de carga no ambiente de stage com 5x o tráfego usual com uma instância Aurora primária e quatro réplicas de leitura para confirmar os ganhos de desempenho e garantir escalabilidade futura. Os resultados do teste confirmaram que a utilização da CPU estava abaixo de 10%, mesmo sob cargas sustentadas. Os requisitos de latência da aplicação também foram excedidos. O Aurora suporta até 15 réplicas de leitura em um cluster Aurora. Como usamos apenas até quatro réplicas do Aurora, temos espaço suficiente para escalar as leituras com réplicas do Aurora adicionais. O Aurora pode escalar automaticamente o armazenamento para até 64 terabytes. O banco de dados do ACM utiliza cerca de 1 terabyte, o que deixa espaço suficiente para o crescimento do armazenamento.
• Implantação Multi-AZ: para melhorar a disponibilidade e os failovers automáticos rápidos, criamos réplicas do Aurora em diferentes Zonas de Disponibilidade (AZs). As réplicas do Aurora servem a dois propósitos: primeiro, como destinos de failover para a instância principal e, segundo, para descarregar leituras de baixa latência porque compartilham o mesmo armazenamento com a instância primária. Definimos uma prioridade de failover para cada réplica do Aurora a fim de especificar a ordem na qual as réplicas do Aurora serão promovidas se a instância principal ficar indisponível. O armazenamento do Aurora mantém seis cópias de dados em três zonas de disponibilidade e é distribuído através de centenas de nós de armazenamento. Essa funcionalidade ajuda a garantir disponibilidade total de leitura e gravação, mesmo com uma improvável perda de conectividade com um AZ inteiro.
• Distribuir a carga: conectar com o endpoint de leitura permite ao Aurora balancear as conexões através das réplicas no cluster. Tal abordagem ajuda a distribuir a carga de trabalho de leitura e pode levar a um melhor desempenho e ao uso mais equitativo dos recursos disponíveis para cada réplica. A carga de trabalho do banco de dados do ACM era read-heavy, com aproximadamente 90% das cargas de trabalho consistindo em leituras. A configuração de quatro réplicas do Aurora permitiu-nos descarregar e distribuir cargas de trabalho de leitura para as réplicas. Ao mesmo tempo, aumentamos o tamanho do pool de conexões na aplicação para melhor usar as réplicas do Aurora.
• Coexistência durante a migração: durante a migração inicial, também configuramos a replicação entre o Aurora e o RDS MySQL para um rollback seguro. Uma semana depois da transição bem-sucedida da produção, ganhamos confiança suficiente e decidimos que não precisávamos mais do ambiente de fallback e encerramos a replicação naquele ponto. A replicação baseada em binlog do MySQL é intensiva e pode causar degradação no desempenho das operações de escrita. Recomendamos desativar o binlog, a não ser que seja necessário por razões operacionais.
• Durabilidade e recuperação de desastre (DR): o Aurora mantém seis cópias de dados através de três Zonas de Disponibilidade e faz backup contínuo dos dados no S3. Para DR, adicionamos um cluster de réplica de leitura de região cruzada em outra Região da AWS e simulamos exercícios de recuperação de desastre no ambiente de stage para ajudar a garantir a prontidão operacional para desastres em grande escala.

Eficiência de desempenho

• Dimensionamento correto: executamos testes de carga com diferentes tipos de instância e escolhemos a r3.8xlarge para obtenção de melhor custo-benefício de desempenho. Também comparamos os resultados de teste de carga com o MySQL para obter uma sensação de melhorias de desempenho obtidas com a migração do Aurora. Em vez de super provisionar a instância principal para atender escritas e leituras, dimensionamos a instância primária para atender predominantemente escritas. Réplicas do Aurora foram adicionadas para melhorar o desempenho de leitura.
• Otimizações opcionais: apesar de geralmente não ser necessário, você pode otimizar a execução de consultas ao trabalhar com os parâmetros de configuração do MySQL disponíveis. Por exemplo, aumentamos o tamanho do cache de consulta a fim de ganhar desempenho em leituras repetidas. Também monitoramos consultas de longa duração e reduzimos os comprimentos das transações. Para encontrar detalhes dos parâmetros do MySQL, consulte o Manual de referência do MySQL.

Excelência operacional

• Otimização de desempenho: habilitamos o monitoramento aprimorado do cluster do Aurora em intervalos de 5 segundos e procuramos por consultas de longa duração. Além disso, agendamos um trabalho semanal para analisar tabelas e coletar estatísticas. Fazer isso permitiu-nos melhorar o tempo de processamento das transações e reduzir as consultas de longa duração.
• Monitoramento contínuo: criamos painéis para o Amazon CloudWatch a fim de manter a visibilidade das principais métricas dos clusters do Aurora e também das métricas da aplicação. Por padrão, a métrica AuroraReplicaLag, que representa o valor do retardo de replicação entre a instância primária e as réplicas do Aurora, é publicada no CloudWatch a cada minuto. Configuramos uma métrica personalizada do CloudWatch para juntar esse valor a cada segundo a fim de manter uma visibilidade mais granular do retardo na replicação. Também criamos subscrição de eventos e alarmes para métricas importantes, como utilização da CPU, utilização de memória, latências e taxas de consultas DML e DDL, e taxa de acertos do cache do buffer. Além disso, configuramos notificações automáticas de eventos para grupos responsáveis usando o Amazon SNS.
• Automação de Builds: empregamos templates do AWS CloudFormation para provisionar clusters do Aurora e réplicas do Aurora com escabilidade automática. Isso reduziu consideravelmente o tempo para provisionar um nova stack. Baseados nessa automação, implantamos uma arquitetura blue-green para atualizações sem tempo de inatividade e gerenciamento de versões.

Segurança

Configuramos o cluster do Aurora no serviço Amazon VPC e configuramos grupos de segurança para isolar o acesso ao cluster do Aurora. A criptografia foi ativada no Aurora a fim de proteger os dados em repouso. Quando a criptografia está ativada no Aurora, os backups e snapshots são criptografados automaticamente. Além disso, configuramos a aplicação para usar a conexão Secure Socket Layer (SSL) com as instâncias do Aurora.

Otimização de custos

Devido à incerteza da carga da aplicação no novo ambiente, decidimos provisionar em excesso o cluster do Aurora com quatro réplicas r3.8xlarge do Aurora. Depois da migração bem-sucedida, continuamos a monitorar o desempenho e a utilização do banco de dados usando as métricas do CloudWatch. Quando adquirimos confiança suficiente na estabilidade do novo sistema, usamos as métricas coletadas para dimensionar corretamente o ambiente. Como parte disto, configuramos o Aurora com base na utilização da CPU a fim de otimizar a utilização das réplicas Aurora. Hoje, a depender da carga de trabalho, nosso cluster do Aurora consiste em uma instância primária e pode escalar até quatro instâncias de réplica do Aurora.

Qual é o próximo passo?

Com a migração bem-sucedida do banco de dados do ACM da Autodesk e as significativas melhorias de desempenho pós-migração, a Autodesk passou a usar o Amazon Aurora em diversas aplicações. O trabalho de migração realizado pela equipe do BIM 360 Field é um ótimo exemplo de migração de um banco de dados MySQL hospedado em EC2 para o Amazon Aurora.

BIM 360 Field Classic

Depois do sucesso da migração do ACM, a Autodesk contratou o time AWS Professional Services para executar outra migração. Assim, migramos uma configuração do MySQL com seis nós hospedado no Amazon EC2 para a aplicação BIM 360 Field Classic para o Amazon Aurora. A configuração do MySQL tinha uma instância primária e cinco réplicas de leitura. Avaliamos o ambiente do BIM 360 Field com as seguintes descobertas:

1. O banco de dados do aplicativo AWS BIM 360 Field contém cerca de 2 terabytes de dados.
2. A alta disponibilidade e o failover são gerenciados por meio da camada de middleware entre a aplicação e o banco de dados.
3. A aplicação de failover está hospedada no EC2.
4. As réplicas do Aurora estão conectadas à instância principal por meio da replicação baseada em binlog do MySQL e também atuam como destinos de failover para realização de viradas em 10 segundos ou menos.
5. A aplicação roteia manualmente as consultas para todos os cinco nós baseado nos números de porta na qual cada uma das réplicas está configurada.
6. O backup é configurado por meio da execução diária dos scripts Percona XtraBackup e MySQLDump. Um snapshot da instância do EC2 também é programado para recuperação no nível da instância.

Apesar de essa configuração ter funcionado para o BIM 360 Field Classic, a Autodesk ainda precisava gerenciar uma área extensa, desde o backup no nível da instância do EC2 até os backups de banco de dados. Como parte disso, era importante garantir alta disponibilidade do banco de dados e implementar estratégias de recuperação de desastre da aplicação. Similarmente, a Autodesk precisava gerenciar o código da aplicação para balancear as consultas e manter a integridade de dados para replicação lógica com o binlog. Apesar de essas operações serem viáveis, não são bem dimensionadas e exigem recursos e planejamento consideráveis. Nós automatizamos e simplificamos os mecanismos de alta disponibilidade, failover e balanceamento de carga ao migrar para o Amazon Aurora, que suporta tais recursos por padrão.

Migração para o Aurora

Avaliamos diferentes abordagens de migração no Manual de migração do Amazon Aurora e escolhemos a abordagem de backup lógico com o uso da ferramenta de código aberto Mydumper para a migração. As migrações são aceleradas ao fazer em paralelo o processo geral de transferência de dados com as instâncias r4.16xlarge.

Para otimizar mais o custo e atender aos requisitos adicionais de várias aplicações da Autodesk, fizemos o seguinte:

1. Habilitamos o Aurora Auto Scaling para ajustar automaticamente o número de réplicas do Aurora com base na utilização da CPU. Em vez de executar continuamente várias réplicas, economizamos custos ao adicionar réplicas quando necessário.
2. Implantamos a ferramenta de snapshots para o Aurora em todos os clusters do Aurora a fim de automatizar a cópia de snapshotsentre as Regiões da AWS e implementando retenções de snapshots do Aurora além de 35 dias. Fizemos isso para atender aos requisitos da Autodesk, tanto de objetivo de ponto de recuperação (RPO) quanto de objetivo de tempo de recuperação (RTO). A ferramenta de snapshots usa vários serviços da AWS no ecossistema da AWS, como o AWS Lambda e o AWS Step Functions, a fim de automatizar o processo de cópia de snapshots entre as Regiões e contas da AWS.
3. Habilitamos o CloudWatch Logs para os eventos de auditoria do Amazon Aurora para publicar logs de auditoria no CloudWatch Logs e criar métricas e alarmes do CloudWatch para monitorar a atividade nos clusters do Aurora DB continuamente.

Conclusão

Com o Amazon Aurora, as aplicações ACM e BIM 360 Field Classic conseguiram melhorar a escalabilidade, aumentar o seu desempenho, reduzir a sobrecarga de gerenciamento e otimizar os custos.

“O banco de dados do ACM tem aproximadamente 1 terabyte de tamanho, com algumas tabelas que ultrapassam um bilhão de linhas. Recebemos de 25 a 30 mil solicitações por minuto durante o horário de pico”, disse Krishna Kumar, gerente sênior de engenharia da Autodesk. “Estamos construindo uma estratégia para lidar com o crescimento de 100 vezes para as nossas aplicações. Definitivamente, vemos o Aurora como uma grande parte do roadmap do ACM e sentimos que o Aurora pode adquirir recursos para resolver tais desafios de escala.”

A migração bem-sucedida do ACM para o Aurora deu direção geral a várias equipes da Autodesk para usarem o maior desempenho, escalabilidade e disponibilidade do Aurora. A Autodesk formalizou uma estratégia de migração para o Aurora e trabalha ativamente para mover várias stacks de aplicações para começarem a usar o Aurora, com o BIM 360 Field Classic como o exemplo mais recente.

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

Sobre os autores

Piyush Patel é consultor sênior de big data da AWS Professional Services Ele trabalha com os clientes para fornecer orientação e assistência técnica sobre projetos de big data e análise, ajudando-os a melhorar o valor de suas soluções ao usar a AWS.

Akm Raziul Islam é consultor com ênfase em banco de dados e análise na Amazon Web Services. Ele trabalha com os clientes para fornecer orientação e assistência técnica sobre vários projetos de banco de dados e análise, ajudando-os a melhorar o valor de suas soluções ao usar a AWS.

Chayan Biswas é gerente de produtos da Amazon Web Services.

Krishna Kumar é gerente sênior de engenharia responsável por vários dos principais serviços básicos de nuvem da Autodesk. Ele tem construído e liderado equipes em várias frentes de tecnologia e domínio há anos. Ele tem paixão por criar aplicativos altamente escaláveis com estabilidade e desempenho confiáveis.

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.