Windows Azure AutoScale

Una de las características más importantes de una plataforma de Cloud computing como Windows Azure, es la capacidad de poder de manejar crecimientos o decrecimientos en la cantidad de requerimientos que son procesados por nuestras aplicaciones.

En este artículo vamos a mostrar un ejemplo simple de como hacer una aplicación de tipo “Cloud Service”, desplegarlo en Windows Azure y luego aplicar una regla para que nuestra aplicación escale de forma automática.

Primero creamos un proyecto del tipo Windows Azure Cloud Service

Agregamos un Web Role (aplicación ASP .NET)

Luego agregaremos una página web Default.aspx e incorporamos un código muy simple que nos permite generar un uso intensivo de CPU (solo para efectos de esta prueba)

Luego de eso hacemos el despliegue a Windows Azure directo desde Visual Studio 2012

En el portal de Windows Azure (https://manage.windowsazure.com/), podemos ver que tenemos nuestra aplicación configurada con una instancia de tipo small y la opción de “autoscale” desactivada

Para hacer algunas pruebas usamos el utilitario “ab - Apache HTTP server benchmarking tool”, que  es un ejecutable de línea de comandos que nos permite simular una carga de requerimientos.

Para nuestro ejemplo ejecutamos 4 procesos realizando 10.000 transacciones, cada uno de ellos con 60 requerimientos concurrentes y los resultados fueron los siguientes

Esta ventana muestra los resultados para uno de los procesos, todos tienen valores muy similares, podemos ver que el tiempo total del proceso completo (10.000 requerimientos 60 concurrentes) fue 1616 segundos y donde el 50% de los requerimientos se atendieron en un poco más de 9 segundos y el requerimiento más lento se completó en un poco más de 14 segundos.

Esto es con una instancia small de nuestra aplicación.

Luego nos vamos al portal de configuración de Windows Azure y activamos el “autoscale” de nuestra aplicación

El tipo de escalamiento aplicado es lo que se denomina “scale out” que significa aumentar o disminuir el número de instancias (virtual machines) que atienden los requerimientos. Los requerimientos que llegan a nuestra aplicación pasan por un balanceador de carga que se encarga de enviar los requerimientos a las diferentes instancias existentes, en nuestro ejemplo anterior (autoscale desactivado) solo existía una instancia.

Lo que configuramos acá es lo siguiente:

Scale Metric: Indicamos que vamos a realizar el aumento basado en la utilización de CPU (es por eso generamos un procedimiento muy simple con un par de “for”)

Instance Range: Acá le decimos que el número mínimo de instancias es 1 y el máximo es 3, es decir el proceso de “autoscale” irá aumentando las instancias  hasta un máximo de 3 y disminuyendo hasta un mínimo de 1 dependiendo de la utilización de CPU en la(s) instancia(s).

Target CPU: Este rango indica en que valores queremos que nuestras instancias se mantengan, en nuestro ejemplo configuramos un rango de 40%-50%, es decir que si la utilización de CPU es menor a 40% disminuimos una instancia (nodo) de nuestra aplicación (con un mínimo de 1) y en caso que el uso de CPU sea mayor a 50% se aumentará una instancia (con un máximo de 3).

Scale up By y scacale down by: Indica cuantas instancias queremos agregar o quitar en cada proceso de escalamiento, también indicamos en la opción “Scale wait time” cada cuando tiempo queremos que se realicen modificaciones en el número de instancias, esto ya que el aumento de instancias tiene una relación directa con el cobro del servicio y también podrían haber bajas o aumentos rápidos de requerimientos, pero podrían ser de corta duración. Al agregar instancias la plataforma debe iniciar una nueva máquina virtual, configurarla y desplegar la aplicación (todo automático) lo que toma un par de minutos.  Si el proceso de “autoscale” fuese en periodos muy cortos podría ocurrir que cuando la nueva instancia esté lista, el tráfico podría haber disminuido y no ser necesaria la nueva instancia.

Luego de realizados y guardados los cambios volvemos a repetir las pruebas, ejecutamos 4 procesos realizando 10.000 transacciones, cada uno de ellos con 60 requerimientos concurrentes y los resultados fueron los siguientes.

Revisamos las instancias durante la prueba y podemos ver que se han generado 2 nuevas instancias automáticamente

Esta ventana muestra los resultados para uno de los procesos, todos tienen valores muy similares, podemos ver que el tiempo total del proceso (10.000 requerimientos 60 concurrentes) fue 544 segundos y donde el 50% de los requerimientos se atendieron en un poco más de 3 segundos y el requerimiento más lento se completó en un poco más de 11 segundos.

Si comparamos la diferencia con la prueba anterior

Prueba	Proceso completo	50% Requerimientos	Requerimiento más largo
1 instancia (sin autoscale)	1616 segundos	9 segundos	14 segundos
1-3 Instancias (con autoscale)	544 segundos	3 segundos	11 segundos

Uno de los grandes beneficios de esta funcionalidad, es que como nos podemos dar cuenta, solo nos hemos preocupado de desarrollar nuestra aplicación y la plataforma se encarga de la configuración de la infraestructura (balanceador, máquinas virtuales, despliegue y conectividad), lo que significa un ahorro en tiempo y esfuerzo muy importante dentro de los proyectos.

Además esto nos permite evitar que nuestros usuarios tengan una mala experiencia con nuestras aplicaciones.

Otra opción interesante del “autoscale” es la posibilidad de agendar por fecha los crecimientos, por ejemplo cuando sabemos que vamos a tener aumentos de tráfico importantes (cierre de mes, navidad, proceso de pagos, etc.)