Devora Cloud · Blog
Escalabilidade, load balance e failover: como seu site aguenta picos
A diferença entre failover, réplicas de load balance e autoescala na Devora Cloud, quanto custam e o que ajustar no código para o seu site aguentar picos de acesso.
Uma campanha que viraliza, a Black Friday, a menção de um influenciador: o pico de acessos costuma chegar sem aviso. Se o site depende de um único servidor, duas coisas podem dar errado ao mesmo tempo: a máquina não dá conta do volume ou simplesmente para.
Escalabilidade é a capacidade de atender mais gente sem cair. Na Devora Cloud ela se apoia em três peças diferentes — failover, réplicas de load balance e autoescala — e vale entender o papel de cada uma antes de contratar qualquer coisa.
Failover: o plano B que já vem em todo projeto
Todo projeto na Devora Cloud, inclusive no plano Hobby, tem uma réplica de failover. Ela fica parada em outro servidor, pronta para entrar. Se a instância principal falhar, a réplica de failover liga e assume o atendimento. Quando a principal volta, a réplica de failover é desligada de novo.
Como fica parada no dia a dia, essa réplica não divide tráfego nem aumenta a capacidade. O papel dela é outro: reduzir o tempo fora do ar quando um servidor tem problema.
- Incluída em todos os planos, sem custo extra.
- Fica em outro servidor, não na mesma máquina da principal.
- Liga só quando a principal falha e desliga quando ela volta.
Load balance: várias cópias dividindo o tráfego
Em todos os planos você pode adicionar réplicas de escala, cobradas por hora. Cada réplica é uma cópia ligada da sua aplicação, com o mesmo tamanho do plano, e o balanceador distribui as requisições entre as cópias saudáveis. Se uma delas tiver problema, as outras continuam atendendo.
Todas as réplicas usam o mesmo banco de dados e o mesmo S3 do projeto. Ou seja: você ganha capacidade de processamento, não um banco novo.
- Hobby: até 2 cópias ligadas ao mesmo tempo.
- Pro: até 3 cópias ligadas ao mesmo tempo.
- Enterprise: até 5 cópias ligadas ao mesmo tempo.
- Primeira réplica extra: preço cheio do plano, por hora.
- Load balance: preço cheio por hora em cada cópia; na autoescala, da próxima cópia extra em diante, 10% de desconto.
- Cobrança por hora, só enquanto a réplica estiver ligada.
Um exemplo com o plano Pro (US$ 20 por mês): a primeira réplica custa o equivalente a US$ 17 se ficar ligada o mês inteiro, e cada réplica seguinte, US$ 15. Se você liga uma réplica só durante uma campanha de três dias, paga apenas as horas desses três dias.
Autoescala: réplicas que ligam quando a CPU sobe
A autoescala está disponível em todos os planos e é cobrada por hora enquanto as cópias extras rodam. Você define um limite de uso de CPU; quando a aplicação passa desse limite, a plataforma liga mais uma réplica, até o máximo permitido pelo plano. Quando a demanda cai, as cópias extras deixam de ser necessárias e são desligadas.
É a opção certa para tráfego irregular: você não mantém cópias ligadas de madrugada e não precisa correr para adicionar capacidade quando o pico chega.
Failover, load balance ou autoescala?
| Failover | Réplicas de load balance | Autoescala | |
|---|---|---|---|
| Para que serve | Continuar no ar se a principal falhar | Dividir o tráfego entre cópias | Ligar cópias quando a CPU sobe |
| Planos | Todos | Todos | Todos |
| No dia a dia | Parada, em outro servidor | Ligadas, recebendo tráfego | Liga e desliga conforme a CPU |
| Custo | Incluído | Preço cheio por hora, sem desconto | Por hora, só enquanto o clone roda: 1ª pelo preço cheio, 10% off da próxima em diante |
Na prática, as três se somam: o failover protege contra a queda de um servidor, as réplicas dão fôlego constante e a autoescala cobre os picos.
O que precisa mudar no seu código
Réplicas só funcionam bem se a aplicação não guardar estado na própria máquina. Cada requisição pode cair em uma cópia diferente, então:
- Guarde as sessões de login no Redis (ou no banco), não na memória do processo. Assim o usuário continua logado em qualquer réplica.
- Envie os arquivos dos usuários para o S3, nunca para o disco do contêiner. O disco não é compartilhado entre réplicas.
- Coordene tarefas agendadas (cron, filas) para que não rodem duplicadas em cada cópia.
- Mantenha a configuração em variáveis de ambiente, iguais para todas as réplicas.
PostgreSQL ou Redis estão incluídos em todos os planos (Hobby 1 banco, Pro 2, Enterprise 4), e o S3 privado de cada projeto já vem pronto para receber os arquivos.
Servidores AMD EPYC: o tamanho de cada cópia importa
As aplicações rodam em servidores com processadores AMD EPYC, nos Estados Unidos. Cada réplica tem os mesmos limites de CPU e memória do plano: adicionar réplicas aumenta a capacidade total, mas não deixa uma cópia individual mais potente.
Por isso a ordem costuma ser: primeiro confirme que o código está eficiente, depois escolha o plano com o tamanho certo por cópia e só então multiplique as cópias. Se a aplicação usa muita memória por requisição, subir de plano resolve melhor do que somar réplicas pequenas.
Para visitantes no Brasil, o cache CDN próprio da Devora acelera a entrega de conteúdo, mas não executa a aplicação: o processamento continua nos servidores dos Estados Unidos.
Perguntas frequentes
O plano Hobby tem load balance?
Sim. O Hobby tem o failover incluso e também load balance e autoescala, cobrados por hora, com até 2 cópias ligadas de 0.5 vCPU e 512 MB.
Cada réplica tem um banco de dados separado?
Não. Todas as réplicas usam o mesmo banco e o mesmo S3 do projeto. Réplicas da aplicação não copiam o banco.
Pago pela réplica de failover?
Não. Ela está incluída em todos os planos, do Hobby ao Enterprise.
Como sei se preciso de réplicas ou de um plano maior?
Olhe as métricas. CPU alta por muito tempo pede mais cópias ou mais vCPU; memória no limite e reinícios pedem um plano com mais RAM. Explicamos como ler esses sinais no guia sobre site lento.