Balanceo de carga de grupos de Auto Scaling de AWS con NGINX Plus

Michael Pleshakov

Una de las funciones más útiles de la nube es la capacidad de escalar automáticamente el número de instancias informáticas. Con AWS Auto Scaling, puede cambiar el número de instancias EC2 de un grupo de Auto Scaling, ya sea de forma manual o automática, en función de una programación o de la demanda. Auto Scaling ayuda a reducir los costes ajustando el número de instancias a la cantidad adecuada para la carga de trabajo actual. Además, Auto Scaling reinicia las instancias que presentan errores, lo que aumenta la resiliencia de sus aplicaciones.

El balanceo de carga es fundamental cuando se utiliza Auto Scaling. AWS proporciona balanceo de carga para las instancias de los grupos de Auto Scaling mediante la integración de sus balanceadores de carga integrados —Elastic Load Balancer (ELB), denominado oficialmente Classic Load Balancer, y Application Load Balancer (ALB)— con Auto Scaling. NGINX Plus proporciona balanceo de carga avanzado en la nube para cualquier entorno de nube, incluido AWS, y es compatible con los grupos de Auto Scaling de AWS.

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

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 la previsión de costes. Los precios de NGINX Plus son sencillos, tanto si adquiere la suscripción a NGINX Plus directamente de nosotros como si ejecuta instancias prediseñadas de NGINX Plus desde AWS Marketplace, que se facturan a una tarifa fija por hora.
3. NGINX Plus no le vincula a API específicas de una plataforma, lo que le permite reutilizar la configuración de equilibrio de carga en varias plataformas en la nube.

Para saber cómo se compara NGINX Plus con las soluciones integradas de AWS (y cómo funciona conjuntamente con ellas), lea nuestras entradas de blog sobre ELB y ALB.

En esta entrada del blog mostramos dos métodos para configurar NGINX Plus a fin de equilibrar la carga de los grupos de Auto Scaling y explicamos cuándo conviene utilizar 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 entrada de blog, estará preparado para implementar NGINX Plus en AWS y proporcionar un balanceo de carga avanzado para grupos de Auto Scaling.

El entorno de ejemplo de AWS Auto Scaling

Utilizamos un entorno de aplicación de ejemplo para ilustrar los dos métodos de uso de NGINX Plus para equilibrar la carga de los grupos de Auto Scaling. Nuestra aplicación web de backend consta de dos servicios —Backend One y Backend Two—, cada uno expuesto en el puerto 80. Cada servicio dispone de un grupo de Auto Scaling con varias instancias de la aplicación. El equilibrador de carga dirige las solicitudes de los clientes al backend correspondiente en función del URI de la solicitud:

• Las solicitudes a /backend‑one se dirigen a Backend One.
• Las solicitudes a /backend‑two se dirigen al Backend Two.

Cuando escalamos los grupos de Auto Scaling de la aplicación (ya sea de forma automática o manual), es necesario actualizar la configuración del balanceador de carga para reflejar el nuevo número de instancias de la aplicación. Los balanceadores de carga integrados de AWS lo hacen automáticamente. En el caso de NGINX Plus, debemos propagar los eventos de escalado a la configuración mediante uno de los métodos mencionados anteriormente (NGINX Plus delante de 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 escalado consiste en utilizar un registro de servicios externo. NGINX Plus admite la integración con sistemas de descubrimiento de servicios que proporcionan una interfaz DNS, como Consul. En esta entrada del 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 utiliza grupos de Auto Scaling y ELB, la forma más sencilla de incorporar algunas de las funciones avanzadas de NGINX Plus a su aplicación es colocar NGINX Plus delante de los balanceadores de carga en la nube de ELB, como se muestra en el diagrama:

En este caso, NGINX Plus actúa como proxy/balanceador de carga para uno o varios ELB. Gracias a sus funciones avanzadas de enrutamiento, NGINX Plus reenvía las solicitudes al ELB correspondiente en función del URI de la solicitud. A continuación, el ELB envía la solicitud a una de las instancias del grupo de Auto Scaling. En esta configuración, ELB proporciona la compatibilidad con el escalado.

Esta es la configuración de NGINX Plus.

resolver 169.254.169.253 valid=10s;
upstream backend-one {
    zone backend-one 64k;
    server DNS-name-of-ELB-for-Backend-One resolve;
}

upstream backend-two {
    zone backend-two 64k;
    server DNS-name-of-ELB-for-Backend-Two resolve;
}

server {
    listen 80;

    location /backend-one {
        proxy_set_header Host $host;
        proxy_pass http://backend-one;
    }

    location /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 internas de ELB. En este caso, es 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 Auto Scaling mediante el nombre DNS del ELB que distribuye el tráfico hacia él. Mediante el parámetro resolve, indicamos a NGINX Plus que vuelva a resolver periódicamente el nombre; la frecuencia se establece mediante el parámetro valid de la directiva resolver mencionada en el punto anterior. En este caso, la establecemos en 10 segundos porque las direcciones IP del ELB pueden cambiar con frecuencia. La directiva zone asigna memoria (en este caso, hasta 64 KB) para almacenar las direcciones IP resueltas.
• Definimos un server virtual que escucha en el puerto 80. Los bloques location indican a NGINX Plus que reenvíe las solicitudes de /backend‑one al ELB del grupo de Auto Scaling Backend One y las solicitudes de /backend‑two al ELB del grupo de Auto Scaling Backend Two.

Como puede ver, este método es fácil de configurar y utilizar, especialmente si ya utiliza ELB. Sin embargo, presenta varios inconvenientes:

• Opciones de balanceo de carga limitadas. Dado que NGINX Plus envía las solicitudes a ELB, y no directamente a las instancias de backend, es ELB quien realiza el balanceo de carga. Por este motivo, no puede aprovechar los algoritmos de balanceo de carga más sofisticados ni las opciones de persistencia de sesión de NGINX Plus.
• Redundancia. NGINX Plus puede realizar el balanceo de carga, por lo que ELB resulta redundante; solo lo utilizamos porque está integrado de forma nativa con Auto Scaling.
• Compatibilidad limitada con protocolos. A diferencia de NGINX Plus, ELB no es compatible con WebSocket ni UDP.

El siguiente método no depende de ELB y, por tanto, no presenta esas desventajas.

Uso de NGINX Plus con el software de integración

Con este método, se instala además un software de integración junto con NGINX Plus. El software (nginx-asg-sync) supervisa constantemente los grupos de Auto Scaling. Cuando detecta que se ha producido un evento de escalado, añade 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 Auto Scaling a través de la API de AWS Auto Scaling.

Para utilizar el software de integración, siga estos pasos:

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

Las instrucciones presuponen que los grupos de Auto Scaling de los backends ya existen. También presuponen 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 Auto Scaling requiere autenticación, por lo que debe proporcionar credenciales para nginx-asg-sync. AWS utiliza roles de IAM para gestionar las credenciales, por lo que debe crear un rol para la instancia de NGINX Plus antes de iniciarla. Para obtener instrucciones detalladas, consulte Roles de IAM para Amazon EC2 en la documentación de AWS.

1. Cree un rol de IAM y adjúntele la política predefinida AmazonEC2ReadOnlyAccess. Esta política permite el acceso de solo lectura a las API de EC2.
2. Cuando inicie la instancia de NGINX Plus, añada este rol de IAM a la instancia.

Paso 2 – Instalar el software de integración

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

• Para Amazon Linux, CentOS y RHEL:

$ sudo rpm -i package-name.rpm

• Para Ubuntu:

$ sudo dpkg -i package-name.deb

Para consultar las instrucciones completas de instalación, consulta la documentación en GitHub.

Paso 3 – Configurar NGINX Plus

El software de integración actualiza la configuración de NGINX Plus mediante las API de reconfiguración dinámica y supervisión de la actividad en tiempo real. Para que el software funcione correctamente, debe configurar dichas API, así como declarar los grupos de servidores ascendentes necesarios:

• Configure los endpoints de la API para la reconfiguración dinámica y la supervisión de la actividad en tiempo real. El software de integración utiliza estos endpoints para añadir y eliminar instancias de backend de los grupos de servidores upstream.
• Cree un bloque upstream para cada grupo de Auto Scaling. No defina ningún servidor en el bloque, ya que nginx-asg-sync los añade y elimina automáticamente en respuesta a los eventos de escalado.

El siguiente ejemplo muestra la configuración de nuestra sencilla aplicación web:

upstream backend-one {    zone backend-one 64k;
    state /var/lib/nginx/state/backend-one.conf;
}

upstream backend-two {
    zone backend-two 64k;
    state /var/lib/nginx/state/backend-two.conf;
}

server {
    listen 80;

    status_zone backend;

    location /backend-one {
        proxy_set_header Host $host;
        proxy_pass http://backend-one;
    }

    location /backend-two {
        proxy_set_header Host $host;
        proxy_pass http://backend-two;
    }
}

server {
    listen 8080;

    root /usr/share/nginx/html;

    location = / {
        return 302 /status.html;
    }

    location = /status.html {}

    location /status {
        access_log off;
        status;
    }

    location /upstream_conf {
        upstream_conf;
    }
}

• Al igual que en el ejemplo de ELB, declaramos dos grupos de servidores ascendentes: backend‑one y backend‑two, que se corresponden con nuestros grupos de Auto Scaling. Sin embargo, en este caso no añadimos ningún servidor a los grupos de servidores ascendentes, ya que los añadirá nginx‑aws‑sync. La directiva state especifica el archivo en el que se almacena la lista de servidores configurable dinámicamente, lo que permite conservarla tras los reinicios de NGINX Plus.
• Definimos un server virtual que escucha en el puerto 80. A diferencia del ejemplo de ELB, NGINX Plus dirige las solicitudes de /backend‑one directamente a las instancias del grupo Backend One, y las solicitudes de /backend‑two directamente a las instancias del grupo Backend Two.
• Definimos un segundo servidor virtual que escucha en el puerto 8080 y configuramos en él las API de NGINX Plus:
  • La API de configuración dinámica 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 de la carpeta /etc/nginx. Para nuestra aplicación, definimos la siguiente configuración:

region: us-west-2upstream_conf_endpoint: http://127.0.0.1:8080/upstream_conf
status_endpoint: http://127.0.0.1:8080/status
sync_interval_in_seconds: 5
upstreams:
 - name: backend-one
   autoscaling_group: backend-one-group
   port: 80
   kind: http
 - name: backend-two
   autoscaling_group: backend-two-group
   port: 80
   kind: http

• La clave region define la región de AWS en la que desplegamos nuestra aplicación.
• Las claves upstream_conf_endpoint y status_endpoint definen los endpoints de la API de NGINX Plus, que configuramos en el paso 3.
• La clave sync_interval_in_seconds define el intervalo de sincronización: nginx-asg-sync comprueba si hay actualizaciones de escalado cada 5 segundos.
• La clave upstreams define la lista de grupos de servidores ascendentes. Para cada grupo de servidores ascendentes, especificamos:
  • name – El nombre que especificamos para el bloque upstream en el paso 3.
  • autoscaling_group – El nombre del grupo de Auto Scaling correspondiente.
  • port – El puerto en el que se exponen nuestros servicios de backend.
  • kind – El protocolo del tráfico que NGINX Plus equilibra hacia la aplicación de backend; en este caso, http. Si la aplicación 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 del balanceo de carga y el escalado

En los pasos anteriores, configuramos NGINX Plus para equilibrar la carga entre los grupos de Auto Scaling de nuestra aplicación. Ahora podemos probar la configuración. NGINX Plus distribuye las solicitudes con el URI /backend‑one entre las instancias del grupo Backend One, y las solicitudes con el URI /backend‑two entre las instancias del grupo Backend Two.

Podemos ver cómo NGINX Plus detecta nuevas instancias cuando escalamos nuestros grupos de Auto Scaling. Primero, accedemos al panel de monitorización de la actividad en tiempo real, disponible en /status.html en el puerto 8080 de la instancia de NGINX Plus. En la pestaña Upstream vemos las instancias de nuestros grupos de Auto Scaling:

Ahora, ampliamos el grupo Backend One de tres a cinco instancias cambiando la capacidad del grupo de Auto Scaling. Una vez iniciadas las nuevas instancias, nginx-asg-sync las añade a la configuración de NGINX Plus. Poco después, las nuevas instancias aparecen en el panel:

Cómo lograr una alta disponibilidad de NGINX Plus

Hasta ahora, solo hemos iniciado una instancia de NGINX Plus. Sin embargo, para garantizar una alta disponibilidad, recomendamos crear un grupo de Auto Scaling para el propio NGINX Plus y utilizar ELB delante de las instancias de NGINX Plus. Como alternativa a ELB, puede utilizar Route 53 para dirigir el tráfico a las instancias de NGINX Plus. El diagrama de nuestro despliegue con ELB tiene este aspecto:

Elegir el método adecuado

Entonces, ¿qué método de configuración de NGINX Plus para equilibrar la carga de los grupos de Auto Scaling le conviene más? La tabla compara brevemente ambos métodos:

NGINX Plus delante de ELB NGINX Plus con el software de integraciónVentajas Configuración sencilla y sin necesidad de instalar software adicional. Todas las ventajas de las funcionalidades de NGINX Plus, sin ninguna de las limitaciones impuestas por el método ELB.Desventajas Limita el número de funcionalidades de NGINX Plus que se pueden utilizar, incluidos los protocolos compatibles. Aumenta tanto el coste de la implementación como la latencia. Requiere instalar y configurar el software de integración.Resumen Utilice este método si sus desventajas son aceptables. Utilice este método para aprovechar al máximo las capacidades de NGINX Plus.

Resumen

AWS Auto Scaling ofrece la ventaja de ajustar el número de instancias de la aplicación al nivel de demanda. NGINX Plus proporciona funciones avanzadas de balanceo de carga que pueden utilizarse junto con los grupos de AWS Auto Scaling.

Pruebe NGINX Plus con sus grupos de AWS Auto Scaling: inicie su prueba gratuita de 30 días o póngase en contacto con nosotros para hablar sobre sus casos de uso.

Sobre el autor

Michael Pleshakov

Más artículos de Michael Pleshakov