Devora Cloud · Blog
Escalabilidad, balanceo de carga y failover: cómo tu sitio aguanta los picos
La diferencia entre failover, réplicas de balanceo de carga y autoescalado en Devora Cloud, cuánto cuestan y qué ajustar en el código para que tu sitio aguante picos de tráfico.
Una campaña que se vuelve viral, el Black Friday, la mención de un influencer: los picos de tráfico rara vez avisan. Si tu sitio depende de un único servidor, pueden fallar dos cosas a la vez: que la máquina no dé abasto o que simplemente se caiga.
La escalabilidad es la capacidad de atender a más gente sin caerse. En Devora Cloud se apoya en tres piezas distintas — failover, réplicas de balanceo de carga y autoescalado — y conviene entender cada una antes de contratar nada.
Failover: el plan B que ya incluye cada proyecto
Todo proyecto en Devora Cloud, también en el plan Hobby, tiene una réplica de failover. Está detenida en otro servidor, lista para entrar. Si la instancia principal falla, la réplica de failover arranca y toma el relevo. Cuando la principal vuelve, la réplica de failover se detiene otra vez.
Como está detenida en el día a día, esta réplica no reparte tráfico ni suma capacidad. Su función es otra: reducir el tiempo fuera de línea cuando un servidor tiene problemas.
- Incluida en todos los planes, sin coste extra.
- Está en otro servidor, no en la misma máquina que la principal.
- Arranca solo cuando la principal falla y se detiene cuando vuelve.
Balanceo de carga: varias copias repartiendo el tráfico
En todos los planes puedes añadir réplicas de escala, cobradas por hora. Cada réplica es una copia encendida de tu aplicación, del mismo tamaño que el plan, y el balanceador reparte las peticiones entre las copias sanas. Si una tiene problemas, las demás siguen atendiendo.
Todas las réplicas usan la misma base de datos y el mismo S3 del proyecto. Es decir, ganas capacidad de procesamiento, no una base nueva.
- Hobby: hasta 2 copias encendidas a la vez.
- Pro: hasta 3 copias encendidas a la vez.
- Enterprise: hasta 5 copias encendidas a la vez.
- Primera réplica extra: precio completo del plan, por hora.
- Load balance: precio completo por hora en cada copia; en la autoescala, desde la siguiente copia extra, 10% de descuento.
- Se factura por hora, solo mientras la réplica está encendida.
Un ejemplo con el plan Pro (US$ 20 al mes): la primera réplica cuesta el equivalente a US$ 17 si está encendida todo el mes, y cada réplica siguiente, US$ 15. Si enciendes una réplica solo durante una campaña de tres días, pagas únicamente esas horas.
Autoescalado: réplicas que arrancan cuando sube la CPU
El autoescalado está disponible en todos los planes y se cobra por hora mientras las copias extra funcionan. Defines un umbral de uso de CPU; cuando la aplicación lo supera, la plataforma enciende otra réplica, hasta el máximo que permite tu plan. Cuando la demanda baja, las copias extra dejan de hacer falta y se detienen.
Es la opción adecuada para tráfico irregular: no mantienes copias encendidas de madrugada y no tienes que correr a añadir capacidad cuando llega el pico.
¿Failover, balanceo de carga o autoescalado?
| Failover | Réplicas de balanceo | Autoescalado | |
|---|---|---|---|
| Para qué sirve | Seguir en línea si falla la principal | Repartir el tráfico entre copias | Encender copias cuando sube la CPU |
| Planes | Todos | Todos | Todos |
| En el día a día | Detenida, en otro servidor | Encendidas, recibiendo tráfico | Se enciende y apaga según la CPU |
| Coste | Incluido | Precio completo por hora, sin descuento | Por hora, solo mientras el clon funciona: la 1.ª a precio completo, 10% menos desde la siguiente |
En la práctica, las tres se suman: el failover protege ante la caída de un servidor, las réplicas dan margen constante y el autoescalado cubre los picos.
Qué cambiar en tu código
Las réplicas solo funcionan bien si la aplicación no guarda estado en su propia máquina. Cada petición puede caer en una copia distinta, así que:
- Guarda las sesiones de inicio de sesión en Redis (o en la base), no en la memoria del proceso, para que el usuario siga conectado en cualquier réplica.
- Sube los archivos de los usuarios a S3, nunca al disco del contenedor. El disco no se comparte entre réplicas.
- Coordina las tareas programadas (cron, colas) para que no se ejecuten una vez por copia.
- Mantén la configuración en variables de entorno, iguales para todas las réplicas.
PostgreSQL o Redis vienen incluidos en todos los planes (Hobby 1 base, Pro 2, Enterprise 4), y el S3 privado de cada proyecto ya está listo para recibir archivos.
Servidores AMD EPYC: el tamaño de cada copia importa
Las aplicaciones se ejecutan en servidores con procesadores AMD EPYC en Estados Unidos. Cada réplica tiene los mismos límites de CPU y memoria que el plan: añadir réplicas aumenta la capacidad total, pero no hace más potente a una copia individual.
Por eso el orden habitual es: primero asegúrate de que el código es eficiente, después elige el plan con el tamaño adecuado por copia y solo entonces multiplica las copias. Si la app usa mucha memoria por petición, subir de plan ayuda más que sumar réplicas pequeñas.
Para los visitantes en Brasil, la caché CDN propia de Devora acelera la entrega de contenido, pero no ejecuta la aplicación: el procesamiento sigue en los servidores de Estados Unidos.
Preguntas frecuentes
¿El plan Hobby tiene balanceo de carga?
Sí. Hobby tiene el failover incluido y también balanceo de carga y autoescalado, cobrados por hora, con hasta 2 copias encendidas de 0.5 vCPU y 512 MB.
¿Cada réplica tiene su propia base de datos?
No. Todas las réplicas usan la misma base y el mismo S3 del proyecto. Las réplicas de la aplicación no copian la base.
¿Pago por la réplica de failover?
No. Está incluida en todos los planes, de Hobby a Enterprise.
¿Cómo sé si necesito réplicas o un plan mayor?
Mira las métricas. CPU alta durante mucho tiempo pide más copias o más vCPU; memoria al límite y reinicios piden un plan con más RAM. En la guía sobre sitios lentos explicamos cómo leer esas señales.