Why Would You Choose Apache APISIX Instead of NGINX or Kong

APIゲートウェイは、クラウドネイティブ時代において重要なインフラストラクチャコンポーネントです。APIゲートウェイを評価するための一般的な基準は、その動的性と観測可能性の成熟度です。多くの企業は以前、NginxやKongをAPIゲートウェイとして使用していましたが、その後Apache APISIXに切り替えました。クラウドネイティブ時代に生まれたAPIゲートウェイとして、Apache APISIXは確かにさまざまな次元でビジネスの多くの課題を解決しています。では、なぜでしょうか？

NGINXとKongの制限

モノリシックサービスの時代には、NGINXはほとんどのシナリオを処理できます。しかし、クラウドネイティブ時代において、NGINXはそのアーキテクチャのために2つの欠点があります：

NGINXはクラスタ管理をサポートしていません。ほぼすべての企業が独自のNGINX設定管理システムを持っています。これらのシステムは似ていますが、統一されたソリューションはありません。
NGINXは設定のホットリロードをサポートしていません。ユーザーがNGINXの設定を変更すると、NGINXをリロードする必要があります。また、Kubernetesではサービスが頻繁に変更されます。そのため、NGINXを使用してトラフィックを処理する場合、サービスを頻繁に再起動する必要があり、これは企業にとって受け入れられません。

KongはNGINXの欠点を解決しますが、新しい制限をもたらします：

KongはPostgreSQLまたはCassandraデータベースに依存する必要があり、これによりKongのアーキテクチャが非常に肥大化し、企業に高可用性の制限をもたらします。データベースが故障すると、APIゲートウェイ全体が故障します。
Kongのルーティングはトラバーサル検索を使用します。ゲートウェイに1000以上のルートがある場合、そのパフォーマンスは劇的に低下します。

APISIXは上記のすべての制限を解決し、クラウドネイティブ時代の最良のAPIゲートウェイとなりました。

Apache APISIXの利点

優れたアーキテクチャ

まず、Apache APISIXは優れたアーキテクチャを持っています。クラウドネイティブは現在の技術トレンドであり、伝統的な企業の技術アーキテクチャを変えるでしょう。多くのアプリケーションがマイクロサービスとコンテナ化に移行しています。APISIXはその誕生以来、技術トレンドに従っています：

上図に示すように、左側と右側はAPISIXのデータプレーンとコントロールプレーンです：

データプレーン：NGINXのネットワークライブラリに基づいており（NGINXのルートマッチング、静的設定、Cモジュールは使用せず）、LuaとNGINXを使用してリクエストトラフィックを動的に制御します。
コントロールプレーン：管理者は組み込みのRESTful APIを介してetcdを操作できます。etcdのWatchメカニズムを利用して、APISIXは設定をミリ秒単位で各ノードに同期できます。

データの更新に関して、Kongはデータベースポーリング方式を使用します。最新の設定を取得するのに5〜10秒かかることがありますが、APISIXはetcdの設定変更を監視することで同じことを達成し、時間をミリ秒単位で制御できます。

APISIXとetcdの両方がマルチインスタンスデプロイをサポートしているため、単一障害点はありません。

豊富なエコシステム

以下の図はAPISIXのエコシステムマップです。この図から、APISIXがHTTP(S)、HTTP2、Dubbo、IoTプロトコルMQTTなどのL7プロトコルをサポートしていることがわかります。さらに、APISIXはTCP/UDPなどのL4プロトコルもサポートしています。

図の右側には、Apache SkyWalking、Prometheus、HashiCorp VaultなどのオープンソースまたはSaaSサービスが含まれています。図の下部には、より一般的なオペレーティングシステム環境、クラウドベンダー、ハードウェア環境があります。オープンソースソフトウェアとして、APISIXはARM64サーバーでも実行できます。

APISIXは多くのプロトコルとオペレーティングシステムをサポートするだけでなく、多言語プログラミングプラグインもサポートしています。最初に登場したとき、APISIXはLua言語を使用してプラグインを書くことしかサポートしていませんでした。この場合、開発者はLuaとNGINXに関連する技術スタックを習得する必要があります。しかし、LuaとNGINXは比較的ニッチな技術であり、開発者にはあまり馴染みがありません。そのため、私たちはAPISIXで多言語でのプラグイン開発を可能にし、Java、Golang、Node.js、Pythonなどの言語を公式にサポートしています。

活発なコミュニティ

以下の図はコントリビューターの成長曲線で、横軸はタイムライン、縦軸はコントリビューターの総数を表しています。Apache APISIXとKongの2つのプロジェクトが比較的活発であることがわかります。Apache APISIXは初日から優れた成長率を維持し、Kongのほぼ2倍の速さで急速に成長しています。2022年7月現在、APISIXのコントリビューター数はKongを上回り、APISIXの人気を示しています。もちろん、プロジェクトの活発さを評価する方法は他にもたくさんあります。例えば、月間アクティブなイシュー、PRの総数などです。良いニュースは、APISIXがこれらの面でも無敵であることです。

統一されたプロキシインフラストラクチャ

以下の図から、APISIXの目標が統一されたプロキシインフラストラクチャであることがわかると思います。

APISIXのコアは高性能なプロキシサービスであり、環境プロパティに縛られていません。そのため、IngressやService Meshなどの製品に進化する際に、APISIXの内部構造を変更する必要はありません。以下では、APISIXがこれらのシナリオをどのようにサポートするかを段階的に紹介します。

ロードバランサーとAPIゲートウェイ

まず、従来のLBとAPIゲートウェイのシナリオです。APISIXはNGINX + LuaJITに基づいて実装されているため、高性能でセキュアな機能を備えており、SSL証明書の動的ロード、SSLハンドシェイクの最適化などの機能をサポートしています。ロードバランシングに関しても、APISIXはより優れたパフォーマンスを発揮します。NGINXからAPISIXに切り替えることで、パフォーマンスが低下することはなく、統一管理などの機能による管理効率の向上が期待できます。

マイクロサービスゲートウェイ

APISIXでは、複数の言語で拡張プラグインを書くことができ、東西マイクロサービスAPIゲートウェイが直面する主な問題、つまり異種環境での統一管理を解決できます。APISIXはNacos、etcd、Eurekaなどのサービスディスカバリや標準のDNSメソッドもサポートしており、Zuul、Spring Cloud Gateway、DubboなどのマイクロサービスAPIゲートウェイを完全に置き換えることができます。

Kubernetes Ingress

現在、K8sの公式Kubernetes Ingress Controllerプロジェクトは主にNGINX設定ファイルに基づいて開発されているため、ルーティング能力とロードモードにおいてやや不十分で、いくつかの明らかな制限があります。例えば、APIを追加または変更する際に、新しいNGINX設定を更新するためにサービスを再起動する必要があります。サービスの再起動はオンライントラフィックに大きな影響を与えます。

APISIX Ingress Controllerは、上記のすべての制限を完全に解決します：完全なホットリロードをサポートします。同時に、APISIXのすべての利点を継承し、ネイティブのKubernetes CRDもサポートしているため、ユーザーが移行するのに便利です。

サービスメッシュ

今後5〜10年で、クラウドネイティブモデルに基づくサービスメッシュアーキテクチャが登場し始めます。APISIXも事前にこの分野に注目しています。豊富な研究と技術分析の後、APISIXはxDSプロトコルをサポートしました。APISIX Meshが誕生し、APISIXはサービスメッシュの分野でも一席を占めています。

まとめ

Apache APISIXがオープンソース化されてから3年が経ちました。活発なコミュニティとケーススタディは、APISIXがクラウドネイティブ時代の完璧なAPIゲートウェイであることを証明しています。この記事を読むことで、APISIXについてより包括的な理解を得られたと思います。

ご質問がある場合は、GitHub issueにメッセージを残してください。コミュニティのコントリビューターが迅速に対応します。もちろん、APISIX Slackチャンネルやメーリングリストに参加することもできます。詳細はJoin Usを参照してください。