Em agosto de 2016, a Amazon Web Services (AWS) lançou o Application Load Balancer para o balanceamento de carga na camada 7 do tráfego HTTP e HTTPS. O novo produto adicionou vários recursos que não estavam disponíveis no balanceador de carga existente da AWS para as camadas 4 e 7, o Elastic Load Balancer, que foi oficialmente renomeado como Classic Load Balancer.
Um ano depois, a AWS lançou o Network Load Balancer para aprimorar o balanceamento de carga da camada 4. Assim, as opções disponíveis para usuários que executam aplicações altamente disponíveis e escaláveis na AWS incluem:
- NGINX Open Source e NGINX Plus
- Classic Load Balancer
- Balanceador de Carga de Aplicações (ALB)
- Balanceador de Carga de Rede (NLB)
Neste post, analisamos os recursos do ALB e comparamos seus preços e recursos com o NGINX Open Source e o NGINX Plus.
Observações –
As informações sobre os recursos compatíveis estão atualizadas até julho de 2020, mas estão sujeitas a alterações. Para uma comparação direta entre o NGINX Plus e o Classic Load Balancer (anteriormente chamado de Elastic Load Balancer ou ELB), bem como informações sobre como usá-los em conjunto, consulte nossa publicação anterior no blog. Para obter informações sobre como usar o NLB em uma implantação de alta disponibilidade do NGINX Plus, consulte nossa publicação anterior no blog.
Recursos do Application Load Balancer
O ALB, assim como o Classic Load Balancer ou o NLB, é totalmente integrado à AWS. A Amazon o descreve como um balanceador de carga de camada 7, embora ele não ofereça toda a variedade de recursos, opções de ajuste e controle direto que um proxy reverso e balanceador de carga de camada 7 independente pode oferecer.
O ALB oferece os seguintes recursos que não estão disponíveis 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,
Hoste em campos da solicitação, incluindo cabeçalhos HTTP padrão e personalizados, métodos HTTP, parâmetros de consulta e endereço IP de origem. (Consulte “Benefícios da migração de um Classic Load Balancer” na documentação do ALB.) - Suporte a aplicações baseadas em contêineres. O ALB aprimora o suporte existente a contêineres hospedados no Amazon EC2 Container Service (ECS).
- Mais métricas. Você pode coletar métricas para cada microsserviço.
- Suporte a WebSocket. O ALB oferece suporte a conexões TCP persistentes entre um cliente e um servidor.
- Suporte a HTTP/2. O ALB oferece suporte a HTTP/2, uma alternativa superior para a entrega de 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 os usuários da AWS que enfrentavam dificuldades com o conjunto limitado de recursos do Classic Load Balancer e ajudou, em certa medida, a atender aos requisitos de usuários avançados que precisam proteger, otimizar e controlar o tráfego de suas aplicações web. No entanto, ele ainda não oferece todos os recursos de proxies reversos dedicados (como o NGINX) e balanceadores de carga (como o NGINX Plus).
Uma abordagem melhor 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 o tráfego. Eles também podem implantar o Classic Load Balancer ou o Network Load Balancer como frontend para obter alta disponibilidade em várias zonas de disponibilidade. A tabela compara os recursos compatíveis com ALB, NGINX e NGINX Plus.
Observação: As informações na tabela a seguir estão corretas até julho de 2020, mas estão sujeitas a alterações.
| Amazon ALB | NGINX Open Source | NGINX Plus | |
|---|---|---|---|
| Métodos e recursos de balanceamento de carga | Métodos Round_robin e least_outstanding_requests, com persistência de sessão baseada em cookies, grupos de destino ponderados e inicialização lenta | Vários métodos de balanceamento de carga (incluindo Round Robin, Menor Número de Conexões, Hash, Hash de IP e Aleatório) com servidores upstream ponderados | Igual ao NGINX Open Source, além do método Menor Tempo, mais métodos de persistência de sessão e inicialização lenta |
| Cache | ❌ Não há suporte a cache no balanceador de carga | ✅ Cache de arquivos estáticos e cache dinâmico (de aplicações) | ✅ Cache estático e dinâmico, além de recursos avançados |
| Verificações de integridade | Ativas (identificam servidores com falha verificando o código de status retornado em verificações assíncronas) | Passivas (identificam servidores com falha verificando as respostas às solicitações dos clientes) | Ativas e passivas — as verificações ativas são mais completas e configuráveis do que as do ALB |
| Alta disponibilidade | É possível implantar instâncias do ALB em várias Zonas de Disponibilidade para obter alta disponibilidade, mas não entre regiões | Alta disponibilidade ativa-ativa com NLB e alta disponibilidade ativa-passiva com endereços IP elásticos | Igual ao NGINX Open Source, além do compartilhamento integrado do estado do cluster para alta disponibilidade contínua entre todas as instâncias do NGINX Plus |
| Suporte a todos os protocolos da suíte IP | ❌ Somente HTTP e HTTPS | ✅ Também TCP e UDP, com verificações passivas de integridade | ✅ Também TCP e UDP, com verificações ativas e passivas de integridade |
| Várias aplicações por instância do balanceador de carga | ✅ | ✅ | |
| Roteamento baseado em conteúdo | ✅ Com base na URL da solicitação, no cabeçalho Host e nos campos da 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 que o ALB, além de cookies e cálculos dinâmicos usando o módulo JavaScript do NGINX como mecanismo JavaScript incorporado | ✅ Com base nos mesmos fatores que o NGINX Open Source, além de declarações JWT e valores no armazenamento de chave-valor |
| Aplicações em contêineres | Pode balancear a carga entre IDs da Amazon, instâncias de contêiner do ECS, grupos do Auto Scaling 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 a SNI ❌ Não há suporte à validação de upstreams SSL/TLS | ✅ Vários certificados SSL/TLS com suporte a SNI ✅ Liberdade total de escolha de cifras SSL/TLS ✅ Validação completa de upstreams SSL/TLS | |
| HTTP/2 e WebSocket | ✅ | ✅ | |
| Recursos de autenticação | – Opções de autenticação OIDC, SAML, LDAP e IdP do AD – Integração com AWS Cognito e CloudFront | Várias opções de autenticação | |
| Recursos avançados | ❌ API básica | ✅ Fornecimento de conteúdo de origem, priorização, limitação de taxa e muito mais | ✅ Igual ao NGINX Open Source, além de API RESTful e armazenamento de chave-valor |
| Registro e depuração | ✅ Formato de log binário da Amazon | ✅ Arquivos de log personalizáveis e várias interfaces de depuração | ✅ Arquivos de log totalmente personalizáveis e várias interfaces de depuração, com suporte completo da NGINX |
| Ferramentas de monitoramento | ✅ Integração com o Amazon CloudWatch | ✅ NGINX Controller* e outras ferramentas de terceiros | ✅ NGINX Controller e outras ferramentas de terceiros; conjunto ampliado de estatísticas relatadas |
| Suporte técnico oficial | ✅ Por um custo adicional | ❌ Somente suporte da comunidade | ✅ Incluído no preço e fornecido diretamente pela NGINX |
| Nível gratuito | ✅ Primeiras 750 horas | ✅ Sempre gratuito | ✅ Assinatura de avaliação por 30 dias |
* O NGINX Controller agora é o F5 NGINX Management Suite.
É claro que você deve avaliar sua escolha de balanceamento de carga não com base em uma lista de recursos, mas considerando as funcionalidades necessárias para disponibilizar suas aplicações sem falhas, com alta segurança, máxima disponibilidade e controle total.
Como lidar com picos de tráfego
O Classic Load Balancer da Amazon (anteriormente chamado de ELB) apresentava uma resposta insatisfatória a picos de tráfego. As instâncias do balanceador de carga eram dimensionadas automaticamente de acordo com o nível de tráfego atual, e o ELB podia levar vários minutos para responder e disponibilizar capacidade adicional quando ocorriam picos. Os usuários precisavam recorrer a um processo manual, baseado em formulários, para solicitar recursos adicionais antes dos picos de tráfego (prática conhecida como “pré-aquecimento”). Como o ALB é baseado no NGINX, suas instâncias conseguem processar um volume de tráfego muito maior, mas ainda é possível observar eventos de escalabilidade em resposta a picos de tráfego. Além disso, um pico de tráfego resulta automaticamente em um consumo maior de Unidades de Capacidade do Balanceador de Carga (LCUs) e, consequentemente, em um custo mais elevado.
Você pode ter controle total sobre a capacidade e os custos ao implantar e dimensionar por conta própria 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 estimativa do desempenho máximo potencial de tipos de instância 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, além de ser rápido implantar mais instâncias – sem precisar preencher formulários – quando for necessária mais capacidade.
Detectando servidores com falha por meio de verificações de integridade
Nossos testes com o Amazon ALB indicam que ele não implementa verificações de integridade “passivas”. Um servidor só é identificado como inoperante quando um teste assíncrono confirma que ele não está retornando o código de status esperado.
Descobrimos isso ao criar uma instância do ALB para balancear a carga de um cluster de instâncias. Configuramos uma verificação de integridade com a frequência mínima de 5 segundos e o limite mínimo de 2 verificações com falha e enviamos um fluxo constante de solicitações ao ALB. Quando interrompemos uma das instâncias, para algumas solicitações o ALB retornou um erro 502 Bad Gateway por vários segundos, até que a verificação de integridade detectasse que a instância estava inativa. As verificações passivas de integridade (compatíveis com o NGINX e o NGINX Plus) evitam que esses tipos de erro sejam vistos pelos usuários finais.
As verificações de integridade do ALB só conseguem determinar a integridade de uma instância inspecionando o código de status HTTP (como 200 OK ou 404 Not Found). Essas verificações de integridade não são confiáveis; por exemplo, algumas aplicações web substituem erros gerados pelo servidor por páginas mais amigáveis ao usuário, e alguns erros são informados apenas no corpo de uma página web.
O NGINX Plus oferece suporte a verificações de integridade passivas e verificações de integridade ativas, sendo estas últimas mais avançadas do que as do ALB, pois podem verificar tanto o corpo de uma resposta quanto o código de status.
Preços
Por fim, a principal questão ao implantar o ALB é o custo. O balanceamento de carga pode representar uma parcela significativa da sua fatura da Amazon.
A AWS usa um algoritmo complexo para determinar os preços. A menos que você saiba exatamente quantas novas conexões e quantas conexões simultâneas haverá, além do volume de dados que você gerenciará por mês – algo muito difícil de prever –, e consiga fazer o cálculo de LCU da mesma forma que a Amazon, você ficará apreensivo com a fatura da Amazon todos os meses.
O NGINX Plus na AWS oferece total previsibilidade. Por um custo fixo por hora, acrescido das tarifas de hospedagem da AWS, você obtém uma solução de balanceamento de carga significativamente mais avançada e com suporte completo.
Conclusão
O NGINX Plus é uma solução comprovada para balanceamento de carga na Camada 7, que também oferece recursos de balanceamento de carga na Camada 4. Ele funciona bem em conjunto com o Classic Load Balancer ou o NLB da própria Amazon.
Incentivamos o uso contínuo e crescente do NGINX e do NGINX Plus no ambiente da AWS, onde já são soluções muito populares. Se você ainda não usa o NGINX Plus, inicie hoje mesmo sua avaliação gratuita de 30 dias ou entre em contato conosco para conversar sobre seus casos de uso.
Sobre o autor
Publicações relacionadas no blog
Como o F5 NGINX One aprimora o gerenciamento e a observabilidade
Descubra como o F5 NGINX One aprimora o gerenciamento e a observabilidade de ambientes híbridos e multicloud ao oferecer um console web centralizado baseado em SaaS, com insights em tempo real, conformidade automatizada e gerenciamento simplificado de configurações.
Do OpenAPI ao NGINX como gateway de API usando uma API declarativa
Descubra como transformar uma definição de esquema OpenAPI em uma configuração NGINX totalmente funcional, operando como um API Gateway com a segurança de um Web Application Firewall e um Portal do Desenvolvedor, usando uma abordagem declarativa de API.
Como gerenciar picos repentinos de tráfego e sobrecarga do servidor
Picos de tráfego e sobrecarga de servidores são preocupações sérias para varejistas online em qualquer época, mas especialmente durante a “Cyber Season” de compras de fim de ano. Detalhamos como você pode aproveitar as soluções de entrega de aplicações de nível de produção da NGINX para se preparar para aumentos repentinos de tráfego.
Distribuição segura de chaves privadas SSL com o NGINX
Descrevemos três maneiras progressivamente mais seguras de proteger chaves privadas SSL ao configurar o NGINX para processar tráfego HTTPS: permitir acesso de leitura apenas ao usuário root, criptografar as chaves com senhas armazenadas separadamente e distribuir as senhas a partir de um repositório central.
Agrupando solicitações de API em lotes com NGINX Plus e o módulo JavaScript do NGINX
O módulo JavaScript do NGINX lançado com o NGINX Plus R15 oferece suporte a subsolicitações, possibilitando uma classe totalmente nova de casos de uso para o NGINX Plus. Este exemplo completo também usa a API do NGINX Plus e os módulos de chave-valor para converter solicitações de API dos clientes em solicitações separadas para as APIs dos microsserviços que compõem um aplicativo.
Como superar o esgotamento de portas efêmeras no NGINX e no NGINX Plus
Confira dicas para evitar o esgotamento de portas efêmeras com ajustes no kernel do Linux, conexões keepalive e conexões vinculadas dinamicamente a endereços IP locais.