Balanceo de carga entre Azure Websites geo-distribuidos
Hola a todos! Hoy les quiero mostrar cómo armar una infraestructura de sitios web distribuidos geográficamente utilizando los servicios de balanceo de carga de Microsoft Azure.
Si aún no usas Azure, te dejo acá opciones para que empieces gratis.
Montarlo toma aproximadamente 5 minutos, pero primero debemos conocer algunos conceptos básicos para saber lo que estamos haciendo.
Traffic Manager
El servicio de Traffic Manager de Azure, básicamente permite definir un punto único de entrada a nuestra aplicación para luego dirigirnos a algún punto de salida, de entre varias opciones, de acuerdo a algún algoritmo. Estos puntos de salida son conocidos como endpoints.
Estos son algunos de los escenarios en los que puede ser útil un balanceador de carga:
- Usuarios accediendo a aplicaciones geográficamente distribuidas.
- Planes de contingencia o recuperación de desastres.
- Smooth deployments.
- Conectar Azure con tu centro de datos on-premises.
- Conectar Azure con tu aplicación externa.
¿Pero Azure no tenía ya un balanceador de carga por default? Sí, esto es cierto, pero el balanceador default sólo funciona para instancias dentro de un mismo data center. El balanceador por defecto, previene problemas de failover y utiliza el algoritmo Round Robin. Esto que estamos viendo, sirve para balancear tráfico entre puntos distribuidos entre data centers/ aplicaciones on-premises.
Algoritmos de balanceo
Son los que indican cómo distribuir la carga entre las instancias de nuestras apps. Son estos 3:
- Round Robin
- Failover
- Performance
Round Robin
En una frase: el balanceador de carga va repartiendo el tráfico entre cada instancia.
Ejemplo: usuario 1 a servidor 1, usuario 2 a servidor 2, usuario 3 a servidor 3, usuario 4 a servidor 1, etc.
Explicación en detalle: ver acá.
¿Cuándo usar RR? Fácil, cuando todos tus endpoints son idénticos y quieras repartir la carga entre ellos.
Weighted RR: Existe la posibilidad de asignarle un peso distinto a cada instancia. Esto significa, que puedo enviar más tráfico a unas que otras. Esta configuración no está disponible desde el portal de administración, pero es muy sencillo de realizar vía Powershell. En este post, se explica paso por paso como correr los cmdlets.
Performance
En una frase: Azure mantiene internamente una tabla que mapea direcciones IP con el data center más cercano, y en base al pedido que recibe TM, lo redirige al endpoint con menor latencia.
Explicación en detalle: ver acá.
¿Cuándo usar Performance? Cuando tus aplicaciones estén distribuidas geográficamente y quieras que cada usuario acceda a la más cercana en términos de latencia.
Failover
En una frase: Tengo varias instancias ordenadas por prioridad, y si la más importante falla, se lo mando a la siguiente en la lista.
Explicación en detalle: ver acá.
¿Cuándo usar Failover? Cuando lo que estoy tratando de armar es un plan de contigencia, recuperación de desastres o similar.
Implementación
La parte divertida. Vamos como siempre a https://manage.windowsazure.com/ y scroll down hasta Traffic Manager
Excelente, ahora el punto de entrada a nuestra aplicación es miprefijo.trafficmanager.net. Esto significa que, si tengo un sitio que es www.mipaginaweb.com.ar, lo que debo hacer es redirigirla a mi punto de entrada de traffic manager.
Elijo mis endpoints a balancear, y go. En este caso, voy a balancear simplemente tres Azure websites que están en tres data centers diferentes.
Desde la pestaña Configure tenemos varias opciones. Destaco acá cómo hacer para cambiar el algoritmo de balanceo:
La prueba final:
Endpoints externos
Dijimos que podíamos balancear carga entre tanto puntos internos de Azure como externos, ¿cómo hago? Por el momento, eso no se puede hacer desde el portal de de Azure. Sin embargo, podemos configurarlo vía PowerShell. En este post, se explica paso por paso como correr los cmdlets. Es relativamente sencillo de implementar.
Otras consideraciones importantes
Evidentemente, esto funciona muy bien para sitios o aplicaciones que tienen la posibilidad de correr independientemente. En la mayoría de los casos, éstos sitios compartirán recursos como bases de datos, blobs, tables, queues o cualquier otro tipo de storage. Debemos analizar cuidadosamente éstos aspectos antes de lanzarnos a geo-replicar nuestra aplicación, ya que el cuello de botella puede estar en otro lado (siendo la base de datos la culpable más frecuente).
Este post únicamente tiene por objetivo acercarte una herramienta más a tu skillset, para que puedas complementarlo con todas las otras soluciones que mencionábamos arriba. Para este escenario en particular, siempre es bueno tener en cuenta otras prácticas arquitectónicas que permitan reducir accesos a los cuellos de botella, como por ejemplo heavy caching, auto-scaling, procesamiento asincrónico (mensajería), storage no-relacional, etc.
Espero que te sirva!