Desempenhos do Open-Source API Gateway: APISIX 3.0 e Kong 3.0

Contexto

O Apache APISIX é um gateway de API nativo da nuvem, de alto desempenho e escalável. Ele é implementado com base no NGINX e no etcd. Além dos recursos dos gateways de API tradicionais, o APISIX possui recursos de roteamento dinâmico e recarregamento a quente de plugins, tornando-o especialmente poderoso para o gerenciamento de APIs em arquiteturas nativas da nuvem.

No outono de 2022, o Apache APISIX e o Kong lançaram suas versões 3.0 quase ao mesmo tempo. Em particular, os novos recursos do Apache APISIX 3.0 focam no ecossistema, inteligência e aplicações. Você pode conferir Apache APISIX 3.0: 11 Destaques do Gateway de API Open Source para saber mais.

Ambos são excelentes gateways de API de código aberto para microsserviços. Quando dois produtos são lançados simultaneamente, muitos usuários se interessam pelas diferenças de recursos e desempenho. Neste artigo, forneceremos os resultados de desempenho dos testes em quatro cenários diferentes.

Método de Teste

Topologia de Requisições

A seguir está o diagrama de topologia das requisições de teste. A ferramenta de teste de estresse utilizada foi o wrk2, e o serviço upstream utilizado foi o OpenResty.

APISIX

Kong

Informações do Servidor

Este teste foi realizado em um servidor em nuvem com Standard D8s v3 (8 vcpu, 32 GiB de memória). Todos os componentes relacionados ao teste foram implantados neste servidor.

Ambiente do Servidor

Versões de Software

A seguir estão as versões do software utilizadas neste teste:

Configuração de Rede

Ao implantar o APISIX e o Kong no docker, utilizamos o modo de rede host no docker para evitar implicações de rede que possam afetar os resultados do teste.

Implantação

Escolhemos o wrk2 como ferramenta de benchmark e o OpenResty como upstream simulado. Implantamos o APISIX e o Kong no docker com configuração declarativa habilitada para ambos.

Queríamos tornar os resultados do teste mais intuitivos, então utilizamos apenas um worker para os testes. Normalmente, a relação entre a capacidade de carga e o número de workers é linear. Portanto, apenas um worker será suficiente para os testes.

Além disso, o APISIX desativou os plugins proxy-cache e proxy-mirror, que são mencionados nos documentos relacionados a benchmarks no projeto APISIX (os plugins proxy-cache e proxy-mirror afetam o desempenho do APISIX em cerca de 4%).

Confira script de implantação e referência do script de teste aqui.

Testes

Teste #1: 1 Rota

Teste o cenário de proxy puro. Utilizaremos apenas uma rota e nenhum plugin para testar o desempenho do APISIX e Kong.

Configuração do APISIX:

routes:
  -
    uri: /hello
    upstream:
      nodes:
        "127.0.0.1:1980": 1
      type: roundrobin
#END

Configuração do Kong:

_format_version: "3.0"
_transform: true

services:
- name: hello
  url: http://127.0.0.1:1980
  routes:
  - name: hello
    paths:
    - /hello

Comparação de Desempenho

Utilizamos a métrica QPS para medir o desempenho. Foram realizadas 10 rodadas de testes.

Como podemos ver no gráfico, no cenário de proxy puro, o desempenho do APISIX 3.0 é muito superior ao do Kong 3.0. O QPS médio do APISIX 3.0 em 10 rodadas é 14104, e o QPS médio do Kong 3.0 em 10 rodadas é 9857. O desempenho do APISIX 3.0 é 140% do Kong 3.0.

Teste #2: 1 Rota + 1 Plugin de Limitação de Taxa

A limitação de taxa é um dos principais cenários de uso dos gateways de API. Portanto, neste cenário, configuramos os gateways com uma rota e um plugin de limitação de taxa.

Configuração do APISIX:

routes:
  -
    uri: /hello
    upstream:
      nodes:
        "127.0.0.1:1980": 1
      type: roundrobin
    plugins:
      limit-count:
        count: 999999999
        time_window: 60
        rejected_code: 503
        key: remote_addr
#END

Configuração do Kong:

_format_version: "3.0"
_transform: true

services:
- name: hello
  url: http://127.0.0.1:1980
  routes:
  - name: hello
    paths:
    - /hello
    plugins:
    - name: rate-limiting
      config:
        minute: 999999999
        limit_by: ip
        policy: local

Este teste mede o desempenho dos gateways de API no cenário de limitação de taxa. Configuramos o plugin de limitação de taxa com um limite mais alto para evitar acionar uma ação real de limitação de taxa.

Comparação de Desempenho

Novamente, realizamos 10 rodadas de testes. Podemos ver no gráfico que, após habilitar o plugin de limitação de taxa, o QPS do APISIX 3.0 e do Kong 3.0 caiu significativamente, mas o QPS do Kong 3.0 caiu mais notavelmente. O QPS médio de 10 rodadas do APISIX 3.0 é 9154, e o QPS médio de 10 rodadas do Kong 3.0 é 4810. Neste cenário, o desempenho do APISIX 3.0 é 190% do Kong 3.0.

Teste #3: 1 Rota + 1 Plugin de Limitação de Taxa + 1 Plugin de Autenticação

A autenticação é outro cenário comum de uso do gateway de API.

Neste cenário, configuramos os gateways com uma rota, um plugin de limitação de taxa e um plugin de autenticação.

Configuração do APISIX:

routes:
  -
    uri: /hello
    upstream:
      nodes:
        "127.0.0.1:1980": 1
      type: roundrobin
    plugins:
      key-auth:
      limit-count:
        count: 999999999
        time_window: 60
        rejected_code: 503
        key: remote_addr
consumers:
  - username: jack
    plugins:
        key-auth:
            key: user-key
#END

Configuração do Kong:

_format_version: "3.0"
_transform: true

services:
- name: hello
  url: http://127.0.0.1:1980
  routes:
  - name: hello
    paths:
    - /hello
    plugins:
    - name: rate-limiting
      config:
        minute: 999999999
        limit_by: ip
        policy: local
    - name: key-auth
      config:
        key_names:
          - apikey
consumers:
- username: my-user
  keyauth_credentials:
  - key: my-key

Este cenário abrange limitação de taxa e autenticação, de modo que vários plugins trabalham juntos no caminho da requisição. É um cenário típico de uso do gateway de API.

Comparação de Desempenho

Novamente, realizamos 10 rodadas de testes para medir o QPS.

Podemos ver no gráfico que, após o APISIX habilitar os plugins limit-count e key-auth, o QPS médio do APISIX 3.0 é 8933, que é apenas ligeiramente menor que o QPS médio de 9154 quando apenas o plugin limit-count está habilitado.

No Kong 3.0, no entanto, o QPS médio caiu para 3977, uma queda significativa em comparação com o QPS médio de 4810 quando apenas o plugin de limitação de taxa está habilitado.

Neste cenário de habilitar plugins de limitação de taxa e autenticação, o desempenho do APISIX 3.0 é 220% do Kong 3.0.

Teste #4: 5000 Rotas

Este teste utiliza scripts para gerar 5000 rotas únicas. O teste mede o desempenho do APISIX e do Kong para correspondência de rotas: quão rapidamente ele encontra uma correspondência.

Comparação de Desempenho

Em 10 rodadas de testes, o QPS médio do APISIX 3.0 é 13787, e o do Kong 3.0 é 9840. O desempenho do APISIX 3.0 é 140% do Kong 3.0.

Conclusão

A partir dos resultados dos testes em múltiplos cenários, é evidente que:

• o desempenho do APISIX 3.0 é cerca de 140% do Kong 3.0 quando os plugins não são utilizados (Teste #1 e Teste #4).
• O desempenho do APISIX 3.0 é cerca de 200% do Kong 3.0 quando os plugins são utilizados (Teste #2 e Teste #3)

Podemos ver que o APISIX mantém uma vantagem considerável de desempenho em sua versão 3.0.