Equilibrio de carga de grupos de escalamiento automático de AWS con NGINX Plus

Una de las características más beneficiosas de la nube es la capacidad de escalar automáticamente el número de instancias de computación. Con AWS Auto Scaling , puede cambiar la cantidad de instancias EC2 en un grupo de Auto Scaling , ya sea de forma manual o automática, según el cronograma o la demanda. El escalamiento automático ayuda a reducir costos al ajustar la cantidad de instancias al número correcto para la carga de trabajo actual. Además, el escalado automático reinicia las instancias fallidas, lo que agrega resiliencia a sus aplicações.

El equilibrio de carga es crucial cuando se utiliza el escalado automático. AWS proporciona equilibrio de carga de instancias de grupos de Auto Scaling mediante la integración de sus balanceadores de carga integrados : Elastic Load Balancer (ELB), ahora llamado oficialmente Classic Load Balancer, y Aplicação Load Balancer (ALB), con Auto Scaling. NGINX Plus proporciona equilibrio de carga en la nube avanzado para cualquier entorno de nube, incluido AWS, y admite grupos de escalamiento automático de AWS.

Hay tres razones principales para elegir NGINX Plus como reemplazo o complemento a los balanceadores de carga en la nube de AWS integrados:

1. NGINX Plus ofrece múltiples funciones avanzadas de las que carecen ELB y ALB.
2. El modelo de precios de los balanceadores de carga de AWS (especialmente ALB) es complejo, lo que dificulta predecir los costos. El precio de NGINX Plus es sencillo, ya sea que compre la suscripción a NGINX Plus directamente con nosotros o ejecute instancias de NGINX Plus prediseñadas desde AWS Marketplace , que se facturan a una tarifa por hora fija.
3. NGINX Plus no lo vincula a API específicas de la plataforma, lo que le permite reutilizar la configuración de equilibrio de carga en múltiples plataformas de nube.

Para ver cómo NGINX Plus se compara con (y funciona junto con) las soluciones integradas de AWS, lea nuestras publicaciones de blog sobre ELB y ALB .

En esta publicación de blog mostramos dos métodos para configurar NGINX Plus para equilibrar la carga de grupos de escalado automático y explicamos cuándo tiene sentido usar cada método:

1. Uso de NGINX Plus delante de ELB
2. Uso de NGINX Plus con el software de integración proporcionado por NGINX, Inc.

Después de leer esta publicación de blog, estará listo para implementar NGINX Plus en AWS para proporcionar equilibrio de carga avanzado para grupos de escalamiento automático.

El entorno de escalamiento automático de AWS de muestra

Estamos utilizando un entorno de aplicação de muestra para ilustrar los dos métodos para usar NGINX Plus para equilibrar la carga de grupos de escalamiento automático. Nuestra aplicação web backend consta de dos servicios: Backend Uno y Backend Dos, cada uno expuesto en el puerto 80. Para cada servicio hay un grupo de escalamiento automático de múltiples instancias de aplicação . El balanceador de carga dirige las solicitudes del cliente al backend apropiado según la URI de la solicitud:

• Las solicitudes de /backend‑one van a Backend One.
• Las solicitudes de /backend‑two van a Backend Two.

Cuando escalamos los grupos de escalamiento automático de la aplicação (ya sea de forma automática o manual), la configuración del balanceador de carga debe actualizarse para reflejar la nueva cantidad de instancias de la aplicação . Los balanceadores de carga integrados de AWS hacen esto automáticamente. Para NGINX Plus, necesitamos propagar eventos de escalamiento a la configuración con uno de los métodos mencionados anteriormente (NGINX Plus frente a ELB, o NGINX Plus con el software de integración).

Otra forma de actualizar la configuración de NGINX Plus en respuesta a eventos de escalamiento es con un registro de servicio externo. NGINX Plus admite la integración con sistemas de descubrimiento de servicios que proporcionan una interfaz DNS , como Consul . En esta entrada de blog nos centramos en soluciones que no dependen del uso de sistemas externos y que son fáciles de configurar y utilizar.

Uso de NGINX Plus delante de ELB

Si ya está utilizando grupos de escalado automático y ELB, la forma más sencilla de incorporar algunas de las funciones avanzadas de NGINX Plus a su aplicação es colocar NGINX Plus delante de los balanceadores de carga en la nube ELB, como se muestra en el diagrama:

En este caso, NGINX Plus actúa como un proxy/balanceador de carga para uno o más ELB. Gracias a sus avanzadas capacidades de enrutamiento, NGINX Plus reenvía las solicitudes al ELB correspondiente según la URI de la solicitud. El ELB luego envía la solicitud a una de las instancias del grupo de escalado automático. En esta configuración, ELB proporciona soporte para escalamiento.

Aquí está la configuración de NGINX Plus.

resolver 169.254.169.253 válido=10s; upstream backend-one { zona backend-one 64k; servidor nombre-DNS-de-ELB-para-Backend-One resolver; } upstream backend-two { zona backend-two 64k; servidor nombre-DNS-de-ELB-para-Backend-Two resolver; } servidor { escuchar 80; ubicación /backend-one { proxy_set_header Host $host; proxy_pass http://backend-one; } ubicación /backend-two { proxy_set_header Host $host; proxy_pass http://backend-two; } }

• La directiva resolver define el servidor DNS que NGINX Plus utiliza para resolver los nombres DNS de las instancias ELB internas. Aquí está la dirección IP del servidor DNS de AWS.

• Creamos dos bloques upstream , uno para cada grupo de Auto Scaling correspondiente a nuestros servicios, Backend One y Backend Two. Identificamos el grupo de escalamiento automático por el nombre DNS del ELB que equilibra la carga del tráfico hacia él.

  Usando el parámetro de resolución , le indicamos a NGINX Plus que vuelva a resolver el nombre periódicamente (la frecuencia se establece mediante el parámetro válido en la directiva de resolución analizada en el punto anterior). Aquí lo establecemos en 10 segundos porque las direcciones IP de ELB están sujetas a cambios frecuentes.

  La directiva de zona asigna memoria (aquí hasta 64 KB) para almacenar las direcciones IP resueltas.

• Definimos un servidor virtual que escucha en el puerto 80. Los bloques de ubicación le indican a NGINX Plus que pase solicitudes para /backend‑one al ELB para el grupo de escalamiento automático de backend uno y solicitudes para /backend‑two al ELB para el grupo de escalamiento automático de backend dos.

Como puede ver, este método es fácil de configurar y usar, especialmente si ya está utilizando ELB. Sin embargo, existen varios inconvenientes:

• Opciones de equilibrio de carga limitadas. Debido a que NGINX Plus pasa solicitudes a ELB, no directamente a las instancias del backend, es ELB el que realiza el equilibrio de carga. Por este motivo, no puede aprovechar los algoritmos de equilibrio de carga más sofisticados y las opciones de persistencia de sesión de NGINX Plus.
• Redundancia. NGINX Plus puede equilibrar la carga, por lo que ELB es redundante: lo usamos solo porque está integrado de forma nativa con el escalado automático.
• Soporte de protocolo limitado. A diferencia de NGINX Plus, ELB no admite WebSocket ni UDP.

El siguiente método no depende de ELB y, en consecuencia, no tiene esas desventajas.

Uso de NGINX Plus con el software de integración

Con este método, instala software de integración adicional junto con NGINX Plus. El software ( nginx-asg-sync ) monitorea constantemente los grupos de escalamiento automático. Cuando detecta que se ha producido un evento de escalamiento, agrega o elimina instancias de backend de la configuración de NGINX Plus. Como se muestra, nginx-asg-sync obtiene información sobre los cambios en los grupos de escalamiento automático a través de la API de escalamiento automático de AWS.

Para utilizar el software de integración, realice los siguientes pasos:

1. Configurar el acceso a la API de AWS
2. Instalar el software de integración
3. Configurar NGINX Plus
4. Configurar el software de integración

Las instrucciones asumen que los grupos de escalamiento automático para los backends ya existen. También asumen que NGINX Plus se ejecuta en una AMI de Amazon Linux.

Paso 1: Configurar el acceso a la API de AWS

La comunicación con la API de escalamiento automático está autenticada, por lo que debe proporcionar credenciales para nginx-asg-sync . AWS usa roles de IAM para manejar credenciales, por lo que debe crear un rol para la instancia NGINX Plus antes de iniciarla. Para obtener instrucciones paso a paso, consulte Roles de IAM para Amazon EC2 en la documentación de AWS.

1. Cree una función de IAM y adjúntele la política predefinida AmazonEC2ReadOnlyAccess . Esta política permite acceso de solo lectura a las API de EC2.
2. Cuando inicie la instancia NGINX Plus, agregue esta función de IAM a la instancia.

Paso 2 – Instalar el software de integración

Para instalar el software de integración, descargue el paquete para su sistema operativo desde el repositorio de GitHub nginx-asg-sync e instálelo en la instancia donde se ejecuta NGINX Plus.

• Para Amazon Linux, CentOS y RHEL:

  $ sudo rpm -i nombre-del-paquete .rpm
  

• Para Ubuntu:

  $ sudo dpkg -i nombre-del-paquete .deb
  

Para obtener instrucciones de instalación completas, consulte la documentación en GitHub.

Paso 3 – Configurar NGINX Plus

El software de integración actualiza la configuración de NGINX Plus utilizando las API de reconfiguración dinámica y monitoreo de actividad en vivo . Para que el software funcione correctamente, debe configurar dichas API y también declarar los grupos ascendentes necesarios:

• Configure los puntos finales de API para la reconfiguración sobre la marcha y el monitoreo de actividad en vivo. El software de integración utiliza estos puntos finales para agregar y eliminar instancias de back-end de grupos ascendentes.
• Cree un bloque ascendente para cada grupo de escalamiento automático. No defina ningún servidor en el bloque, ya que nginx-asg-sync los agrega y los elimina automáticamente en respuesta a eventos de escalamiento.

El siguiente ejemplo representa la configuración de nuestra aplicação web sencilla:

backend-uno ascendente { zona backend-uno 64k;
estado /var/lib/nginx/state/backend-one.conf;
}

backend-dos ascendente {
zona backend-dos 64k;
estado /var/lib/nginx/state/backend-two.conf;
}

servidor {
escuchar 80;

estado_zona backend;

ubicación /backend-uno {
encabezado_proxy_set Host $host;
contraseña_proxy http://backend-uno;
}

ubicación /backend-dos {
encabezado_proxy_set Host $host;
contraseña_proxy http://backend-dos;
}
}

servidor {
escuchar 8080;

raíz /usr/share/nginx/html;

ubicación = / {
devolver 302 /estado.html;
}

ubicación = /estado.html {}

ubicación /estado {
desactivar acceso;
estado;
}

ubicación /configuración_de_subida {
configuración_de_subida;
}
}

• Al igual que en el ejemplo de ELB, declaramos dos grupos ascendentes: backend-one y backend-two , que corresponden a nuestros grupos de escalamiento automático. Aquí, sin embargo, no agregamos ningún servidor a los grupos ascendentes, porque los servidores serán agregados por nginx‑aws‑sync . La directiva estatal nombra el archivo donde se almacena la lista dinámicamente configurable de servidores, lo que le permite persistir luego de los reinicios de NGINX Plus.
• Definimos un servidor virtual que escucha en el puerto 80. A diferencia del ejemplo ELB, NGINX Plus pasa las solicitudes para /backend‑one directamente a las instancias del grupo Backend One, y las solicitudes para /backend‑two directamente a las instancias del grupo Backend Two.

• Definimos un segundo servidor virtual que escucha en el puerto 8080 y configuramos las API de NGINX Plus en él:

  • La API sobre la marcha está disponible en 127.0.0.1:8080/upstream_conf
  • La API de estado está disponible en 127.0.0.1:8080/status

Paso 4 – Configurar el software de integración

El software de integración se configura en el archivo aws.yaml en la carpeta /etc/nginx . Para nuestra aplicação, definimos la siguiente configuración:

Región: us-west-2upstream_conf_endpoint: http://127.0.0.1:8080/upstream_conf
estado_endpoint: http://127.0.0.1:8080/status
intervalo_de_sincronización_en_segundos: 5
Upstreams:
- nombre: backend-one
autoscaling_group: backend-one-group
puerto: 80
tipo: http
- nombre: backend-two
grupo_de_escalado_automático: grupo-backend-two
puerto: 80
tipo: http

• La clave de región define la región de AWS donde implementamos nuestra aplicação.
• Las claves upstream_conf_endpoint y status_endpoint definen los puntos finales de la API NGINX Plus, que configuramos en el Paso 3 .
• La clave sync_interval_in_seconds define el intervalo de sincronización: nginx-asg-sync busca actualizaciones de escala cada 5 segundos.

• La clave upstreams define la lista de grupos ascendentes. Para cada grupo ascendente especificamos:

  • nombre – El nombre que especificamos para el bloque ascendente en el Paso 3.
  • autoscaling_group : el nombre del grupo de escalamiento automático correspondiente.
  • puerto : el puerto en el que están expuestos nuestros servicios de backend.
  • tipo – El protocolo del tráfico que NGINX Plus equilibra la carga hacia la aplicação backend, aquí http . Si la aplicação utiliza TCP/UDP, especifique stream en su lugar.

Después de editar el archivo aws.yaml , reinicie el software:

$ sudo restart nginx-asg-sync

Prueba de equilibrio y escalado de carga

En los pasos anteriores, configuramos NGINX Plus para equilibrar la carga de los grupos de escalamiento automático para nuestra aplicação. Ahora podemos probarlo. NGINX Plus distribuye las solicitudes con el URI /backend‑one a las instancias del grupo Backend One, y las solicitudes con el URI /backend‑two a las instancias del grupo Backend Two.

Podemos ver cómo NGINX Plus selecciona nuevas instancias cuando escalamos nuestros grupos de escalado automático. Primero, accedemos al panel de monitoreo de actividad en vivo , accesible en /status.html en el puerto 8080 de la instancia NGINX Plus. En la pestaña Upstream vemos las instancias en nuestros grupos de Auto Scaling:

Ahora, ampliamos el grupo Backend One de tres a cinco instancias cambiando la capacidad del grupo Auto Scaling. Una vez lanzadas las nuevas instancias, nginx-asg-sync las agrega a la configuración de NGINX Plus. Pronto aparecerán las nuevas instancias en el panel:

Haciendo que NGINX Plus sea altamente disponible

Hasta ahora, solo hemos lanzado una instancia de NGINX Plus. Sin embargo, para lograr una alta disponibilidad, recomendamos crear un grupo de escalamiento automático para NGINX Plus y usar ELB delante de las instancias de NGINX Plus. Como alternativa a ELB, puede utilizar Route 53 para enrutar el tráfico a las instancias de NGINX Plus. El diagrama de nuestra implementación con ELB se ve así:

Elegir el método correcto

Entonces, ¿qué método de configuración de NGINX Plus para equilibrar la carga de los grupos de escalado automático es mejor para usted? La tabla compara brevemente ambos:

resumen

AWS Auto Scaling ofrece el beneficio de ajustar la cantidad de instancias de aplicação al nivel de demanda. NGINX Plus proporciona funciones avanzadas de equilibrio de carga que se pueden utilizar junto con los grupos de AWS Auto Scaling.

Pruebe NGINX Plus con sus grupos de AWS Auto Scaling: comience su prueba gratuita de 30 días o contáctenos para analizar sus casos de uso .