Apache APISIXは、NGINXとetcdの上に構築されたクラウドネイティブなAPIゲートウェイです。動的ルーティング、負荷分散、認証、可観測性などのトラフィック管理機能を持ち、Kubernetes Ingressコントローラーとしても使えます。近年はAIゲートウェイ機能も備え、複数のLLMプロバイダーへの統一的なプロキシやトークン単位のレート制限も提供します。
コアはLuaJIT上で動くNGINX拡張で、apisix/init.luaやapisix/http/route.luaがリクエストのライフサイクルを制御します。ルート情報はapisix/core/config_etcd.luaを通じてetcdから動的に読み込まれ、設定変更はホットリロードされるためNGINXの再起動は不要です。apisix/balancer配下にroundrobin・chash・ewma・least_conn・priorityの各アルゴリズムがあり、apisix/discovery配下ではKubernetes・Consul・Nacos・Eureka・DNSなど多様なサービスディスカバリに対応します。プラグインはapisix/plugins配下にLuaファイルとして実装され、ai-providers・ai-protocols・ai-cacheなどAIゲートウェイ関連のプラグイン群も同じ仕組みで動きます。Admin API(apisix/admin配下)がルート・アップストリーム・SSLなどのリソースをREST経由でetcdに書き込み、それをデータプレーンが検知して反映する構成です。
- STEP 01
quickstartスクリプトをcurlで実行すると、DockerでAPISIX本体とetcdコンテナが起動し、ポート9080と9180が公開されます。
- STEP 02
curlでポート9080にHEADリクエストを送ると、Serverヘッダーにapisix/バージョン文字列が表示され、稼働確認ができます。
- STEP 03
Admin API(ポート9180)にPUTでルート定義をJSONで送信すると、httpbin.orgへ転送するルートがetcdに登録されます。
- STEP 04
登録したルート経由で/getにアクセスすると、httpbin.orgからのレスポンスがAPISIXを通じて返ってきます。
- STEP 05
ソースからビルドする場合はmake deps・make install-runtimeなどMakefile経由の手順が必要で、LuaJIT・OpenResty・etcdなど依存関係が多く、事前準備に時間がかかります。
- STEP 06
AI Gateway機能を試す場合はai-providers配下のプラグイン設定でOpenAIやAnthropicなどのAPIキーが必要になり、外部LLMサービスへの実際の通信が発生します。
手元にはetcdを設定ストアとするAPIゲートウェイが1つ立ち上がり、Admin API経由でルート・アップストリーム・プラグインを動的に追加変更できる環境が得られます。負荷分散やレート制限などのトラフィック管理に加え、AI関連プラグインを使えば複数LLMプロバイダーへの統一プロキシも構築できます。
etcdへの依存が強く、etcdが落ちるとデータプレーンの設定更新が反映されなくなるため、本番運用にはetcdクラスタの可用性設計が別途必要です。
プラグインの種類が非常に多く(ai-providers・ai-protocols・discoveryなど)、実運用で必要な機能を選び出すための学習コストがあります。
ソースからのビルドはUbuntu 24.04ベースのDevcontainerでもcpanmやetcdバイナリの手動取得が必要で、環境依存のトラブルが起きやすい構成です。
AI Gateway関連プラグインは外部LLM APIキーとネットワーク接続が前提のため、オフライン検証はできません。
既に稼働実績のあるAPIゲートウェイをetcdベースの動的設定で運用したいチーム、あるいはKubernetes Ingressや複数LLMプロバイダーの統一窓口を必要とするチームに向いています。README記載のquickstartコマンド一発でDocker環境が立ち上がる設計と、Admin API・プラグイン・バランサー・ディスカバリの各モジュールがソース上で明確に分離されている点から、実行せずとも構成の妥当性は判断可能です。ただしetcd依存とプラグイン数の多さゆえ、実運用移行には個別の検証が要ります。