O impacto de apenas algumas “bad queries” na operação de um negócio

Por Matheus Oliveira, Célula de Dados na Dedalus

A G-Click é uma startup brasileira da área de gestão de processos que, desde 2018, disponibiliza aos escritórios de contabilidade uma solução inovadora para o gerenciamento de tarefas e processos contábeis.

Com o sucesso do negócio e consequente ampliação de sua base de clientes, surgiram os primeiros desafios tecnológicos.

“Tínhamos a previsão de ampliar nossa base de clientes e precisávamos buscar uma empresa que nos proporcionasse segurança, agilidade, conhecimento técnico, inovação e experiência em gestão dos recursos da AWS e encontramos estas características na Dedalus”, comenta Richard Werneck que, atualmente, é diretor de tecnologia da G-Click.

O DESAFIO

Com o crescimento da base de clientes da G-Click e consequente aumento no volume de requisições da aplicação e aumento do volume de dados gerados, sua instância RDS MySql passou a apresentar um alto consumo de CPU, atingindo picos de 100%, que resultavam em indisponibilidade na aplicação.

Cenário inicial: Consumo de CPU e quantidade de conexões do RDS db.m4.xlarge.

Inicialmente, o banco de dados da G-click utilizava uma instância RDS MySql db.m4.xlarge.

Ao se deparar com essa situação de alto consumo de CPU, um scaleup do seu RDS para uma instância db.m4.2xlarge foi realizado. Entretanto, o aumento da instância RDS além de não resolver os problemas de consumo de CPU e instabilidades da aplicação, dobrou seu custo com banco de dados.

Diante do cenário descrito, o desafio era solucionar de fato os problemas de indisponibilidade sem que a solução trouxesse aumento significativo de custos para que a Gclick continuasse crescendo sua base de clientes.

A SOLUÇÃO

Com o monitoramento detalhado das queries lentas (queries que levam acima de 100ms para serem executadas) no RDS, identificamos que apenas 10 queries, dentre mais de 1900 queries distintas, eram responsáveis pelo consumo de mais de 70% do tempo de execução no banco de dados por dia.

Aprofundamos a análise nas 10 queries que mais consumiam tempo de execução no banco de dados e identificamos a necessidade da criação de 16 índices.

Inicialmente a necessidade desses índices não era percebida devido ao pequeno volume de dados e requisições. Com o aumento da demanda e volume de dados no banco de dados, o impacto causado pela falta dos índices necessários para que o banco de dados resolvesse de maneira otimizada as queries enviadas pela aplicação ficou mais evidente.

O RESULTADO

Após a criação dos 16 índices sugeridos, o consumo de CPU no RDS caiu significativamente o que permitiu o scale-down do RDS para uma instância db.m4.xlarge. Mesmo após o scaledown, o consumo de CPU se manteve abaixo de 10%.

Além de resolver os problemas de indisponibilidade e escalabilidade da G-click, a solução implementada permitiu uma redução de custo significativa.

“A superação deste desafio foi fundamental para que pudéssemos manter, com tranquilidade, o plano de negócios que possuímos para o G-Click. É esta solução que vai assegurar a estrutura que precisamos para atingir a meta de clientes estimada até o fim deste ano”, explica o diretor de Tecnologia. “Além disso, esta estabilidade nos dará segurança para o passo seguinte, que trará ainda mais inovações. E, não tenho dúvidas que o apoio da Dedalus, para a arquitetura de todos os processos, aliada às soluções da AWS, será fundamental para alcançarmos estes objetivos”, finaliza.

—

A Dedalus é um Parceiro AWS Premier, nível mais alto da Rede de Parceiros da AWS. Temos uma AWS Competency em Migração e fazemos parte dos programas Managed Service Provider, AWS Public Sector Partner e Well-Architected, entre outros.