Amazon Aurora, ¿podemos montar una alternativa en IaaS?

Hace unas semanas hablamos de las virtudes de los servicios gestionados de AWS y por qué es buena idea utilizarlos. Ahora, en este nuevo post, vamos a por la segunda parte del artículo donde vamos a analizar algunas de estas soluciones y analizar alternativas IaaS que podríamos implementar.

Realizaremos un ejercicio teórico para entender el funcionamiento de los servicios gestionados de AWS y exploraremos la viabilidad de diseñar alternativas IaaS a estas soluciones.

A la hora de analizar cómo funciona un servicio gestionado, utilizaremos como base las sesiones que AWS suele disponibilizar como “Deep Dives” o “Under The Hood” (pero en el artículo no podremos entrar a un nivel de detalle exhaustivo, ya que sería un artículo infinito).

Hoy vamos a analizar un servicio que tiene una implementación de infraestructura muy interesante. ¡Comencemos!

¿Qué es Amazon Aurora?

Amazon Aurora es un servicio de bases de datos bastante potente y que puede utilizar como motor MySQL o PostgreSQL. Provee de rendimiento superior, además de unos niveles impresionantes en cuanto a alta disponibilidad y durabilidad. Incluye bastantes mejoras a nivel de MySQL o PostgreSQL, y el punto diferenciador de Aurora es cómo utiliza su infraestructura.

¿Cómo funciona Amazon Aurora?

Amazon Aurora tiene desacoplada la capa del motor de BBDD y la capa de persistencia. De este modo utiliza un Storage dedicado y SSD con 6 copias distribuidas en 3 zonas de disponibilidad.

En cada zona de disponibilidad, se generan 2 copias de datos; esto, además de permitir mucha durabilidad, permite segregar las escrituras de las lecturas.

En la zona donde se despliega la instancia primaria de Aurora tenemos una copia de datos donde ejecutaremos las operaciones de escritura y que se replicará a todas las copias (la copia en la misma AZ y las copias en las otras AZs).

Pero en vez de utilizar esa misma copia para las operaciones de lectura, utilizaremos la copia replicada en la misma AZ.

Esto permite la consistencia del dato, ya que no leemos el dato hasta que no está replicado en todas las copias y permite la utilización de Read Replicas, ya que los datos están completamente sincronizados a nivel de Storage.

La principal ventaja de este modelo es que al desacoplar el Storage y desacoplar las operaciones de lectura y escritura, permite mucha flexibilidad a la hora de diseñar la alta disponibilidad sin perjudicar el rendimiento; es más, Aurora tiene un rendimiento muy alto.

De este modo, el motor de base de datos está totalmente desacoplado. Es verdad que no podemos cambiar de MySQL a PostgreSQL (porque los datos no son compatibles), pero sí podemos cambiar sin ningún problema de instancia. Al final, la instancia de Aurora no tiene ningún dato en local.

En este sentido, Aurora Serverless V2 es una maravilla, permitiendo un escalado vertical automático y en el modelo tradicional permite un escalado horizontal en lectura. Pero en cuanto a alta disponibilidad es muy interesante, ya que con una Read Replica en otra AZ tenemos alta disponibilidad.

Básicamente, si falla una AZ al estar replicados los datos, la Read Replica se promociona a instancia principal, de forma que una de sus copias de Storage será la utilizada para las operaciones de escritura, replicándose en todas las copias y continuará utilizando la otra copia para las operaciones de lectura.

Este proceso es muy rápido y se ejecuta automáticamente en pocos minutos.

Pero es más, realmente ni siquiera necesitamos una Read Replica levantada, ya que las copias siempre están disponibles. No sería un mecanismo de alta disponibilidad porque no es automático, pero siempre podemos levantar una instancia de Aurora en otra zona, si la zona primaria tuviese una caída.

Aurora no es solo esta funcionalidad, sino que tiene muchas más como una mejora de rendimiento, tiene backups automáticos con “Restore to point in time”, tiene un modelo Global para permitir el funcionamiento interregional y muchas más funcionalidades.

Para nuestro ejercicio, nos vamos a centrar solamente en esta funcionalidad, luego veremos el motivo.

Nuestra solución

Empezamos con la solución más lógica, que sería montar una instancia de MySQL o PostgreSQL con Read Replicas.

Incluso es una opción totalmente viable utilizando RDS, no necesitamos ni montar una EC2.

Pero realmente no queremos usar un servicio gestionado.

Realmente parecen despliegues muy similares, pero hay bastantes diferencias.

La primera y principal es la latencia, en este modelo, la replicación no se ejecuta a nivel de disco, sino que es una réplica de datos vía red, es verdad que la red en AWS es rápida, pero no tanto como una sincronización a nivel de disco.

El segundo problema es que triplicamos la infraestructura en ciertas partes, es verdad que en Aurora podemos tener 3 instancias, pero como hemos hablado anteriormente, podemos llegar a usar una y replicaríamos los datos en las 3 AZs, esto no pasa si usamos EC2, ya que tenemos que realizar esta replicación nosotros.

Por otro lado, tenemos que diseñar y planificar nuestro sistema en caso de caída, si bien es cierto que podemos apoyarnos en diferentes software para implementarlo.

Otro gran problema es el escalado, ya que los escalados van a ser más lentos.

• Tenemos que levantar una nueva instancia e instalar la BBDD (siempre podemos generar una AMI).
• Tenemos que añadir esta instancia a nuestro Cluster
• Sincronizar datos vía Red.

En el caso de un escalado vertical:

• Tenemos que parar la sincronización de una de las Read Replicas.
• Parar la EC2.
• Cambiar el tamaño de la EC2.
• Levantar la EC2.
• Resincronizar.
• Promocionar la nueva instancia como primaria.

Mientras que en Aurora, para los escalados horizontales basta con añadir nuevas Read Replicas que estarán sincronizadas y para los escalados verticales basta con lanzar una nueva Read Replica más grande y realizar una conmutación.

A nivel de costes de infraestructura puros es verdad que una instancia EC2 es más barata, pero podemos ver ciertas carencias.

En Aurora podemos tener un escalado horizontal e incluso un escalado vertical con la versión Serverless de forma económica, no tenemos que duplicar el Storage; mientras que en este modelo tenemos que tener discos EBS por cada Read Replica, lo que incrementa el coste.

Por otro lado, a nivel de costes también tenemos que tener en cuenta el licenciamiento, ya que si vamos a modelos de Alta disponibilidad, vamos a tener que utilizar funcionalidades disponibles en las versiones Enterprise. Todo esto sin contar el backup, la gestión de versiones, el mantenimiento de los Sistemas Operativos, etc.

Pero además tampoco hemos cumplido el requisito principal que era desacoplar la capa de almacenamiento. Vamos ahora a ver una posible solución desacoplando la capa de Storage.

Para este caso de uso tenemos que entender algunas limitaciones del servicio de EBS (Amazon Elastic Block Store).

Es un servicio zonal y, por tanto, los discos que generemos solo están disponibles en la zona donde los creemos. Esto tiene sus implicaciones en este modelo porque no podemos atachar un disco de una instancia en la zona A a otra instancia de la zona B. Pero sí podemos atachar un mismo disco a varias instancias de la misma zona utilizando la funcionalidad EBS Multi-Attach.

De esta forma podemos montar una instancia que lea del disco en que nuestra BBDD está escribiendo y con diferentes herramientas podemos sincronizar los datos con otras instancias en otras AZs.

Para esto, podemos usar múltiples herramientas, como drbd, pero volvemos a encontrarnos con el mismo problema que antes y es la latencia. Este tipo de sincronización añade latencia adicional.

Por otro lado, tenemos que gestionar instancias de Storage para la sincronización de discos. Es verdad que si tenemos múltiples bases de datos, podemos utilizar la misma instancia para varias sincronizaciones, pero sigue añadiendo complejidad y coste. Además, tenemos que gestionar la replicación y gestionar los eventos de sincronización a nivel de disco.

Por otro lado, las BBDD son bastante complejas en cuanto al uso del almacenamiento y una copia síncrona de los datos a bajo nivel no implica que los datos sean consistentes.

Normalmente, las BBDD no escriben directamente a disco, sino que almacenan las escrituras en memoria para volcarlas de la forma más óptima posible a nivel de disco y, por otro lado, no trabajan con escrituras secuenciales en diferentes ficheros, sino que trabajan siempre con datafiles abiertos, esto implica que una sincronización a bajo nivel requiere de una gestión adicional por la propia BBDD.

Casi todas las BBDD tienen sistemas que permiten esta replicación a nivel físico, pero requieren de una gestión adicional por nuestra parte.

Además, tenemos todas las pegas que ya hemos visto en el modelo anterior: tenemos que gestionar la alta disponibilidad, mantenimiento de SO, gestión de versiones de BBDD, etc.

Conclusiones

Como hemos visto, al final es posible montar una solución similar a Aurora, pero requiere gestionar mucha más infraestructura y gestionar también las replicaciones.

Esto es algo habitual con los servicios gestionados, es posible generar la misma solución, pero esa solución va a ser compleja de gestionar, vamos a requerir más infraestructura que la inicialmente prevista y el rendimiento en muchos casos va a ser peor.

Este es el motivo por el que se suelen recomendar los servicios gestionados. Es verdad que pueden parecer caros y algo más cerrados, pero al final las ventajas que tenemos son bastantes y muchas veces lo que vemos más cerrado, es simplemente una implementación que nos facilita el día a día.