Tengo un sitio web de comercio electrónico con alrededor de 30.000 usuarios diarios con más de 50.000 sesiones. Estamos utilizando la instancia RDS m5.xlarge. No enfrentamos ningún problema como tal en las operaciones de lectura o escritura en el día a día. Pero ocasionalmente nos enfrentamos a los siguientes desafíos:
- Algunos días, debido a rebajas o marketing agresivo, obtenemos más del doble de usuarios; en esos momentos, la CPU alcanza el 100 % varias veces durante el día.
- Muy ocasionalmente, mientras se realiza una escritura intensa, la lectura se vuelve lenta
Al observar esto, no puedo decidir si debo ampliar aún más verticalmente la instancia de RDS o activar una réplica de lectura. Dos puntos que quiero considerar al tomar esta decisión:
- ¿Tener una réplica de lectura me ayudará a eliminar la necesidad de espaciar aún más la base de datos verticalmente en los días de mucho tráfico?
- ¿Puedo reducir o mantener el costo igual con una réplica de lectura y al mismo tiempo lograr una mayor escalabilidad?
En promedio, tengo el siguiente uso en la instancia m5.xlarge:
- Uso de CPU 40%
- Conexiones de base de datos 100
- RAM 6GB usados
- 125 Escribir IOPS
- 3 Leer IOPS
Parece ser un uso muy bajo, excepto la CPU. ¿Es la réplica de lectura una forma de lograr una mayor escalabilidad sin aumentar el costo?
Respuesta1
Parece que lo que necesita es un RDS de escalado automático, que desafortunadamente no existe para computación.
Aumentar el tamaño de RDS
Si aumenta el tamaño de su instancia, pagará más las 24 horas del día, los 7 días de la semana. Es la solución más sencilla y debería reducir muchos de sus problemas. Si el costo no es un problema, este probablemente sea el mejor.
Leer réplica
La otra opción importante es una réplica de lectura. Tendría que modificar su software para usar una réplica de lectura, ya que tendrá un punto final diferente a la URL de la base de datos principal. Por ejemplo, podría enviar todas las escrituras a la base de datos principal y todas las lecturas a la réplica de lectura. La réplica de lectura puede estar ligeramente por detrás de las actualizaciones del maestro. Es posible que incluso pueda reducir el tamaño de la base de datos principal, pero deberá realizar una evaluación comparativa o ser conservador con su enfoque.
Podría considerar activar manualmente una réplica de lectura antes de cualquier evento importante esperado. Esto sería manual y llevaría algún tiempo, y su aplicación tendría que hacer frente a una base de datos que a veces, pero no siempre, está ahí.
Almacenamiento en caché
Dependiendo de sus patrones de acceso, el almacenamiento en caché de datos en Redis/Memcached podría reducir la carga de la base de datos lo suficiente como para que no necesite actualizarla. Por supuesto, esto depende de tener que leer los mismos datos más de una vez y de tener suficiente almacenamiento en caché.
Aurora
Podrías considerarAmazon Aurora para MySQL. Yo no lo he usado, pero está pensado para escalar muy bien, aunque es posible que cada transacción individual no sea tan rápida como el RDS estándar.
Optimización de la base de datos
Otra opción es observar qué está ocupando la capacidad de la base de datos y optimizar consultas o índices "costosos". Si tiene consultas simples y la carga es alta, es posible que eso no ayude.