RDS resource usage review
Visando reduzir custo de uso de recursos, este documento tem por objetivo avaliar a quantidade de espaço alocado e o tipo de máquina usada por cada um dos bancos RDS do projeto DataViva - os nomes dos bancos são production, staging e etl.
Na tabela abaixo temos a descrição dos recursos usados atualmente pelo projeto. Temos também o custo mensal associado a cada recurso levando em consideração um mês com trinta dias. O custo total de cada mecanismo é dado pelo custo de espaço de disco do banco mais o custo associado a máquina usada.
| Instância | Tipo | vCPU | Mem | Rede | Custo máquina | Espaço alocado | Custo espaço | Custo total |
|---|---|---|---|---|---|---|---|---|
| production | m3.large | 2 | 7,5GB | Moderado | $133,20 | 700GB | $80,50 | $213,7 |
| staging | m3.medium | 1 | 3,75Gb | Moderado | $64,80 | 1000GB | $115,00 | $179,8 |
| elt | m4.xlarge | 4 | 16GB | Alto | $252,00 | 1500GB | $172,50 | $424,5 |
Para realizar a análise foram coletados dados de uso de CPU, memória livre e espaço de disco livre na plataforma AWS Cloud Watch, sendo que foram coletados no período de 25/05/2018 até o dia 05/07/2018 (exceto para o banco de produção que só há dados a partir do dia 05/06/2018).
Como pode ser analisado no gráfico a seguir, o percentual de uso de CPU tanto para a máquina production quanto para a staging fica a maior parte do tempo abaixo do percentual de 5% de uso. Vale salientar que a primeira faz uso de dois vCPU enquanto a segunda somente um, motivo pelo qual o percentual da instância de production se mantém sempre mais baixo. Ambos o recursos podem ser drasticamente reduzidos para uma máquina mais próxima do uso real. Já para o banco utilizado para o processo de ETL podemos observar que durante atualizações de dados temos um percentual de vCPU bem variado, mas boa parte dentro da faixa de 10% e 30%, sendo que o percentual máximo alcançado foi de %58. Estes dados indicam também a possibilidade de redução do tipo de máquina usada neste banco.
Outro dado importante de ser levado em consideração sobre o uso de recursos é a quantidade de memória disponível na máquina (memória livre ou passível de ser liberada). Como pode ser observado no gráfico abaixo, o banco de ETL apresenta um baixo uso de memória, tendo quase 2.5GB de memória utilizável. Já os bancos utilizados para o site (production e staging), operam com uma quantidade de memória disponível menor. Este dado deve ser levado em consideração para dimensionar o recurso para a máquina mas é importante salientar que boa parte da memória utilizada é cache do próprio MySQL (este pode ser alterado de acordo com a capacidade de memória disponível).
Como podemos ver no gráfico abaixo, o uso de disco na instância staging está muito sobrestimado, podendo ser reduzido em até 800GB. Também é plausível a diminuição do espaço em disco utilizado pela instância de produção em 250GB, uma vez que não haverão atualizações de dados neste banco. Já o banco de etl se encontra com apenas 212GB de espaço livre, dado que o mesmo armazena dados históricos de todos os processos de ETL realizados. Foi julgado desnecessário o armazenamento de todos esses dados históricos, é proposto que este banco utilize um espaço em disco bem reduzido servindo apenas para guardar os dados enquanto são transformados no processo de atualização ao invés de armazenar o processo de ETL para todos anos.
A AWS oferece mais de uma opção de máquina e tipo para ser usada para o RDS, sendo que cada tipo apresenta suas vantagens e desvantagens. Segue a definição de cada uma delas para a geração atual de máquinas. Avaliações de preço foram realizadas levando em consideração máquinas hospedadas no servidor Norte Virgínia, funcionando sobre demanda.
Recomendada para serviços que apresentam um uso intermitente de recurso, sendo que quando está ociosa acumula crédito de vCPU que podem ser utilizados em momentos de pico (quando ultrapassar um percentual de uso de vCPU). Porém este tipo de instância não apresenta a otimização IOPS (que otimiza a leitura e a escrita de dados), mas é a opção de menor custo. Segue abaixo a descrição de algumas opções de máquinas deste tipo:
| Modelo | vCPU | Créditos de CPU/hora | Mem (GiB) | Custo/hora |
|---|---|---|---|---|
| t2.small | 1 | 12 | 2 | $0,034 |
| t2.medium | 2 | 24 | 4 | $0,068 |
| t2.large | 2 | 36 | 8 | $0,136 |
| t2.xlarge | 4 | 54 | 16 | $0,272 |
| t2.2xlarge | 8 | 81 | 32 | $0,544 |
Indicada para uso comum em que não há uma variação muito grande do uso de recursos. Apresenta otimização de IOPS e disco de dados SSD.
| Modelo | vCPU | Mem (GiB) | Armazenamento em SSD (GB) | Largura de banda (Mbps) | Custo/hora |
|---|---|---|---|---|---|
| m4.large | 2 | 8 | Somente EBS | 450 | $0,175 |
| m4.xlarge | 4 | 16 | Somente EBS | 750 | $0,35 |
| m4.2xlarge | 8 | 32 | Somente EBS | 1.000 | $0,70 |
Além das instâncias RDS tradicionais, também devemos avaliar outras opções de banco de dados. O Amazon Aurora é uma opção interessante por ter um bom custo benefício e ser compatível com o MySQL e com o PostgreSQL, além de apresentar um desempenho de throughput (transferência) superior de que ambos (quando executados em hardwares equivalentes).
| Modelo | vCPU | Mem (GiB) | Desempenho das redes | Custo/hora |
|---|---|---|---|---|
| t2.small | 1 | 2 | Baixo | $0,041 |
| t2.medium | 2 | 4 | Moderada | $0,082 |
| db.r3.large | 2 | 15.25 | Moderada | $0,29 |
Como o acesso aos dados deste banco variam bastante ao longo do dia e atualmente o DataViva não faz uso da otimização IOPS para acesso a dados, é sugerido que o tipo da instância seja modificado para o T2.
Uma vez que foi levantado que o uso de recursos deste banco está bem abaixo da capacidade da máquina e com a API do DataViva seu uso pode ser reduzido ainda mais, é sugerido a redução desta máquina para a configuração medium.
Sendo que o banco production está usando em torno de 429GB de armazenamento e não haverá atualização de bases armazenadas nele, recomenda-se alterar seu espaço total de disco para 500GB.
Visto que o acesso aos dados deste banco é feito de forma esporádica, somente em momentos de teste da aplicação, é proposto que para este ambiente seja utilizado uma instância do tipo T2. Dado que ela tem um menor custo e pode acumular créditos de vCPU em momentos de ociosidade.
Uma vez que este ambiente não precisa apresentar um desempenho muito grande na busca de dados, é sugerido que seja utilizado a configuração small. Está atende bem os requisitos de uso de memória e vCPU.
O armazenamento de dados atual deste banco está em torno de 300GB, sendo que novos dados não serão adicionados a este é indicado que o armazenamento total do banco seja configurado para 320GB.
A principal forma de reduzir o custo mensal deste recurso é usá-lo somente quando se fizer necessário. Ou seja, ao invés de deixar este banco sempre disponível com os dados armazenados, somente utilizar durante o período de atualização de dados e em seguida remover a instância.
Visto que durante o processo de atualização o uso deste recurso é relativamente constante em termo de processamento usado, é sugerido que o tipo de instância seja mantido (M4).
Como foi analisado, a quantidade de memória e processamento usado durante o período de processamento está bem abaixo das capacidades da máquina. Deste modo, recomenda-se que esta seja reduzida para a configuração large.
Uma vez que este banco não guarde dados históricos do processo de ETL, a quantidade de espaço reservado para este pode ser reduzido para 200GB. Estimativa feita com a seguinte proposição: para atualização dos dados RAIS 2016 temos as seguinte tabela com o quantidade de MB alocados para cada:
| Tabela | Memória (em MB) |
|---|---|
| RAIS_2016 | 42661 |
| RAIS_2016_STEP1 | 4623 |
| RAIS_2016_STEP2 | 4468 |
| RAIS_2016_STEP3 | 4926 |
| Total | 56678 |
Ou seja, um total de 56GB para atualizar esta base, sendo esta a com maior número de registros. Deste modo, a quantidade de 000GB suportaria a atualização de duas bases RAIS simultâneas e ainda restaria uma certa quantidade de espaço para uso.
Custo total de uso de recurso RDS para a proposta de configuração, levando em consideração uso constante durante um mês (de trinta dias). Sendo que foram consideradas duas opções de SGBD.
Alternativa padrão, sem mudar a tecnologia de banco de dados utilizada.
| Instância | Tipo | vCPU | Mem | Custo máquina | Espaço alocado | Custo espaço | Custo total |
|---|---|---|---|---|---|---|---|
| production | t2.medium | 2 | 4GB | $48,96 | 500GB | $57,50 | $106,46 |
| staging | t2.small | 1 | 2Gb | $24,48 | 320GB | $36,80 | $61,28 |
| elt | m4.large | 2 | 8GB | $126,00 | 200GB | $23,00 | $149,00 |
Versão alternativa de configuração para as bases de dados fazendo uso do banco Amazon Aurora. Esta opção, além dos custo fixos, apresenta um custo $0,20 para 1 milhão de solicitações realizadas.
| Instância | Tipo | vCPU | Mem | Custo máquina | Espaço alocado | Custo espaço | Custo total |
|---|---|---|---|---|---|---|---|
| production | t2.medium | 2 | 4Gb | $59,04 | 500GB | $50,00 | $109,04 |
| staging | t2.small | 1 | 2Gb | $29,52 | 320GB | $32,00 | $61,52 |
Para fazer um estimativa de custo mensal que poderiam ser cobrados por solicitações (leitura/escrita de dados), foi recuperado a média das operações (por meio do serviço CloudWatch), por segundo, levando em consideração os últimos 3 meses. Segue a estimativa realizada:
| Instância | WriteIOPS | ReadIOPS | Total operações/mês | Custo/mês |
|---|---|---|---|---|
| production | 0.42/s | 1.02/s | 3732480 | $0,74 |
| staging | 0,53/s | 0,37/s | 2332800 | $0,466 |
Como pode ser visto na tabela, o custo de entrada e saída de dados neste banco não apresenta um custo impactante para o orçamento mensal. Além deste custo, o Aurora oferece uma ferramenta que permite que estado do banco possa ser retomado para um dado instante de tempo (permitindo recuperação para uma alteração realizada em um dado instante). Este é cobrado por cada operação de registro de alterações realizadas no banco e o valor é de $0,012 para cada 1 milhão de registros.