Bases de datos globales de Amazon Aurora con Serverless v2

Por Alejandro Guevara Arquitecto de Soluciones,
Obed Gutiérrez Arquitecto de Soluciones y
Servio Reyes, Arquitecto de Soluciones.

Introducción

Amazon Aurora es un motor de base de datos relacional totalmente administrado que es compatible con MySQL y PostgreSQL. Combinando la velocidad y la confiabilidad de las bases de datos comerciales con la simplicidad de las bases de datos de código abierto a una fracción del costo. Este motor ha tenido diferentes cambios con base en las solicitudes de los clientes de AWS, moviéndose a un enfoque más administrado del lado de AWS (enfoque serverless) e incrementando su alta disponibilidad. En el presente artículo hablaremos sobre las características de bases de datos globales de Amazon Aurora para múltiples regiones (multi-región) de AWS, y cómo ejecutarlo con las funcionalidades Serverless v2.

Bases de datos globales de Amazon Aurora

La arquitectura de Amazon Aurora implica la separación del almacenamiento y el cómputo. Aurora incluye características de alta disponibilidad que se aplican a los datos de su clúster de base de datos. Los datos se mantienen seguros incluso si alguna o todas las instancias de base de datos del clúster dejan de estar disponibles. Esto porque la capa de almacenamiento es independiente a las instancias y los datos se encuentran replicados en diferentes zonas de disponibilidad dentro de la región, cuando hablamos de Amazon Aurora en una sola región.

Las bases de datos globales de Amazon Aurora fueron creadas pensando en las aplicaciones que deben de tener un enfoque y distribución global en múltiples regiones de AWS. Ya sea porque tienen clientes en múltiples partes del mundo y se busque acercarles el contenido mejorando su experiencia con la aplicación, y/o debido a que la aplicación es tan crítica para el negocio, que su nivel de disponibilidad requiera estar en múltiples regiones.

El clúster multi-región de Amazon Aurora consiste en una región primaria, dónde se tendrá la instancia de escritura y hasta 15 réplicas de solo lectura. La instancia en esta región es la que distribuirá los cambios al resto de las regiones. Las regiones secundarias son únicamente de lectura, donde cada una de ellas podrá tener hasta 16 réplicas. Donde la comunicación entre las diferentes regiones es administrada por AWS.

Reenvío de escritura

Si se está utilizando una aplicación compatible con las versiones de MySQL de Amazon Aurora, y las aplicaciones en las regiones secundarias necesitan un punto de escritura dentro de la misma región (enfoque multi-región activo-activo), a las instancias de Amazon Aurora se les puede habilitar una funcionalidad para el reenvío de escritura. Este proceso se encarga de enviar los comandos de DML (Data Manipulation Language) a la instancia de escritura en la región primaria, para posteriormente replicar el cambio a todas las instancias. Dado que solo reenvía este tipo de comandos, en la instancia primaria es necesario ejecutar directamente los comandos de DDL (Data Definition Language) para la creación del modelo de la base de datos como pueden ser: nombres de las bases de datos, nombre de las tablas, atributos, relaciones, etc.

Tipos de consistencia

Cuando se tiene habilitado el reenvío de escritura, la información es enviada a un clúster remoto y por el tiempo de replicación, se necesita definir el nivel de consistencia adecuado para el consumo de la información de la BD. Las tablas globales de Amazon Aurora tienen tres niveles de consistencia:

Consistencia por sesión: El motor de Amazon Aurora se asegura de que las consultas de lectura después de una escritura en la misma sesión esperarán a que la replicación se ponga al día con esa escritura anterior. Esto asegura que la sesión vea sus propios cambios, pero no se garantiza ver cambios emitidos por otras sesiones.
Consistencia global: Con este nivel se asegura de que las consultas de lectura esperen a que la replicación alcance el punto en el tiempo en que comenzó la lectura. Esto significa que la lectura desde el clúster remoto verá todos los cambios comprometidos en el clúster primario hasta el punto en que se inició la consulta de lectura en el clúster remoto. Aunque este modo proporciona la consistencia más fuerte de lectura después de escritura, lo hace a expensas del rendimiento. Al utilizar este modo, el tiempo de espera en las consultas es al menos tan largo como el retraso de replicación.
Consistencia eventual: En consultas de lectura sujetas al retardo de tiempo de replicación. Esto reduce la latencia de escritura porque la réplica remota no espera a que se complete la replicación, sino que cambia eso por no asegurarse de que las siguientes lecturas puedan ver la escritura anterior. Tenga en cuenta que esto no significa que las escrituras se puedan perder. Si la consulta continúa significa que el clúster primario ha aplicado la escritura y lo ha reconocido de nuevo al clúster más remoto. Sin embargo, los cambios de datos resultantes generados por esa escritura pueden no haberse replicado de nuevo en el clúster remoto cuando se ejecuta la lectura.

Estas configuraciones de consistencias tienen que definirse a nivel sesión antes que las réplicas de lecturas puedan reenviar las escrituras.

Mecanismos de Amazon Aurora para alta disponibilidad

Amazon Aurora fue diseñado desde un inicio pensando en mantener cargas con altos niveles de disponibilidad. En el caso de los clústeres en una región, cuando la zona de disponibilidad, donde se encuentra la instancia de escritura, presenta problemas. Se promueve una instancia de lectura en otra zona de disponibilidad o se instancia una nueva en caso de no existir dependiendo las políticas definidas por el usuario. Sin la necesidad de hacer cambios en sus aplicaciones, ya que el endpoint se mantendrá sin cambios.

Con las bases de datos globales de Amazon Aurora a nivel regional se mantiene este comportamiento. Con la diferencia que, a nivel global, en caso de una problemática con el servicio a nivel regional, la promoción de la región primaria (donde se encuentra la instancia de escritura) debe ser ejecutada por un proceso definido por el usuario. Ya sea un cambio ejecutado desde la consola o CLI, o automatizado por una AWS Lambda que efectúe este cambio.

Objetivo de punto de recuperación

Bases de datos globales de Amazon Aurora permite tener un objetivo de punto de recuperación (RPO) estimado de un segundo, dependiendo del volumen de escrituras y lecturas al clúster, que es el tiempo de latencia estimado para la replicación de los datos entre regiones. En el caso de que se tenga habilitado el reenvío de escritura, el tiempo de recuperación estimado pasa a dos segundos. Estos tiempos son calculados cuando se tienen volúmenes de escrituras que se encuentran abajo de las 150K escrituras por segundo.

Tiempo objetivo de recuperación

Hablando del tiempo objetivo de recuperación (RTO) este se encuentra en menos de un minuto. Dado que se puede tener una región primaria con múltiples secundarias, el proceso para promover una región es definido por una acción del usuario. Ya sea por medio de una intervención directa en la consola de AWS, el CLI o alguna AWS Lambda, se debe ejecutar esta acción.

Grandes volúmenes de escrituras

En el caso que se tengan volúmenes mayores a las 150K escrituras por segundo, y se busque mantener el RPO de replicación entre las instancias. Un posible enfoque a revisar es el de separar la DB en múltiples fragmentos (shards), de tal forma que las escrituras se distribuyan entre múltiples clústeres de Amazon Aurora. Esta administración deberá ser controlada desde sus aplicaciones, donde se configurará para definir qué información debe ir en el shard adecuado.

Amazon Aurora Serverless v2

Amazon Aurora Serverless V2 es una configuración de Amazon Aurora que permite el escalamiento automático, el servicio bajo demanda inicia, apaga y escala o reduce la capacidad de manera automática de acuerdo a las necesidades de la aplicación. Este enfoque se Aurora Serverless V2 se recomienda utilizar cuando el tráfico de escritura y de lectura tiene patrones erráticos.

Una de las características de Amazon Aurora Serverless v2 es la capacidad de escalar en una fracción de segundo para atender cientos de miles de transacciones, permitiendo ahorros de costos de hasta 90% comparado con escenarios en el cual se aprovisiona la capacidad de cómputo del motor de base de datos para soportar los picos de demanda.

Otra característica a resaltar de Amazon Aurora Serverless v2 es que soporta configuraciones en múltiples zonas de disponibilidad (Multi-AZ), bases de datos globales, réplicas de lectura y reenvío de escrituras para un motor compatible con MySQL. Permitiendo así, su uso para un mayor número de aplicaciones y casos de uso. Por ejemplo, se podrían crear hasta 15 replicas de lectura de Amazon Aurora desplegadas en múltiples zonas de disponibilidad, que podrían ser utilizadas como destinos (targets) para casos de alta disponibilidad o para escalar el número de las operaciones de lectura.

Esta característica es medida en unidades de capacidad de Aurora (en inglés Aurora Capacity Units y abreviadas como ACU’s). Cada una de ellas tiene 2 GiB de memoria, con el cómputo y ancho de banda correspondientes. Estas unidades van de 0.5 hasta 128 en incrementos de 0.5. Cuando se crea el clúster se definen las ACU’s mínimas y máximas. Siendo estos valores modificables una vez que el clúster fue creado.

Demostración

La siguiente demostración ejemplifica como habilitar un clúster de bases de datos globales de Amazon Aurora compatible con MySQL, usando instancias tipo Serverless V2, y habilitando el reenvío de escritura desde la región secundaria. Para esto se necesita: una cuenta de AWS, experiencia con el manejo de la consola de AWS y configurando características del motor de MySQL.

En la consola de AWS, navegar a Amazon RDS. Luego clic en Crear base de datos.

Seleccionar la siguiente configuración:

a. Creación estándar
b. Tipo de motor: Amazon Aurora
c. Edición compatible con MySQL de Amazon Aurora

Seleccionar una versión del motor compatible con Serverless v2

Dependiendo su caso de uso, seleccionar una plantilla para producción o desarrollo, personalizando las configuraciones de su clúster como lo necesite.
En la configuración de la instancia, seleccionar el modo Serverless v2. Especificando la capacidad mínima y máxima de su base de datos, dependiendo los GiB de memoria necesitados.

Para esta demostración, dejar el resto de las configuraciones con los valores por defecto. Y clic en Crear base de datos, en la parte inferior de la página web.

Esperar a que el clúster se termine de crear y esté disponible.
Seleccionar el clúster a habilitar una base de datos global de Amazon Aurora. Clic en Acciones, y clic en Agregar región de AWS.

Agregar un identificador para el clúster global, y seleccionar la región secundaria.

Buscar la sección de Reenvío de escritura de réplicas de lectura, y seleccionamos Habilite el reenvío de escritura de réplicas de lectura.

Para esta demostración, dejar el resto de las configuraciones con los valores por defecto. Y clic en Añadir región, en la parte inferior de la página web.

Esperar a que el clúster se termine de modificar y crear la réplica en la región secundaria. En nuestro escenario se cargó una base de datos ejemplo de 2GB y su creación tardó 30 minutos en la región secundaria. Estos tiempos son ilustrativos y pueden variar dependiendo cada caso.

¡Felicidades ya tiene su clúster de Amazon Aurora con Serverless v2 en un enfoque multi-región! Ahora los comandos de DML ejecutados en la región secundaria serán replicados a la región primaria. Cambios que después se replicarán en todas las regiones secundarias.
1. Nota: Una vez creado su modelo de base de datos en la región primaria, establezca en la sesión de las regiones secundarias el tipo de consistencia. Por ejemplo:

mysql> set @@aurora_replica_read_consistency = 'session';

Cierre

En esta publicación se comentaron las principales características de bases de datos globales de Amazon Aurora y Amazon Aurora Serverless V2. Para profundizar más a cerca de estos temas revise la siguiente documentación, donde también se menciona como implementar los enfoques en sus aplicaciones:

Acerca de los autores

Alejandro Guevara es Arquitecto de Soluciones en AWS México

Obed Gutiérrez es Arquitecto de Soluciones en AWS México

Servio Reyes es Arquitecto de Soluciones en AWS México

Blog de Amazon Web Services (AWS)