NGINXaaS for Azure permite que as empresas forneçam aplicações de alto desempenho na nuvem com segurança. Baseado no NGINX Plus, é um serviço totalmente gerenciado que se tornou disponível ao público em janeiro de 2023. Desde o lançamento e daqui em diante, continuamos aprimorando o NGINXaaS for Azure com a adição de novos recursos.
Neste blog, destacamos alguns dos recursos mais recentes de desempenho e segurança que permitem aproveitar ainda mais os benefícios do NGINX Plus sem precisar implantar, manter e atualizar suas próprias instâncias do NGINX Plus. Para obter informações gerais sobre o NGINXaaS for Azure e seus recursos abrangentes, leia Simplifique e acelere as migrações para a nuvem com o F5 NGINXaaS for Azure.
Figura 1: Visão geral do NGINXaaS for Azure
Proteção do tráfego upstream com mTLS
Embora os proxies reversos exijam SSL/TLS para criptografar o tráfego do lado do cliente na internet pública, o TLS mútuo (mTLS) torna-se essencial para autenticar e garantir a confidencialidade no lado do servidor. Com a adoção do Zero Trust, também é necessário verificar se o tráfego para os servidores upstream não foi alterado nem interceptado.
Figura 2: mTLS com o NGINXaaS
NGINXaaS for Azure agora oferece suporte a diretivas do NGINX para proteger o tráfego upstream com certificados SSL/TLS. Com essas diretivas, além de manter o tráfego upstream criptografado via mTLS, você também pode verificar se os servidores upstream estão apresentando um certificado válido emitido por uma autoridade certificadora confiável.
Rotação de certificados
Uma parte fundamental (com o perdão do trocadilho) do uso de certificados TLS com o NGINXaaS for Azure é gerenciar esses certificados com segurança por meio do Azure Key Vault (AKV). O AKV mantém protegido o material criptográfico confidencial e permite que o NGINXaaS for Azure use esses certificados, evitando a exposição acidental ou intencional do material de chave por meio do portal do Azure.
Figura 3: Rotação de certificados com o Azure Key Vault
NGINXaaS for Azure agora pode alternar certificados automaticamente nas suas implantações do NGINX sempre que eles forem atualizados no AKV. As novas versões dos certificados são incorporadas às suas implantações em até quatro horas.
Proxy HTTP/2 (e opções adicionais de protocolo)
Feche os olhos e volte no tempo até 1997. Curtíamos Tubthumping, do Chumbawamba, vestíamos nossas calças jeans JNCO (ou Modrobes, para os colegas canadenses por aí), e o HTTP/1.1 foi lançado. Naquela época, a maioria dos usuários finais acessava a Internet por meio de um modem discado, as páginas da web continham apenas algumas dezenas de elementos e, quando o assunto era experiência do usuário, a largura de banda era uma preocupação muito maior do que a latência.
Vinte e cinco anos depois, uma parcela considerável dos aplicativos web ainda usa HTTP/1.1 para fornecer conteúdo. Isso pode ser um problema. Embora o HTTP/1.1 ainda funcione, ele permite entregar apenas um recurso por conexão de cada vez. Enquanto isso, aplicativos web modernos podem fazer centenas de solicitações para atualizar uma interface de usuário.
Embora a maioria dos usuários disponha de uma largura de banda consideravelmente maior, a velocidade de transmissão de dados (limitada pela velocidade fundamental da luz) não avançou no mesmo ritmo. Portanto, a latência acumulada de todas essas solicitações pode ter um impacto significativo na percepção de desempenho do seu aplicativo. Os navegadores modernos abrem várias conexões TCP com o mesmo servidor, mas as solicitações em cada uma dessas conexões ainda são processadas sequencialmente, o que significa que um recurso lento pode atrasar todos os demais que vêm depois dele.
Veja como fica a página inicial da F5 quando ela é carregada usando apenas HTTP/1.1:
Figura 4: F5.com acessado via HTTP/1.1
Está vendo todas aquelas barras cinzas? É um tempo precioso que o navegador está desperdiçando enquanto aguarda o estabelecimento da sessão, fica bloqueado por um único recurso lento ou espera que uma nova conexão TCP fique disponível.
Vamos habilitar o HTTP/2 e tentar novamente:
Figura 5: A mesma solicitação, mas usando HTTP/2
Muito melhor. Ainda há alguns recursos lentos, mas eles não estão atrasando outras solicitações, e o tempo gasto aguardando atrasos relacionados ao enfileiramento foi reduzido significativamente. O HTTP/2 mantém a mesma semântica do HTTP/1.1 com a qual navegadores e servidores web já estão familiarizados, ao mesmo tempo que adiciona novos recursos para solucionar algumas das causas da percepção de baixo desempenho das aplicações (por exemplo, priorização de solicitações, compactação de cabeçalhos e multiplexação de solicitações).
Diante de uma diferença tão clara, o NGINXaaS for Azure agora permite atender às solicitações dos clientes por meio de HTTP/2. As conexões do lado do cliente têm maior probabilidade de ser afetadas por tempos de ida e volta mais longos. Assim, você pode fornecer esse tráfego com os benefícios de redução de latência do HTTP/2, sem alterar seus servidores upstream.
Apesar do que alguns profissionais do setor de aplicações web possam querer acreditar, reconhecemos que há outras opções de protocolo além do HTTP à sua disposição. É por isso que o módulo gRPC do NGINX agora também está disponível no NGINXaaS for Azure. Ele oferece várias diretivas de configuração para trabalhar com tráfego gRPC, incluindo interceptação de erros, manipulação de cabeçalhos e muito mais.
Para tráfego que não seja HTTP/gRPC, o módulo stream agora está disponível no NGINXaaS for Azure. Esse módulo oferece suporte a proxy e balanceamento de carga para tráfego TCP e UDP.
Suporte ao balanceamento de carga das camadas 4 e 7
O NGINXaaS for Azure agora pode funcionar como um balanceador de carga nativo da nuvem tanto na camada 4, com TCP/UDP, quanto na camada 7, com HTTP/HTTP. Por que isso é importante? Em vez de implantar dois serviços ou balanceadores de carga diferentes, o NGINXaaS for Azure permite implantar um único balanceador de carga e configurá-lo para operar nas duas camadas simultaneamente, simplificando sua arquitetura de nuvem e reduzindo seus custos.
Você pode saber mais sobre a configuração aqui.
Maior capacidade (até 160 NCUs)
NGINXaaS for Azure é um serviço baseado em consumo, medido por hora e cobrado mensalmente em Unidades de Capacidade do NGINX (NCUs). Recentemente, dobramos essa capacidade de implantação de 80 NCUs para 160 NCUs. Os clientes podem implantar um sistema menor, de 20 NCUs, e, se a carga de trabalho aumentar, escalá-lo para até 160 NCUs. Além disso, os clientes também têm a opção de implantar até 160 NCUs desde o início.
Adição de diretivas do NGINX Plus
Para proporcionar uma experiência simples de migração da configuração de um ambiente local para uma oferta de nuvem totalmente gerenciada, adicionamos muitas diretivas do NGINX Plus. Consulte todas as diretivas do NGINX Plus compatíveis com o NGINXaaS for Azure aqui.
Comece hoje mesmo
Estamos sempre aprimorando e ampliando as formas como você pode usar as tecnologias da NGINX e da F5 para proteger, disponibilizar e otimizar todos os aplicativos e APIs, em qualquer lugar. Com os recursos mencionados acima e outras novas funcionalidades adicionadas ao NGINXaaS for Azure, mais usuários do Azure podem solucionar diversos problemas de aplicativos e APIs com o poder do NGINX Plus, sem a sobrecarga de gerenciar uma infraestrutura adicional de máquinas virtuais ou contêineres.
Se quiser saber mais sobre o NGINXaaS for Azure, recomendamos que consulte a documentação do produto. Se estiver pronto para experimentar o NGINXaaS for Azure, acesse o Azure Marketplace 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.