Comunicación asincrónica y auto-scale con Azure Cloud Services

  • Article

Hola a todos! Hoy les traigo un tema diferente, cómo escalar cloud services en base a colas de mensajería. Estas son las partes que vamos a necesitar conocer:

  • Azure Cloud Services. Esencialmente son máquinas virtuales sin estado, esto significa, que la información debería almacenarse en un lugar compartido por todas las instancias (ejemplos: SQL database, Redis cache, blob storage, queue storage, etc). Esta arquitectura permite escalar horizontalmente hasta el infinito, de forma rápida, olvidándonos por completo de la administración del hardware. Te recomiendo leer esto.
  • Azure Worker Roles. Son uno de los componentes de los cloud services. Esencialmente máquinas virtuales que corren código .NET, PHP, Python, Node.js, Java o Ruby. A diferencia de los web roles, no tienen un web server pre-instalado.
  • Azure Queues. Las famosas colas de mensajería, que permiten que distintos escritores pongan un mensaje y distintos lectores lo tomen. Se pueden acceder vía REST (al igual que prácticamente todos los servicios de Azure) y existen SDKs para los distintos lenguajes.

El ejemplo que usaremos hoy es el ya conocido Twitter Bot. Si no lo conoces, mira este post.

Arquitectura de mensajería asincrónica

¿Cómo hacemos para que, por ejemplo. una aplicación .NET "hable" con una aplicación Java? Existen varias formas, siendo tal vez las más comunes los web services. Como sabremos, estos servicios son sincrónicos (envío algo, espero una respuesta). El patrón que presentamos acá es asincrónico, es decir, no espero una respuesta luego de ejecutar alguna acción.

Para mensajería asincrónica, frecuentemente se utilizan las colas de mensajería (existen otras estructuras también, como por ejemplo topics). El funcionamiento es muy sencillo: una aplicación escribe un mensaje (cola.GuardarMensaje("hola!") ) y otra aplicación los lee (var mensaje = cola.LeerMensaje() ). Esto funciona con la modalidad FIFO, o First In First Out (el primero que guardo es el primero que se lee). Como la cola de la panadería.

Dicho esto, imaginémonos que pueden haber muchas aplicaciones escribiendo mensajes y muchas aplicaciones leyendo estos mensajes. Azure Queues resuelven todo el tema de sincronización de escritura y lectura de mensajes.

Twitter Bot Multi-tenant

En el Twitter Bot, lo que sucede es lo siguiente: hay un worker role constantemente haciendo follow y escribiendo mensajes en la cola. Ahora supongamos que deseamos hacer que nuestro twitter bot sea multi-tenant, es decir, que atienda múltiples cuentas de twitter. Seguramente habrán varios worker roles escribiendo mensajes, y luego tendremos otro worker role procesando y haciendo unfollow. Acá nos damos cuenta de un problema: la cola puede llegar a crecer tanto que no llegamos a procesar todos los mensajes .

Escalar según la cantidad de mensajes en una cola de mensajería

Azure provee una solución muy sencilla para esto, y es el auto-scale basado en la cantidad de mensajes en una cola. Esencialmente, es una manera de definir una política de escala.

Ahora podemos elegir qué worker escalamos:

Elegimos queue ó cola y definimos las políticas:

Las políticas son las siguientes:

  • Instance Range o Rango de Instancias: estos son los umbrales de cantidades máximas y mínimas de workers que estás dispuesto a tener prendidos.
  • Account or Namespace: la cuenta de storage de la cola.
  • Queue Name: nombre de la cola de referencia.
  • Target Per Machine: cantidad de mensajes por worker. Ejemplo, si Target = 2000 y hay 6000 mensajes, habrán 3 workers.
  • Scale Up By: cantidad de workers a instanciar en simultáneo.
  • Scale Up Wait Time: cuánto tiempo esperarmos para prender otra instancia.
  • Scale Down By: cantidad de workers para desinstanciar en simultáneo.
  • Scale Down Wait Time: cuánto tiempo esperamos para apagar otra instancia.

 

Listo. Ahora así funcionará mi arquitectura:

Hay n workers procesando tweets y escribiendo mensajes en la cola users. En base a la cantidad de mensajes, habrá entre 1 y 3 worker roles haciendo unfollow. Si hay 2000 o menos mensajes en la cola, habrá 1 solo. Si hay entre 2000 y 4000 mensajes en la cola, habrá 2 workers. Si hay 4000 o más mensajes, habrá 3 workers procesando mensajes.