Los cinco principales patrones de escalabilidad

La disponibilidad es un asunto serio en una economía donde las aplicações son moneda corriente. Las aplicaciones que no responden se eliminan inmediatamente y se critican en Internet con la misma velocidad y el sarcasmo de una crítica negativa en Yelp.

Desde los primeros días de Internet, las organizaciones han buscado garantizar que las aplicações (sitios web, en el pasado) estuvieran disponibles las 24 horas del día, los 7 días de la semana y los 365 días del año. Porque Internet nunca duerme, nunca se toma vacaciones y nunca llama para avisar que está enfermo.

Para satisfacer esa necesidad (requisito, en realidad), la escalabilidad surgió como uno de los primeros servicios de aplicação en brindar disponibilidad. El servicio de aplicação más visible (y mejor comprendido) que satisface las necesidades de disponibilidad es el equilibrio de carga.

Sin embargo, existen muchas formas de equilibrio de carga y patrones de escalabilidad que se pueden implementar utilizando esta tecnología central. Hoy voy a destacar los cinco principales patrones de escalabilidad en uso que mantienen las aplicaciones e Internet en línea y disponibles las 24 horas del día, los 7 días de la semana y los 365 días del año.

Global Server Load Balancing (GSLB)

GSLB tiene un nombre terriblemente equivocado. En realidad, nunca se trató de equilibrar la carga del servidor , sino de la disponibilidad del sitio . Hoy en día, eso también se está ampliando para incluir la disponibilidad de las aplicaciones.

GSLB es el medio por el cual se garantiza que si un centro de datos (en la nube o tradicional) no responde, se puede encontrar otro. GSLB se puede aplicar a nivel de dominio o de host. De esta manera, puedes usarlo para cambiar example.com entre ubicaciones, así como también api.example.com.

En su forma más básica, GSLB utiliza un equilibrio de carga rudimentario basado en DNS. Eso significa que tiene una lista de direcciones IP asociadas a un dominio o host, y si la primera no está disponible, las solicitudes se dirigen a la segunda en la lista, o a la tercera, o a la cuarta, y así sucesivamente.

Este proceso consta de dos pasos:

1. Solicite al balanceador de carga global la dirección IP adecuada. Este es el aspecto negativo siempre asociado con GSLB: si has preguntado en los últimos 15 minutos o cualquiera que sea el TTL actual para la dirección IP de cheese.com, obtendrás la última respuesta que recibiste. Entonces, si ese sitio deja de funcionar durante ese tiempo, no podrás conectarte.
2. Realice la solicitud a la dirección IP del sitio devuelta por la consulta GSLB. A menudo, esto termina siendo un equilibrador de carga local que utiliza sus propios algoritmos y proceso de toma de decisiones para llevar la solicitud al recurso apropiado.

Generalmente no hay inteligencia en la decisión tomada en el paso 1; se basa estrictamente en si un sitio determinado responde o no. Aun así, así es como puedes utilizar múltiples ubicaciones (nube, proveedor de alojamiento, local) para garantizar la disponibilidad. Al elegir estratégicamente ubicaciones en diversas áreas geográficas, puede evitar el impacto de desastres naturales o cortes de Internet.

Pero eso es más un escenario de DR (recuperación ante desastres) o BC (continuidad del negocio). Hay otros que aprovechan servicios de aplicação GSLB más inteligentes, como la geolocalización y el rendimiento de las aplicação . Entonces, si la aplicación en el Sitio A funciona mal, tal vez quieras enviar visitantes al Sitio B hasta que se resuelva el problema. O tal vez desee dirigir a los usuarios a la ubicación geográficamente más cercana para ayudar a mejorar el rendimiento (porque la velocidad de la luz sigue siendo una regla y la distancia es importante para el rendimiento de la aplicación).

Independientemente de cómo se tome la decisión, el patrón básico sigue siendo el mismo: GLSB distribuye solicitudes entre múltiples sitios separados físicamente devolviendo la dirección IP de uno de los sitios disponibles. Ya sean API o aplicaciones, GSLB es un patrón de garantía de disponibilidad de alto nivel.  

Equilibrio de carga tradicional (POLB)

Disponibilidad basada en conexión

Plain Old Load Balancing (POLB) es un término que me gusta usar para describir el equilibrio de carga estándar basado en TCP. La disponibilidad se logra utilizando este patrón simplemente clonando aplicaciones y asegurándose de que se pueda establecer una conexión entre el cliente (usuario, dispositivo) y la aplicación.

El balanceador de carga (o proxy si lo prefiere) recibe una solicitud de conexión, selecciona una instancia de aplicación disponible y reenvía la conexión. Esa es la última vez que el balanceador de carga participa activamente. Es como el «correo electrónico de presentación» mediante el cual se facilita el encuentro entre dos colegas. Eres un participante activo en el intercambio inicial, pero luego te trasladan a la línea cc y, por lo general, no participas más.

Utilizo el término POLB porque no hay nada más que algoritmos involucrados en la elección de cómo dirigir las solicitudes. Lamentablemente, hay muchas cosas que pueden salir mal dependiendo del algoritmo que se utilice para distribuir las solicitudes. Por ejemplo, al sistema round robin no le importa ni la capacidad ni el rendimiento. Simplemente selecciona “la siguiente aplicación” y se realiza la solicitud. Elegir “menos conexiones” puede afectar rápidamente el rendimiento al cargar un recurso, mientras que otras pueden ser más rápidas. La elección de algoritmos se convierte en un componente crítico para mantener la disponibilidad.

POLB es el método predeterminado de equilibrio de carga dentro de entornos de contenedores y para muchos servicios de equilibrio de carga nativos de la nube.

Persistencia

Sesiones persistentes y SSL

Una de las realidades de las aplicações de tres niveles es que, por regla general, tienen estado. Esto significa que almacenan información entre solicitudes y respuestas que es fundamental para el funcionamiento de la aplicação. Su carrito de compras, sus credenciales, su estado, la última página que visitó y en qué paso del proceso se encuentra son todos datos que a menudo se almacenan como parte de la “sesión”. El problema es que muchas aplicaciones desarrolladas utilizando marcos de tres niveles terminaron almacenando esa sesión en la aplicação o en el servidor web, y no en una base de datos. Eso significaba que una vez que te conectabas a un servidor, tenías que volver a ese servidor para asegurarte de que toda tu información estuviera disponible.

Los balanceadores de carga implementan la persistencia de diversas maneras, siendo la más popular la basada en cookies. Los identificadores de sesión se almacenaban en una cookie que luego utilizaba el balanceador de carga para garantizar que las solicitudes llegaran al servidor correcto, omitiendo efectivamente un proceso de selección algorítmico.

Cuando el uso de SSL/TLS se convirtió en un requisito crítico para que los compradores se sintieran seguros, surgieron los mismos problemas. SSL/TLS permite una sesión segura entre un cliente y un servidor de aplicaciones específico. Para garantizar que ambos lados de la conversación pudieran descifrar y utilizar los datos intercambiados a través de esa conexión, el balanceador de carga tenía que poder enviar solicitudes de clientes al mismo servidor en el que se inició. Utilizando las mismas técnicas que permiten la persistencia basada en sesiones, los balanceadores de carga pudieron soportar la persistencia basada en SSL/TLS.

Independientemente del tipo específico de persistencia utilizado, el patrón es el mismo. Si existe un indicador de que ya se ha establecido una sesión, el balanceador de carga respeta la conexión existente y garantiza que permanezca mientras dure la sesión del usuario. Si no lo hay, el balanceador de carga selecciona un recurso según su configuración y algoritmos y realiza la conexión.

Esto tiene consecuencias en la planificación de la capacidad al seleccionar un algoritmo de equilibrio de carga. La menor cantidad de conexiones es una buena opción para este escenario, ya que garantiza que ningún recurso se sobrecargue con sesiones en curso mientras otros permanecen inactivos. Con otros algoritmos existe la posibilidad de que un solo recurso termine manteniendo muchas sesiones de usuario al mismo tiempo, lo que tiene un impacto negativo en el rendimiento de todos los usuarios dirigidos a ese servidor.

Equilibrio de carga basado en host

Servidores virtuales

El equilibrio de carga basado en host es uno de los patrones de escalabilidad más comunes y ampliamente admitidos. Podrías pensar que no necesitas un balanceador de carga para implementar esto, ya que todos los servidores web admiten la capacidad de hacerse pasar por múltiples hosts al mismo tiempo. Pero lo haces. Si bien un servidor web/de aplicaciones puede alojar varios servidores virtuales, no necesariamente equilibra la carga entre ellos. Por lo tanto, todavía necesitas un balanceador de carga para escalar. La pregunta es: ¿el balanceador de carga dividirá los hosts o dejará eso en manos del servidor web/aplicación?

Ya sea que se utilicen directivas de servidor web/aplicación o un balanceador de carga externo, el flujo sigue siendo el mismo. Se realiza una solicitud y el destino (balanceador de carga o servidor web/aplicación) la recibe. Luego, el servidor de destino inspecciona los encabezados HTTP y encuentra el valor del host antes de dirigir la solicitud al servidor virtual apropiado. 

La ventaja de utilizar un balanceador de carga para dividir hosts radica en su capacidad de permitir el aislamiento de dominios en función del host y escalarlos individualmente. Esto es más eficiente y puede reducir la cantidad de servidores (hardware y software) que necesita para escalar una aplicação. Además, facilita la planificación de la capacidad, ya que puede predecir mejor qué carga puede soportar cada servidor host en un momento determinado.

Esto se debe a que invocar la lógica empresarial no es lo mismo en términos de procesamiento requerido que solicitar una imagen. La mezcla y combinación de hosts en el mismo dominio de escalabilidad genera una carga volátil y una capacidad impredecible. Si decide utilizar un equilibrador de carga para proporcionar un equilibrio de carga tradicional, entonces el servidor web/de aplicaciones es responsable de dividir los hosts y dirigir las solicitudes al servidor virtual apropiado. Otras desventajas de este enfoque es la de una infraestructura compartida, con conflictos de versiones y parches, así como actualizaciones de aplicaciones que pueden causar fricción entre servidores virtuales.

La creciente adopción de contenedores y microservicios está impulsando el uso del equilibrio de carga basado en host en forma de controladores de ingreso .

Ruta y regreso 

Equilibrio de carga de capa 7 (HTTP)

El equilibrio de carga de capa 7 (HTTP) es mi favorito gracias a la versatilidad (¿agilidad?) que ofrece. Puede equilibrar la carga de las solicitudes en función de cualquier dato HTTP, incluida la carga útil. La mayoría de las personas (inteligentemente, en mi opinión) restringen sus reglas de equilibrio de carga a lo que se puede encontrar en el encabezado HTTP. Esto incluye el host, el método HTTP, el tipo de contenido, las cookies, los encabezados personalizados y el agente de usuario, entre otros.

El equilibrio de carga HTTP tiene que ver primero con el enrutamiento y luego con el equilibrio de carga. Un patrón típico de equilibrio de carga HTTP toma la forma de ruta -> distribuir. Esto significa que primero se toma una decisión sobre a qué servidor virtual se debe dirigir una solicitud y luego un algoritmo selecciona un recurso del conjunto que respalda ese servidor virtual.

El equilibrio de carga HTTP permite patrones como el control de versiones de API, donde la versión de API está integrada en la URI (o en un encabezado HTTP personalizado). El equilibrador de carga puede separar versiones y garantizar que los clientes se envíen al servicio back-end correcto para su ejecución. Esta migración de clientes es siempre elegante en situaciones en las que no es posible forzar la actualización.

Este tipo de patrón de escalabilidad también admite otros patrones de escalabilidad como la descomposición funcional y la partición de datos. Es el patrón de escalabilidad más robusto y ágil de la combinación y permite una amplia gama de opciones al escalar aplicaciones y, cada vez más, microservicios.

En resumen, tenemos cinco patrones principales de escalabilidad, la mayoría de los cuales se pueden combinar (y a menudo se combinan) para permitir el uso más eficiente de los recursos y el mayor rendimiento posible. Lo más probable es que si no estás usando uno de ellos ahora, lo harás, por lo que comprender su composición básica es una buena base para construir una arquitectura escalable sin importar qué tipo de aplicaciones estés usando o dónde las tengas implementadas.

¡Escala activada!