Teste de desempenho do NGINX Ingress Controller e do Red Hat OpenShift Router

Amir RawdatEngenheiro de Soluções

O Red Hat OpenShift Container Platform (OCP) é uma das plataformas Kubernetes gerenciadas mais populares e, assim como seus concorrentes, inclui ferramentas padrão de gerenciamento de tráfego para ajudar os usuários a começar rapidamente. O OCP Router – baseado no HAProxy – é o ponto de entrada padrão dos clusters do OCP. Ele pode balancear o tráfego HTTP e WebSocket, oferece suporte à terminação TLS e ao TLS entre o Router e as instâncias da aplicação, além de poder balancear conexões TLS no modo passthrough.

Os clientes frequentemente nos perguntam: “Por que devo usar o NGINX Ingress Controller no OpenShift quando o Router está disponível gratuitamente?” Em Por que você precisa de um controlador de Ingress de nível empresarial no OpenShift, o blogueiro convidado Max Mortillaro, da GigaOm, apresenta alguns motivos qualitativos para usar o NGINX Ingress Controller: gerenciamento avançado de tráfego, facilidade de uso, validação de JWT e integração com WAF. Mas também é importante responder a essa pergunta de uma perspectiva quantitativa. Por isso, testamos o desempenho do Router e do NGINX Ingress Controller baseado no NGINX Plus (nginxinc/kubernetes-ingress) no ambiente OCP, em uma implantação dinâmica na qual aumentamos e reduzimos o número de servidores upstream (backend) durante o teste.

Ao realizar testes de desempenho, analisamos dois fatores para avaliar o desempenho das ferramentas:

• Fator 1: resultados de latência para implantações dinâmicasConstatamos que a métrica mais eficaz para avaliar a experiência do usuário final em uma implantação dinâmica é a distribuição dos percentis de latência. Quanto mais latência um sistema adiciona, maior é o impacto na experiência do usuário. Também constatamos que, para obter uma visão fiel da experiência do usuário, é necessário incluir as latências dos percentis superiores da distribuição. Para uma explicação detalhada, consulte a seção Resultados de desempenho de NGINX e HAProxy: testando a experiência do usuário na nuvem em nosso blog.
• Fator 2: Tempos limite e errosQuando um sistema em teste causa latência em uma implantação dinâmica, geralmente é porque ele tem dificuldade para processar recarregamentos dinâmicos, resultando em tempos limite ou erros.

Resultados dos testes de desempenho

Vamos direto ao que interessa e analisar os resultados. A seguir, apresentamos detalhes sobre a topologia e o método de teste.

Conforme discutido acima, consideramos dois fatores ao avaliar o desempenho: latência e tempos limite/erros.

Fator 1: Distribuição dos percentis de latência

Como ilustra o gráfico a seguir, o NGINX Ingress Controller adicionou uma latência insignificante durante todo o teste, atingindo um máximo inferior a 700 ms no percentil 99,999. Em contrapartida, o OCP Router adicionou latência já em percentis relativamente baixos, e essa latência aumentou exponencialmente até se estabilizar em pouco mais de 25.000 ms (25 segundos) no percentil 99,99. Isso demonstra que, quando está sob carga e alterações no ambiente do cluster são aplicadas com frequência, o Router pode prejudicar a experiência do usuário.

Fator 2: Tempos limite e erros

A latência observada acima pode ser atribuída a tempos limite e erros: o OCP Router registrou 260 tempos limite de conexão e 85 erros de leitura de soquete, enquanto o NGINX Ingress Controller não registrou nenhum. Como vimos em outros testes de desempenho (consulte Testes de desempenho dos NGINX Ingress Controllers em um ambiente de nuvem Kubernetes dinâmico), os tempos limite e os erros do Router são causados pela forma como o HAproxy processa recarregamentos dinâmicos. O NGINX Ingress Controller baseado no NGINX Plus não causa tempos limite nem erros porque usa a API do NGINX Plus para atualizar dinamicamente a configuração do NGINX quando os endpoints são alterados.

Configuração e metodologia dos testes

Topologia de testes

Executamos os mesmos testes tanto no NGINX Ingress Controller quanto no OpenShift Router como o sistema em teste (SUT). O SUT encerrou as conexões TLS 1.3 do cliente e encaminhou a solicitação do cliente por meio de uma conexão separada para a implantação de backend.

O cliente estava hospedado em uma máquina separada executando o CentOS 7, localizada na mesma LAN que o cluster do OpenShift.

A implantação do SUT e do backend foi executada em um cluster OCP hospedado no VMware vSphere 6.7.0.45100.

Para a criptografia TLS, usamos RSA com uma chave de 2048 bits e sigilo encaminhado perfeito (Perfect Forward Secrecy).

Cada resposta da aplicação de backend consistia em cerca de 1 KB de metadados básicos do servidor, juntamente com o código de status HTTP 200 OK.

Metodologia de testes

Implantação do cliente

Usando o wrk2 (versão 4.0.0), executamos o seguinte script na máquina cliente, realizando o teste por 60 segundos (definidos com a opção -d) a uma taxa de transferência constante de 1000 solicitações por segundo (RPS, definida com a opção -R):

./wrk -t 2 -c 50 -d 60s -R 1000 -L https://ingress-url:443/

Software do SUT utilizado

• OpenShift Platform versão 4.8, que inclui o roteador baseado em HAProxy por padrão
• NGINX Ingress Controller versão 1.11.0 (NGINX Plus R22)

Implantação do backend

Realizamos testes com uma implantação dinâmica da aplicação de backend, usando o script a seguir para aumentar e reduzir periodicamente o número de réplicas do backend. Isso simula um ambiente dinâmico do OpenShift e mede a eficácia com que o NGINX Ingress Controller ou o OCP Router se adapta às alterações nos endpoints.

while [ 1 -eq 1 ]
do
  oc scale deployment nginx-backend --replicas=4  
  sleep 10 
  oc scale deployment nginx-backend --replicas=2
  sleep 10
done

Conclusão

A maioria das empresas que adotam metodologias de microsserviços está enviando novos desenvolvimentos por meio de seus pipelines de CI/CD com uma frequência maior do que nunca. Por isso, é fundamental utilizar um plano de dados que acompanhe essas novas metodologias em termos de capacidade e desempenho, sem prejudicar a experiência do usuário final. Oferecer uma experiência ideal ao usuário final exige manter uma baixa latência em todas as conexões dos clientes, em quaisquer circunstâncias.

Com base nos resultados de desempenho, o NGINX Ingress Controller oferece a melhor experiência possível ao usuário final em ambientes conteinerizados nos quais há uma grande necessidade de iterar e aprimorar o desenvolvimento.

Para começar, baixe uma versão de avaliação gratuita do NGINX Ingress Controller e descubra como fazer a implantação usando o NGINX Ingress Operator.

Sobre o autor

Amir RawdatEngenheiro de Soluções

Mais publicações de Amir Rawdat