Tenho um site de comércio eletrônico com cerca de 30.000 usuários diários com mais de 50.000 sessões. Estamos usando a instância RDS m5.xlarge. Não enfrentamos nenhum problema nas operações de leitura ou gravação no dia a dia. Mas ocasionalmente enfrentamos os seguintes desafios:
- Em alguns dias devido a vendas ou marketing agressivo conseguimos mais que o dobro de usuários, nesses momentos temos CPU atingindo 100% várias vezes durante o dia
- Muito Ocasionalmente, enquanto alguma gravação pesada está em andamento, a leitura se torna lenta
Olhando para isso, não sou capaz de julgar se devo aumentar verticalmente a instância do RDS ou aumentar uma réplica de leitura. Dois pontos que quero considerar ao tomar esta decisão:
- Ter uma réplica de leitura me ajudará a remover a necessidade de espaçar ainda mais o banco de dados verticalmente em dias de alto tráfego?
- Posso diminuir ou manter o custo igual com uma réplica de leitura e, ao mesmo tempo, obter mais escalabilidade.
Em média, tenho o seguinte uso na instância m5.xlarge:
- Uso de CPU 40%
- Conexões de banco de dados 100
- RAM 6 GB usados
- 125 Gravar IOPS
- 3 Leia IOPS
Parece ter um uso muito baixo, exceto CPU. A réplica de leitura é uma maneira de obter maior escalabilidade sem aumentar o custo?
Responder1
Parece que você precisa é de um RDS com escalonamento automático, que infelizmente não existe para computação.
Aumentar o tamanho do RDS
Se você aumentar o tamanho da sua instância, pagará mais 24 horas por dia, 7 dias por semana. É a solução mais simples e deve reduzir muitos dos seus problemas. Se o custo não for um problema, este é provavelmente o melhor problema.
Ler réplica
A outra opção principal é uma réplica de leitura. Você teria que modificar seu software para usar uma réplica de leitura, pois ela teria um endpoint diferente do URL do banco de dados principal. Você pode, por exemplo, enviar todas as gravações para o banco de dados principal e todas as leituras para a réplica de leitura. A réplica de leitura pode estar um pouco atrasada em relação às atualizações do mestre. Você pode até conseguir reduzir o tamanho do banco de dados principal - mas precisará fazer um benchmark ou ser conservador em sua abordagem.
Você pode considerar ter uma réplica de leitura ativada manualmente antes de qualquer evento importante esperado. Isso seria manual e levaria algum tempo, e seu aplicativo teria que lidar com um banco de dados que às vezes está presente, mas nem sempre.
Cache
Dependendo dos seus padrões de acesso, armazenar dados em cache no Redis/Memcached pode reduzir potencialmente a carga do banco de dados o suficiente para que você não precise atualizar seu banco de dados. É claro que isso depende da necessidade de ler os mesmos dados mais de uma vez e de ter armazenamento em cache suficiente.
aurora
Você poderia considerarAmazon Aurora para MySQL. Eu não o usei, mas foi projetado para escalar muito bem - embora cada transação individual possa não ser tão rápida quanto o RDS padrão.
Otimização de banco de dados
Outra opção é observar o que está consumindo a capacidade do banco de dados e otimizando consultas ou índices "caros". Se você tiver consultas simples e apenas uma carga alta, isso pode não ajudar.