Balanceamento de carga de grupos de dimensionamento automático da AWS com NGINX Plus

Um dos recursos mais benéficos da nuvem é a capacidade de dimensionar automaticamente o número de instâncias de computação. Com o AWS Auto Scaling , você pode alterar o número de instâncias do EC2 em um grupo de Auto Scaling , manual ou automaticamente, com base na programação ou na demanda. O dimensionamento automático ajuda a reduzir custos ajustando o número de instâncias para o número certo para a carga de trabalho atual. Além disso, o Auto Scaling reinicia instâncias com falha, o que adiciona resiliência aos seus aplicativos.

O balanceamento de carga é crucial ao usar o dimensionamento automático. A AWS fornece balanceamento de carga de instâncias de grupos de Auto Scaling integrando seus balanceadores de carga integrados – Elastic Load Balancer (ELB), agora oficialmente chamado de Classic Load Balancer, e Application Load Balancer (ALB) – com Auto Scaling. O NGINX Plus fornece balanceamento de carga de nuvem avançado para qualquer ambiente de nuvem, incluindo AWS, e oferece suporte a grupos de dimensionamento automático da AWS.

Há três razões principais para escolher o NGINX Plus como um substituto ou uma adição aos balanceadores de carga de nuvem AWS integrados:

1. O NGINX Plus oferece vários recursos avançados que o ELB e o ALB não possuem.
2. O modelo de preços para os balanceadores de carga da AWS (especialmente ALB) é complexo, dificultando a previsão de custos. O preço do NGINX Plus é direto, quer você compre a assinatura do NGINX Plus diretamente de nós ou execute instâncias pré-criadas do NGINX Plus no AWS Marketplace , que são cobradas a uma taxa horária definida.
3. O NGINX Plus não vincula você a APIs específicas da plataforma, permitindo que você reutilize a configuração de balanceamento de carga em várias plataformas de nuvem.

Para ver como o NGINX Plus se compara (e funciona em conjunto com) as soluções integradas da AWS, leia nossas postagens de blog sobre ELB e ALB .

Nesta postagem do blog, mostramos dois métodos de configuração do NGINX Plus para balancear a carga de grupos de dimensionamento automático e explicamos quando faz sentido usar cada método:

1. Usando NGINX Plus na frente do ELB
2. Usando o NGINX Plus com software de integração fornecido pela NGINX, Inc.

Depois de ler esta postagem do blog, você estará pronto para implantar o NGINX Plus na AWS para fornecer balanceamento de carga avançado para grupos de dimensionamento automático.

O ambiente de dimensionamento automático da AWS de exemplo

Estamos usando um ambiente de aplicativo de exemplo para ilustrar os dois métodos de uso do NGINX Plus para balancear a carga de grupos de dimensionamento automático. Nosso aplicativo web de backend consiste em dois serviços – Backend Um e Backend Dois – cada um exposto na porta 80. Para cada serviço, há um grupo de dimensionamento automático de várias instâncias de aplicativo. O balanceador de carga roteia as solicitações do cliente para o backend apropriado com base no URI da solicitação:

• Solicitações para /backend‑one vão para o Backend One.
• Solicitações para /backend‑two vão para o Backend Two.

Quando dimensionamos os grupos de dimensionamento automático do aplicativo (automaticamente ou manualmente), a configuração do balanceador de carga deve ser atualizada para refletir o novo número de instâncias do aplicativo. Os balanceadores de carga integrados da AWS fazem isso automaticamente. Para o NGINX Plus, precisamos propagar eventos de dimensionamento para a configuração com um dos métodos mencionados acima (NGINX Plus na frente do ELB ou NGINX Plus com o software de integração).

Outra maneira de atualizar a configuração do NGINX Plus em resposta a eventos de dimensionamento é com um registro de serviço externo. O NGINX Plus oferece suporte à integração com sistemas de descoberta de serviços que fornecem uma interface DNS , como o Consul . Nesta postagem do blog, nos concentramos em soluções que não dependem do uso de sistemas externos e que são fáceis de configurar e usar.

Usando NGINX Plus na frente do ELB

Se você já estiver usando grupos de dimensionamento automático e ELB, a maneira mais fácil de trazer alguns dos recursos avançados do NGINX Plus para seu aplicativo é colocar o NGINX Plus na frente dos balanceadores de carga de nuvem ELB, conforme mostrado no diagrama:

Neste caso, o NGINX Plus atua como um proxy/balanceador de carga para um ou mais ELBs. Usando seus recursos avançados de roteamento, o NGINX Plus encaminha solicitações para o ELB apropriado com base no URI da solicitação. O ELB então passa a solicitação para uma das instâncias no grupo Auto Scaling. Nessa configuração, o ELB fornece suporte para dimensionamento.

Aqui está a configuração do 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;
    }
}

• A diretiva resolver define o servidor DNS que o NGINX Plus usa para resolver os nomes DNS das instâncias internas do ELB. Aqui está o endereço IP do servidor DNS da AWS.

• Criamos dois blocos upstream , um para cada grupo de dimensionamento automático correspondente aos nossos serviços, Backend Um e Backend Dois. Identificamos o grupo de dimensionamento automático pelo nome DNS do ELB que balanceia a carga do tráfego para ele.

  Usando o parâmetro resolve , dizemos ao NGINX Plus para resolver novamente o nome periodicamente – a frequência é definida pelo parâmetro válido para a diretiva resolver discutida no tópico anterior. Aqui, definimos para 10 segundos porque os endereços IP do ELB estão sujeitos a alterações frequentes.

  A diretiva de zona aloca memória (aqui até 64 KB) para armazenar os endereços IP resolvidos.

• Definimos um servidor virtual que escuta na porta 80. Os blocos de localização informam ao NGINX Plus para passar solicitações de /backend‑one para o ELB para o grupo de dimensionamento automático do Backend One e solicitações de /backend‑two para o ELB para o grupo de dimensionamento automático do Backend Two.

Como você pode ver, esse método é fácil de configurar e usar, especialmente se você já estiver usando o ELB. No entanto, existem várias desvantagens:

• Opções limitadas de balanceamento de carga. Como o NGINX Plus passa solicitações para o ELB, não diretamente para as instâncias de backend, é o ELB que faz o balanceamento de carga. Por esse motivo, você não pode aproveitar os algoritmos de balanceamento de carga mais sofisticados e as opções de persistência de sessão do NGINX Plus.
• Redundância. O NGINX Plus pode fazer balanceamento de carga, então o ELB é redundante – estamos usando-o apenas porque ele é nativamente integrado com o Auto Scaling.
• Suporte de protocolo limitado. Ao contrário do NGINX Plus, o ELB não oferece suporte a WebSocket e UDP.

O próximo método não depende do ELB e, consequentemente, não tem essas desvantagens.

Usando o NGINX Plus com o software de integração

Com esse método, você instala software de integração adicional junto com o NGINX Plus. O software ( nginx-asg-sync ) monitora constantemente os grupos de dimensionamento automático. Ao detectar que um evento de dimensionamento ocorreu, ele adiciona ou remove instâncias de backend da configuração do NGINX Plus. Conforme mostrado, o nginx-asg-sync aprende sobre alterações em grupos de dimensionamento automático por meio da API de dimensionamento automático da AWS.

Para usar o software de integração, execute as seguintes etapas:

1. Configurar acesso à API da AWS
2. Instalar o software de integração
3. Configurar NGINX Plus
4. Configurar o software de integração

As instruções pressupõem que os grupos de dimensionamento automático para os backends já existam. Eles também presumem que o NGINX Plus está sendo executado em uma AMI do Amazon Linux.

Etapa 1 – Configurar acesso à API da AWS

A comunicação com a API de dimensionamento automático é autenticada, portanto, você deve fornecer credenciais para nginx-asg-sync . A AWS usa funções do IAM para manipular credenciais, então você precisa criar uma função para a instância do NGINX Plus antes de iniciá-la. Para obter instruções passo a passo, consulte Funções do IAM para Amazon EC2 na documentação da AWS.

1. Crie uma função do IAM e anexe a política predefinida AmazonEC2ReadOnlyAccess a ela. Esta política permite acesso somente leitura às APIs do EC2.
2. Ao iniciar a instância do NGINX Plus, adicione esta função do IAM à instância.

Etapa 2 – Instalar o software de integração

Para instalar o software de integração, baixe o pacote para seu sistema operacional do repositório nginx-asg-sync do GitHub e instale-o na instância onde o NGINX Plus está em execução.

• Para Amazon Linux, CentOS e RHEL:

  $ sudo rpm -i package-name.rpm
  

• Para Ubuntu:

  $ sudo dpkg -i package-name.deb
  

Para obter instruções completas de instalação, consulte a documentação no GitHub.

Etapa 3 – Configurar o NGINX Plus

O software de integração atualiza a configuração do NGINX Plus usando as APIs de reconfiguração dinâmica e monitoramento de atividades ao vivo . Para que o software funcione corretamente, você deve configurar essas APIs e também declarar os grupos upstream necessários:

• Configure os endpoints da API para reconfiguração instantânea e monitoramento de atividades em tempo real. O software de integração usa esses endpoints para adicionar e remover instâncias de backend de grupos upstream.
• Crie um bloco upstream para cada grupo de dimensionamento automático. Não defina nenhum servidor no bloco, pois o nginx-asg-sync os adiciona e remove automaticamente em resposta a eventos de dimensionamento.

O exemplo a seguir representa a configuração do nosso aplicativo web simples:

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;
    }
}

• Como no exemplo do ELB, declaramos dois grupos upstream – backend‑one e backend‑two , que correspondem aos nossos grupos de dimensionamento automático. Aqui, no entanto, não adicionamos nenhum servidor aos grupos upstream, porque os servidores serão adicionados pelo nginx‑aws‑sync . A diretiva de estado nomeia o arquivo onde a lista dinamicamente configurável de servidores é armazenada, permitindo que ela persista após reinicializações do NGINX Plus.
• Definimos um servidor virtual que escuta na porta 80. Em contraste com o exemplo do ELB, o NGINX Plus passa solicitações para /backend‑one diretamente para as instâncias do grupo Backend One, e solicitações para /backend‑two diretamente para as instâncias do grupo Backend Two.

• Definimos um segundo servidor virtual escutando na porta 8080 e configuramos as APIs do NGINX Plus nele:

  • A API on-the-fly está disponível em 127.0.0.1:8080/upstream_conf
  • A API de status está disponível em 127.0.0.1:8080/status

Etapa 4 – Configurar o software de integração

O software de integração é configurado no arquivo aws.yaml na pasta /etc/nginx . Para nossa aplicação, definimos a seguinte configuração:

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

• A chave de região define a região da AWS onde implantamos nosso aplicativo.
• As chaves upstream_conf_endpoint e status_endpoint definem os endpoints da API do NGINX Plus, que configuramos na Etapa 3 .
• A chave sync_interval_in_seconds define o intervalo de sincronização: nginx-asg-sync verifica atualizações de dimensionamento a cada 5 segundos.

• A chave upstreams define a lista de grupos upstream. Para cada grupo upstream especificamos:

  • nome – O nome que especificamos para o bloco upstream na Etapa 3.
  • autoscaling_group – O nome do grupo de dimensionamento automático correspondente.
  • porta – A porta na qual nossos serviços de backend são expostos.
  • kind – O protocolo do tráfego NGINX Plus balanceia a carga para o aplicativo de backend, aqui http . Se o aplicativo usar TCP/UDP, especifique stream .

Depois de editar o arquivo aws.yaml , reinicie o software:

$ sudo restart nginx-asg-sync

Testando balanceamento de carga e dimensionamento

Nas etapas acima, configuramos o NGINX Plus para balancear a carga de grupos de dimensionamento automático para nosso aplicativo. Agora podemos testar. O NGINX Plus distribui solicitações com o URI /backend‑one para as instâncias do grupo Backend One e solicitações com o URI /backend‑two para as instâncias do grupo Backend Two.

Podemos ver como o NGINX Plus seleciona novas instâncias quando dimensionamos nossos grupos de dimensionamento automático. Primeiro, acessamos o painel de monitoramento de atividades ao vivo , acessível em /status.html na porta 8080 da instância do NGINX Plus. Na guia Upstream , vemos as instâncias em nossos grupos de dimensionamento automático:

Agora, ampliamos o grupo Backend One de três para cinco instâncias alterando a capacidade do grupo Auto Scaling. Depois que as novas instâncias são iniciadas, o nginx-asg-sync as adiciona à configuração do NGINX Plus. Em breve as novas instâncias aparecerão no painel:

Tornando o NGINX Plus altamente disponível

Até agora, lançamos apenas uma instância do NGINX Plus. No entanto, para alta disponibilidade, recomendamos criar um grupo de dimensionamento automático para o próprio NGINX Plus e usar o ELB na frente das instâncias do NGINX Plus. Como alternativa ao ELB, você pode usar o Route 53 para rotear o tráfego para instâncias do NGINX Plus. O diagrama da nossa implantação com ELB se parece com isso:

Escolhendo o método certo

Então, qual método de configuração do NGINX Plus para balancear a carga de grupos de dimensionamento automático é melhor para você? A tabela compara brevemente os dois:

Resumo

O AWS Auto Scaling oferece o benefício de ajustar o número de instâncias do aplicativo ao nível de demanda. O NGINX Plus fornece recursos avançados de balanceamento de carga que podem ser usados em conjunto com grupos de dimensionamento automático da AWS.

Experimente o NGINX Plus com seus grupos de dimensionamento automático da AWS – comece seu teste gratuito de 30 dias ou entre em contato conosco para discutir seus casos de uso .