オープンソースAPIゲートウェイのパフォーマンス比較:APISIX 3.0とKong 3.0

Zhengsong Tu

November 3, 2022

Products

背景

Apache APISIX は、クラウドネイティブで高性能かつスケーラブルなAPIゲートウェイです。NGINXとetcdを基盤に実装されており、従来のAPIゲートウェイの機能に加えて、動的ルーティングやプラグインのホットリロードといった機能を備えており、クラウドネイティブアーキテクチャにおけるAPI管理に特に強力です。

Apache APISIX Architecture

2022年秋、Apache APISIXとKongはほぼ同時に3.0バージョンをリリースしました。特に、Apache APISIX 3.0の新機能はエコシステム、インテリジェンス、アプリケーションに焦点を当てています。詳細については、Apache APISIX 3.0: オープンソースAPIゲートウェイの11のハイライトをご覧ください。

両者ともマイクロサービス向けの優れたオープンソースAPIゲートウェイです。2つの製品が同時にリリースされると、多くのユーザーがその機能や性能の違いに興味を持ちます。この記事では、4つの異なるシナリオでのテスト結果を提供します。

テスト方法

リクエストトポロジ

以下はテストリクエストのトポロジ図です。ストレステストツールとしてwrk2を使用し、アップストリームサービスとしてOpenRestyを使用しました。

APISIX

APISIX request topology

Kong

Kong request topology

サーバー情報

このテストは、Standard D8s v3(8 vCPU、32 GiBメモリ)のクラウドサーバーで実行されました。テストに関連するすべてのコンポーネントはこのサーバーにデプロイされています。

サーバー環境

名前
OSDebian 10 "buster"
ulimit -n65535

ソフトウェアバージョン

このテストで使用されたソフトウェアのバージョンは以下の通りです:

名前バージョン
Docker20.10.18, build b40c2f6
APISIX3.0.0
Kong3.0.0
UpstreamOpenResty 1.21.4.1
テストツールwrk2

ネットワーク設定

APISIXとKongをdockerでデプロイする際、ネットワークの影響を避けるためにdockerのホストネットワークモードを使用しました。

デプロイメント

ベンチマークテストツールとしてwrk2を選択し、シミュレートされたアップストリームとしてOpenRestyを使用しました。APISIXとKongをdockerでデプロイし、両方で宣言的設定を有効にしました。

テスト結果をより直感的にするため、テストには1つのワーカーのみを使用しました。通常、負荷容量とワーカー数の関係は線形です。そのため、1つのワーカーで十分です。

また、APISIXではproxy-cacheproxy-mirrorプラグインを無効にしました。これらはAPISIXプロジェクトのベンチマーク関連ドキュメントで言及されている通り、APISIXの性能に約4%の影響を与えます。

デプロイメントスクリプトとテストスクリプトの参照はこちらをご覧ください。

テスト

テスト #1: 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ゲートウェイの主要なユースケースの1つです。このシナリオでは、1つのルートと1つのレートリミットプラグインを設定しました。

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ゲートウェイのもう1つの一般的なユースケースです。

このシナリオでは、1つのルート、1つのレートリミットプラグイン、および1つの認証プラグインを設定しました。

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: