Cómo elegir el balanceador de carga adecuado en Amazon: Balanceador de carga de aplicação de AWS frente a... NGINX Plus
En agosto de 2016, Amazon Web Services (AWS) presentó Aplicação Load Balancer para equilibrar la carga de capa 7 del tráfico HTTP y HTTPS. El nuevo producto agregó varias características que faltaban en el balanceador de carga de capa 4 y capa 7 existente de AWS, Elastic Load Balancer, que pasó a llamarse oficialmente Classic Load Balancer.
Un año después, AWS lanzó Network Load Balancer para mejorar el equilibrio de carga de capa 4, por lo que el conjunto de opciones para los usuarios que ejecutan aplicações escalables y de alta disponibilidad en AWS incluye:
- NGINX de código abierto y NGINX Plus
- Balanceo de carga clásico
- Balanceador de carga de aplicação (ALB)
- Balanceador de carga de red (NLB)
En esta publicación, revisamos las características de ALB y comparamos sus precios y características con NGINX Open Source y NGINX Plus.
Notas –
- La información sobre las funciones compatibles es precisa a julio de 2020, pero está sujeta a cambios.
- Para una comparación directa de NGINX Plus y Classic Load Balancer (anteriormente Elastic Load Balancer o ELB), así como información sobre su uso conjunto, consulte nuestra publicación de blog anterior .
- Para obtener información sobre el uso de NLB para una implementación de NGINX Plus de alta disponibilidad, consulte nuestra publicación de blog anterior .
Características del balanceador de carga de aplicação
ALB, como 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 gama de funciones, ajustes y control directo que un proxy inverso y balanceador de carga de capa 7 independientes pueden ofrecer.
ALB proporciona las siguientes características que faltan en Classic Load Balancer:
- Enrutamiento basado en contenido. ALB admite el enrutamiento basado en contenido según la URL de la solicitud, el encabezado
del hosty los campos de la solicitud que incluyen encabezados y métodos HTTP estándar y personalizados, parámetros de consulta y dirección IP de origen. (Consulte “Beneficios de migrar desde un balanceador de carga clásico” en la documentación de ALB ). - Soporte para aplicações basadas en contenedores. ALB mejora el soporte existente para los contenedores alojados en el Servicio de contenedores EC2 (ECS) de Amazon.
- Más métricas. Puede recopilar métricas por microservicio.
- Compatibilidad con WebSocket. ALB admite conexiones TCP persistentes entre un cliente y un servidor.
- Compatibilidad con HTTP/2. ALB admite HTTP/2, una alternativa superior para entregar contenido protegido por SSL/TLS.
(Para obtener una comparación completa de las características de ALB y Classic Load Balancer, consulte “Comparaciones de productos” en la documentación de AWS ).
ALB fue una actualización importante para los usuarios de AWS que habían tenido dificultades con el conjunto limitado de características de Classic Load Balancer y contribuyó en cierta medida a abordar los requisitos de los usuarios sofisticados que necesitan poder proteger, optimizar y controlar el tráfico a sus aplicações web. Sin embargo, todavía no proporciona todas las capacidades de los servidores proxy inversos dedicados (como NGINX) y de los balanceadores de carga (como NGINX Plus).
Un mejor enfoque 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 la carga del tráfico. También pueden implementar Classic Load Balancer o Network Load Balancer como interfaz para lograr alta disponibilidad en múltiples zonas de disponibilidad. La tabla compara las características compatibles con ALB, NGINX y NGINX Plus.
Nota: La información contenida en la siguiente tabla es precisa a julio de 2020, pero está sujeta a cambios.
| Amazon ALB | NGINX Open Source | NGINX Plus | |
|---|---|---|---|
| Equilibrio de carga métodos y características |
Métodos round_robin y less_outstanding_requests , con persistencia de sesión basada en cookies, grupos objetivo ponderados e inicio lento |
Múltiples métodos de equilibrio de carga (incluidos Round Robin, Menos conexiones, Hash, Hash de IP y Aleatorio) con servidores ascendentes ponderados | Igual que NGINX de código abierto, más el método de menor tiempo, más métodos de persistencia de sesión e inicio lento |
| Almacenamiento en caché | ❌ No se admite el almacenamiento en caché en el balanceador de carga | ✅ Almacenamiento en caché de archivos estáticos y dinámicos (de aplicação) | ✅ Almacenamiento en caché estático y dinámico, además de funciones avanzadas |
| Comprobaciones de estado | Activo (identifica los servidores fallidos al verificar el código de estado devuelto para las verificaciones asincrónicas) | Pasivo (identifica servidores fallidos al verificar las respuestas a las solicitudes de los clientes) | Tanto activas como pasivas: las comprobaciones activas son más completas y configurables que las de ALB. |
| Alta disponibilidad | Puede implementar instancias de ALB en múltiples zonas de disponibilidad para HA, pero no en diferentes regiones | HA activo-activo con NLB y HA activo-pasivo con direcciones IP elásticas | Igual que NGINX de código abierto, más uso compartido de estado de clúster integrado para una alta disponibilidad sin inconvenientes 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 aplicações por instancia de balanceador de carga | ✅ | ✅ | |
| Enrutamiento basado en contenido | ✅ Basado en la URL de solicitud, el encabezado del host y los campos de solicitud, incluidos encabezados HTTP estándar y personalizados, métodos, parámetros de consulta y dirección IP de origen |
✅ Basado en los mismos factores que ALB, más cookies y cálculos dinámicos utilizando el módulo JavaScript NGINX como motor JavaScript en línea | ✅ Basado en los mismos factores que NGINX Open Source, además de afirmaciones JWT y valores en el almacén de clave-valor |
| Aplicações en contenedores | Puede equilibrar la carga de ID de Amazon, instancias de contenedor ECS, grupos de escalado automático 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, prueba y producción) deben estar en AWS | ✅ Cualquier entorno puede estar en cualquier plataforma de implementación | |
| SSL/TLS | ✅ Múltiples certificados SSL/TLS con soporte SNI ❌ No se admite la validación de flujos ascendentes SSL/TLS |
✅ Múltiples certificados SSL/TLS con soporte SNI ✅ Elección completa de cifrados SSL/TLS ✅ Validación completa de los upstreams SSL/TLS |
|
| HTTP/2 y WebSocket | ✅ | ✅ | |
| Capacidades de autenticación | – Opciones de autenticación de OIDC, SAML, LDAP y AD IdP – Integrado con AWS Cognito y CloudFront |
Múltiples opciones de autenticación | |
| Capacidades avanzadas | ❌ API básica | ✅ Servicio de origen, priorización, limitación de velocidad y más | ✅ Igual que NGINX de código abierto, más API RESTful, almacén de clave-valor |
| Registro y depuración | ✅ Formato de registro binario de Amazon | ✅ Archivos de registro personalizables y múltiples interfaces de depuración | ✅ Archivos de registro totalmente personalizables y múltiples interfaces de depuración, totalmente compatibles con NGINX |
| Herramientas de monitorización | ✅ Integrado con Amazon CloudWatch | ✅ Controlador NGINX* y otras herramientas de terceros | ✅ Controlador NGINX y otras herramientas de terceros; conjunto ampliado de estadísticas informadas |
| Soporte técnico oficial | ✅ Con coste adicional | ❌ Solo soporte de la comunidad | ✅ Incluido en el precio y directamente desde NGINX |
| Nivel gratuito | ✅ Primeras 750 horas | ✅ Siempre gratis | ✅ Suscripción de prueba de 30 días |
* NGINX Controller ahora es F5 NGINX Management Suite .
Por supuesto, debe evaluar su elección de equilibrio de carga no mediante una lista de características, sino evaluando las capacidades que necesita para entregar sus aplicações sin problemas, con alta seguridad, máxima disponibilidad y control total.
Manejo de picos de tráfico
El balanceador de carga clásico de Amazon (anteriormente ELB) sufrió una respuesta deficiente a los picos de tráfico. Las instancias del balanceador de carga se dimensionaron automáticamente para el nivel actual de tráfico, y podría tomar muchos minutos para que ELB respondiera e implementara capacidad adicional cuando ocurrían picos. Los usuarios tuvieron que recurrir a un proceso manual basado en formularios para solicitar recursos adicionales antes de los picos de tráfico (lo que se conoce como “precalentamiento”). Debido a que ALB se basa en NGINX, las instancias de ALB pueden manejar mucho más tráfico, pero aún es posible que se observen eventos de escalamiento en respuesta a picos de tráfico. Además, un pico de tráfico genera automáticamente un mayor consumo de unidades de capacidad del balanceador de carga (LCU) y, en consecuencia, un mayor costo.
Puede obtener control total sobre la capacidad y el costo si implementa y escala usted mismo sus servidores proxy de equilibrio de carga. NGINX y NGINX Plus se implementan dentro de instancias estándar de Amazon, y nuestra guía de dimensionamiento brinda una indicación del rendimiento máximo potencial de los tipos de instancias con diferentes capacidades. El precio de NGINX Plus es el mismo para todos los tamaños de instancias, por lo que es rentable implementar capacidad excedente para manejar picos, y es rápido implementar más instancias (sin formularios para completar) cuando se necesita más capacidad.
Detección de servidores fallidos mediante comprobaciones de estado
Nuestras pruebas de Amazon ALB indican que no implementa controles de estado “pasivos”. Solo se detecta que un servidor ha fallado cuando una prueba asincrónica verifica que no está devolviendo el código de estado esperado.
Descubrimos esto al crear una instancia ALB para equilibrar la carga de un clúster de instancias. Configuramos un control de estado con una frecuencia mínima de 5 segundos y un umbral mínimo de 2 controles fallidos, y enviamos un flujo constante de solicitudes al ALB. Cuando detuvimos una de las instancias, para algunas solicitudes ALB devolvió un 502 Malo Puerta Error durante varios segundos hasta que la verificación de estado detectó que la instancia estaba inactiva. Los controles de salud pasivos (compatibles con NGINX y 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 inspeccionando el código de estado HTTP (como 200OK o 404Extraviado ) . Estos controles de salud no son confiables; por ejemplo, algunas aplicações web reemplazan los errores generados por el servidor con páginas fáciles de usar y algunos errores solo se informan en el cuerpo de una página web.
NGINX Plus admite verificaciones de estado tanto pasivas como activas , y estas últimas son más potentes que las de ALB y pueden coincidir con el cuerpo de una respuesta, así como con el código de estado.
Precios
Finalmente, la pregunta más importante a la que te enfrentas si implementas ALB es el costo. El equilibrio de carga puede ser una parte importante de su factura de Amazon .
AWS utiliza un algoritmo complicado para determinar los precios . A menos que sepas con precisión cuántas conexiones nuevas, cuántas conexiones simultáneas y cuántos datos administrarás cada mes (lo cual es muy difícil de predecir) y puedas ejecutar el cálculo de LCU de la misma manera que lo hace Amazon, temerás recibir tu factura de Amazon cada mes.
NGINX Plus en AWS le ofrece previsibilidad total. Por un costo fijo por hora más los cargos de alojamiento de AWS, obtiene una solución de equilibrio de carga significativamente más potente con soporte completo.
CONCLUSIÓN
NGINX Plus es una solución probada para el equilibrio de carga de capa 7, con funciones de equilibrio de carga de capa 4 también. Funciona bien en conjunto con el Classic Load Balancer o NLB de Amazon.
Fomentamos el uso continuo y creciente de NGINX y NGINX Plus en el entorno de AWS, una solución ya muy popular. Si aún no es usuario de NGINX Plus, comience hoy su prueba gratuita de 30 días o contáctenos para analizar sus casos de uso .
"Esta publicación de blog puede hacer referencia a productos que ya no están disponibles o que ya no reciben soporte. Para obtener la información más actualizada sobre los productos y soluciones F5 NGINX disponibles, explore nuestra familia de productos NGINX . NGINX ahora es parte de F5. Todos los enlaces anteriores de NGINX.com redirigirán a contenido similar de NGINX en F5.com.