BLOG | NGINX

Escolhendo o balanceador de carga certo na Amazon: Balanceador de carga de aplicativo da AWS vs. NGINX Plus

NGINX-Parte-de-F5-horiz-preto-tipo-RGB
Miniatura de Owen Garrett
Owen Garrett
Publicado em 21 de julho de 2020

Em agosto de 2016, a Amazon Web Services (AWS) introduziu o Application Load Balancer para balanceamento de carga da Camada 7 do tráfego HTTP e HTTPS. O novo produto adicionou vários recursos ausentes no balanceador de carga de Camada 4 e Camada 7 existente da AWS, o Elastic Load Balancer, que foi oficialmente renomeado para Classic Load Balancer.

Um ano depois, a AWS lançou o Network Load Balancer para melhorar o balanceamento de carga da Camada 4, então o conjunto de opções para usuários que executam aplicativos escaláveis e altamente disponíveis na AWS inclui:

Nesta postagem, revisamos os recursos do ALB e comparamos seus preços e recursos com o NGINX Open Source e o NGINX Plus.

Notas –

     

  • As informações sobre os recursos suportados são precisas em julho de 2020, mas estão sujeitas a alterações.
  • Para uma comparação direta do NGINX Plus e do Classic Load Balancer (antigo Elastic Load Balancer ou ELB), bem como informações sobre como usá-los juntos, consulte nossa postagem anterior no blog .
  • Para obter informações sobre como usar o NLB para uma implantação de alta disponibilidade do NGINX Plus, consulte nossa postagem de blog anterior .
  •  

Recursos no Application Load Balancer

O ALB, assim como o Classic Load Balancer ou NLB, é totalmente integrado à AWS. A Amazon o descreve como um balanceador de carga de Camada 7, embora ele não forneça toda a amplitude de recursos, ajustes e controle direto que um proxy reverso e balanceador de carga de Camada 7 autônomo pode oferecer.

O ALB fornece os seguintes recursos que estão ausentes no Classic Load Balancer:

  • Roteamento baseado em conteúdo. O ALB oferece suporte ao roteamento baseado em conteúdo com base na URL da solicitação, no cabeçalho do host e nos campos da solicitação que incluem cabeçalhos e métodos HTTP padrão e personalizados, parâmetros de consulta e endereço IP de origem. (Consulte “Benefícios da migração de um balanceador de carga clássico” na documentação do ALB .)
  • Suporte para aplicativos baseados em contêineres. O ALB melhora o suporte existente para contêineres hospedados no EC2 Container Service (ECS) da Amazon.
  • Mais métricas. Você pode coletar métricas por microsserviço.
  • Suporte a WebSocket. O ALB suporta conexões TCP persistentes entre um cliente e um servidor.
  • Suporte a HTTP/2. O ALB suporta HTTP/2, uma alternativa superior ao entregar conteúdo protegido por SSL/TLS.

(Para uma comparação completa dos recursos do ALB e do Classic Load Balancer, consulte “Comparações de produtos” na documentação da AWS .)

O ALB foi uma atualização significativa para usuários da AWS que tinham dificuldades com o conjunto limitado de recursos do Classic Load Balancer e ajudou a atender aos requisitos de usuários sofisticados que precisam proteger, otimizar e controlar o tráfego para seus aplicativos da web. No entanto, ele ainda não fornece todos os recursos de proxies reversos dedicados (como NGINX) e balanceadores de carga (como NGINX Plus).

Uma melhor abordagem para controlar o tráfego na AWS

Em vez de usar o Amazon ALB, os usuários podem implantar o NGINX Open Source ou o NGINX Plus na AWS para controlar e balancear a carga do tráfego. Eles também podem implantar o Classic Load Balancer ou o Network Load Balancer como um front-end para obter alta disponibilidade em várias zonas de disponibilidade. A tabela compara os recursos suportados pelo ALB, NGINX e NGINX Plus.

Observação:  As informações na tabela a seguir são precisas em julho de 2020, mas estão sujeitas a alterações.

  Amazonas ALB NGINX Open Source NGINX Plus
Balanceamento de carga
métodos e características
Métodos round_robin e least_outstanding_requests , com persistência de sessão baseada em cookie, grupos-alvo ponderados e início lento Vários métodos de balanceamento de carga (incluindo Round Robin, Least Connections, Hash, IP Hash e Random) com servidores upstream ponderados O mesmo que o NGINX Open Source, mais o método Least Time, mais métodos de persistência de sessão e início lento
Cache ❌ O cache no balanceador de carga não é suportado ✅ Cache de arquivo estático e cache dinâmico (aplicativo) ✅ Cache estático e dinâmico, além de recursos avançados
Verificações de integridade Ativo (identifica servidores com falha verificando o código de status retornado para verificações assíncronas) Passivo (identifica servidores com falha verificando as respostas às solicitações do cliente) Tanto ativas quanto passivas – as verificações ativas são mais ricas e configuráveis do que as ALB
Alta disponibilidade Você pode implantar instâncias ALB em várias Zonas de Disponibilidade para HA, mas não entre regiões HA ativo-ativo com NLB e HA ativo-passivo com endereços IP elásticos O mesmo que o NGINX Open Source, além do compartilhamento de estado de cluster integrado para HA contínuo em todas as instâncias do NGINX Plus
Suporte para todos os protocolos do conjunto IP ❌ Somente HTTP e HTTPS ✅ Também TCP e UDP, com verificações de integridade passivas ✅ Também TCP e UDP, com verificações de saúde ativas e passivas
Vários aplicativos por instância do balanceador de carga
Roteamento baseado em conteúdo ✅ Com base na URL de solicitação, cabeçalho do host e campos de solicitação, incluindo cabeçalhos HTTP padrão e personalizados, métodos, parâmetros de consulta e endereço IP de origem ✅ Com base nos mesmos fatores do ALB, mais cookies e cálculos dinâmicos usando o módulo NGINX JavaScript como um mecanismo JavaScript inline ✅ Com base nos mesmos fatores do NGINX Open Source, além de declarações e valores JWT no armazenamento de chave-valor
Aplicações em contêineres Pode balancear a carga para IDs da Amazon, instâncias de contêiner ECS, grupos de dimensionamento automático e funções do AWS Lambda Requer configuração manual ou modelos de configuração Configuração automatizada usando DNS, incluindo registros SRV ; funciona com os principais serviços de registro
Portabilidade ❌ Todos os ambientes (desenvolvimento, teste e produção) devem estar na AWS ✅ Qualquer ambiente pode estar em qualquer plataforma de implantação
SSL/TLS ✅ Vários certificados SSL/TLS com suporte SNI
❌ Validação de upstreams SSL/TLS não suportada
✅ Vários certificados SSL/TLS com suporte SNI
✅ Escolha completa de cifras SSL/TLS
✅ Validação completa de upstreams SSL/TLS
HTTP/2 e WebSocket
Capacidades de autenticação – Opções de autenticação OIDC, SAML, LDAP, AD IdP
– Integrado com AWS Cognito e CloudFront
Várias opções de autenticação
Capacidades avançadas ❌ API Barebones ✅ Serviço de origem, priorização, limitação de taxa e muito mais ✅ O mesmo que NGINX Open Source, mais RESTful API, armazenamento de chave-valor
Registro e depuração ✅ Formato de log binário da Amazon ✅ Arquivos de log personalizáveis e múltiplas interfaces de depuração ✅ Arquivos de log totalmente personalizáveis e múltiplas interfaces de depuração, totalmente suportados pelo NGINX
Ferramentas de monitoramento ✅ Integrado com Amazon CloudWatch ✅ NGINX Controller* e outras ferramentas de terceiros ✅ Controlador NGINX e outras ferramentas de terceiros; conjunto estendido de estatísticas relatadas
Suporte técnico oficial ✅ Com custo adicional ❌ Apenas suporte da comunidade ✅ Incluído no preço e direto da NGINX
Nível gratuito ✅ Primeiras 750 horas ✅ Sempre grátis ✅ Assinatura de teste de 30 dias

* O NGINX Controller agora é o F5 NGINX Management Suite .

É claro que você deve avaliar sua escolha de balanceamento de carga não por uma lista de verificação de recursos, mas avaliando os recursos necessários para entregar seus aplicativos sem falhas, com alta segurança, disponibilidade máxima e controle total.

Lidando com picos de tráfego

O Classic Load Balancer da Amazon (antigo ELB) sofreu com uma resposta ruim a picos de tráfego. As instâncias do balanceador de carga eram dimensionadas automaticamente para o nível atual de tráfego, e podia levar muitos minutos para o ELB responder e implantar capacidade adicional quando ocorriam picos. Os usuários tinham que recorrer a um processo manual baseado em formulários para solicitar recursos adicionais antes dos picos de tráfego (chamado de “pré-aquecimento”). Como o ALB é baseado no NGINX, as instâncias do ALB podem lidar com muito mais tráfego, mas você ainda pode observar eventos de dimensionamento em resposta a picos de tráfego. Além disso, um pico de tráfego resulta automaticamente em maior consumo de Unidades de Capacidade do Balanceador de Carga (LCUs) e, consequentemente, em um custo mais alto.

Você pode obter controle total sobre capacidade e custo se você mesmo implantar e dimensionar seus proxies de balanceamento de carga. O NGINX e o NGINX Plus são implantados em instâncias padrão da Amazon, e nosso guia de dimensionamento fornece uma indicação do desempenho máximo potencial de tipos de instâncias com diferentes capacidades. O preço do NGINX Plus é o mesmo para todos os tamanhos de instância, portanto, é econômico implantar capacidade excedente para lidar com picos e é rápido implantar mais instâncias (sem formulários para preencher) quando mais capacidade é necessária.

Detectando servidores com falha com verificações de integridade

Nossos testes do Amazon ALB indicam que ele não implementa verificações de integridade “passivas”. Um servidor só é detectado como tendo falhado quando um teste assíncrono verifica que ele não está retornando o código de status esperado.

Descobrimos isso criando uma instância ALB para balancear a carga de um cluster de instâncias. Configuramos uma verificação de integridade com frequência mínima de 5 segundos e limite mínimo de 2 verificações com falha, e enviamos um fluxo constante de solicitações ao ALB. Quando paramos uma das instâncias, para algumas solicitações o ALB retornou um 502 Ruim Porta de entrada erro por vários segundos até que a verificação de integridade detectasse que a instância estava inativa. Verificações de integridade passivas (com suporte do NGINX e do NGINX Plus) evitam que esses tipos de erros sejam vistos pelos usuários finais.

As verificações de integridade do ALB só podem determinar a integridade de uma instância inspecionando o código de status HTTP (como 200OK ou 404Não encontrado ). Essas verificações de integridade não são confiáveis; por exemplo, alguns aplicativos da web substituem erros gerados pelo servidor por páginas amigáveis ao usuário, e alguns erros são relatados apenas no corpo de uma página da web.

O NGINX Plus oferece suporte a verificações de integridade passivas e ativas , sendo que estas últimas são mais poderosas que as ALB, capazes de corresponder ao corpo de uma resposta e também ao código de status.

Preços

Por fim, a maior questão que você enfrentará ao implantar o ALB é o custo. O balanceamento de carga pode ser uma parte significativa da sua fatura da Amazon .

A AWS usa um algoritmo complicado para determinar os preços . A menos que você saiba precisamente quantas novas conexões, quantas conexões simultâneas e quantos dados você gerenciará a cada mês — o que é muito difícil de prever — e você possa executar o cálculo do LCU da mesma forma que a Amazon, você ficará com medo de pagar sua fatura da Amazon todo mês.

O NGINX Plus na AWS oferece previsibilidade completa. Por um custo fixo por hora mais taxas de hospedagem da AWS, você obtém uma solução de balanceamento de carga significativamente mais poderosa com suporte total.

Conclusão

O NGINX Plus é uma solução comprovada para balanceamento de carga da Camada 7, com recursos de balanceamento de carga da Camada 4 também. Ele funciona bem em conjunto com o Classic Load Balancer ou NLB da Amazon.

Incentivamos o uso contínuo e crescente do NGINX e do NGINX Plus no ambiente AWS, que já é uma solução muito popular. Se você ainda não é um usuário do NGINX Plus, comece hoje mesmo seu teste gratuito de 30 dias ou entre em contato conosco para discutir seus casos de uso .


"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."