Uno de los principales problemas de rendimiento de las Bases de Datos Relacionales Transaccionales (OLTP) se produce al incluir Cargas de Trabajo Analíticas (OLAP) con consultas que recuperan gran cantidad de información. En muchos casos para fines ajenos a la propia aplicación como los sistemas BI. Este tipo de acceso tiene un impacto considerable en el rendimiento por varias razones, como la capacidad de la infraestructura de base de datos adaptada al uso transaccional de la aplicación, o el diseño del modelo de datos optimizado para el tipo de acceso, más atómico, de un sistema transaccional que analítico.

Para resolver estos problemas Amazon Aurora dispone de dos funcionalidades que vamos a estudiar, Auto Scaling de réplicas de sólo lectura (Readers) y Custom Endpoints dedicados a instancias específicas.

En este post de la serie de dos partes vamos a explorar las capacidades de Auto Scaling de Amazon Aurora, cómo funciona, cómo aprovechar las capacidades de failover, cómo implementarlo y algunos consejos perspicaces para sacarle el máximo partido. Comencemos.

Readers Auto Scaling

Amazon Aurora Auto Scaling permite ajustar automáticamente el número de réplicas de lectura de un clúster de Amazon Aurora RDS. Esto le permite principalmente ajustar la capacidad de la plataforma para cargas de trabajo impredecibles.

Amazon Aurora Auto Scaling permite definir un máximo y un mínimo de instancias del mismo modo que los grupos de Amazon EC2 Auto Scaling. Sin embargo, como diferencia, en lugar de definir un valor de escalado de salida y un valor de escalado de entrada para la métrica de Auto Scaling, solo se define un valor objetivo, que sirve como valor de umbral superior. Amazon Aurora Auto Scaling define automáticamente el valor inferior

Funcionamiento

El funcionamiento de Amazon Aurora Auto Scaling se basa en dos componentes diferentes que es necesario definir.

Objetivo escalable

Se encarga de definir la capacidad máxima y mínima del autoescalado. Solo puede existir un objetivo escalable por clúster de Amazon Aurora. La capacidad definida en el objetivo escalable afecta a todo, es decir, se tiene en cuenta el número total de instancias lectoras ya sean autogestionadas o gestionadas por autoescalado.

Algunos ejemplos:

Supongamos que tenemos la siguiente capacidad.

• Capacidad mínima: 1
• Capacidad máxima: 4

El clúster mostrado a continuación tendría la capacidad de crecer sólo 2 instancias más ya que el número total de instancias lectoras no puede superar las 4 unidades. De la misma forma no se puede tener menos de 1 instancia Reader, sin embargo, cuando se tiene una instancia Reader autogestionada, se podría llegar a tener 0 instancias Reader gestionadas por Auto Scaling.

En el siguiente caso, el clúster tendría la capacidad de aumentar 1 instancia más hasta alcanzar el máximo. Para el mínimo, podría eliminar todas las instancias de lectura excepto 1.

En este último ejemplo, ya se ha alcanzado la capacidad máxima de Auto Scaling, de hecho, se ha superado al tener 5 instancias autogestionadas ya creadas. El límite de Auto Scaling no influye en el límite máximo de instancias Reader autogestionadas en un clúster de Amazon Aurora, sin embargo el límite máximo permitido por Amazon Aurora es de 15. Este límite incluye ambos tipos de instancias Reader, autogestionadas o gestionadas por Auto Scaling.

Política de escalado

Se encarga de definir la métrica a monitorizar para controlar el Auto Escalado, y el valor objetivo a alcanzar en el clúster.

Puede haber varias políticas de escalado asociadas a un objetivo de escalado, aunque lo habitual es definir sólo una.

Las métricas pueden ser de dos tipos, predefinidas o personalizadas.

Las métricas predefinidas que puede elegir son dos:

• RDSReaderAverageCPUUtilization – Es el valor medio de la métrica CPUUtilization en CloudWatch entre todas las réplicas de Aurora en el clúster de Amazon Aurora.
• RDSReaderAverageDatabaseConnections – Es el valor medio de la métrica DatabaseConnections en CloudWatch entre todas las réplicas de Aurora en el clúster de Aurora.

Para las métricas personalizadas se puede elegir cualquier métrica que tenga sentido, siempre y cuando se tenga en cuenta el estado de todas las réplicas de lectura. Una limitación de esto es, por ejemplo, la imposibilidad de elegir una métrica que afecte sólo a un subconjunto de instancias de réplica de lectura. Esto se debe a cómo están organizadas las dimensiones en CloudWatch para RDS/Aurora. En un clúster de Amazon Aurora, las únicas dimensiones válidas son ClusterId, Role (Writer o Reader) o sólo ClusterId.

Conmutación por error de clúster de Auto Scaling

Para evitar la conmutación por error en una instancia administrada de Auto Scaling, AWS asigna la prioridad más baja (tier-15) a este tipo de instancia. De este modo, las instancias de lectura autogestionadas (normalmente con prioridad de nivel 1) tendrán preferencia como candidatas en caso de conmutación por error. Sin embargo, si no hay lectores autogestionados en el clúster, cualquiera de las instancias lectoras autogestionadas de Auto Scaling se marcaría como candidata en caso de conmutación por error.

Algunos ejemplos:

En este caso, la conmutación por error se realizará siempre entre la instancia 1 y la instancia 2.

En este caso, la conmutación por error se realizará a cualquiera de las instancias del lector (2, 3 o 4), sin embargo, una segunda conmutación por error siempre volverá a la instancia 1.

Implementación

Se puede implementar la configuración de Auto Scale tanto desde la consola de AWS como desde la CLI de AWS. Desde la consola de AWS sólo es posible utilizar métricas predefinidas. La creación tanto del objetivo escalable como de la política de escalado se realiza en un único paso, por lo que resulta muy sencillo de configurar.

Desde AWS CLI, es necesario definir el objetivo escalable y la política de escalado individualmente, también es necesario definir la configuración de la métrica en un JSON que se utiliza como entrada en la creación de la política de escalado. Esto se aplica tanto si la métrica está predefinida como si es personalizada.

Los detalles de implementación se pueden encontrar en Using Amazon Aurora Auto Scaling with Aurora replicas.

Limitaciones y recomendaciones

Aunque algunas de las limitaciones ya se han comentado en secciones anteriores, es necesario tener en cuenta las siguientes limitaciones y recomendaciones de Amazon Aurora Autoscaling.

• No configure Capacidad mínima = 0, especialmente en aquellos clusters que no dispongan de instancias Reader autogestionadas. Si un clúster se queda sin instancias Reader, el Auto Scaling deja de funcionar, ya que las reglas que ejecutan el escalado se quedan en estado de Datos insuficientes.
• Si todas las instancias del clúster no están en estado Disponible, las acciones de Autoescalado no se ejecutan.
• El valor objetivo de la métrica define el límite máximo del Auto Scale, es decir, aquel que una vez superado provoca un scale-out. El valor mínimo es auto calculado por AWS y es siempre un 10% inferior al valor máximo. Cuando la métrica está por debajo de este valor mínimo se produce un scale-in.
• El periodo de tiempo que la métrica tiene que estar por encima o por debajo del valor máximo o mínimo respectivamente es fijo. El valor máximo es de 5 minutos. El valor mínimo es de 15 minutos.
• El incremento de instancias en el scale-out es variable, AWS determina el número de instancias necesarias para alcanzar el valor objetivo, siempre dentro de los límites máximo y mínimo, y las crea al mismo tiempo.
• El decremento de instancias en el scale-in es siempre fijo con un ritmo de 1 instancia cada vez.
• Si no hay instancias autogestionadas Reader, la conmutación por error del clúster se realiza en una de las instancias gestionadas por Auto Scaling.

Configuración recomendada

En base a lo visto en los apartados anteriores, se recomienda la siguiente configuración estándar. Será necesario adaptarla a las necesidades específicas del clúster de Amazon Aurora en el que se vaya a aplicar.

Como regla general para esta configuración, se recomienda tener una instancia Writer y una instancia Reader autogestionada del mismo tipo y tamaño. Se recomienda dejar el parámetro Failover priority en su valor por defecto que es tier-1, asegurando así que el failover del clúster se realizará siempre entre estas dos instancias. El número de instancias gestionadas por Auto Scaling será variable, entre cero y el número máximo que se especifique en la configuración dependiendo de la carga de lectura en el clúster.

Se recomienda aplicar la configuración en la consola de AWS, aunque también es posible hacerlo en AWS CLI tal y como se describe en Adding a scalling policy to an Aurora DB clúster.

Estos son los parámetros recomendados:

Detalles de la política

• Métrica objetivo: Se recomienda elegir cualquiera de las métricas predefinidas en función de las necesidades del clúster. Estas son Promedio de utilización de CPU de las réplicas de Aurora o Promedio de conexiones de las réplicas de Aurora.
• Valor objetivo:El valor objetivo a mantener para la métrica Target seleccionada.

Detalles de la capacidad del cluster

• Capacidad mínima: Se recomienda utilizar siempre el valor 1.
• Capacidad máxima: Indique el número máximo de instancias deseadas según las necesidades del clúster. El límite máximo es 15.

En el próximo y último post de la serie veremos qué son los Custom Endpoints, cómo pueden funcionar con Readers Auto Scaling y algunas configuraciones sugeridas.

Imagen: Unsplash | Uriel SC