Um das grandes dúvidas antes de uma migração para Amazon Aurora é acerca do custo e como suas instâncias são precificadas.

É comum encontrarmos situações onde o cliente já teve alguma experiência negativa com o custo do Aurora e, para isso, trouxemos um caso que exemplifica bem esse tipo de situação e o que deve ser feito para evitar surpresas. Antes, vamos entender como é feita a precificação:

Precificação: Amazon Aurora vs RDS MySQL

No Amazon Aurora, a quantidade de operações de escrita e leitura de disco também é cobrada. Devido a isso, muitos usuários se surpreendem com valores não esperados ao final do mês. A AWS cobra com base no tamanho do dataset e quantidade de requisições por segundo. Cada operação de leitura ou escrita de uma página do banco de dados conta como um IO. Além disso, as instâncias do Aurora custam cerca de 20% a mais do que RDS MySQL, por exemplo.

O Amazon Aurora realiza leituras na camada de armazenamento para buscar as páginas do banco de dados não presentes no buffer cache e realiza escritas ao enviar registros de log de transações para a camada de armazenamento com o objetivo de tornar as transações duráveis.

Embora para Aurora você pague apenas pelos dados que você realmente usa em incrementos de 10 GB. Independentemente do tipo de instância, você é cobrado $0,10 por GB-mês e $0,20 por 1 milhão de requisições de IO. Ou seja, três fatores afetam o preço: tipo de instância, tamanho do storage e número de requisições de IO. Já para o RDS MySQL, os custos de armazenamento são baseados no tipo de instância e tamanho do storage apenas.

Caso real de um cliente: Allowme, Intelligence by Tempest

É comum, após uma nova funcionalidade da aplicação entrar em produção, haver alguma mudança de comportamento que não estava prevista. Nesse caso não foi diferente, além de um aumento significativo de uso de CPU, houve um aumento de USD 100 por dia (cerca de USD 3K/mês) no custo do AWS Aurora (relacionado aos I/O requests).

Como vocês podem perceber nos gráficos abaixo:

• CPU/Utilization

• IOPS

Solução

Utilizando o software Nazar, foi feita uma análise de todos os comandos distintos que eram executados no banco de dados e foi constatado que apenas 7 comandos eram responsáveis por 95% do tempo total de execução.

Após a análise aprofundada desses 7 comandos, nosso time de especialistas recomendou a criação de 4 índices apenas.

Resultados

Após analisar os resultados dessa solução, constatou-se uma redução drástica no volume de IOPS e, consequentemente, nos picos de CPU que vinham ocorrendo.

• Billed Volume Read IOPS: baixou de picos de 3.5MM/dia para picos de, no máximo, 4K/dia. Representando uma economia de USD 3K/mês.

• Picos de CPU: concluiu-se, também, que os picos eram causados pelas queries sem os índices, que eram executadas de hora em hora. Como resultado, a média de consumo de CPU caiu de 100% para 5%, como vocês podem perceber no gráfico a seguir:

Outro fato relevante é que isso possibilitou a redução das instâncias utilizadas:

• Writer instance from r5.xlarge to r5.large (economia de USD 430/mês);
• Read instance from r5.large to t3.medium (economia de USD 310/mês);

Por fim, o cliente foi beneficiado com uma economia anual de custos de aproximadamente USD 45K.

Conclusão

Se você está utilizando o Aurora, é recomendado o monitoramento da quantidade de requisições de IOs que sua instância está consumindo através das métricas “[Billed] Volume Read IOPS” e “[Billed] Volume Write IOPS”.

No entanto, essas métricas mostram apenas a consequência e não a causa raiz do aumento dessas requisições de IO. Para isso, é fundamental que haja um monitoramento contínuo do seu banco de dados. Com o software Nazar é possível detectar o que está, de fato, causando esse aumento para que as medidas corretivas sejam tomadas.

Através de alertas, a ferramenta avisa toda a sua equipe sobre qualquer mudança no comportamento do seu servidor de banco de dados, possibilitando a identificação da causa do problema, como foi demonstrado no caso acima.

Portanto, ao utilizar o Amazon Aurora, fique atento às métricas citadas para que não haja surpresa no fim do mês.

“É importante contar com a Nazar para esse tipo de situação que pode ocorrer a qualquer momento, não só como um aumento de custos como, também, problemas de performance e disponibilidade.” — Gustavo Monteiro, Managing Director na Allowme

Sobre AllowMe — Intelligence by Tempest

O AllowMe é uma solução criada para proteger as relações entre as empresas e seus clientes através da avançada tecnologia que atua na validação, identificação e autenticação de usuários no ambiente online. Tudo isso aliado aos 20 anos de background em segurança da informação da Tempest Security Intelligence.