Conoce las diferencias entre las distintas infraestructuras de gestión y distribución de tráfico: API Gateway vs Load Balancer vs Reverse Proxy.

Escalado de aplicaciones web

Con el paso del tiempo, las aplicaciones basadas en la web y los servicios que ofrecen han ido incrementado tanto en escala como en complejidad. Aunque era lo habitual años atrás, la idea de mantener un proyecto grande funcionando con un solo servidor es algo cada vez menos realista.

Para manejar mayores volúmenes de tráfico tenemos dos formas diferentes de escalado: el escalado vertical y el escalado horizontal.

Escalado vertical

Básicamente consiste en mejorar el hardware sobre el que corre nuestro proyecto, añadiendo más memoria, más CPU, más disco duro, más tarjetas de red… Antiguamente era la forma más barata de escalar y a día de hoy es una opción poco realista, ya que a medida que la demanda del servicio web aumenta, puede llegar un punto en el que el escalado vertical ya no sea suficiente para satisfacer las necesidades de rendimiento y disponibilidad del proyecto.

Escalado horizontal

Consiste en agregar más servidores o instancias de manera distribuida para manejar la carga. Esto permite una mayor flexibilidad y capacidad para adaptarse a cambios en la demanda, así como una mayor tolerancia a fallos, ya que los servidores individuales pueden fallar sin degradar significativamente la disponibilidad del servicio.

Infraestructuras de Gestión y Distribución de Tráfico

Es aquí, en las estrategias de escalado horizontal, donde juegan un papel importante las infraestructuras de gestión y distribución de tráfico, ya que gracias a ellas podemos controlar el flujo de datos y distribuir la carga de manera eficiente entre múltiples servidores o instancias, garantizando así un rendimiento óptimo y una alta disponibilidad del servicio.

Vamos a ver tres de las más conocidas: Reverse Proxy (Proxy inverso), API Gateway (Puerta de acceso) y Load Balancer (balanceador de carga).

Si no te has visto en la necesidad de utilizarlas, es posible que tengas dudas sobre qué hace cada una de ellas o en qué se diferencian, así que vamos a ver las características y usos de cada una de ellas.

Reverse Proxy

Empezamos por el más simple de los tres, el reverse proxy o proxy inverso.

El reverse proxy básicamente es un servidor que actúa como intermediario entre los clientes y el/los servidore/s de destino. En lugar de establecerse una comunicación directa entre cliente y servidor, el cliente conecta con el reverse proxy y éste se encarga de pasar la petición al servidor y devolver la respuesta correspondiente a los clientes.

¿Con qué propósito usamos un reverse proxy?

• Seguridad. Actúa como una barrera entre los clientes y los servidores de destino, ocultando la estructura interna de la red y proporcionando una capa adicional de seguridad contra ataques maliciosos.
• Cacheo de contenido estático. Almacena en caché el contenido estático como imágenes, archivos CSS y JavaScript para reducir la carga en los servidores de origen y mejorar los tiempos de carga de la página.
• Terminación SSL/TLS. Gestiona las conexiones SSL/TLS de los clientes y las termina en el proxy antes de reenviar las solicitudes a los servidores de destino, lo que simplifica la gestión de certificados SSL/TLS y mejora el rendimiento de los servidores. De esta forma la conexión HTTPS es únicamente entre el cliente y el proxy. Esto es especialmente útil cuando el reverse proxy enmascara más de un servidor.
• Balanceo de carga. Sí, así es, el reverse proxy se puede usar como balanceador de carga, ya que distribuye el tráfico entrante entre varios servidores de destino para mejorar la escalabilidad y la disponibilidad del servicio.

La función de proxy inverso la realizan la mayoría de servidores web comerciales, como NGINX, Apache y Microsoft IIS, y también software específico como HAProxy.

Load Balancer

Un balanceador de carga (o Load Balancer en inglés) es un dispositivo o software que distribuye el tráfico de red entrante entre múltiples servidores, con el objetivo de mejorar el rendimiento, la disponibilidad y la fiabilidad de una aplicación o servicio web.

Al igual que en el caso del reverse proxy, actúa como un intermediario entre el cliente y (en este caso) los servidores, ya que no es solo uno sino varios los servidores que oculta el load balancer. Al ser varios servidores, se paralelizan las peticiones y se puede manejar un flujo de peticiones mucho mayor

¿Con qué propósito usamos un balanceador de carga?

• Distribución de carga. Distribuye el tráfico de red entre varios servidores para evitar la sobrecarga de uno solo y garantizar un uso equitativo de los recursos disponibles.
• Mejora del rendimiento. Al distribuir la carga de trabajo entre múltiples servidores, un balanceador de carga puede mejorar el tiempo de respuesta y el rendimiento general de una aplicación o servicio.
• Alta disponibilidad. Si un servidor falla, el balanceador de carga puede redirigir automáticamente el tráfico a servidores alternativos que estén funcionando correctamente, lo que garantiza la disponibilidad continua del servicio.
• Escalabilidad. Facilita la adición o eliminación dinámica de servidores según las necesidades de carga, lo que permite escalar horizontalmente la infraestructura de manera flexible.

¿Cómo reparte la carga un balanceador?

Dependiendo de su implementación, puede utilizar algoritmos de balanceo de carga simples, como round-robin (cada solicitud se envía a los servidores en secuencia) o algoritmos más avanzados que consideran la carga actual de los servidores (latencia) entre otros factores.

Los algoritmos de distribución de carga más habituales incluyen:

• Round Robin. Este algoritmo distribuye las solicitudes de manera uniforme entre los servidores en secuencia. Cada solicitud se envía al siguiente servidor en la lista, y cuando se alcanza el último servidor, se vuelve al principio.
• Least Connections (Menos Conexiones). Este algoritmo dirige las nuevas solicitudes al servidor con la menor cantidad de conexiones activas en ese momento. Es útil para distribuir la carga de manera más equitativa, considerando la carga real de cada servidor.
• Least Response Time (Menor Tiempo de Respuesta). Similar al algoritmo de Menos Conexiones, este enfoque dirige las solicitudes al servidor que tiene el menor tiempo de respuesta en ese momento. Ayuda a maximizar la capacidad de respuesta y el rendimiento general del sistema.
• IP Hashing (Hashing de IP). Este algoritmo utiliza la dirección IP del cliente para determinar a qué servidor enviar la solicitud. De esta manera, todas las solicitudes de un cliente particular se envían siempre al mismo servidor, lo que puede ser útil para mantener la sesión de un usuario en un servidor específico.
• Weighted Round Robin (Round Robin Ponderado). Este algoritmo asigna un peso a cada servidor en función de su capacidad de procesamiento, y luego distribuye las solicitudes en función de esos pesos. Los servidores con mayor capacidad recibirán una mayor proporción de solicitudes.
• Random (Aleatorio). Este algoritmo elige aleatoriamente un servidor para manejar cada solicitud entrante. Aunque simple, puede no ser la opción más eficiente en términos de distribución de carga equitativa.

¿Cómo manejamos las sesiones con un balanceador de carga?

Si el servicio que estamos enmascarando con nuestro balanceador requiere de una sesión, corremos el peligro de que en las siguientes peticiones un mismo cliente sea redirigido a otro servidor que no tenga su sesión guardada, y esto puede producir cierto malestar en el usuario al estar constantemente pidiéndole iniciar sesión de nuevo.

Para ello, los balanceadores de carga cuentan con una característica conocida como sticky bit, que permite que las solicitudes de un cliente se dirijan siempre al mismo servidor durante la duración de una sesión específica, es decir, garantiza la persistencia de sesión al asociar un cliente con un servidor particular.

Cuando se habilita el sticky bit, el balanceador de carga utiliza una técnica, como el hashing de la dirección IP del cliente o la inserción de una cookie en el navegador del cliente, para identificar y asociar al cliente con un servidor específico. Como resultado, todas las solicitudes posteriores de ese cliente durante la misma sesión se redirigen al mismo servidor, lo que asegura una experiencia coherente para el usuario y permite que las sesiones persistan correctamente a través de múltiples solicitudes.

Podemos encontrar implementaciones de balanceadores de carga en las principales plataformas cloud, como AWS Elastic Load Balancer (ELB), Microsoft Azure Load Balancer y Cloud Load Balancing de Google.

API Gateway

Por último, un API Gateway es un componente de software que actúa como punto de entrada único (single entry point) para una variedad de servicios y APIs dentro de una arquitectura de microservicios o de servicios distribuidos. Funciona como una capa intermedia entre clientes y múltiples servicios, proporcionando una interfaz unificada y facilitando la gestión, seguridad, supervisión y orquestación de las solicitudes y respuestas entre ellos.

¿Cómo funciona un API Gateway?

El funcionamiento de un API Gateway ya es algo más complejo que los casos anteriores. De base podemos entender sus similitudes con el balanceador de carga, pero con un matiz muy importante: tras un API Gateway hay distintos servicios que, además, pueden funcionar con diferentes protocolos. De hecho, un API Gateway puede estar encubriendo un servicio que usa internamente un balanceador de carga para repartir la carga del servicio entre distintas instancias o servidores (hablamos por supuesto de magnitudes de tráfico enormes).

Veamos los pasos básicos de su funcionamiento:

1. Recepción de solicitudes. El API Gateway recibe las solicitudes de los clientes y las enruta a los servicios correspondientes basándose en reglas de enrutamiento configuradas.
2. Traducción de protocolos. Puede traducir los protocolos de comunicación, por ejemplo, convirtiendo solicitudes HTTP en llamadas a servicios internos usando protocolos como gRPC o Thrift.
3. Autenticación y autorización. Gestiona la autenticación y la autorización de los clientes, verificando las credenciales y aplicando políticas de acceso antes de enviar las solicitudes a los servicios subyacentes.
4. Agregación de datos. Puede combinar múltiples llamadas a servicios internos para formar una única respuesta para el cliente, reduciendo así la latencia y el tráfico de red.
5. Monitorización y análisis. Recopila métricas y registros de las solicitudes y respuestas para facilitar la supervisión, el análisis de rendimiento y la solución de problemas.

¿Con qué propósito usamos un balanceador de carga?

• Unificación de interfaces. Proporciona una única interfaz para los clientes, simplificando su interacción con un conjunto diverso de servicios internos.
• Gestión de versiones. Permite la introducción y el control de versiones de APIs, lo que facilita la evolución de los servicios subyacentes sin afectar a los clientes.
• Seguridad centralizada. Implementa políticas de seguridad centralizadas, como autenticación, autorización y cifrado, para todos los servicios internos.
• Orquestación y transformación. Permite la orquestación de solicitudes a través de múltiples servicios internos y la transformación de datos según sea necesario.
• Escalabilidad y disponibilidad. Puede distribuir la carga de manera equitativa entre múltiples instancias de servicios internos, mejorando así la escalabilidad y la disponibilidad del sistema.

Problemas comunes

Una infraestructura tan compleja no está exenta de problemas, veamos cuales son los más comunes:

1. Cuellos de botella de rendimiento. Un API Gateway puede convertirse en un cuello de botella si no se dimensiona adecuadamente para manejar la carga de solicitudes entrantes.
2. Complejidad de configuración. Configurar y mantener reglas de enrutamiento, políticas de seguridad y transformaciones de datos puede volverse complejo a medida que aumenta la cantidad de servicios y funcionalidades implementadas.
3. Puntos únicos de fallo. Si un API Gateway es el único punto de entrada para todos los servicios, un fallo en él puede afectar la disponibilidad de todo el sistema.
4. Sobrecarga de red: El enrutamiento de todas las solicitudes a través del API Gateway puede introducir una sobrecarga adicional en la red, especialmente en entornos distribuidos a gran escala.

De nuevo, podemos encontrar implementaciones de API Gateway en los principales proveedores de cloud como AWS API Gateway, Azure API Management o Google Cloud API Gateway (Apigee), así como soluciones Open Source como Kong.

Conclusiones

Como hemos podido ver, aunque similares en su propósito, estas tres infraestructuras de gestión y distribución de tráfico tienen usos muy distintos y trabajan de formas muy diferentes.

Es importante saber elegir en cada caso cuál necesitamos, ya que elegir mal puede derivar en añadir un extra de complejidad a nuestro proyecto, además de salirnos caro el error (económicamente hablando).

Recordad, empezad siempre por lo mínimo necesario, ¡siempre habrá tiempo de escalar más alto!