Escalando vertical y horizontalmente su instancia Amazon RDS

Por Marie Yap, Arquitecta de Soluciones en AWS

Como un servicio administrado, Amazon RDS se encarga del escalamiento de sus instancias de bases de datos relacionales para que sus bases de datos puedan mantenerse al día con las crecientes demandas de su aplicación o aplicaciones.

En este blog vamos a echar un vistazo a cómo podemos escalar vertical y horizontalmente una instancia de RDS. RDS puede escalar verticalmente para satisfacer las crecientes demandas de una aplicación que utiliza un número similar o igual de lecturas tanto como de escrituras. O bien, puede escalar horizontalmente para aplicaciones con acceso mayoritariamente de lectura.

Escalando Verticalmente

Para controlar una carga de trabajo mayor en la base de datos, puede escalar verticalmente su instancia RDS de base de datos con solo pulsar un botón. Actualmente hay más de 74 (y continua aumentando, para más detalles por favor consulte https://aws.amazon.com/rds/instance-types/ ) tamaños de instancia entre los que puede elegir al cambiar el tamaño de la instancia de RDS MySQL, PostgreSQL, MariaDB, Oracle o Microsoft SQL Server. Amazon Aurora tiene 9 (y también continua aumentando, para más detalles por favor consulte https://aws.amazon.com/rds/instance-types/ ) tamaños de instancia optimizados para memoria de donde elegir. La amplia selección de tipos de instancias le permite elegir la mejor configuración y costo para su servidor de bases de datos

A continuación se muestran algunas consideraciones que se deben tener en cuenta al escalar verticalmente una instancia RDS:

• Antes de escalar, asegúrese de que tiene las licencias correctas para los motores de bases de datos comerciales (SQL Server, Oracle), especialmente si trae su propia licencia (BYOL). Una cosa importante a destacar es que para los motores de bases de datos comerciales, usted está restringido por la licencia, que generalmente está vinculada al número de núcleos de CPU incluidos en la instancia RDS.
• Determine cuándo desea aplicar el cambio. Tiene la opción de aplicar el cambio inmediatamente o durante la ventana de mantenimiento especificada para la instancia.
• El almacenamiento y el tipo de instancia están desacoplados, son independientes uno del otro. Al escalar la instancia de base de datos hacia arriba o hacia abajo, el tamaño de almacenamiento sigue siendo el mismo y no se ve afectado por el cambio. Puede modificar por separado la instancia de base de datos para aumentar el espacio de almacenamiento asignado o mejorar el rendimiento cambiando el tipo de almacenamiento. Por ejemplo, SSD de uso general (gp2) a SSD con IOPS aprovisionados (io1).
• El tiempo fuera de línea es mínimo cuando se escala verticalmente en un ambiente configurado con Multi-AZ porque la base de datos secundaria (standby) se actualiza primero y, a continuación, se producirá un failover a la base de datos de nuevo tamaño que pasa a ser la nueva base de datos primaria. Una instancia Single-AZ no estará disponible durante toda la operación de escalado.

Para cambiar el tipo de instancia, elija Modify (Modificar) en el menú Instance Actions (Acciones de instancia) de la consola de RDS.

A continuación, elija la nueva clase de instancia de base de datos

Por último, decida si desea aplicar el cambio inmediatamente o no. Para aplicar el cambio inmediatamente, active la casilla Apply Immediately (Aplicar Inmediatamente) en la parte inferior de la página Modify (Modificar). Si no aplica el cambio inmediatamente, el cambio se programará para que se produzca durante la ventana de mantenimiento preferida que ha definido.

Escalando Horizontalmente

Además de escalar verticalmente la base de datos primaria, también puede mejorar el rendimiento de una base de datos con acceso mayoritariamente de lectura mediante el uso de réplicas de lectura para escalar horizontalmente la base de datos. Oracle, SQL Server, MySQL, PostgreSQL y MariaDB de RDS pueden tener hasta 5 réplicas de lectura, y Amazon Aurora puede tener hasta 15 réplicas de lectura.

Las réplicas de lectura permiten crear copias sólo lectura que se sincronizan con la base de datos primaria. También puede colocar la réplica de lectura en una región de AWS diferente más cerca de los usuarios para mejorar el rendimiento. Además, puede usar réplicas de lectura para aumentar la disponibilidad de la base de datos mediante la promoción de una réplica de lectura a servidor principal para una recuperación más rápida en caso de desastre. Sin embargo, las réplicas de lectura no reemplazan las capacidades de alta disponibilidad y failover automático por cualquier falla que proporciona la opción Multi-AZ de RDS.

Actualmente, las réplicas de lectura RDS soportan balanceo de carga transparente de consultas o conexiones. Cada réplica tiene asociada un nombre de Dominio (DNS name) único para que las aplicaciones puedan implementar balanceo de cargas de trabajo conectándose al nombre de Dominio adecuado. Analicemos las opciones sobre cómo podemos visibilizar de manera transparente las réplicas de lectura RDS a las aplicaciones.

Si su aplicación está utilizando el controlador (driver) nativo de MySQL, hay conectores de MySQL que le permiten realizar la división de solicitudes lectura/escritura y el balanceo automático de cargas de trabajo de solo lectura sin mayores cambios en su aplicación. Por ejemplo, si tiene una aplicación PHP, puede usar el complemento (plug-in) de replicación y balanceo de cargas disponible en el controlador nativo de MySQL

Además de utilizar un conector de MySQL, puede agregar un balanceador de cargas de trabajo entre los servidores de aplicaciones y de bases de datos. Realice este cambio para tener un único punto de conexión (DNS endpoint) para la base de datos presentado a la aplicación. Este enfoque permite un ambiente más dinámico en el que puede agregar o quitar réplicas de lectura de forma transparente detrás del balanceador de cargas de trabajo sin actualizar constantemente la cadena de conexión de base de datos en la aplicación. También puede añadir una revisión de salud para el servidor utilizando una política de distribución de cargas de trabajo a través de scripts desarrollados con ese propósito.

Como se muestra en el diagrama anterior, puede utilizar un balanceador de cargas de trabajo nivel 4 (transporte) en conjunción con el conector MySQL. Actualmente, el servicio de balanceo de cargas de trabajo ofrecido por AWS Elastic Load Balancing (ELB) no admite el direccionamiento automático del tráfico a las instancias RDS. Por lo tanto, es posible que desee considerar otras opciones como HAProxy, que es un balanceador de cargas de trabajo basado en software de código abierto que muchos clientes usan. En esta solución, puede configurar HAProxy para escuchar en un puerto para sentencias SQL de lectura y otro puerto para sentencias SQL de escritura.

Otra opción es usar un balanceador de cargas de trabajo compatible con SQL nivel 7 (aplicación), que le permite reenviar consultas a las bases de datos mediante reglas más complejas. Este tipo de balanceador de cargas de trabajo tiene una capacidad más sofisticada de comprender cómo realizar correctamente las divisiones de lectura/escritura en solicitudes con múltiples instrucciones que un conector de MySQL. Esta solución controla los problemas de escalado horizontal en un entorno de base de datos distribuidas, por lo que no es necesario controlar el escalado horizontal dentro de la aplicación. En consecuencia, muy pocos o ningún cambio en la propia aplicación son requeridos. Para lograr esto hay varias soluciones de código abierto (como MaxScale, ProxySQL y MySQL Proxy) y también soluciones comerciales, algunas de las cuales se pueden encontrar en AWS Marketplace.

En el caso de RDS SQL Server, una solución equivalente a la descrita anteriormente se puede implementar fácilmente utilizando un Amazon Route 53 Hosted Zone, siguiendo las instrucciones incluidas en este artículo.

Conclusión

En resumen, se puede escalar vertical o horizontalmente la configuración de RDS para satisfacer las crecientes necesidades de las aplicaciones. RDS se encarga del trabajo pesado en el escalado de la base de datos para que usted pueda centrarse más en su aplicación o aplicaciones.

Este artículo fue traducido del Blog de AWS en Inglés.

Sobre la autora

Marie Yap es una arquitecta de soluciones en Amazon Web Services.

Sobre el traductor

Camilo León es un arquitecto de soluciones senior, especialista en SQL Server.

Conozca más contenidos sobre base de datos en la página de sesiones bajo demanda. Acceda >