Consideraciones al migrar bases de datos Amazon RDS y Amazon Aurora a Graviton.

Amazon Relational Database Service (Amazon RDS) y Amazon Aurora soportan una gran variedad de tipos de instancias para que pueda escalar sus cargas de trabajo de bases de datos en función de sus necesidades ( consulte las clases de instancias de base de datos de Amazon RDS y las clases de instancias de base de datos de Aurora, respectivamente). En 2020, AWS anunció dos tipos de instancias Amazon M6g y R6g para Amazon RDS y R6g para Aurora con procesadores AWS Graviton2. Durante los meses de Abril y Mayo de 2023, AWS anunció un nuevo tipo de instancias M7g y R7g para Amazon RDS y R7g para Amazon Aurora respectivamente, con procesadores AWS Graviton3, que ofrecen una mejor relación coste-rendimiento en comparación con sus homólogos x86 y Graviton2.Los procesadores Graviton están diseñados a medida por AWS con núcleos Arm Neoverse de 64 bits y ofrecen varias optimizaciones en comparación con los procesadores AWS Graviton de generaciones anteriores. Puede lanzar nuevas instancias de bases de datos aprovechando AWS Graviton mediante la consola de Amazon RDS o la interfaz de línea de comandos de AWS (AWS CLI). Puede mover bases de datos Multi-AZ a tipos de instancia Graviton con un tiempo de inactividad mínimo, suspendiendo las operaciones de lectura/escritura en el proceso de conmutación por error (Failover).En esta publicación, analizamos las consideraciones clave a la hora de modificar las instancias de base de datos RDS y Aurora existentes para convertirlas en tipos de instancias Graviton2. Analizamos los requisitos previos y las diferentes estrategias que puede adoptar para reducir el tiempo de inactividad.

¿Por qué pasar a Graviton?

Los siguientes son algunos de los motivos para utilizar instancias del tipo Graviton para Amazon RDS y Amazon Aurora:

Las instancias del tipo Graviton2 ofrecen una mejora de la relación precio/rendimiento de las bases de datos de código abierto de RDS de hasta un 52%, según el motor de la base de datos, la versión y la carga de trabajo. También proporcionan una mejora de la relación precio/rendimiento de Aurora de hasta un 35%, según el tamaño de la base de datos.
Las instancias de Graviton2 ofrecen siete veces más rendimiento, cuatro veces más núcleos de procesamiento, caché por núcleo dos veces más grandes, memoria cinco veces más rápida y un rendimiento de punto flotante por núcleo dos veces más rápido que los procesadores AWS Graviton de primera generación.
Los procesadores Graviton2 cuentan con memoria DDR4 totalmente cifrada y un rendimiento de cifrado por núcleo un 50% más rápido. Los procesadores Graviton3 cuentan con memoria DDR5, lo que proporciona un 50% más de ancho de banda de memoria en comparación con DDR4.
Las instancias basadas en Graviton utilizan hasta un 60% menos de energía para el mismo rendimiento que las instancias de EC2 comparables.
No se requieren cambios de portabilidad, ni de código para migrar de instancias Intel a Graviton en Amazon RDS y Aurora.

Descripción general de la solución

Los pasos que debe seguir para modificar el tipo de instancia son similares para Amazon RDS (Amazon RDS para MySQL, Amazon RDS para PostgreSQL, Amazon RDS para MariaDB) y Aurora (Aurora MySQL y Aurora PostgreSQL).

Para esta publicación, consideremos un caso de uso en el que tenemos un clúster de bases de datos Aurora Multi-AZ en la versión 9.6.16 de PostgreSQL con tres instancias: un escritor y dos lectores.

Como práctica recomendada general, se recomienda probar el proceso en un no productivo. Puede empezar por utilizar un respaldo de la base de datos de producción y restaurarlo en una instancia en su entorno no productivo, que tenga una configuración similar (clase de instancia, configuración de grupos de parámetros, cifrado). A continuación, modifique su instancia a Graviton y realice pruebas de validación para asegurarse de que todo esté configurado y funcionando según sus expectativas.

Los pasos de alto nivel del proceso son los siguientes:

Actualice la base de datos (si es necesario):
1. Determine si la versión actual de la base de datos cumple con la versión mínima requerida para pasar a Graviton.
2. Actualice el motor de base de datos a la versión mínima requerida.
Modifique los tipos de instancias:
1. Determine su estrategia y el orden en que modificará las instancias.
2. Modifique la clase de instancia de sus instancias actuales por la instancia de tipo Graviton correspondiente.
Valide y confirme que la aplicación funciona correctamente.
Reverse, si es necesario.

Actualizar la base de datos

Este es un paso opcional y solo es necesario si la versión actual de la base de datos no cumple con la versión mínima requerida para utilizar instancias del tipo Graviton, por lo que empezamos por determinar si necesitamos actualizar la versión de la base de datos.

Determine la versión de la base de datos

La siguiente tabla muestra las versiones compatibles de Graviton2/3 a partir de esta publicación:

	MySQL	PostgreSQL	María DB
Amazon RDS, Graviton2	8.0.17 y superior	13, 12.3 y superior	10.5 y 10.4.13 y versiones posteriores
Amazon Aurora, Graviton2	2.09.2 y superior	12.4 y superior, 11.9 y superior	—-
Amazon RDS, Graviton3	8.0.28 y superior	13.4 y superior, 14.5 y superior	10.4.26 y superior, 10.5.17 y superior, 10.6.10 y superior
Amazon Aurora, Graviton3	3.03.1 y superior	13.10 y superior, 14.7 y superior, 15.2 y superior	—-

Para nuestro caso de uso en esta publicación, utilizamos la versión 9.6.16 de Aurora PostgreSQL, que es inferior a la versión necesaria para pasar ausar una instancia de tipo Graviton2.

Para obtener las actualizaciones más recientes, consulte “Motores de base de datos compatibles para clases de instancias de base de datos (Amazon RDS)” y “Motores de base de datos compatibles para clases de instancias de base de datos (Aurora)”.

Si su base de datos no tiene una versión compatible con Graviton2, debe actualizarla a una versión compatible. Para obtener una lista de todas las actualizaciones válidas para la versión actual, utilice el comando de CLI describe-db-engine-versions.

Para Linux, macOS o Unix, utilice el siguiente comando:

aws rds describe-db-engine-versions  --engine aurora-postgresql  --engine-version 9.6.16 --query 'DBEngineVersions[].ValidUpgradeTarget[?IsMajorVersionUpgrade == `true`]'

Para Windows, utilice el siguiente comando:

aws rds describe-db-engine-versions  --engine aurora-postgresql  --engine-version 9.6.16 --query "DBEngineVersions[].ValidUpgradeTarget[?IsMajorVersionUpgrade == `true`]"

La siguiente captura de pantalla muestra el resultado del comando anterior en un sistema operativo basado en Linux. Muestra el valor del arreglo ValidUpgradeTarget que contiene las versiones de posible actualización.

Si el valor isMajorVersionUpgrade es verdadero, puede realizar una actualización de la versión principal a la EngineVersion asociada. Si el arreglo se encuentra vacío, no puede realizar una actualización a la versión deseada. Primero debe actualizar a una versión secundaria que tenga una ruta de actualización a la versión de deseada.

Actualice la base de datos a la versión mínima requerida

En algunos casos, no existe una ruta de actualización directa desde la versión actual de la base de datos a una versión mínima de base de datos compatible con Graviton2. Para nuestro caso de uso en esta publicación, estamos en la versión 9.6.16 de Aurora PostgreSQL y la versión mínima admitida para Graviton2 es la 11.9. No hay una ruta de actualización directa de la 9.6 a la 11.9, por lo que primero tenemos que actualizar de la 9.6.16 a la 10.14 y solo después a la 11.9. Por lo tanto, este es un proceso de actualización de dos pasos.

Para Amazon RDS, puede seguir estos pasos para actualizar la versión del motor de base de datos:

Para Aurora, puede seguir estos pasos para actualizar la versión del motor de base de datos:

Durante el proceso tiene la opción de realizar una actualización in-place, lo que requiere tiempo de inactividad. Si desea minimizar el tiempo de inactividad, puede utilizar un enfoque alternativo ya sea utilizando una configuración Multi-AZ con conmutación por error de segundos o mediante el servicio AWS Database Migration Service (AWS DMS). Para obtener más información, consulte cómo lograr un tiempo de inactividad mínimo para actualizaciones de versiones en Amazon Aurora para PostgreSQL mediante AWS DMS.

Modificar las instancias

Para modificar las instancias, debe completar los siguientes pasos de alto nivel:

Determinar la estrategia y el orden en que se modificarán las instancias.
Modificar la clase de instancia actual por la instancia Graviton2 adecuada.

Determinar la estrategia

La estrategia que se elija para modificar los tipos de instancias depende de la configuración existente, ya sea Multi-AZ o réplicas de lectura.

En el caso de Amazon RDS con Multi-AZ, toda modificación de la instancia se realiza en la instancia secundaria, tras lo cual se realiza la conmutación por error. A continuación, los pasos de modificación se repiten en la nueva instancia secundaria (antigua primaria). La duración del tiempo de inactividad planificado se limita únicamente al tiempo de conmutación por error. Los tiempos de conmutación por error suelen ser de 60 a 120 segundos. Una instancia Single-AZ no está disponible durante la modificación del tipo de instancia.

En el caso de Aurora con una o más réplicas de Aurora, al modificar la instancia primaria, una réplica de Aurora pasa a ser la instancia primaria mientras la modificación continúa en la nueva réplica de Aurora (antigua primaria). Hay una interrupción breve que normalmente dura menos de 120 segundos. Para minimizar el tiempo de inactividad y el riesgo, puede modificar primero la instancia de la réplica de Aurora, comprobar que funciona según las expectativas y, a continuación, realizar la conmutación por error a la actual Graviton2. Dentro del clúster de Aurora, puede modificar las instancias a Graviton2 en el orden que sea adecuado para cada caso de uso.

También se puede combinar instancias de Graviton2 R6g e Intel R5 dentro del mismo clúster para la instancia primaria o para su réplica de lectura, lo que permitirá maximizar las mejoras de precio y rendimiento en función de los requisitos de la carga de trabajo.

Un cambio de tipo de instancia implica la reubicación de la instancia en otro host de hardware, lo que significa que no se mantiene la memoria caché del búfer. Por lo tanto, cuando se reinicia la base de datos de la instancia modificada, la memoria caché del búfer está inactiva y las consultas iniciales pueden tardar más.

Como práctica recomendada, se puede tomar un respaldo manual antes de la modificación para garantizar una restauración(rollback) sencilla. En el caso de Amazon RDS en una configuración Single-AZ, esto implica la suspensión de las operaciones de lectura/escritura durante el tiempo del respaldo, de unos segundos a unos minutos, según el tamaño. En una configuración Multi-AZ, no hay suspensión de las operaciones de lectura/escritura durante el respaldo. En el caso de Aurora, no se produce ningún impacto en el rendimiento ni se interrumpe el servicio de base de datos.

Es una buena idea planificar el cambio durante una ventana de mantenimiento de Amazon RDS. Puede considerarse la ventana de mantenimiento como una oportunidad para controlar cuándo se producen las modificaciones y los parches del software, en caso de que se soliciten o se requieran.

Para nuestro caso práctico en esta publicación, empezamos por mover una instancia réplica de lectura de Aurora a Graviton2 y, a continuación, ejecutamos las validaciones para asegurarnos de que funciona correctamente. Modificamos el tipo de instancia de la réplica de lectura a Graviton2, luego mediante conmutación por error promovemos la réplica de lectura a instancia primaria. El proceso de conmutación por error tarda unos segundos en completarse.

Modificar la clase de instancia

Empezamos por iniciar sesión en la consola de Amazon RDS. Como estaba previsto, modificamos primero la clase de instancia en una réplica de lectura.

1. En la consola de Amazon RDS, en el panel de navegación, seleccione Bases de dato.
2. Seleccione la instancia de lectura (para esta publicación, usamos auroralab-pgsql-node-3) y eligir Modificar.
3. Para el tamaño de la clase de instancia de base de datos, seleccione Clases optimizadas para memoria.
4. Elija la clase de instancia; para esta publicación, elegimos db.r6g.large (la «g» significa Graviton).
5. Seleccione Continuar.
6. En la página de resumen, revise los cambios.
7. Para aplicar el cambio inmediatamente, seleccione Aplicar inmediatamente. Si no se aplica el cambio inmediatamente, el cambio será programado para que se produzca durante el período de mantenimiento que se haya definido. Si se selecciona Aplicar inmediatamente, se puede provocar una interrupción en algunos casos.
8. Elija Modificar instancia de base de datos.

La siguiente captura de pantalla muestra la instancia que se está modificando.

Para nuestro caso de uso en esta publicación, el tiempo de modificación de la instancia de réplica de lectura tardó unos minutos. Mientras se modifica esta instancia, la instancia primaria y otra instancia de lectura están disponibles para atender las solicitudes de la aplicación. No se ha demostrado que el tamaño del conjunto de datos o el estado de cifrado de la base de datos afecten al tiempo necesario para modificar la clase de instancia.

La siguiente captura de pantalla muestra la instancia primaria y otra de lectura con instancias del tipo db.r5 large (x86), finalmente una instancia de lectora del tipo db.r6g.large (Graviton).

Ahora transferimos por conmutación por error la instancia primaria a la instancia de lectura db.r6g.large. Cada réplica de lectura está asociada a un nivel de prioridad. En caso de conmutación por error, Amazon RDS promueve la réplica de lectura que tenga la prioridad más alta (el nivel con el número más bajo). Si dos o más réplicas tienen la misma prioridad, Amazon RDS promociona la que tenga el mismo tamaño que la instancia principal anterior. Antes de la conmutación por error, debemos asegurarnos de que la prioridad de conmutación por error de la instancia de tipo db.r6g.large sea superior a la otra instancia de lectura. De forma predeterminada, ambos están en el nivel 1, por lo que debemos elegir la instancia de lectura auroralab-pgsql-node-2 y cambiar la configuración al nivel 2.

Seleccione la instancia auroralab-pgsql-node-2 y elija Modificar.
Para la prioridad de conmutación por error, elija el nivel 2.
Seleccione Continuar.
Elija Modificar instancia de base de datos.

Realizar conmutación por error

Seleccione la instancia de escritura auroralab-pgsql-node-1 y, en el menú Acción, elija Conmutación por error.

Las aplicaciones experimentan una interrupción mínima del servicio si se conectan mediante el enpoint del clúster (recomendado) en lugar del endpoint de la base de datos y se implementa una lógica de reintento de conexión. Durante la conmutación por error, AWS modifica el DNS del endpoint del clúster para que apunte a la instancia de base de datos recién creada o promocionada. Tras el cambio, se tiene una instancia de escritura que se ejecuta en Graviton.

Para minimizar las interrupciones del servicio y aumentar la resiliencia de las aplicaciones, también puede utilizar Amazon RDS Proxy. Para reducir aún más el tiempo de conmutación por error, puede configurar ajustes de TCP keepalive y de conexión JDBC o utilizar el driver AWS JDBC. Para obtener más información, consulte Prácticas recomendadas con Amazon Aurora PostgreSQL.

Valide y confirme que la aplicación funciona correctamente

Ahora puede validar que su aplicación funciona correctamente con las bases de datos RDS o Aurora basadas en Graviton. Si tiene Performance Insights habilitado, puede utilizar el panel de Performance Insights para visualizar la carga de la base de datos y filtrarla por esperas, sentencias SQL, hosts o usuarios.

Tras un período de prueba (probablemente un par de días o según su nivel de comodidad), puede cambiar el resto de las instancias a Graviton y eliminar el respaldo tomado antes del cambio.

Reversión

Con cualquier cambio, es importante contar con una estrategia alternativa si los nuevos cambios no funcionan como se esperaba. A alto nivel, cuenta con las siguientes opciones:

Si el clúster posee instancias de lectura x86, puede realizar una conmutación por error a una instancia x86 del clúster cambiando la prioridad de conmutación por error.
También puede volver a cambiar el tipo de instancia a un tipo de instancia x86 siguiendo un proceso similar al que vimos durante publicación.
Si sigue teniendo problemas, puede restaurar desde el respaldo tomado antes de iniciar el cambio. Para obtener más información sobre las consideraciones adicionales al utilizar Amazon RDS o Aurora, consulte Restauración a partir de un respaldo de base de datos y Restauración a partir de un respaldo de clúster de base de datos, respectivamente.
Restoring from a DB snapshot and Restoring from a DB cluster snapshot, respectively.

Los procedimientos de restauración son un tema aparte en sí mismo y están fuera del alcance de esta publicación.

Resumen

En esta publicación se proporcionaron instrucciones paso a paso para modificar las instancias de Aurora PostgreSQL a Graviton, junto con algunas de las consideraciones clave para minimizar el tiempo de inactividad. Puede seguir pasos similares para modificar las instancias de RDS a Graviton. También hablamos brevemente sobre el proceso de actualización de la base de datos si no se tiene la versión mínima requerida para cambiar instancias a Graviton.

Como práctica recomendada, pruebe siempre cualquier cambio en ambientes no productivos, como desarrollo o QA, incluidas las extensiones de base de datos que pueda tener, y asegúrese de que el entorno de prueba se parezca al entorno de producción en términos de configuración y volumen.

Recursos adicionales

Para obtener más información y recursos adicionales, consulte lo siguiente:

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

Acerca de los autores

Reagan Rosario trabaja como arquitecto de soluciones y se centra en la tecnología educativa en AWS. Le encanta ayudar a los clientes a crear soluciones escalables, seguras y de alta disponibilidad en la nube de AWS.

Tyler Lynch es un arquitecto de soluciones sénior especializado en tecnología educativa en AWS. Le apasiona la educación y el aprendizaje permanente.

Revisores

Maximiliano Kretowicz es Senior Solutions Architect para Amazon Web Services, basado en Santiago de Chile.

Rene Martínez Bravet es Arquitecto de Soluciones senior en AWS con foco en clientes del segmento enterprise e industria financiera.

Blog de Amazon Web Services (AWS)