开源API网关Apache APISIX的技术探索
背景
Apache APISIX は、動的でリアルタイム、高性能なオープンソースのAPIゲートウェイであり、ロードバランシング、動的ルーティング、カナリアリリース、サーキットブレーカー、認証、および可観測性などの豊富なトラフィック管理機能を提供します。
APIゲートウェイとして、Apache APISIXは、ゲートウェイ、Kubernetes Ingress、サービスメッシュなどのシナリオで、企業がAPIやマイクロサービスのトラフィックを迅速かつ安全に処理するのを支援します。さらに、クライアントからサーバーへの南北トラフィックや、企業内のさまざまなマイクロサービス間の東西トラフィックも処理できます。
2019年6月6日にオープンソースとして公開されたAPISIXは、2019年10月にApache Software Foundationに寄贈され、数ヶ月でApache Software Foundationのトップレベルプロジェクトとなりました。
なぜAPISIXは短期間で急成長したのか？APISIXはどのような技術的探求を行ったのか？なぜますます多くの開発者や企業がAPISIXを使用するようになったのか？それを探ってみましょう。
Apache APISIXの主な特徴
データベースへの依存からの解放
APISIXプロジェクトが登場する前にも、多くの商用APIゲートウェイやオープンソースのAPIゲートウェイプロジェクトが存在していました。これらの競合製品の潜在的な問題は、APIデータ、設定情報、証明書設定、ルート情報のほとんどがリレーショナルデータベースに保存されていることです。
リレーショナルデータベースに保存することの明らかな利点は、ユーザーがSQL文を使用して柔軟なクエリを実行し、バックアップや後続のメンテナンスを行うのに便利であることです。
しかし、すべての物事には両面があります。基本的なミドルウェアとして、APIゲートウェイはすべてのクライアントトラフィックを処理するため、可用性に対する要求が高くなります。もしAPIゲートウェイがリレーショナルデータベースに依存している場合、データベースにエラーが発生すると（例えばクラッシュやデータ損失）、ゲートウェイも影響を受けます。この場合、システム全体の可用性の制限が強化されます。
そのため、APISIXの設計者は、アーキテクチャの根本的な側面からこのような問題を回避するためにあらゆる手段を試みました。
APISIXのアーキテクチャは主に2つの部分に分かれています。最初の部分はデータプレーンと呼ばれ、クライアントのリクエストとトラフィックを処理するコンポーネントです。これは認証、証明書のオフロード、ログ分析、可観測性をサポートしています。データプレーンはデータを保存しないため、ステートレスな構造です。
2番目の部分はコントロールプレーンと呼ばれます。APISIXは、コントロールプレーン上でMySQLのような従来の設定ストレージを使用せず、代わりにetcdを使用しています。
これを行う利点は以下の通りです：
- クラウドネイティブアーキテクチャの製品との統一性が高まる
- APIゲートウェイが保存するデータタイプに適している
- 高可用性の特性をよりよく反映する
- 変更のミリ秒単位での通知
etcdを使用することで、データプレーンはetcdの変更を監視するだけで済みます。データベースをポーリングする場合、最新の設定を取得するのに5〜10秒かかるかもしれませんが、etcdの設定変更を監視することで、ミリ秒単位でフィードバックを得ることができ、リアルタイムの効果を実現できます。
したがって、リレーショナルデータベースの代わりにetcdを使用することで、APISIXはネイティブクラウド環境との互換性が高まり、高可用性の利点が強化されます。
複数のプログラミング言語に対応したプラグイン
APIゲートウェイは、データベースや他のミドルウェアとは少し異なります。後者と比較して、ゲートウェイはカスタマイズ開発やシステム統合でより頻繁に使用されます。
APISIXは多くの公式プラグインをリリースしていますが、すべてのユースケースをカバーするのは難しいです。そのため、実際の使用では、ビジネスに応じてカスタマイズされたプラグインを開発する必要があります。APISIXはまた、ゲートウェイを通じてより多くのプロトコルやシステムを統合し、最終的にゲートウェイ層で一元管理を実現します。
当初、APISIXはLua言語でのプラグイン開発のみをサポートしていました。利点は、開発されたプラグインがネイティブプログラミング言語の最適化により高性能を発揮できることです。しかし、明らかな欠点は、新しい言語であるLuaを学ぶのに時間と学習コストがかかることです。
本質的に、APISIXは2つの方法でこの問題を解決しています。
1つ目の方法は、Java、Python、Goなどの主流のプログラミング言語をRunner Pluginを通じてサポートすることです。もしあなたがバックエンドエンジニアであれば、これらの言語の少なくとも1つを知っているはずです。そのため、RPCプロトコルを利用して、自分が慣れ親しんだ言語でAPISIXプラグインを開発することが容易になります。
一方で、開発コストの削減と開発効率の向上に役立ちますが、パフォーマンスレベルでは若干の遅延が発生します。そこで疑問が生じます。Luaのネイティブ性能を維持しつつ、高級言語も考慮できる解決策はあるのでしょうか？
ここで2つ目の方法が登場します。上記の画像の左側に示されているように、WebAssemblyは最初にフロントエンドやブラウザの技術として使用され、次第にサーバーサイドでもその利点を提供するようになりました。
APISIXにWebAssemblyを組み込むことで、ユーザーはWebAssemblyバイトコードをAPISIXで実行するためにコンパイルすることができます。最終的な効果は、高性能でありながら高級プログラミング言語で書かれたAPISIXプラグインを効率的に開発できることです。
したがって、現在のAPISIXバージョンでは、ユーザーはLua、Go、Python、Wasmなどの方法でAPISIXに基づいたカスタムコードを作成できます。この設計により、開発者の参入障壁が下がり、APISIXの機能にさらなる可能性がもたらされます。
プラグインのホットリロード
APISIXはNGINXと比較して2つの大きな進歩があります：APISIXはクラスタ管理と動的リロードをサポートしています。
もしNGINXを使用したことがあれば、NGINXのすべての設定がnginx.confファイルに記述されることを知っているでしょう。クラスタ制御を行うためには、すべてのサーバーでnginx.confファイルを修正する必要があります。このプロセス全体において、集中管理コントロールプレーンは存在しません。各NGINXはデータプレーンとコントロールプレーンの組み合わせです。ユーザーが数十台または数百台のNGINXサーバーを持っている場合、管理コストは非常に高くなります。
上記のシナリオでは、nginx.confファイルを修正した後、すべてのNGINXサーバーを再起動する必要があります。例えば、証明書の更新やアップストリームの変更を行う場合、設定ファイルを修正してからサーバーを再起動して有効にする必要があります。リクエストがそれほど多くない場合、この方法はまだ許容範囲内です。しかし、APIやマイクロサービスが増えるにつれて、修正のたびにサーバーを再起動する必要がある場合、クライアントへの影響は非常に大きくなります。
- ホットアップデートとホットプラグイン：再起動なしで設定とプラグインを継続的に更新！
- プロキシリライト：アップストリームに送信する前にリクエストのホスト、URI、スキーマ、メソッド、ヘッダーを書き換えることをサポート。
- レスポンスリライト：クライアントにカスタマイズされたレスポンスステータスコード、ボディ、ヘッダーを設定。
- 動的ロードバランシング：重み付きラウンドロビンロードバランシング。
- ハッシュベースのロードバランシング：一貫性のあるハッシュセッションによるロードバランシング。
- ヘルスチェック：アップストリームノードのヘルスチェックを有効にし、ロードバランシング中に不健康なノードを自動的にフィルタリングしてシステムの安定性を確保。
- サーキットブレーカー：不健康なアップストリームサービスをインテリジェントに追跡。
- プロキシミラー：クライアントリクエストをミラーリングする機能を提供。
- トラフィックスプリット：ユーザーがさまざまなアップストリーム間でトラフィックの割合を段階的に指示できるようにする。
上記の画像は、APISIXが現在ホットリロードを実装しているコンポーネントを示しています。アップストリームから証明書、さらにはプラグインまで、コードがリアルタイムで有効になることがわかります。一部のコミュニティメンバーは、アップストリームや証明書が動的である理由を理解できますが、プラグインの修正が動的である必要がある理由については疑問を持つかもしれません。彼らはプラグインの修正が頻繁に行われるものではないため、高度にアクティブである必要はないと考えているからです。
APISIXの設計者として、私たちはそれが最終的に動的であることを望んでいます。これにより、企業にとってより多くの可能性が増えます。例えば、ユーザーはデバッグプラグインを修正しながらコードのトラブルシューティングを行うことができ、プラグインコードを変更することなく問題を再現し、記録することができます。デバッグ機能を備えたプラグインとホットリロードメカニズムを組み合わせることで、開発者がトラブルシューティングに費やす時間と労力を大幅に削減できます。
プラグインの動的オーケストレーション
ホットリロードに加えて、APISIXはプラグイン間のリアルタイム動的オーケストレーションをサポートしています。動的オーケストレーションは、プラグインの運用に無限の可能性をもたらします。
プラグインオーケストレーションとは何でしょうか？私たちがさまざまな要件を提示するとき、リクエストをプラグインに変えることを望んでいます。それはLEGOを組み立てるようなものです。LEGOでは、形状の適合や交差などの統一された標準を通じて、無限の可能性のある形状を構築できます。APISIXのプラグインの場合、各プラグインは独立したケース要件を満たします。ユーザーがLEGOを組み立てるように、プラグインを使って自分のニーズをカスタマイズできるかどうかを問い続けています。
例えば、APISIXに100個のプラグインがある場合、ユーザーはこれらの100個のプラグインの機能しか見ることができず、その背後にある柔軟性を見ることができません。したがって、ミドルウェアを開発する際には、製品が何になり得るか、そして人々がそれを使用する際にどのようにしてより多くの可能性を与えるかを考慮する必要があります。
APISIXは現在、ほぼ100個のプラグインを持っていますが、その可能性は100個をはるかに超えています。そのため、プラグインの配置能力を開発した後、その組み合わせは100 * 99 * 98 * 97 * 96 * ...となり、ほぼ無限に近づきます。
例えば、ユーザーのレートを制限した後、通常はエラーコードが発生します。その後にロギングプラグインやエラーレポートプラグインを接続して、後続のアクティビティを記録することができます。以下の画像は、APISIXのプラグインオーケストレーションのモデルを示しています。
この機能には隠れた利点があります：各プラグインのコードをカバーする完全なテストスイートが存在します。 ユーザーがプラグインを配置するとき、彼はコードを書く必要はありません。この設計は、製品マネージャー、セキュリティエンジニア、運用エンジニアにとって非常に友好的です。彼らは長時間のトレーニングや学習を必要とせず、プラグインをドロップして設定を調整することで新しいAPISIXプラグインを作成できます。さらに、新しいプラグインコードの品質は、オープンソースAPISIXの公式コードと同じくらい高くなります。
全方向トラフィックのゲートウェイ
ゲートウェイ関連の開発を行うサーバーサイドエンジニアは、2つの基本的な概念に精通しているかもしれません：南北トラフィック（クライアント、ブラウザ、またはIoTデバイスからサーバーへのトラフィック）と東西トラフィック（企業内のシステムやマイクロサービス間の相互呼び出し）です。
南北トラフィックと東西トラフィックを処理するコンポーネントは異なります。例えば、南北トラフィックはロードバランサーを通過し、APIゲートウェイに到達し、サービスゲートウェイに入るかもしれません。そのため、NGINX、APISIX、Spring Cloud Gatewayなどのコンポーネントが存在します。サービスメッシュで東西トラフィックを処理する場合、Envoyのようなコンポーネントを使用するかもしれません。これらは多く見えますが、その機能に注目すると、類似点を見つけることができます。ほとんどがルーティングスケジューリング、動的アップストリーム、安全な認証のためのプラグインです。この場合、南北トラフィックと東西トラフィックを処理するコンポーネントを統一できるでしょうか？理想的な方法は、クライアントのリクエストがサーバーに入ると、すべてAPISIXによって処理されることです。南北または東西に関係なく、すべてのトラフィックとデータがコントロールプレーンを通じて制御されます。これはAPISIXの現在の技術で完全に実現可能です。
私たちのユーザーの一部は、このモードがユーザーの運用コストを大幅に削減できることを確認しています。同時に、複雑さを減らし、システム全体の応答速度を向上させることができます。さらに、このようなポジティブなフィードバックは、APISIXの今後のイテレーションにより明確な方向性を与え、APISIXが全トラフィックゲートウェイレベルでより多くの機能や役割を試すことを可能にします。
複数のサービスディスカバリーコンポーネントのサポート
ゲートウェイは基本的ですが重要なコンポーネントです。すべてのクライアントリクエストを処理し、さまざまなシステムやオープンソースプロジェクトと統合することが重要です。
もう1つの重要なコンポーネントは、サービスディスカバリーと登録です。これは他の要素と統合する際に使用されます。ユーザーはさまざまなサービスをEurekaやNacosなどの別々の部分に配置します。そのため、大規模で長期間のITシステムでは、複数のサービスディスカバリーコンポーネントが共存することが一般的です。
この状況では、すべてのトラフィックの出入り口がゲートウェイになります。ほとんどすべてのゲートウェイは1つのサービスディスカバリーしかサポートしていません。Aルートで別のNacosサービスディスカバリーコンポーネントを指定し、Bルートで別のConsulコンポーネントを指定する必要があります。その結果、異なるサービスディスカバリーコンポーネントに合わせて複数のゲートウェイを展開する必要があります。
現在、APISIXはデータプレーン上のサービスディスカバリーだけでなく、コントロールプレーン上のサービス登録とサービスディスカバリーコンポーネントも徐々にサポートしています。これは、大規模で長期的な企業サービスにとって非常に効率的なソリューションです。1つのAPIゲートウェイを展開するだけで、さまざまなサービスディスカバリーと登録コンポーネントに簡単に接続できます。
マルチクラウドとハイブリッドクラウドシナリオの探求
ユーザーがクラウドネイティブアーキテクチャを備えた本番環境にゲートウェイを展開する場合、マルチクラウドとハイブリッドクラウドは長期的な技術シナリオです。一方、APISIXがすべての機能、パフォーマンス、プラグイン、および複数のサービスディスカバリーを備えている場合、問題は避けられません。それは、ユーザーが本番環境でより良く実行する方法です。 マルチクラウドとハイブリッドクラウドシナリオは、APISIXにさらなる課題をもたらします。そのため、以下の詳細を考慮する必要があります。
1. アップストリームとダウンストリームの両方がmTLSをサポート
以前は、アップストリームmTLSをサポートする機能が優先度が高いとは認識していませんでした。しかし、クロスクラウドシナリオでは、アップストリームが別のクラウド上のサービスやSaaSサービスになる可能性があります。そのため、データセキュリティを向上させるために、アップストリームmTLSをサポートすることが必要です。
2. コントロールプレーンとデータプレーンアーキテクチャの完全な分離
過去1年間にAPISIXのいくつかのセキュリティ脆弱性が明らかになりましたが、そのほとんどはコントロールプレーンとデータプレーンのハイブリッド展開に起因しています。つまり、APISIXサービスが起動すると、コントロールプレーンとデータプレーンが同じサービス内に存在します。そのため、ハッカーが特定のデータプレーンにセキュリティの穴を通じて侵入すると、コントロールプレーンにも侵入し、すべてのデータを制御できるため、壊滅的な結果を招く可能性があります。
3. セキュリティ管理の強化
ゲートウェイは一般的にいくつかの機密データを保存します。例えば、一部のユーザーはSSL証明書やetcdに接続するための重要な情報をゲートウェイに保存するかもしれません。このような状況では、etcdやデータプレーンが侵害されると、深刻なデータ漏洩が発生する可能性があります。 したがって、重要な情報を保存する際には、Vaultのような鍵を保存する専用のコンポーネントを使用して機密データを保護することを考慮する必要があります。
4. より多くのクラウド標準の統合
私たちは、ユーザーがマルチクラウドシナリオで何も設定せずにさまざまなクラウドプラットフォームでスムーズに実行できるようにすることを目指しています。これは、ユーザーがカスタマイズされたプラグインを設定する必要があるという意味ではなく、APISIXがさまざまなクラウドからの標準、API、または他のサービスを直接統合できるようにすることを意味します。このモードは、ユーザーが事前に適応し、後続の使用において便利で快適であることを保証します。
Apache APISIXのサポーター
APISIXの開発史を通じて、多くの技術的革新が行われました。コード構築段階から多くのコミュニティ貢献者が手を取り合い、APISIXを統合されたAPIゲートウェイに構築しました。現在、APISIXはサポーターの努力により急速なイテレーションを維持しています。
オープンソース製品のイテレーションとアップグレードは、貢献者とユーザーに帰属します。
3年前にAPISIXがApache Software Foundationに寄贈されたとき、それは未熟なプロジェクトで、わずか20人の貢献者しかいませんでした。幸いなことに、APISIXはその急速な発展により、世界中のより多くのユーザー、貢献者、企業を引きつけました。例えば、私たちの顧客にはTencent、WPS、Sina Weibo、iQiyiなどの企業が含まれ、毎日数百億のAPI呼び出しを処理しています。さらに、NASA、European Factory Platform、Swisscomなどのさまざまな業界の国際的なユーザーも私たちのクライアントリストに含まれています。
WPSを例にとると、これは中国のSaaSオフィスソフトウェア会社で、Microsoft Office 365のようなソフトウェアを提供しています。携帯電話、ブラウザ、または端末デバイスで複数の人と作業する場合、数十人または数百人のユーザーが同じドキュメントを編集し、変更を同時に確認できます。この機能は、APIのさまざまな呼び出しを通じて実現されています。
ほとんどの大手企業は、毎日数百億のAPI呼び出しを処理し、ピーク時のQPSは100万を超えます。 このような使用規模により、APISIXは大規模な状況で実際のユーザーからのフィードバックを得ることができます。これらの企業ユーザーのサポートのおかげで、APISIXは急速に成熟したオープンソースプロジェクトに成長しました。
さらに、多くのユーザーがコミュニティでAPISIXを使用した経験やコード機能のイテレーションを共有し、双方にとって相互利益とウィンウィンの関係を築いています。これは、ユーザーがAPISIXを良い製品としてだけでなく、価値あるオープンソースプロジェクトとして見ていることを示しています。開発者の信頼を得た後で初めて、私たちは価値あるオープンソースプロジェクトになる機会を得ることができます。
貢献者は経験とフィードバックを適応させ、多くの製品機能を作成します。ユーザーはこれらの機能を利用して企業に価値をもたらします。これがオープンソースの本質です。 私たちは常にこのような真実を探求しており、無数のフォロワーのバブルを盲目的に追い求めることはありません。
APISIX 3.0プレビュー
これまで、APISIXが過去と現在に何を行ってきたかについて多くのことを話してきました。APISIXの開発プロセスはいくつかの段階に分けることができます。
APISIX 1.0はそのフレームワークを構築し、基盤となるアーキテクチャを強化し、APIゲートウェイの基本的な機能を提示することでした。2.0バージョンでは、より深く探求し、基盤をより柔軟にし、アーキテクチャをより成熟させました。
成熟したオープンソースプロジェクトにとって、その成熟の兆候は、その優れた機能ではなく、ユーザーと開発者にとってより良い体験をもたらすことに焦点を当てています。
現在の段階では、APISIXは多くの技術的探求と革新を行っていますが、ユーザーエクスペリエンスを完全に考慮していません。この問題は、ドキュメントの品質が不安定で、チュートリアルビデオが不足していることから明らかです。そのため、多くのユーザーが初めてAPISIXに触れるときに戸惑います。彼らはそれをどのように使用するか、特定の機能を異なるユースケースに適用する方法、そしてAPISIXが企業にどのような独自の価値をもたらすかについて確信が持てません。
したがって、次のAPISIX 3.0バージョンでは、このような問題を解決し、開発者エクスペリエンスに不親切な多くの欠陥を再構築しようとしています。例えば、APIを再設計してetcdの特定の戻り値への依存を排除し、公式ドキュメントをよりユーザーフレンドリーでわかりやすい説明に更新します。機能レベルでは、コントロールプレーンとデータプレーンも分離してセキュリティを強化し、より多くのレイヤー4プロトコルとRPCプロトコルをサポートして、ユーザーがすべてのゲートウェイ方向からトラフィックを迅速に取得できるようにします。
上記の機能を実装した後、APISIX 3.0はより安全で信頼性が高く、使いやすくなります。私たちは常に優れた運用とユーザーエクスペリエンスに注目しています。APISIXが世界中のすべてのAPIとマイクロサービスのリクエストを処理し、企業がAPIとマイクロサービスのトラフィックをより効率的に管理するのを支援することを願っています。
APISIXは2022年末に新しいバージョン3.0をリリースする予定です。最新バージョンのAPISIXの動向をフォローし、Apache APISIXプロジェクトの貢献に積極的に参加することを願っています。
APISIXの未来
サーバーサイド技術の開発と置き換えは非常に急速です。5年前に人気のあった多くの技術やフレームワークは消えつつあります。その理由は、エンジニアが新しいものを好むからではなく、これらの技術がエンジニアや企業の真のニーズを満たせないからです。その運命は決まっています：淘汰されることです。この重要な現実は、技術がビジネスや製品に奉仕しなければならず、現在の市場ニーズに合致しなければ生き残れないことを教えてくれます。
「沼地に城を建てるな」という言葉は、Apache APISIXの開発者に常に思い出させます。彼らは実際のニーズとシナリオに基づいてその開発と進化を導くべきです。そうでなければ、製品は徐々にエンジニアに捨てられるでしょう。
Apache APISIXの技術を業界の最先端に保つにはどうすればよいでしょうか？これは、Apache APISIXが将来も開発者や企業ユーザーを引きつけ続けることができるかどうかの重要な質問です。答えは簡単です：急速に成長している企業やエンジニアと共に成長し、互いにサポートすること。これにより、Apache APISIXは常に技術の最前線に立つことができます。そうすることで、APISIXは世界クラスの常緑のオープンソースプロジェクトになる可能性があります。
APISIXの未来は、Serverlessシナリオをより良くサポートし、サービスメッシュを改善し、APIの完全なライフサイクルプラットフォームを構築し、パブリッククラウド上のユーザーエクスペリエンスを向上させることです。これらは、少数の社内開発者によって計画されるのではなく、業界の何千人もの開発者によって計画されます。 だから、私たちと一緒にオープンソースの魅力を体験しましょう！