Un primer vistazo a Amazon Aurora Serverless RDS

Si implementa con frecuencia servicios en la nube, por supuesto, al menos una vez se olvida de instalar una instancia de prueba. Soy como tú y me olvidé de mi parte sobre ellos. Otro error que cometo de vez en cuando es dar un ejemplo más grande de lo que se necesita, por si acaso, y olvidarme de la reducción. Si bien esto es cierto para los casos de computación, es especialmente cierto para los casos de bases de datos. Con el tiempo, esta situación termina agregando una prima de costo. En esta publicación, discutiremos una solución para mitigar estos costos adicionales, el uso del servicio RDS Aurora Serverless.

¿Qué es Amazon Aurora Serverless?

Desde la primavera pasada, Amazon ha introducido un nuevo producto de base de datos: RDS Aurora sin servidor. El objetivo de este nuevo producto es simplificar la administración en torno a los clústeres de Aurora. Aporta un beneficio probable a los usuarios finales, un mejor control de costes. Estos son algunos de los beneficios que podemos esperar de este producto:

  • Escala automática
  • Escala automática
  • Apagado automático después de un período de inactividad
  • Arranque automático

La base de datos se supervisa constantemente y, si la carga supera un cierto límite, se agrega una instancia de Aurora más grande al clúster, se mueven las conexiones y se descarta la instancia anterior. Los pasos opuestos ocurren cuando se detecta una carga baja. Además, si la base de datos está completamente inactiva durante algún tiempo, se apaga automáticamente y se reinicia cuando es necesario. El tipo de clúster Aurora Serverless RDS está disponible para MySQL (5.6 y 5.7) y PostgreSQL (10.12).

Arquitectura

La arquitectura Serverless RDS Aurora es similar a la arquitectura RDS Aurora normal. Hay tres componentes principales; una capa de proxy que maneja los puntos finales, los servidores que procesan las solicitudes y el almacenamiento. La capa de proxy y el almacenamiento son casi iguales. Como su nombre lo indica, lo que es dinámico con el tipo Aurora Serverless son los servidores.

No hay muchos detalles disponibles sobre cómo se implementan realmente las cosas, pero probablemente, pero la capa de proxy es capaz de transferir una conexión de un servidor a otro cuando hay un evento que aumenta o disminuye la escala. Esencialmente, podemos asumir que cuando se modifica el clúster, los pasos son los siguientes:

  1. Se crea una nueva instancia del servidor Aurora con la nueva dimensión
  2. La nueva instancia se agrega al clúster de Aurora
  3. El rol de escritor se transfiere a la nueva instancia.
  4. Se han movido las conexiones existentes
  5. El viejo ejemplo se elimina

Como configurar

La configuración de un clúster RDS Aurora Serverless es muy similar a un clúster Aurora normal, solo hay unos pocos pasos adicionales. Primero, por supuesto, debe elegir el tipo sin servidor:

Clúster sin servidor RDS Aurora

Y luego tienes que especificar los límites de tu clúster en «Capacidad». La unidad de capacidad es ACU, que significa Unidad de capacidad Aurora. No pude encontrar el significado exacto de ACU, la documentación decía: «Cada ACU es una combinación de capacidades de procesamiento y memoria». Una ACU parece proporcionar aproximadamente 2 GB de RAM y el rango de valores posibles es de 1 a 256. Establezca la ACU mínima y máxima que desea para el clúster en el siguiente cuadro de diálogo:

Unidad de capacidad Aurora

El último paso es especificar el tiempo de espera inactivo después de que se pausa la base de datos:

especificar el tiempo de espera inactivo

Cómo funciona

Puesta en marcha

Si el clúster de Aurora Serverless no tiene instancias de servidor en ejecución, un intento de conectarse a la base de datos desencadenará la creación de una nueva instancia. Este proceso lleva algo de tiempo. Usé un script simple para medir el tiempo de conexión después de un tiempo de inactividad y encontré las siguientes estadísticas:

Debe asegurarse de que la aplicación tenga conocimiento de una nueva conexión, ya que la base de datos puede tardar cerca de un minuto en completarse. Lo tomé varias veces con el tiempo de sysbench después de los 30. Es importante tener en cuenta que la capacidad inicial utilizada es la misma que cuando se cerró la instancia de Aurora Serverless, a menos que haya habilitado la opción «Forzar capacidad de escalado …» en la configuración.

Se acabó el tiempo

Si un clúster de Aurora Serverless está inactivo durante más tiempo del definido, se detendrá automáticamente. La inactividad aquí se define en términos de conexión activa, no preguntas. Una conexión inactiva evita que la instancia de Aurora Serverless se apague. Si planea usar la función de pausa automática, le recomiendo que configure «wait_timeout» e «interactive_timeout» en los valores en línea con el tiempo de inactividad del clúster.

Aumentar proporcionalmente

Un proceso monitorea la instancia de Aurora Serverless y si ve un problema de rendimiento que podría resolverse con el uso de un tipo de instancia más grande, activa un evento de escalado. Cuando hay un evento de escalado (o disminución), verá un proceso como este en la lista de procesos de MySQL:

Tenga en cuenta que un evento de escalado puede llevar algún tiempo, especialmente si el servidor está muy ocupado. Al hacer algunos puntos de referencia, he sido testigo de más de 200 en algunas ocasiones. La carga de preguntas se ve afectada durante unos segundos cuando se intercambian instancias.

Para ilustrar el comportamiento de escalamiento, ejecuté un punto de referencia de sysbench modificado para forzar una carga de CPU. Aquí hay un punto de referencia de 32 cables que escanea una tabla en un clúster Aurora Serverless que tiene una capacidad inicial de 1.

Benchmark del sistema Aurora Serverless

La primera escala ocurrió poco después de 600, mientras que la segunda ocurrió alrededor de 1100. El segundo evento no mejoró mucho la carga, pero probablemente sea un artefacto de referencia. Llevó mucho tiempo aumentar la capacidad de 1 a 2, podría estar relacionado con el alto uso de CPU en la instancia. Por lo general, hay una pequeña interrupción de la carga de demanda cuando se intercambian instancias, pero nada malo.

Escaleras abajo

Si bien los eventos de escalado se producen cuando es necesario, los eventos de escalado se reducen aproximadamente una vez cada 5 minutos, a menos que el evento de escalado anterior fuera un «aumento de escala», entonces el retraso es de 15 minutos.

Pros y contras de Aurora Serverless

La oferta de RDS Aurora Serverless es muy convincente para muchos casos de uso. Reduce el costo y simplifica la gestión. Sin embargo, debe aceptar las limitaciones inherentes, como el tiempo de inicio prolongado cuando se pausó la instancia y los pequeños sollozos cuando se cambia la capacidad. Si no puede manejar la hora de inicio, puede configurar la instancia para que no se detenga, bajará a una capacidad de 1 que parece mapearse en un tipo de instancia t3.small.

Por supuesto, tal arquitectura impone ciertos inconvenientes. Aquí hay una lista de algunos consumos:

  • Como hemos visto, el tiempo de escalado se ve afectado por la carga de la base de datos.
  • La conmutación por error también puede tardar más de lo esperado, especialmente si el valor de ACU es alto
  • Estoy limitado a un nodo aunque, en una ACU de 256, significa un db.r4.16xlarge
  • Sin IP pública, pero puede configurar una API de datos
  • La aplicación debe ser sólida en la forma en que se ocupa de la conexión a la base de datos debido a posibles retrasos y reconexiones.

Ahorro de costes

El costo de un clúster RDS Aurora tiene tres componentes: costos de instancia, costos de E / S y costos de almacenamiento. La oferta de Aurora Serverless solo afecta los costos de las instancias. El costo es una tarifa fija por unidad de capacidad por hora. Como ocurre con los casos normales, los costos dependen de la región. El más bajo está en el este de EE. UU. A $ 0.06 USD por unidad de capacidad por hora.

Si consideramos una base de datos utilizada por los desarrolladores web durante el día y que se puede pausar fuera del horario comercial normal y los fines de semana, los ahorros pueden superar los $ 240 / mes si la capacidad diaria promedio es de solo ocho horas.

Author: Ing. Luis

A lo largo de conocer Windows y otros sistemas operativos me eh encontrado con diversos tipos de error, ahora brindo soluciones según mi experiencia-

Deja un comentario