Cómo elegir el balanceador de carga adecuado en Amazon: AWS Application Load Balancer frente a NGINX Plus

NGINX | 21 de julio de 2020

Owen GarrettDirector sénior de Gestión de Producto

En agosto de 2016, Amazon Web Services (AWS) presentó Application Load Balancer para el balanceo de carga de capa 7 del tráfico HTTP y HTTPS. El nuevo producto incorporó varias funciones que no estaban disponibles en Elastic Load Balancer, el balanceador de carga de capas 4 y 7 que AWS ya ofrecía y que pasó a denominarse oficialmente Classic Load Balancer.

Un año después, AWS lanzó Network Load Balancer para mejorar el balanceo de carga de capa 4, por lo que las opciones disponibles para los usuarios que ejecutan aplicaciones escalables y de alta disponibilidad en AWS incluyen:

En este artículo, analizamos las funcionalidades de ALB y comparamos sus precios y funcionalidades con los de NGINX Open Source y NGINX Plus.

Notas –

La información sobre las funciones compatibles es correcta a fecha de julio de 2020, pero está sujeta a cambios. Para consultar una comparación directa entre NGINX Plus y Classic Load Balancer (anteriormente Elastic Load Balancer o ELB), así como información sobre cómo utilizarlos conjuntamente, consulte nuestra entrada anterior del blog. Para obtener información sobre el uso de NLB en una implementación de NGINX Plus de alta disponibilidad, consulte nuestra entrada anterior del blog.

Características de Application Load Balancer

ALB, al igual que Classic Load Balancer o NLB, está estrechamente integrado en AWS. Amazon lo describe como un balanceador de carga de capa 7, aunque no ofrece toda la variedad de funciones, opciones de ajuste y control directo que puede proporcionar un proxy inverso y balanceador de carga de capa 7 independiente.

ALB ofrece las siguientes funciones que no están disponibles en Classic Load Balancer:

Enrutamiento basado en el contenido. ALB admite el enrutamiento basado en el contenido en función de la URL de la solicitud, el encabezado Host, y los campos de la solicitud, incluidos los encabezados HTTP estándar y personalizados, los métodos HTTP, los parámetros de consulta y la dirección IP de origen. (Consulte «Ventajas de migrar desde un Classic Load Balancer» en la documentación de ALB.)
Compatibilidad con aplicaciones basadas en contenedores. ALB mejora la compatibilidad existente con los contenedores alojados en Amazon EC2 Container Service (ECS).
Más métricas. Puede recopilar métricas para cada microservicio.
Compatibilidad con WebSocket. ALB admite conexiones TCP persistentes entre un cliente y un servidor.
Compatibilidad con HTTP/2. ALB es compatible con HTTP/2, una alternativa superior para entregar contenido protegido mediante SSL/TLS.

(Para consultar una comparación completa de las características de ALB y Classic Load Balancer, véase «Comparaciones de productos» en la documentación de AWS.)

ALB supuso una actualización importante para los usuarios de AWS que habían tenido dificultades con el limitado conjunto de funciones de Classic Load Balancer, y contribuyó en cierta medida a satisfacer las necesidades de los usuarios avanzados que requieren proteger, optimizar y controlar el tráfico de sus aplicaciones web. Sin embargo, sigue sin ofrecer todas las prestaciones de los proxies inversos dedicados (como NGINX) y los balanceadores de carga (como NGINX Plus).

Un enfoque mejor para controlar el tráfico en AWS

En lugar de utilizar Amazon ALB, los usuarios pueden implementar NGINX Open Source o NGINX Plus en AWS para controlar y equilibrar el tráfico. También pueden implementar Classic Load Balancer o Network Load Balancer como frontend para lograr una alta disponibilidad en varias zonas de disponibilidad. La tabla compara las funcionalidades compatibles con ALB, NGINX y NGINX Plus.

Nota: La información de la siguiente tabla es correcta a fecha de julio de 2020, pero está sujeta a cambios.

	Amazon ALB	NGINX Open Source	NGINX Plus
Métodos y funciones de balanceo de carga	Métodos `Round_robin` y `least_outstanding_requests`, con persistencia de sesión basada en cookies, grupos de destino ponderados y arranque lento	Varios métodos de balanceo de carga (incluidos Round Robin, Menos conexiones, Hash, Hash de IP y Aleatorio) con servidores ascendentes ponderados	Lo mismo que NGINX Open Source, además del método Menor tiempo, más métodos de persistencia de sesión y arranque lento
Almacenamiento en caché	❌ No se admite el almacenamiento en caché en el balanceador de carga	✅ Almacenamiento en caché de archivos estáticos y almacenamiento en caché dinámico (de aplicaciones)	✅ Almacenamiento en caché estático y dinámico, además de funciones avanzadas
Comprobaciones de estado	Activas (identifican los servidores con errores comprobando el código de estado devuelto en las comprobaciones asíncronas)	Pasivas (identifican los servidores con errores comprobando las respuestas a las solicitudes de los clientes)	Activas y pasivas; las comprobaciones activas ofrecen más funciones y opciones de configuración que las de ALB
Alta disponibilidad	Puede implementar instancias de ALB en varias zonas de disponibilidad para obtener alta disponibilidad, pero no entre regiones	Alta disponibilidad activa-activa con NLB y alta disponibilidad activa-pasiva con direcciones IP elásticas	Lo mismo que NGINX Open Source, además de uso compartido integrado del estado del clúster para ofrecer alta disponibilidad sin interrupciones en todas las instancias de NGINX Plus
Compatibilidad con todos los protocolos de la suite IP	❌ Solo HTTP y HTTPS	✅ También TCP y UDP, con comprobaciones de estado pasivas	✅ También TCP y UDP, con comprobaciones de estado activas y pasivas
Varias aplicaciones por instancia del balanceador de carga	✅	✅
Enrutamiento basado en contenido	✅ Basado en la URL de la solicitud, la cabecera `Host` y campos de la solicitud, incluidas cabeceras HTTP estándar y personalizadas, métodos, parámetros de consulta y dirección IP de origen	✅ Basado en los mismos factores que ALB, además de cookies y cálculos dinámicos mediante el módulo JavaScript de NGINX como motor JavaScript integrado	✅ Basado en los mismos factores que NGINX Open Source, además de notificaciones JWT y valores del almacén de clave-valor
Aplicaciones en contenedores	Puede balancear la carga entre ID de Amazon, instancias de contenedores de ECS, grupos de Auto Scaling y funciones de AWS Lambda	Requiere configuración manual o plantillas de configuración	Configuración automatizada mediante DNS, incluidos registros `SRV`; funciona con los principales servicios de registro
Portabilidad	❌ Todos los entornos (desarrollo, pruebas y producción) deben estar en AWS	✅ Cada entorno puede estar en cualquier plataforma de implementación
SSL/TLS	✅ Varios certificados SSL/TLS compatibles con SNI ❌ No se admite la validación de servidores ascendentes SSL/TLS	✅ Varios certificados SSL/TLS compatibles con SNI ✅ Selección completa de cifrados SSL/TLS ✅ Validación completa de servidores ascendentes SSL/TLS
HTTP/2 y WebSocket	✅	✅
Funciones de autenticación	– Opciones de autenticación OIDC, SAML, LDAP y proveedor de identidades de AD – Integración con AWS Cognito y CloudFront	Varias opciones de autenticación
Funciones avanzadas	❌ API básica	✅ Servicio de origen, priorización, limitación de velocidad y mucho más	✅ Lo mismo que NGINX Open Source, además de API RESTful y almacén de clave-valor
Registro y depuración	✅ Formato de registro binario de Amazon	✅ Archivos de registro personalizables y varias interfaces de depuración	✅ Archivos de registro totalmente personalizables y varias interfaces de depuración, con soporte completo de NGINX
Herramientas de supervisión	✅ Integración con Amazon CloudWatch	✅ NGINX Controller* y otras herramientas de terceros	✅ NGINX Controller y otras herramientas de terceros; conjunto ampliado de estadísticas notificadas
Soporte técnico oficial	✅ Con coste adicional	❌ Solo soporte de la comunidad	✅ Incluido en el precio y proporcionado directamente por NGINX
Nivel gratuito	✅ Primeras 750 horas	✅ Siempre gratuito	✅ Suscripción de prueba de 30 días

* NGINX Controller ahora es F5 NGINX Management Suite.

Por supuesto, no debe evaluar su elección de solución de equilibrio de carga basándose en una lista de funcionalidades, sino valorando las capacidades que necesita para ofrecer sus aplicaciones sin contratiempos, con un alto nivel de seguridad, la máxima disponibilidad y un control total.

Gestión de picos de tráfico

El balanceador de carga clásico de Amazon (anteriormente ELB) respondía de forma deficiente a los picos de tráfico. Las instancias del balanceador de carga se dimensionaban automáticamente según el nivel de tráfico existente en ese momento, y ELB podía tardar varios minutos en reaccionar y desplegar capacidad adicional cuando se producían picos. Los usuarios tenían que recurrir a un proceso manual basado en formularios para solicitar recursos adicionales antes de que se produjeran los picos de tráfico (lo que se denominaba «precalentamiento»). Dado que ALB se basa en NGINX, sus instancias pueden gestionar mucho más tráfico, aunque es posible que se sigan produciendo eventos de escalado en respuesta a los picos de tráfico. Además, un pico de tráfico aumenta automáticamente el consumo de unidades de capacidad del balanceador de carga (LCU) y, por tanto, el coste.

Puede tener un control total sobre la capacidad y los costes si implementa y escala usted mismo sus proxies de balanceo de carga. NGINX y NGINX Plus se implementan en instancias estándar de Amazon, y nuestra guía de dimensionamiento ofrece una estimación del rendimiento máximo potencial de los tipos de instancia con distintas capacidades. El precio de NGINX Plus es el mismo para todos los tamaños de instancia, por lo que resulta rentable implementar capacidad adicional para hacer frente a los picos de tráfico. Además, cuando se necesita más capacidad, se pueden implementar rápidamente más instancias, sin tener que rellenar formularios.

Detección de servidores con errores mediante comprobaciones de estado

Nuestras pruebas de Amazon ALB indican que no implementa comprobaciones de estado «pasivas». Solo se detecta que un servidor ha fallado cuando una prueba asíncrona verifica que no está devolviendo el código de estado esperado.

Lo descubrimos al crear una instancia de ALB para equilibrar la carga de un clúster de instancias. Configuramos una comprobación de estado con la frecuencia mínima de 5 segundos y el umbral mínimo de 2 comprobaciones fallidas, y enviamos un flujo constante de solicitudes al ALB. Cuando detuvimos una de las instancias, ALB devolvió, para algunas solicitudes, un error 502 Bad Gateway durante varios segundos, hasta que la comprobación de estado detectó que la instancia estaba inactiva. Las comprobaciones de estado pasivas (compatibles tanto con NGINX como con NGINX Plus) evitan que los usuarios finales vean este tipo de errores.

Las comprobaciones de estado de ALB solo pueden determinar el estado de una instancia examinando el código de estado HTTP (como 200 OK o 404 Not Found). Estas comprobaciones de estado no son fiables; por ejemplo, algunas aplicaciones web sustituyen los errores generados por el servidor por páginas más fáciles de entender para el usuario, y algunos errores solo se notifican en el cuerpo de una página web.

NGINX Plus admite comprobaciones de estado tanto pasivas como activas, y estas últimas son más potentes que las de ALB, ya que pueden comprobar tanto el cuerpo de una respuesta como el código de estado.

Precios

Por último, la cuestión más importante a la que se enfrenta si implementa ALB es el coste. El balanceo de carga puede representar una parte considerable de su factura de Amazon.

AWS utiliza un algoritmo complejo para determinar los precios. A menos que sepa exactamente cuántas conexiones nuevas y simultáneas habrá y cuántos datos gestionará cada mes —algo muy difícil de predecir—, y pueda realizar el cálculo de LCU de la misma forma que Amazon, temerá recibir la factura de Amazon cada mes.

NGINX Plus en AWS le ofrece una previsibilidad total. Por un coste fijo por hora más los gastos de alojamiento de AWS, obtiene una solución de balanceo de carga mucho más potente y con asistencia completa.

Conclusión

NGINX Plus es una solución de eficacia probada para el balanceo de carga de capa 7 que también ofrece funciones de balanceo de carga de capa 4. Funciona perfectamente junto con Classic Load Balancer o NLB de Amazon.

Fomentamos el uso continuado y creciente de NGINX y NGINX Plus en el entorno de AWS, donde ya son una solución muy popular. Si aún no utiliza NGINX Plus, inicie hoy mismo su prueba gratuita de 30 días o póngase en contacto con nosotros para hablar sobre sus casos de uso.