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 –
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:
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 .)(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).
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.
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.
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 200
OK
ou 404
Nã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.
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.
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."