Soluciones Efectivas para Escalar su Base de Datos en la Nube y Mejorar el Rendimiento de Aplicaciones en AWS

Pregunta

Está realizando un ejercicio de prueba de carga en su aplicación que está alojada en AWS.

Mientras prueba su instancia de base de datos MySQL de Amazon RDS, observa que su aplicación deja de responder cuando alcanza el 100 % de utilización de la CPU.

Su aplicación tiene muchas lecturas.

¿Qué métodos ayudarían a escalar su nivel de datos para satisfacer las necesidades de la aplicación? (Seleccione tres)

Respuestas

R. Agregue réplicas de lectura de bases de datos de Amazon RDS y haga que su aplicación les dirija consultas de lectura.

B. Agregue su instancia de base de datos de Amazon RDS a Storage Auto Scaling y establezca el límite de almacenamiento máximo deseado.

C. Utilice una cola de Amazon SQS para acelerar los datos que van a la instancia de base de datos de Amazon RDS.

D. Usar ElastiCache para almacenar en caché las consultas comunes de su Amazon RDS D.

E. Fragmente su conjunto de datos entre varias instancias de base de datos de Amazon RDS.

F. Habilite Multi-AZ para su instancia de base de datos de Amazon RDS.

Respuesta Correcta

A.BCDEF

Respuestas correctas: A, D y E.

Las réplicas de lectura de Amazon RDS proporcionan un rendimiento y una durabilidad mejorados para las instancias de base de datos (DB).

Esta función de replicación facilita el escalado horizontal elástico más allá de las limitaciones de capacidad de una única instancia de base de datos para cargas de trabajo de base de datos con muchas lecturas.

Puede crear una o más réplicas de una instancia de base de datos de origen dada y servir tráfico de lectura de aplicaciones de gran volumen desde múltiples copias de sus datos, aumentando así el rendimiento de lectura agregado.

Para obtener más información sobre las réplicas de lectura, consulte el siguiente enlace.

https://aws.amazon.com/rds/details/read-replicas/

La fragmentación es un concepto común para dividir datos en varias tablas de una base de datos.

Consideremos el siguiente ejemplo.

Fragmentos de aplicación.

En este ejemplo, asumimos que nuestra aplicación actualmente no tiene suficiente carga para necesitar un fragmento de aplicación para cada categoría, pero queremos planificar el futuro teniendo en cuenta el crecimiento.

Para facilitar el crecimiento futuro, utilizamos fragmentos de aplicaciones.

Entonces, nuestro código de aplicación actuará como si tuviera siete fragmentos, pero Hibernate asignará esos siete fragmentos a una cantidad menor de fragmentos de aplicación.

Cada fragmento de aplicación se asignará a una instancia de base de datos MySQL.

Mediante el uso de este mapeo, podemos distribuir la carga para que se adapte mejor a nuestras necesidades.

Para nuestra aplicación, suponga que los deportes y el entretenimiento generan tanta carga como las otras cinco categorías combinadas.

Estas dos categorías se asignarán a un fragmento de aplicación y las otras cinco categorías se asignarán al otro fragmento de aplicación.

Los dos fragmentos de aplicación se asignarán de la siguiente manera.

Para obtener más información sobre la fragmentación, consulte el siguiente enlace.

https://forums.aws.amazon.com/thread.jspa?messageID=203052

Amazon ElastiCache es un servicio web que facilita la implementación, el funcionamiento y el escalado de un almacenamiento de datos en memoria o caché en la nube.

El servicio mejora el rendimiento de las aplicaciones web al permitirle recuperar información de almacenes de datos en memoria rápidos y administrados en lugar de depender completamente de bases de datos más lentas basadas en disco.

Para obtener más información sobre ElastiCache, consulte el siguiente enlace.

https://aws.amazon.com/elasticache/

La opción B es incorrecta porque no es una forma ideal de escalar una base de datos.

Amazon RDS Auto Scaling es escalar la capacidad de almacenamiento.

Si se alcanza el umbral de capacidad de almacenamiento, la capacidad se escalará a través de Auto Scaling.

RDS Auto Scaling no busca el umbral de utilización de la CPU.

Por lo tanto, no puede ser una solución para los cuellos de botella para leer bases de datos pesadas.

La opción C no es una opción ideal.

Porque nuestra aplicación tiene muchas lecturas y esta es la causa del problema que enfrentamos con el RDS.

Entonces, para este problema, la creación de réplicas de lectura, la implementación de caché elástica y la fragmentación del conjunto de datos son las formas en que podemos abordar este problema.

Pero si tenemos demasiadas solicitudes PUT para la base de datos que está causando el problema, podemos crear una cola SQS y almacenar estas solicitudes PUT en la cola de mensajes y luego procesarlas en consecuencia.

La opción F no es válida porque la función Multi-AZ es solo una opción de conmutación por error.