BLOG | NGINX

Benchmarking de soluções de gerenciamento de API da NGINX, Kong e Amazon: Eles entregam APIs em tempo real?

NGINX-Parte-de-F5-horiz-preto-tipo-RGB
Alessandro Fael Garcia Miniatura
Alessandro Fael Garcia
Publicado em 14 de julho de 2020

Velocidade – é essencial no cenário digital de hoje, onde os consumidores podem facilmente mudar para um concorrente se o desempenho do seu aplicativo for muito lento. A velocidade do aplicativo é, em última análise, determinada por APIs responsivas, saudáveis e adaptáveis, e um dos fatores críticos na capacidade de resposta da API é a latência introduzida pelo seu gateway de API. Mas nem todos os gateways de API funcionam no mesmo nível.

Esse ponto foi trazido à tona para nós no outono passado, quando um cliente da NGINX – um grande player no setor de crédito ao consumidor – nos contou sobre a crescente importância do desempenho da API “em tempo real”, já que mais e mais aplicativos e outros componentes precisam se comunicar para fornecer a experiência digital que os usuários esperam. Ficamos muito satisfeitos em saber que o NGINX Plus foi o único gateway de API que atingiu as latências de API super-rápidas – tão baixas quanto 10 milissegundos (ms) – que o cliente precisava. Muitos outros clientes , como a Capital One , também compartilharam conosco como reduziram a latência e melhoraram o rendimento com o NGINX Open Source ou o NGINX Plus como seu gateway de API.

Decidimos analisar mais profundamente o ecossistema de APIs e tentar descobrir o que torna uma API “em tempo real”. Com base em uma série de fatores, determinamos que uma API em tempo real deve processar chamadas de API de ponta a ponta em menos de 30 ms em cada percentil até o 99º (o que significa que, em média, apenas 1 chamada em 100 leva mais de 30 ms).

Comparando soluções de gerenciamento de API

Nossos próprios testes mostram consistentemente que é fácil atingir o desempenho da API em tempo real com nossa solução de gerenciamento de API, que combina o NGINX Plus como o gateway de API para processar chamadas de API e o Módulo de gerenciamento de API do NGINX Controller para gerenciar instâncias do NGINX Plus e suas APIs conforme você as define, publica, gerencia e monitora durante todo o seu ciclo de vida.

Mas entendemos que você pode não querer acreditar em nossa palavra. Então, contratamos a GigaOm , uma empresa independente de pesquisa e análise técnica, para uma avaliação comparativa objetiva e transparente de nossa solução de gerenciamento de API e outras soluções populares no mercado: duas soluções que, como o NGINX, podem ser implantadas no local ou na nuvem, Apigee e Kong Enterprise , e duas ofertas de nuvem totalmente gerenciadas, Amazon API Gateway e Kong Cloud.

Neste blog resumimos os resultados dos testes do GigaOm (spoiler: O NGINX Plus entregou APIs em tempo real em todas as condições testadas, e as outras soluções não. Para todos os detalhes sobre as soluções, a metodologia de testes e os resultados, entre em contato com um membro da nossa equipe .

Observação:  O contrato de licença de usuário final (EULA) da Apigee proíbe a publicação de resultados de testes sem a permissão expressa do Google, então, infelizmente, nem o relatório nem este blog incluem informações sobre a Apigee.

Visão geral do benchmark

A GigaOm usou a ferramenta de teste de carga HTTP Vegeta para gerar solicitações (chamadas de API) e mediu quanta latência – a quantidade de tempo que levou para retornar a resposta a uma chamada de API – o gateway de API introduziu em vários números de solicitações por segundo (RPS), o que a GigaOm chama de “taxas de ataque”. O GigaOm executou testes com taxas de ataque começando em 1.000 RPS e aumentando para 5.000, 10.000, 20.000 e assim por diante até que Vegeta relatou códigos de status de erro. Cada teste durou 60 segundos e foi repetido 3 vezes. Conforme mostrado nos gráficos abaixo, o GigaOm capturou as latências nos percentis 50, 90, 95, 99, 99,9 e 99,99 e também registrou a maior latência observada durante o teste ( Máx. nos gráficos).

Resultados: Comparação NGINX Empresa Kong

A GigaOm conduziu dois benchmarks comparando o NGINX Plus (implantado usando o NGINX Controller) e o Kong Node (implantado usando o Kong Enterprise). No primeiro benchmark, havia um único nó de trabalho (uma instância do NGINX Plus ou Kong Node). No segundo, havia três nós de trabalho com carga balanceada pelo NGINX Open Source no modo Round-Robin. (GigaOm enfatiza que usar o NGINX Open Source como balanceador de carga não criou uma vantagem para o NGINX Plus, e até mesmo a Kong o recomenda como balanceador de carga a ser usado para instâncias Kong Node em cluster.)

Conforme mostrado nos gráficos a seguir, a diferença de latência entre NGINX e Kong é insignificante até o 99º percentil, ponto em que a latência do Kong começa a crescer exponencialmente. No percentil 99,99, a latência do Kong é o triplo ou o dobro da do NGINX nos dois benchmarks, respectivamente.

O 99º percentil é um valor mínimo decente para definir uma API como em tempo real, mas a GigaOm observa que em implantações no mundo real é "extremamente importante" manter baixa latência em percentis mais altos, como o 99,9º e o 99,99º. O relatório explica:

Os resultados de latência tendem a ser multimodais ao longo do tempo, com os topos dos picos representando “soluços” nos tempos de resposta.

Esses soluços são importantes. Se o tempo médio de resposta ou latência for menor que 30 ms, mas houver interrupções de latência de 1 segundo ou mais, na verdade há um efeito cumulativo na experiência subsequente do usuário. Por exemplo, se você visitar um drive-thru de fast food onde o tempo médio de espera pela comida é de 1 minuto, você provavelmente pensaria que essa foi uma boa experiência para o cliente. Mas e se o cliente à sua frente tiver um problema com o pedido e ele levar 10 minutos para ser resolvido? Seu tempo de espera seria na verdade de 11 minutos. Como sua solicitação chegou na fila depois do soluço, o atraso do percentil 99,99 atrasado pode se tornar seu atraso também.

O efeito negativo de latências anormalmente grandes em percentis altos se torna ainda mais significativo em aplicativos distribuídos, onde uma única solicitação de cliente pode gerar várias chamadas de API downstream. Por exemplo, suponha que 1 solicitação de cliente crie 10 chamadas de API para um subsistema com 1% de probabilidade de responder lentamente. Pode ser demonstrado matematicamente que, como resultado, há quase 10% de probabilidade de que a solicitação do cliente seja afetada por uma resposta lenta. Para obter detalhes sobre a matemática, consulte Quem moveu minha latência do 99º percentil?

A Figura 1 descreve os resultados para a taxa de ataque de 30.000 RPS com um único nó de trabalho. No percentil 99,99, a latência do Kong é mais de 3 vezes maior que a do NGINX e excede o limite de 30 ms para APIs em tempo real. Em contraste, o NGINX Plus atinge latência em tempo real em cada percentil – mesmo sua latência mais alta registrada ( Máx. ) de 13 ms é menos da metade do limite de tempo real.

Figura 1. Controlador NGINX e Kong Enterprise a 30.000 RPS com 1 nó

A Figura 2 mostra resultados muito semelhantes para o benchmark com três nós de trabalho, também na taxa de ataque de 30.000 RPS. Curiosamente, o Kong supera o NGINX nos percentis 99 e 99,9, mas mais uma vez sofre um grande pico de latência no percentil 99,99, desta vez atingindo uma latência que é quase o dobro da do NGINX. Assim como no primeiro benchmark, o NGINX permanece abaixo do limite de tempo real de 30 ms em todos os percentis.

Figura 2. Controlador NGINX e Kong Enterprise a 30.000 RPS com 3 nós

Outra maneira de avaliar o desempenho de um gateway de API é determinar o RPS máximo que ele pode processar com 100% de sucesso (sem 5xx ou429 [ Erros de muitas solicitações] e latência abaixo de 30 ms em todos os percentis, tanto para as configurações de nó único quanto de três nós. A Figura 3 mostra como, por esta medida, o NGINX sustenta um RPS 50% maior que o Kong: 30.000 contra 20.000.

Figura 3. Máxima produtividade alcançada sem erros

Resultados: Comparação NGINX Kong Cloud e Amazon API Gateway

No terceiro conjunto de benchmarks, a GigaOm comparou o NGINX Plus ao Kong Cloud e ao Amazon API Gateway. A GigaOm enfatiza que uma comparação direta é altamente problemática porque o Kong Cloud e o Amazon API Gateway são ofertas SaaS totalmente gerenciadas, enquanto o NGINX Controller é uma oferta PaaS e não está disponível atualmente como SaaS. Em particular, nenhuma oferta de SaaS revela o tipo de instância, poder de computação, memória ou recursos de rede que utiliza. Portanto, a GigaOm teve que fazer uma estimativa das melhores configurações comparáveis para o NGINX Plus.

Mesmo deixando de lado a comparação com o NGINX Plus, fica imediatamente claro que as ofertas de SaaS não conseguem fornecer APIs em tempo real em nenhum dos percentis testados, mesmo na segunda menor taxa de ataque (5.000 RPS) mostrada na Figura 4. No 50º percentil, a latência das ofertas de SaaS já é mais de 7 vezes o limite de 30 ms; no 99,99º percentil, ela excede esse limite em mais de 8.000%. A implicação óbvia é que não há condições sob as quais o Kong Cloud ou o Amazon API Gateway alcancem 100% de sucesso com latência abaixo de 30 ms.

Figura 4. Controlador NGINX, Amazon API Gateway e Kong Cloud a 5.000 RPS com 1 nó

Validando o NGINX como a única solução de API em tempo real

Em resumo, o NGINX é a única solução testada pela GigaOm que atendeu aos padrões de processamento de API em tempo real, alcançando menos de 30 ms de latência em cada percentil. O Kong Enterprise atinge desempenho em tempo real no 99º percentil, mas sua latência aumenta significativamente em percentis mais altos, tornando-o inadequado para ambientes de produção que exigem até mesmo um volume moderado de processamento de API em tempo real. Nenhuma das soluções SaaS testadas pode ser categorizada como em tempo real.

O relatório GigaOm valida nossos benchmarks anteriores e o que ouvimos de nossos clientes. O NGINX Plus é o gateway de API mais rápido do mercado e a única solução de API capaz de sustentar uma latência de menos de 30 ms em todos os percentis. E se você combiná-lo com o NGINX Controller, você ganha acesso a uma solução de gerenciamento de API exclusivamente arquitetada onde, devido ao desacoplamento cuidadoso, não há impacto algum no desempenho do plano de dados do gateway de API (NGINX Plus) do plano de controle de gerenciamento de API (NGINX Controller).

Você pode testar o desempenho da sua própria API com nossa ferramenta de medição de latência rtapi . Confira e entre em contato conosco para discutir como podemos ajudar você a tornar suas APIs em tempo real.


"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."