なぜApache APISIXが最適なAPIゲートウェイなのか？

現在、モバイルフォンはさまざまな用途に使用されており、AppStoreにはソーシャルメディア、ユーティリティ、ゲーム、ライフスタイル、オンラインショッピングなど、多種多様なアプリケーションが提供されています。これらのアプリを構築する上で、APIは不可欠な存在です。そのため、APIを通じてサービスを提供する企業は、サービスの速度、安定性、セキュリティを確保するために、信頼性の高いAPIゲートウェイを選択する必要があります。

CNCFのAPIゲートウェイランドスケープには、Apache APISIX、Kong、Tykなど、約20種類のAPIゲートウェイ（クラウドベンダーのサービスを除く）がリストされています。多くのプロジェクトが自らを最も人気のあるオープンソースAPIゲートウェイプロジェクトや次世代APIゲートウェイと称していますが、果たしてそうなのでしょうか？

この記事では、開発者間での人気、オープンソースライセンス、パフォーマンス、エコシステム全体の観点から、複数のAPIゲートウェイを分析します。この分析を通じて、Apache APISIXが次世代APIゲートウェイとして、多くの面で他を凌駕していることがわかります。

ソフトウェアエンジニアがよく知っている

ソフトウェアエンジニアはAPIおよびAPIゲートウェイのユーザーであり開発者でもあるため、エンジニア間での人気はトレンドを直接示す指標です。以下は、Apache APISIX、Kong、Tyk、Glooの4つのAPIゲートウェイのGitHubコントリビューターの総数を比較したグラフです。

このグラフから、KongとTykは2015年頃に開始されたのに対し、Apache APISIXとGlooは2019年と比較的新しいことがわかります。さらに重要なのは、最も新しいApache APISIXが最も急勾配の曲線を持ち、320人以上のコントリビューターを集め、2位のKongを57人上回り、最も多くのコントリビューターを持つAPIゲートウェイプロジェクトとなっていることです。

コントリビューターの総数に加えて、月間アクティブコントリビューターの数はさらに重要な指標です。Tykの月間アクティブコントリビューターは5人前後で、10人を超えることはほとんどありません。一方、KongとGlooは10人から20人の間で変動しています。その間、Apache APISIXは安定して20人以上の月間アクティブコントリビューターを持ち、ピーク時には40人近くに達し、最もアクティブなAPIゲートウェイプロジェクトとなっています。

これら4つのオープンソースAPIゲートウェイプロジェクトの背後には、それぞれ商業化された企業があります。APISIXが際立つもう一つの指標は、月間アクティブコントリビューター数と従業員数の比率です。

2022年現在、KongとTykの比率は4％、Glooは24％です。一方、APISIXはほぼ100％に達しています。その理由は、API7.aiがAPISIXプロジェクトを開始した当初から、オープンソースコミュニティに継続的に力を入れ、開発者間での評判を獲得してきたためです。

オープンソースライセンス：オープンソースAPIゲートウェイを選ぶ上で最も重要な要素

2018年にMongoDBがオープンソースライセンスをSSPL（Server Side Public License）に変更して以来、MongoDBがマネージドサービスとして使用される場合、企業は自社のコードをオープンソースにする必要があります。その結果、企業はプロジェクトを選択する際に、そのプロジェクトのオープンソースライセンスを真剣に考慮する必要があります。

表面上、Apache APISIX、Kong、Glooはすべて商用に適したApache License Version 2.0を使用しており、TykはMozilla Public License Version 2.0を使用しています。しかし、深く掘り下げると、Kong、Gloo、Tkyはすべて商業化されたオープンソースベンダーによって支えられています。彼らはMongoDBのようにいつでもライセンスを変更し、パブリッククラウドや他の企業が自由に使用することを制限し、新しいバージョンにアクセスするために支払いを強制することができます。

ライセンス変更の確率は誰にもわかりません。しかし、このリスクはダモクレスの剣のようにユーザーの頭上にぶら下がっています。

このような状況下では、Apache Software Foundation（ASF）のオープンソースプロジェクトやCNCFのオープンソースプロジェクトを選ぶことが最良の選択です。なぜなら、彼らはプロジェクトのライセンスを変更することができないからです。Apache APISIXはそのようなプロジェクトです。ASFのトップレベルプロジェクトであり、商業企業がApache APISIXプロジェクトを完全にコントロールすることはなく、すべてのコードはASFに属し、ライセンスは変更されません。企業ユーザーは自由に使用でき、弁護士やコンプライアンス部門からの問い合わせメールを受け取ることを心配する必要はありません。

Apache APISIX、Kong、Glooのパフォーマンス

コミュニティでよく尋ねられる質問：EnvoyベースのGlooとNGINXベースのAPISIX、どちらがパフォーマンスが優れているのか？パフォーマンスは最も重要な指標ではありませんが、最も直接的な指標であることは間違いありません。以下の表は、Apache APISIXとGlooのベンチマークスコアを示しています。Apache APISIXのQPSはGlooの4.6倍で、レイテンシはGlooのわずか7％です。

NGINXまたはEnvoyの選択は、パフォーマンスの違いの主な要因ではありません。APISIXがソースコードで行った最適化がその理由です。同じくNGINXベースのKONGと比較しても、APISIXは大きなパフォーマンス優位性を持っています。以下のグラフは、GigaOmのレポートから抽出したもので、Kongのエンタープライズ版とAP7エンタープライズ版（完全なデータはこちらからリクエストできます）のテスト結果を示しています。

Kongのレイテンシは、API7（Apache APISIXの作者が作成したエンタープライズ版）の数十倍、場合によっては百倍にもなります。

なぜAPISIXはこれほど大きなパフォーマンス優位性を持っているのでしょうか？コードの前には秘密はありません。

言葉は安い、コードを見せてくれ

ここで、Apache APISIX、Kong、Glooを技術的な観点から分析しましょう。Apache APISIXの優位性は、主にソースコードの最適化と革新に依存しています。これらの技術の利点は、単純なPoC（Proof of Concept）では必ずしも反映されませんが、より複雑な本番環境で発揮されます。

APISIXプロジェクトが登場する前、多くの商用APIゲートウェイやオープンソースAPIゲートウェイ製品がありました。これらの製品は、APIデータ、ルーティング情報、証明書、設定データをリレーショナルデータベースに保存していました。リレーショナルデータベースにこれらのデータを保存する利点は非常に明白です。ユーザーはSQL文を使用して柔軟なクエリを実行でき、バックアップやその後のメンテナンスも容易です。

しかし、ゲートウェイはクライアントからのすべてのトラフィックを処理するミドルウェアです。可用性に対する要求は非常に高く、APIゲートウェイがリレーショナルデータベースに依存している場合、リレーショナルデータベースが故障（ダウンタイムやデータ損失など）すると、APIゲートウェイも影響を受け、システム全体の可用性も低下します。

この損害を減らすため、APISIXはダウンタイムやデータ損失の可能性を回避するようにアーキテクチャを構築しました。APISIXはリレーショナルデータベースの代わりにetcdを使用して設定データを保存します。これには以下の利点があります：

1. クラウドネイティブアーキテクチャに適している
2. APIゲートウェイに必要なデータ型をより適切に表現できる
3. 可用性が高い
4. 変更をミリ秒レベルで通知できる

etcdを使用して設定データを保存すると、ユーザーはデータ変更のためにetcdの更新を監視するだけで済みます。APISIXはミリ秒単位で最新の設定を取得でき、リアルタイム効果を実現します。一方、データベースからポーリングする場合、最新の設定情報を取得するのに5〜10秒かかる可能性があります。したがって、etcdをストレージスキームとして使用することで、APISIXはよりクラウドネイティブになり、可用性も高くなります。

高性能ルートマッチングアルゴリズム

リクエストを処理するために、APIゲートウェイはターゲット式を各リクエストのホスト情報、URI、HTTPメソッドなどの情報と照合する必要があります。したがって、効率的なマッチングアルゴリズムが重要です。ハッシュベースのアルゴリズムはパフォーマンスが良いですが、ファジーマッチングはできません。正規表現はファジーマッチングが可能ですが、パフォーマンスはそれほど良くありません。Apache APISIXの解決策は、ファジーマッチングをサポートする効率的な検索データ構造であるツリーを使用することです。より正確には、Apache APISIXはラディックスツリー（圧縮プレフィックスツリー）を使用します。これは、子が1つしかない中間ノードを圧縮するデータ構造です。既知のAPIゲートウェイ製品の中で、Apache APISIXはラディックスツリーをルートマッチングに適用し、1つのプレフィックスが複数のルートにマッチするシナリオをサポートする最初の製品です。実装の詳細については、lua-resty-radixtreeを参照してください。

リクエストをマッチングする際、ラディックスツリーを使用したアルゴリズムは漸進的にマッチングを行い、O(K)の複雑さ（KはルートのURIの長さで、APIの数に依存しない）を持ちます。このアルゴリズムは、パブリッククラウドやCDNなど、多数のルートがあるシナリオに非常に適しています。また、急速に増加する多数のルートを処理するのにも問題ありません。

高性能IPマッチングアルゴリズム

IPアドレスには2つの表記法があります：標準IP表記とCIDR表記です。32ビットIPv4を例にとると：

• 標準IP表記：192.168.1.1
• CIDR表記：192.168.1.1/8

Apache APISIXのIPマッチングとルートマッチングは異なるアルゴリズムを使用します。192.168.1.1というIPを例にとると、各IPセグメントの範囲は0から255であるため、IPアドレスは4つの16ビット整数で構成されていると考えることができ、IPの長さは固定されています。したがって、より効率的なアルゴリズムを使用してマッチングを完了できます。

500のIPv4レコードを含むIPライブラリがあると仮定すると、APISIXは500のIPv4レコードをハッシュテーブルにキャッシュし、ハッシュテーブルを使用してIPマッチングを行います。時間複雑度はO(1)です。他のAPIゲートウェイはリストイテレーションを通じてIPマッチングを完了し、ゲートウェイに送信される各リクエストは最大500回イテレーションされる可能性があります。したがって、APISIXの高精度IPマッチングアルゴリズムは、大量のIP許可リストと拒否リストのマッチング（WAFなど）を必要とするシナリオの効率を大幅に向上させます。

ルートの細分化

APIゲートウェイは、ホスト情報、URI、URIクエリパラメータ、URIパスパラメータ、HTTPメソッド、リクエストヘッダーなど、リクエストのさまざまな情報と事前定義されたルールを照合します。これらの情報は、ほとんどのAPIゲートウェイでサポートされています。しかし、Apache APISIXはこれらに加えて、より複雑なケースを解決するために、さらに多くのデータをサポートしています。

まず、Apache APISIXはNGINXの組み込み変数をサポートしています。つまり、uri、server_name、server_addr、request_uri、remote_port、remote_addr、query_string、host、hostname、arg_nameなど、数十のNGINX組み込み変数をマッチングパラメータとして使用できます。

NGINXの組み込み変数のリストについては、NGINX Variablesを参照してください。

次に、Apache APISIXは条件式をマッチングルールとしてサポートしており、その構造は[var, operator, val], ...]]です。ここで：

• varの値はNGINXの組み込み変数です。
• operatorは等しい、より大きい、より小さい、正規表現、含むなどをサポートします。

式が["arg_name", "==", "json"]であると仮定すると、現在のリクエストのURIクエリパラメータにnameというパラメータ値がjsonと等しいかどうかを意味します。Apache APISIXはこの機能をlua-resty-exprライブラリを通じて実装しています。詳細については、lua-resty-exprを参照してください。この機能はユーザーに多くの柔軟性を与え、拡張性が高いです。

さらに、Apache APISIXはユーザーがルートのTTL（Time to Live）を設定することを許可しています。

$ curl http://127.0.0.1:9080/apisix/admin/routes/2?ttl=60 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
    "uri": "/aa/index.html",
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "39.97.63.215:80": 1
        }
    }
}'

上記のコードは、APISIXが60秒後にルーティング設定を自動的に削除することを意味します。これは、カナリアリリースなどの一時的な検証シナリオで必要とされます。また、オンライントラフィック分割にも非常に便利で、他のゲートウェイ製品にはない機能です。

最後に、Apache APISIXはカスタムフィルター関数をサポートしています。filter_funcパラメータにカスタムLua関数を記述できます。例えば：

$ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
    "uri": "/index.html",
    "hosts": ["foo.com", "*.bar.com"],
    "filter_func": "function(vars)
                    return vars['host'] == 'api7.ai'
                end",
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "127.0.0.1:1980": 1
        }
    }
}'

filter_funcの入力パラメータはvarsで、NGINX変数はvarsから取得でき、フィルタリングロジックをカスタマイズできます。

マルチ言語プラグインのサポート

ユーザーは、特定のシナリオに向けてAPIゲートウェイの開発やシステム統合をカスタマイズする必要があることがよくあります。

APISIXは現在80以上のプラグインをサポートしていますが、すべてのユーザーシナリオをカバーするのは難しいです。そのため、ほとんどの企業は特定のビジネス向けにカスタマイズされたプラグインを開発し、ゲートウェイを通じてより多くのプロトコルやシステムを統合し、ゲートウェイ層で一元管理を実現します。

APISIXの以前のバージョンでは、開発者はLuaを使用してプラグインを開発するしかありませんでした。ネイティブの計算言語で開発されたプラグインは非常に高いパフォーマンスを持っていますが、新しい開発言語であるLuaを学ぶには時間と学習コストがかかります。

この状況に対応するため、APISIXは2つの解決策を提供しています。

最初の解決策は、Plugin Runnerを通じてより多くの主流プログラミング言語（Java、Python、Goなど）をサポートすることです。Plugin Runnerを使用すると、バックエンドエンジニアはローカルRPCを通じて通信し、自分が慣れ親しんだプログラミング言語を使用してAPISIXプラグインを開発できます。この利点は、開発コストを削減し、開発効率を向上させることです。欠点はパフォーマンスの損失です。では、開発者が慣れ親しんだ高級言語を使用して、Luaのネイティブに近いパフォーマンスを実現する方法はあるのでしょうか？

2番目の解決策は、Wasmを使用してプラグインを開発することです。上記の図の左側に示されているように、Wasm（WebAssembly）は最初にブラウザで実行される新しいタイプの技術として使用されましたが、現在ではサーバーサイドでもその利点を示し始めています。私たちはWasmをAPISIXに組み込み、ユーザーはWasmを使用してWasmバイトコードをコンパイルし、APISIXで実行できます。Wasmを利用するために、Wasmプラグインを開発し、ユーザーは高級プログラミング言語を使用してネイティブに近いAPISIXプラグインを開発できます。

その結果、ユーザーはLua、Go、Java、Python、Node.js、Wasmを使用してAPISIX上でカスタムプラグインを記述できます。開発を容易にすることで、APISIXプラグイン開発の扉を開きます。

結論

この記事では、ソフトウェアエンジニア、オープンソースプロトコル、パフォーマンス評価、技術、エコシステムなど、複数の視点からAPIゲートウェイ製品を分析し、比較しました。Apache APISIXが多くの面で優れていることがわかります。Apache APISIXは、南北トラフィックを処理できるAPIゲートウェイだけでなく、APISIX Ingress ControllerやService Meshなどのオープンソース製品も提供しています。

また、APISIXベースのエンタープライズ製品やSaaS製品も提供しています。

今日からApache APISIXとAPI7エンタープライズ製品を試してみてください！