Balanceamento de carga de grupos do AWS Auto Scaling com NGINX Plus

Michael Pleshakov

Um dos recursos mais vantajosos 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 do Auto Scaling, de forma manual ou automática, com base em uma programação ou na demanda. O Auto Scaling ajuda a reduzir custos ajustando o número de instâncias à quantidade adequada para a carga de trabalho atual. Além disso, o Auto Scaling reinicia instâncias com falha, o que aumenta a resiliência das suas aplicações.

O balanceamento de carga é essencial ao usar o Auto Scaling. A AWS oferece balanceamento de carga para instâncias de grupos do Auto Scaling por meio da integração de seus balanceadores de carga integrados – Elastic Load Balancer (ELB), agora oficialmente chamado de Classic Load Balancer, e Application Load Balancer (ALB) – com o Auto Scaling. O NGINX Plus oferece balanceamento de carga avançado na nuvem para qualquer ambiente de nuvem, incluindo a AWS, e é compatível com grupos do AWS Auto Scaling.

Há três motivos principais para escolher o NGINX Plus como substituto ou complemento dos balanceadores de carga em nuvem integrados da AWS:

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 dos balanceadores de carga da AWS (especialmente o ALB) é complexo, o que dificulta a previsão dos custos. Os preços do NGINX Plus são simples, seja ao adquirir a assinatura do NGINX Plus diretamente conosco ou ao executar instâncias pré-configuradas do NGINX Plus no AWS Marketplace, que são cobradas a uma tarifa horária fixa.
3. O NGINX Plus não vincula você a APIs específicas de uma plataforma, permitindo reutilizar a configuração de balanceamento de carga em várias plataformas de nuvem.

Para saber como o NGINX Plus se compara às soluções integradas da AWS (e como funciona em conjunto com elas), leia nossas publicações no blog sobre o ELB e o ALB.

Nesta publicação do blog, mostramos dois métodos para configurar o NGINX Plus para balancear a carga de grupos do Auto Scaling e explicamos quando faz sentido usar cada método:

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

Depois de ler esta publicação do blog, você estará pronto para implantar o NGINX Plus na AWS e fornecer balanceamento de carga avançado para grupos do Auto Scaling.

O ambiente de exemplo do AWS Auto Scaling

Estamos usando um ambiente de aplicação de exemplo para ilustrar os dois métodos de uso do NGINX Plus para balancear a carga de grupos do Auto Scaling. Nossa aplicação web de backend consiste em dois serviços – Backend One e Backend Two –, cada um exposto na porta 80. Para cada serviço, há um grupo do Auto Scaling com várias instâncias da aplicação. O balanceador de carga encaminha as solicitações dos clientes ao backend apropriado com base no URI da solicitação:

• As solicitações para /backend‑one são encaminhadas ao Backend One.
• As solicitações para /backend‑two são encaminhadas ao Backend Two.

Quando escalamos os grupos de Auto Scaling da aplicação (de forma automática ou manual), a configuração do balanceador de carga precisa ser atualizada para refletir o novo número de instâncias da aplicação. Os balanceadores de carga integrados da AWS fazem isso automaticamente. No caso do NGINX Plus, precisamos propagar os eventos de escalabilidade para a configuração usando um dos métodos mencionados acima (NGINX Plus à 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 escalabilidade é usar um registro de serviços externo. O NGINX Plus oferece suporte à integração com sistemas de descoberta de serviços que fornecem uma interface DNS, como o Consul. Nesta publicação do blog, abordamos soluções que não dependem do uso de sistemas externos e que são fáceis de configurar e usar.

Como usar o NGINX Plus na frente do ELB

Se você já usa grupos do Auto Scaling e o ELB, a maneira mais fácil de incorporar alguns dos recursos avançados do NGINX Plus à sua aplicação é posicionar o NGINX Plus à frente dos balanceadores de carga do ELB na nuvem, conforme mostrado no diagrama:

Nesse caso, o NGINX Plus atua como proxy/balanceador de carga para um ou mais ELBs. Usando seus recursos avançados de roteamento, o NGINX Plus encaminha as solicitações ao ELB apropriado com base no URI da solicitação. Em seguida, o ELB repassa a solicitação para uma das instâncias do grupo de Auto Scaling. Nessa configuração, o ELB oferece suporte ao escalonamento.

Esta é 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. Neste caso, trata-se do endereço IP do servidor DNS da AWS.
• Criamos dois blocos upstream, um para cada grupo do Auto Scaling correspondente aos nossos serviços, Backend One e Backend Two. Identificamos o grupo do Auto Scaling pelo nome DNS do ELB que faz o balanceamento de carga do tráfego destinado a ele. Usando o parâmetro resolve, instruímos o NGINX Plus a resolver novamente o nome periodicamente. A frequência é definida pelo parâmetro valid da diretiva resolver, abordada no item anterior. Aqui, definimos o valor como 10 segundos porque os endereços IP do ELB estão sujeitos a alterações frequentes. A diretiva zone aloca memória (neste caso, até 64 KB) para armazenar os endereços IP resolvidos.
• Definimos um server virtual que escuta na porta 80. Os blocos location instruem o NGINX Plus a encaminhar as solicitações de /backend‑one ao ELB do grupo de Auto Scaling Backend One e as solicitações de /backend‑two ao ELB do grupo de Auto Scaling Backend Two.

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

• Opções limitadas de balanceamento de carga. Como o NGINX Plus encaminha as solicitações ao ELB, e não diretamente às instâncias de backend, é o ELB que realiza o balanceamento de carga. Por esse motivo, não é possível 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 o balanceamento de carga, portanto, o ELB é redundante – nós o utilizamos apenas porque ele é integrado nativamente ao Auto Scaling.
• Suporte limitado a protocolos. 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 apresenta essas desvantagens.

Como usar o NGINX Plus com o software de integração

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

Para usar o software de integração, siga estas etapas:

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

As instruções pressupõem que os grupos de Auto Scaling dos backends já existam. Elas também pressupõem que o NGINX Plus esteja sendo executado em uma AMI do Amazon Linux.

Etapa 1 – Configurar o acesso à API da AWS

A comunicação com a API do Auto Scaling é autenticada, portanto, você deve fornecer credenciais para o nginx-asg-sync. A AWS usa funções do IAM para gerenciar credenciais, portanto, 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 o Amazon EC2 na documentação da AWS.

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

Etapa 2 – Instalar o software de integração

Para instalar o software de integração, baixe o pacote correspondente ao seu sistema operacional no repositório nginx-asg-sync do GitHub, e instale-o na instância em que 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 – Configure 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 em tempo real. 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 dinâmica e monitoramento de atividades em tempo real. O software de integração usa esses endpoints para adicionar e remover instâncias de backend dos grupos upstream.
• Crie um bloco upstream para cada grupo do Auto Scaling. Não defina nenhum servidor no bloco, pois o nginx-asg-sync adiciona e remove os servidores automaticamente em resposta a eventos de escalabilidade.

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

• Assim como no exemplo do ELB, declaramos dois grupos upstream – backend‑one e backend‑two, que correspondem aos nossos grupos de Auto Scaling. No entanto, aqui não adicionamos nenhum servidor aos grupos upstream, pois os servidores serão adicionados pelo nginx‑aws‑sync. A diretiva state especifica o arquivo no qual a lista de servidores configurável dinamicamente é armazenada, permitindo que ela seja mantida após as reinicializações do NGINX Plus.
• Definimos um server virtual que escuta na porta 80. Ao contrário do exemplo com o ELB, o NGINX Plus encaminha as solicitações para /backend‑one diretamente às instâncias do grupo Backend One e as solicitações para /backend‑two diretamente às instâncias do grupo Backend Two.
• Definimos um segundo servidor virtual que escuta na porta 8080 e configuramos nele as APIs do NGINX Plus:
  • A API de configuração dinâmica 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 – Configure o software de integração

O software de integração é configurado no arquivo aws.yaml localizado 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 region define a região da AWS onde implantamos nossa aplicação.
• 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: o nginx-asg-sync verifica se há atualizações de escalabilidade a cada 5 segundos.
• A chave upstreams define a lista de grupos upstream. Para cada grupo upstream, especificamos:
  • name – O nome que especificamos para o bloco upstream na Etapa 3.
  • autoscaling_group – O nome do grupo de Auto Scaling correspondente.
  • porta – A porta na qual nossos serviços de backend são expostos.
  • kind – O protocolo do tráfego que o NGINX Plus balanceia para a aplicação de backend, neste caso, http. Se a aplicação usar TCP/UDP, especifique stream em vez disso.

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

$ sudo restart nginx-asg-sync

Testando o balanceamento de carga e o escalonamento

Nas etapas acima, configuramos o NGINX Plus para balancear a carga dos grupos de Auto Scaling da nossa aplicação. Agora podemos testar essa configuração. O NGINX Plus distribui as solicitações com o URI /backend‑one entre as instâncias do grupo Backend One e as solicitações com o URI /backend‑two entre as instâncias do grupo Backend Two.

Podemos ver como o NGINX Plus detecta novas instâncias quando escalamos nossos grupos de Auto Scaling. Primeiro, acessamos o painel de monitoramento de atividades em tempo real, disponível em /status.html na porta 8080 da instância do NGINX Plus. Na guia Upstream, vemos as instâncias dos nossos grupos de Auto Scaling:

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

Tornando o NGINX Plus altamente disponível

Até agora, iniciamos apenas uma instância do NGINX Plus. No entanto, para garantir alta disponibilidade, recomendamos criar um grupo de Auto Scaling para o próprio NGINX Plus e usar o ELB à frente das instâncias do NGINX Plus. Como alternativa ao ELB, você pode usar o Route 53 para direcionar o tráfego às instâncias do NGINX Plus. O diagrama da nossa implantação com o ELB é semelhante a este:

Escolhendo o método certo

Então, qual método de configuração do NGINX Plus para balancear a carga de grupos do Auto Scaling é o mais adequado para você? A tabela apresenta uma breve comparação entre os dois:

NGINX Plus na frente do ELB NGINX Plus com o software de integraçãoVantagens Configuração simples e sem necessidade de instalar software adicional. Todos os benefícios dos recursos do NGINX Plus, sem nenhuma limitação imposta pelo método com ELB.Desvantagens Limita o número de recursos do NGINX Plus que podem ser usados, incluindo os protocolos compatíveis. Aumenta o custo da implantação e a latência. Requer a instalação e a configuração do software de integração.Resumo Use este método se as desvantagens forem aceitáveis. Use este método para aproveitar ao máximo os recursos do NGINX Plus.

Resumo

O AWS Auto Scaling oferece a vantagem de ajustar o número de instâncias da aplicação de acordo com o nível de demanda. O NGINX Plus oferece recursos avançados de balanceamento de carga que podem ser usados em conjunto com grupos do AWS Auto Scaling.

Experimente o NGINX Plus com seus grupos do AWS Auto Scaling — inicie sua avaliação gratuita de 30 dias ou entre em contato conosco para conversar sobre seus casos de uso.

Sobre o autor

Michael Pleshakov

Mais publicações de Michael Pleshakov