Estoy bastante seguro que con este título acabo de marear al 95% de los lectores del blog. Sin embargo al igual que el último post, quiero enfocar la temática en aspectos relacionados con la performance.

Esta madrugada hicimos el deployment de una nueva versión de nuestro sistema de balanceo de carga web, el primero en integrar un tipo de balanceo de carga llamado Dynamic-Weighted con otro llamado Sticky-Sessions. Algo no muy común ya que son dos sistemas que tienen a usarse de forma suplementaria, no complementaria. Lo vi en el WebSphere de IBM y si alguien conoce otros sistemas del estilo que quiera compartir se lo agradezco.

Voy a tratar de explicar de qué se trata.

Empecemos con el concepto de Balanceo de Carga. El LB, Load Balancing o Balanceo de Carga, es una técnica mediante la cual se distribuye un cierto trabajo, entre varias partes todas capaces de realizar las mismas tareas. En el caso de servicios Web se utilizan equipos que reciben las solicitudes de los usuarios (personas visitando sitios web), las analizan y las derivan de forma transparente a uno o más servidores web que procesan la solicitud y entregan un resultado.

Balancear la carga permite tener redundancia, y también escalar horizontalmente ampliando recursos según necesidad sin demandar migraciones de datos o interrupciones de servicio.

Existen varios tipos de Balanceo de Carga, estos son solamente algunos:

DNS Round-Robin:
Esta técnica no requiere de hardware ni servidores especiales gestionando el balanceo. Simplemente se le dan varias direcciones IP a cada sitio, y se asume que eso va a dar una distribución pareja de las visitas a cada una de las IP asignadas. (y por supuesto, cada una de ellas en un servidor distinto con los mismos contenidos del mismo sitio, replicado o compartido)
Una contra de este sistema es que en caso de que uno de los servidores salga de servicio, todos los usuarios que tengan esa IP van a perder acceso. A veces se busca resolverlo con herramientas como HeartBeat y Fake.

LB Round-Robin:
Similar al anterior, pero en lugar de hacer una distribución via DNS, hacemos una distribución al azar a través de un balanceador de carga.

Weighted LB:
También utilizamos un balanceador de carga, con la diferencia de que en lugar de hacer una distribución al azar se hace contemplando la capacidad (que un administrador debe definir) relativa entre los servidores web del grupo de balanceo.

Dynamic-Weighted LB:
En este caso, no se requiere de un administrador definiendo de forma manual la capacidad de cada integrante del grupo de balanceo, sino que el load balancer puede medir y estimar esto por sus propios medios, a través de monitoreos períodicos de los equipos.

Sticky-Sessions o Sticky-User:
Asumamos nuevamente que todos los equipos del grupo tienen las mismas características y capacidades, muchas veces es conveniente (y hasta necesario) que un usuario que haya sido derivado a un servidor web determinado, sea derivado nuevamente al mismo servidor web en caso que vuelva a ingresar. Para ello se usan “Sticky-Session” o “Sesiones pegajosas”, donde se “pega” al usuario a un servidor web determinado. En determinados entornos estos es necesario para el funcionamiento correcto de las sesiones, o para maximizar la performance cuando se usan aplicaciones que tienen un alto costo (computacional) de arranque (por ejemplo aplicaciones FastCGI como PHP, Ruby, etc) pero no tan alto de reutilización.
Esto se puede hacer por Cookies o simplemente por IP del usuario que visita.

Sin embargo este sistema que se centra en el usuario no tiene muy en cuenta las características de cada servidor de la red, de la misma forma que un LB normal no tienen en consideración las características del usuario.

Dynamic-Weighted Sticky-Session Load Balancing
Como seguro ahora se entiende claramente un sistema de estas características hace un balanceo de carga considerando el estado y capacidad de cada servidor de la red, distribuyendo los usuarios de un sitio a lo largo de dicha red de forma que cada usuario se mantenga lo más “pegado” posible a un servidor en la medida que eso sea más beneficioso que moverlo a otro, a fin de mantener los tiempos de respuesta parejos para todos.

Estas implementaciones nos permiten crecer y ampliar nuestra red más fácil y rápidamente, para poder adaptarnos y ofrecer servicio a la necesidades crecientes que el SaaS y la Web 2.0 requiere.

Antes de que alguno me pregunte, si, mencioné Ruby a propósito. No está disponible hoy, pero está cerca!

Compártelo