오픈소스 API 게이트웨이 성능 비교: APISIX 3.0과 Kong 3.0

Zhengsong Tu

November 3, 2022

Products

배경

Apache APISIX는 클라우드 네이티브, 고성능, 확장 가능한 API 게이트웨이입니다. 이는 NGINX와 etcd를 기반으로 구현되었습니다. 전통적인 API 게이트웨이의 기능 외에도, APISIX는 동적 라우팅 및 플러그인 핫 리로딩 기능을 갖추고 있어, 클라우드 네이티브 아키텍처에서의 API 관리에 특히 강력합니다.

Apache APISIX 아키텍처

2022년 가을, Apache APISIX와 Kong은 거의 동시에 3.0 버전을 출시했습니다. 특히, Apache APISIX 3.0의 새로운 기능은 생태계, 지능화, 애플리케이션에 초점을 맞추고 있습니다. Apache APISIX 3.0: 오픈소스 API 게이트웨이의 11가지 하이라이트에서 더 자세히 알아볼 수 있습니다.

두 제품 모두 마이크로서비스를 위한 훌륭한 오픈소스 API 게이트웨이입니다. 두 제품이 동시에 출시되면서 많은 사용자들이 그들의 기능과 성능 차이에 관심을 가지고 있습니다. 이 글에서는 네 가지 다른 시나리오에 대한 테스트 결과를 제공합니다.

테스트 방법

요청 토폴로지

다음은 테스트 요청의 토폴로지 다이어그램입니다. 스트레스 테스트 도구로는 wrk2를 사용했으며, 업스트림 서비스로는 OpenResty를 사용했습니다.

APISIX

APISIX 요청 토폴로지

Kong

Kong 요청 토폴로지

서버 정보

이 테스트는 Standard D8s v3 (8 vcpu, 32 GiB 메모리) 클라우드 서버에서 수행되었습니다. 모든 테스트 관련 컴포넌트는 이 서버에 배포되었습니다.

서버 환경

이름
OSDebian 10 "buster"
ulimit -n65535

소프트웨어 버전

이 테스트에서 사용된 소프트웨어 버전은 다음과 같습니다:

이름버전
Docker20.10.18, build b40c2f6
APISIX3.0.0
Kong3.0.0
업스트림OpenResty 1.21.4.1
테스트 도구wrk2

네트워크 설정

APISIX와 Kong을 도커에 배포할 때, 도커의 호스트 네트워크 모드를 사용하여 테스트 결과에 영향을 미칠 수 있는 네트워크 문제를 피했습니다.

배포

우리는 벤치마크 테스트 도구로 wrk2를 선택했고, 시뮬레이션된 업스트림으로 OpenResty를 사용했습니다. APISIX와 Kong을 선언적 구성으로 도커에 배포했습니다.

테스트 결과를 더 직관적으로 만들기 위해, 테스트에는 하나의 워커만 사용했습니다. 일반적으로 부하 용량과 워커 수의 관계는 선형적이므로, 하나의 워커만으로도 충분합니다.

또한, APISIX는 proxy-cacheproxy-mirror 플러그인을 비활성화했습니다. 이는 APISIX 프로젝트의 벤치마크 관련 문서에 언급된 바와 같이, 이 플러그인들이 APISIX의 성능에 약 4% 정도 영향을 미치기 때문입니다.

배포 스크립트 및 테스트 스크립트 참조를 확인하세요.

테스트

테스트 #1: 1개의 라우트

순수 프록시 시나리오를 테스트합니다. 하나의 라우트와 플러그인 없이 APISIX와 Kong의 성능을 테스트합니다.

APISIX의 구성:

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

Kong의 구성:

_format_version: "3.0"
_transform: true

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

성능 비교

performance(1).png

QPS 지표를 사용하여 성능을 측정했습니다. 총 10라운드의 테스트를 수행했습니다.

그래프에서 볼 수 있듯이, 순수 프록시 시나리오에서 APISIX 3.0의 성능은 Kong 3.0보다 훨씬 높습니다. APISIX 3.0의 10라운드 평균 QPS는 14104이고, Kong 3.0의 10라운드 평균 QPS는 9857입니다. APISIX 3.0의 성능은 Kong 3.0의 **140%**입니다.

테스트 #2: 1개의 라우트 + 1개의 속도 제한 플러그인

속도 제한은 API 게이트웨이의 주요 사용 시나리오 중 하나입니다. 따라서 이 시나리오에서는 하나의 라우트와 하나의 속도 제한 플러그인으로 게이트웨이를 구성했습니다.

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

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

이 테스트는 속도 제한 시나리오에서 API 게이트웨이의 성능을 측정합니다. 실제 속도 제한 동작이 트리거되지 않도록 속도 제한 플러그인을 높은 제한으로 설정했습니다.

성능 비교

performance(2).png

다시, 총 10라운드의 테스트를 수행했습니다. 그래프에서 볼 수 있듯이, 속도 제한 플러그인을 활성화한 후 APISIX 3.0과 Kong 3.0의 QPS가 모두 크게 떨어졌지만, Kong 3.0의 QPS가 더 크게 떨어졌습니다. APISIX 3.0의 10라운드 평균 QPS는 9154이고, Kong 3.0의 10라운드 평균 QPS는 4810입니다. 이 시나리오에서 APISIX 3.0의 성능은 Kong 3.0의 **190%**입니다.

테스트 #3: 1개의 라우트 + 1개의 속도 제한 플러그인 + 1개의 인증 플러그인

인증은 API 게이트웨이의 또 다른 일반적인 사용 시나리오입니다.

이 시나리오에서는 하나의 라우트, 하나의 속도 제한 플러그인, 그리고 하나의 인증 플러그인으로 게이트웨이를 구성했습니다.

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

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

이 시나리오는 속도 제한과 인증을 포함하여 여러 플러그인이 요청 경로에서 함께 작동하는 경우를 다룹니다. 이는 API 게이트웨이를 사용하는 전형적인 시나리오입니다.

성능 비교

performance(3).png

다시, QPS를 측정하기 위해 10라운드의 테스트를 수행했습니다.

그래프에서 볼 수 있듯이, APISIX가 limit-countkey-auth 플러그인을 활성화한 후, APISIX 3.0의 평균 QPS는 8933으로, limit-count 플러그인만 활성화했을 때의 평균 QPS 9154보다 약간 낮습니다.

그러나 Kong 3.0의 경우, 평균 QPS가 3977로 떨어졌으며, 이는 rate-limiting 플러그인만 활성화했을 때의 평균 QPS 4810에 비해 크게 떨어진 수치입니다.

속도 제한 및 인증 플러그인을 활성화한 이 시나리오에서, APISIX 3.0의 성능은 Kong 3.0의 **220%**입니다.

테스트 #4: 5000개의 라우트

이 테스트는 스크립트를 사용하여 5000개의 고유한 라우트를 생성합니다. 이 테스트는 APISIX와 Kong의 라우트 매칭 성능을 측정합니다: 얼마나 빠르게 매칭이 이루어지는지 확인합니다.

성능 비교

performance(4).png

10라운드의 테스트에서, APISIX 3.0의 평균 QPS는 13787이고, Kong 3.0의 평균 QPS는 9840입니다. APISIX 3.0의 성능은 Kong 3.0의 **140%**입니다.

결론

여러 시나리오에 대한 테스트 결과를 통해 다음과 같은 사실이 명확해졌습니다:

  • 플러그인이 사용되지 않을 때 APISIX 3.0의 성능은 Kong 3.0의 약 **140%**입니다 (테스트 #1 및 테스트 #4).
  • 플러그인이 사용될 때 APISIX 3.0의 성능은 Kong 3.0의 약 **200%**입니다 (테스트 #2 및 테스트 #3).

APISIX는 3.0 버전에서 상당한 성능 우위를 유지하고 있음을 알 수 있습니다.

Tags: