Este texto organiza alguns aprendizados no uso do serviço da Amazon Aurora MySQL que utilizo em produção em um projeto importante já há alguns anos.
Por que escolher o Aurora MySQL?
- O projeto é uma plataforma com uma base de dados muito grande. Era importante que o custo de armazenamento fosse baixo e sem limite de tamanho significativo;
- Usamos o Heroku para o servidor, e as máquinas do Heroku são armazenadas na Amazon. Assim, nosso banco de dados fica na mesma região do servidor;
- O Aurora é ótimo quando não se tem alguém de infra dedicado na equipe. O próprio serviço se ocupa de levantar uma máquina se ela cair por qualquer motivo, faz replicação interna de dados e tem bons recursos de monitoramento de performance.
Mas quais são as outras opções?
-
Máquina própria: Poderíamos contratar uma máquina específica na própria amazon, instalar o mysql e gerirmos o banco de dados. O preço da instância fica até um pouco mais barata, mas o esforço de gerenciamento não compensa;
-
Banco de dados no Heroku: Poderíamos usar um serviço de base de dados disponível como plugin do heroku como o ClearDB. O problema é que os preços para uma base de dados de grande volume são impraticáveis. Devem funcionar bem com sistemas transacionais mais simples que não tem bases muito grandes;
- MySQL com RDS da própria Amazon: Atende as principais vantagens do Aurora, que é atuar como um serviço de seguro de bases de dados relacionais, mas não tem tanto poder de auto gerenciamento como o Aurora que trabalha com muita replicabilidade e capacidade de recuperação automática.
A grande desvantagem até o momento é que ainda não é possível migrar para o MySQL 8 ao usar o Aurora. O uso de MySQL com RDS já tem essa opção. Isso nos deixa atrelados a um conjunto de features do MySQL 5.7.
Tópicos Diversos
Configurações das máquinas disponíveis para o MySQL Aurora
O serviço RDS, sobre o qual funciona o Aurora MySQL, aceita diversos tipos de instâncias. Neste link acima, a configuração de cada tipo e quais bancos de dados aceita. A máquina mais básica para rodar o MySQL é a db.t2.small, com 2GB de memoria RAM e 1 CPU.
Na prática essa máquina apresentou problemas de queda com nosso uso. O ideal é trabalhar com pelo menos 4Gb de RAM.
Preço para colocar meu banco de dados no MySQL Aurora
https://aws.amazon.com/pt/rds/aurora/pricing/
Os custos da Amazon não são simples. No caso do banco de dados você tem quatro custos:
- O custo da máquina virtual, que vai definir o número de CPU’s e memória RAM por exemplo, para MySQL a menor opção é db.t2.small;
- O custo de armazenamento dos dados. Falo disso mais abaixo;
- O custo de leitura e escrita no disco rígido, que varia proporcional ao quanto o banco de dados é utilizado em termos de leitura e escrita;
- Transferência de Rede, que varia proporcional ao volume de dados que sai do banco de dados para a internet;
O primeiro custo é fixo. Você compra a máquina, geralmente uma instância reservada e ele é constante. A instância mais básica (que já é ótima para aplicações pequenas) custa $25 dólares por mês contratando por um ano, ou seja, você se compromete com 12 parcelas de $25. Se você puder já comprar antecipado para um ou três anos, o preço cai muito, vale muito a pena. E não se preocupe se depois precisar mudar o tamanho da instância, seus créditos comprados serão aproveitados (isso é uma das coisas mais incríveis do RDS, veja no tópico “Flexibilidade de tamanho das instâncias reservadas”);
O segundo, terceiro e quarto custos são variáveis.
O custo de armazenamento é insignificante no meu ponto de vista. Uma base de dados de 20GB custa em termos de armazenamento, 2 dólares adicionais por mês. Você não precisa se preocupar aqui.
O custo de leitura e escrita é diretamente proporcional ao volume de transações. Ele conta operações de leitura e escrita. Tem algumas especificidades em relação ao tamanho em bytes da operação, isso está explicado aqui. Cada 1 milhão de operações de leitura e escrita geram um custo de 0,20 centavos de dólar. Aqui é onde você precisa monitorar melhor. Mas a boa notícia é que absolutamente linear em relação ao número de operações, ou seja, tende a ser linear ao número de usuários, então, você consegue acompanhar. Mas também não é motivo de grandes preocupações, para uma aplicação com alguns poucos milhares de acesso por mês, isso deve ficar em algo entre 2 e 5 dólares adicionais por mês.
O custo de rede pode se tornar insignificante se sua máquina estiver na mesma região do seu RDS, nesse caso, o custo de transferência dos dados do banco para a máquina é zero. Aí você só tem o custo de dumps e de uploads de dados externos, o que vai custar 0,09 centavos de dólar por GB, tranquilo.
Concluindo, um banco de dados para uma aplicação de pequeno porte vai custar no entorno de $30 mensais, podendo ficar bem menor se você pagar o valor antecipado da instância reservada.
Conexões simultâneas suportadas
O número de conexões simultâneas suportadas por uma instância depende do tipo dela. A menor possível suporta 45 conexões simultâneas. A média, suporta 90, e a terceira opção, 1000.
Os tais créditos de CPU
https://docs.aws.amazon.com/pt_br/AWSEC2/latest/UserGuide/t2-credits-baseline-concepts.html
As instâncias da Amazon tem um mecanismo de crédito de CPU que funciona como um mecanismo de balanço das máquinas para que uma máquina não consuma 100% de CPU constantemente. De forma simples, se você tiver alto consumo de CPU por alguns minutos seguidos, sua máquina perde prioridade no processamento o que pode degradar a performance. Quanto mais CPU consome, mais créditos perde, mas, eles são recuperados continuamente pelo tempo que você fica sem usar a CPU no máximo. Ou seja, se sua aplicação tem picos de 100% de CPU, tranquilo, não há com o que se preocupar. Se sua aplicação está consumindo muita CPU, a solução vai ser comprar uma instância maior para sua base de dados.
Instâncias T2 Ilimitadas
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/t2-unlimited.html
São instâncias fornecidas pela amazon com as quais você não precisa se preocupar com uso de CPU. Nas instâncias tradicionais, caso o consumo de CPU fique próximo de 100% muito tempo, a máquina perde performance. Mas de qualquer forma, o Aurora MySQL não fornece esse tipo de instância. Fica aqui anotado como lembrete.