Este artigo aponta os principais cuidados e boas práticas para escolher os volumes SSD mais econômicos no RDS.
São três opções de armazenamento SSD no RDS. O Amazon RDS oferece dois tipos de SSD de uso geral: gp2 e gp3. Há ainda o SSD com IOPS Provisionado, o io1. (Existe também o antigo armazenamento magnético, lento demais para a maioria das aplicações. Vale notar que o io2, disponível no EBS, ainda não tem suporte no RDS.)
- gp2 — Geração mais antiga, IOPS atrelado ao tamanho do volume, com burst
- gp3 — Geração atual, IOPS consistente, vem com IOPS de baseline e permite contratar IOPS e throughput adicionais
- io1 — (Também conhecido como PIOPS.) Performance consistente, exige a contratação de IOPS Provisionado. É o mais caro.
Os três tipos entregam latência na casa de um dígito de milissegundo.
O custo por GB é igual para gp2 e gp3 no RDS (diferente do EC2, em que o gp3 sai mais barato). Em compensação, o gp3 oferece mais IOPS de baseline (em volumes de até 4.000 GB) sem a limitação do bursting.
Planilha com a matriz de preços
A planilha abaixo mostra os detalhes de preço e IOPS para um determinado tamanho de volume em gp2 vs. gp3 vs. io1.
Comparativo de custo de volumes SSD
Veja alguns exemplos extraídos da tabela:
Em um volume de 1.000 GB, você obtém 12.000 IOPS sustentados no gp3. No gp2, são os mesmos 12.000 IOPS, mas só em bursts limitados — o IOPS sustentado fica em apenas 3.000. Os dois custam os mesmos US$ 115. Já no io1 PIOPS, configurado com os mesmos 12.000 IOPS, a conta sobe para US$ 425!
Para um volume de 5.000 GB, o gp2 entrega 15.000 IOPS por US$ 525. Pelo mesmo preço, o gp3 entrega só 12.000 IOPS (dá para pagar mais e ter mais). O io1 PIOPS sai bem mais caro: US$ 2.125.
Striping de disco no RDS
Todos os engines do RDS (com exceção do MS SQL Server) fazem striping em 4 volumes a partir de um tamanho mínimo. Por isso, tanto o gp2 quanto o gp3 entregam IOPS e throughput maiores do que normalmente se esperaria, como mostrado acima.
Detalhes do striping:
- MariaDB, MySQL e PostgreSQL fazem striping em volumes acima de 400 GB
- Oracle faz striping acima de 200 GB
- Aumentar o tamanho de um volume existente a ponto de disparar o striping (por exemplo, > 400 GB) pode causar um aumento expressivo de IOPS e latência por várias horas durante a alteração.
Consulte a AWS para detalhes sobre tipo e tamanho de DB [3].
Então, qual tipo de armazenamento usar?
Em quase todos os casos, a escolha padrão deve ser o gp3. No passado, mesmo para necessidades baixas de IOPS, a AWS recomendava o io1 pela latência baixa e consistente. Hoje, porém, tanto o io1 quanto o gp3 oferecem latência na casa de um dígito de milissegundo. A diferença é que o io1 garante isso em 99,9% do tempo, enquanto o gp3 garante "apenas" 99,0% do tempo. Como o gp3 chega a ser 73% mais barato que o io1 (assumindo que o io1 esteja configurado com o mesmo baseline do gp3), a decisão é simples.
Quando usar o io1:
- quando precisar de mais de 64.000 IOPS
- quando precisar de performance consistente acima de 99,0% do tempo
Mudando o tipo de volume em um DB em execução:
- Em geral, não há downtime nas mudanças entre io1, gp2 e gp3 [2]
- Mas você não pode fazer mais de uma alteração a cada 6 horas
Pegadinhas
- Crescer além de 400 GB dispara o striping e consome um volume considerável de IOPS no processo, o que pode comprometer bastante a latência. Por isso, se a expectativa é crescer logo, o ideal é já começar com 400 GB. O Oracle faz striping a partir de 200 GB, e o MS SQL Server nunca faz striping.
- O autoscaling de armazenamento do RDS pode reservar várias surpresas. Conheça bem todas as limitações [1]. Ele pode, por exemplo, disparar o striping de forma inesperada.
- Pode ser que a AWS esteja entregando mais IOPS do que você paga no seu volume gp2 atual. (Isso vale especialmente para workloads com vários anos de uso.) Assim, ao migrar para o gp3, você pode perder esses IOPS gratuitos e acabar com performance pior. (Dá para conferir no CloudWatch se você está recebendo IOPS acima do esperado.)
- Limitações de IOPS por tipo de instância: todas as instâncias RDS têm limites de banda e IOPS. Mesmo pagando por PIOPS, sua instância vai aplicar throttle se ela não for grande o suficiente. Os limites por tipo de instância estão na documentação do AWS EC2 [4].
Por exemplo:
c6g.4xlarge limitada a 20.000 IOPS c7g.4xlarge limitada a 20.000 IOPS, mas com burst de até 40.000
Conclusão
Escolha com cuidado o tipo de armazenamento das suas instâncias RDS. Em geral, dá para economizar bastante optando por gp3 em vez de io1, sem abrir mão de performance.
Referências:
[1] Gerenciando capacidade automaticamente com o autoscaling de armazenamento do Amazon RDS [2] Modificando uma instância de DB do Amazon RDS
[3] Armazenamento de instâncias de DB do Amazon RDS — Amazon RDS
[4] Instâncias otimizadas para Amazon EBS — Amazon Elastic Compute Cloud
Frequently asked
questions
Devo usar io1 + PIOPS?
- Só se precisar de 64.000 a 256.000 IOPS (ou throughput acima de 4.000 Mbps)
- Se precisar de consistência de I/O de 99,9% em vez dos 99% do gp2 ou gp3
- Vai custar 270% a mais que gp2/gp3
- Apesar de o console da AWS mostrar o io1 como padrão (em alguns templates de configuração), você pode trocar para gp3 (ou outro).
Faz sentido criar um novo DB no RDS com gp2 em algum cenário?
- Sim. Quando o tamanho de volume necessário for superior a 4.000 GB. Nesse caso, o IOPS do gp2 fica maior do que o baseline que o gp3 entregaria (veja a planilha acima). Se você precisar de mais IOPS do que o baseline do gp2, sai mais barato usar gp3 e contratar os IOPS extras.
Devo migrar de io1 para gp3 (ou gp2)?
- Sim! Se você precisa de menos de 64.000 IOPS, vale migrar para economizar até 73% (veja a planilha).
Devo migrar de gp2 para gp3?
Depende:
- Se está funcionando, não mexa. Não há economia de custo. A performance pode até piorar — veja as Pegadinhas abaixo.
- Se o volume for maior que 4.000 GB, o gp3 vai entregar menos IOPS (a menos que você pague por mais).
- Se sua workload precisa de mais IOPS do que você obtém hoje no gp2, migre para o gp3 e pague pelos IOPS adicionais.
- Atenção: como em qualquer alteração de DB, a boa prática é primeiro clonar o banco e testar a conversão. Confirme que o gp3 está entregando o IOPS e o throughput esperados.