API GatewayでのPlugin Orchestrationの実装方法

動画を見る

まず、自己紹介をさせてください。私はMing Wen、API7.aiの共同創業者です。オープンソースプロジェクトApache APISIXのVPおよびPMCメンバーでもあります。また、Apache SkyWalkingのコミッターでもあります。さらに、qihoo 360オープンソース委員会の創設者、Tencent Cloud TVP、TARS FoundationのTOCメンバーでもあります。40以上のセキュリティ特許を持っています。

今日のトピックでは、4つの部分を紹介します。まず、Apache APISIXの簡単な紹介です。Apache APISIXとは何か、そしてそれが私たちのどのような問題を解決できるのかについて説明します。次に、APIゲートウェイにおけるカスタム開発について、そして3番目にApache APISIXのプラグインについて、どのように自動生成できるのかを紹介します。最後に、APIゲートウェイの未来についてのいくつかの考えを共有します。

まず、Apache APISIXについて簡単に紹介します。一言で言えば、クラウドネイティブなAPIゲートウェイです。以下はGitHub上のApache APISIXのリポジトリアドレスです。

Apache APISIXは非常に若いプロジェクトです。昨年6月にオープンソース化され、10月にApacheインキュベーターに寄贈されました。今年7月にApacheインキュベーターを卒業し、トップレベルプロジェクトになりました。これは急速に成長しているコミュニティで、わずか9ヶ月で達成されました。

Apache APISIXに詳しくない開発者のために、簡単に言えば、NGINXの強化版と考えることができます。NGINXのすべての機能をカバーしつつ、Luaを使用しています。これにより、NGINXにさらに動的な機能を追加し、非常に強力なAPIゲートウェイに変えています。Apache APISIXの最大の特徴は、完全に動的であることです。ルーティング、SSL証明書、プラグインなど、すべての機能が管理APIを通じて動的に設定され、サービスを再起動する必要はありません。Apache APISIXでは、ユーザーのビジネスニーズはすべてLuaを使用してプラグインを開発することで実現されます。APISIXには40以上の組み込みプラグインがあり、認証、レート制限、リクエスト制限、セキュリティ、ログ、可観測性など、企業でユーザーが遭遇する可能性のあるすべての機能をほぼカバーしています。

では、Apache APISIXが何をできるのかを見てみましょう。レイヤー4およびレイヤー7のトラフィックを処理できます。HTTP、HTTPS、TCP、UDP、MQTTなどが含まれます。

Apache APISIXはNGINXをベースにしているため、自然にNGINXの代わりにApache APISIXを使用して南北トラフィックを処理できます。同時に、Apache APISIXはマイクロサービス間のトラフィックも適切に処理できるため、envoyの代わりに使用することもできます。また、KubernetesのIngressコントローラーとしてApache APISIXを使用しているユーザーもいます。同時に、Apache APISIXのmqttプラグインを使用して、APISIXをIoTゲートウェイとして使用したり、IDPプラグインを使用してAPISIXをゼロトラストゲートウェイに変えたりすることもできます。したがって、APISIXはゲートウェイ自体のパワーに重点を置いています。プラグインを通じて、ユーザーはAPISIXをビジネスに必要なさまざまなゲートウェイに変えることができます。

これがApache APISIXの技術アーキテクチャです。これを見ると、APISIXには2つの部分があることがわかります。左側がデータプレーンで、右側がコントロールプレーンです。

まずデータプレーンを見てみましょう。ユーザーのリクエストがApache APISIXを通過して処理された後、プライベートAPI、パブリックAPI、またはパートナーAPIに渡されます。Apache APISIX内部では、プラグインはレゴブロックのように構築されています。サービスを再起動することなく、簡単にプラグインを追加または削除できます。

次にコントロールプレーンを見てみましょう。コントロールプレーンでは、管理者が管理APIを通じて設定をetcdクラスターに書き込み、APISIXのデータプレーンはetcdを監視するため、設定はミリ秒単位ですべてのデータプレーンに到達します。データプレーンのノードがデータを処理した後、いくつかのメトリクスとログデータをSkyWalkingやPrometheusなどのコンポーネントに報告します。

このアーキテクチャ図から、APISIXはetcdのみに依存しており、MySQLやPostgreSQLのようなRDSを持っていないことがわかります。したがって、APISIXは高可用性のためにより良く設計されています。同時に、そのアーキテクチャはよりシンプルで、デプロイと運用が容易です。

この図はApache APISIXのランドスケープです。左から見ると、APISIXは多くのレイヤー4およびレイヤー7プロトコルをサポートしています。ブラウザやモバイルアプリからのトラフィックだけでなく、さまざまなIoTデバイスがAPISIXにトラフィックを報告することもサポートしています。

Apache APISIXは、etcd consoulを含む多くの外部サービスディスカバリーセンターもサポートしています。

非常に重要なインフラストラクチャソフトウェアとして、APIゲートウェイは一般的にトラフィックの入り口に配置されます。したがって、クライアントからのすべてのリクエストを処理するだけでなく、SkyWalking、Datadog、Kafkaなどのバックエンドサービスに接続する必要もあります。

この図の下部には、APISIXがベアメタルだけでなく、さまざまなパブリッククラウドのサーバー上でも実行できることが示されています。また、ARMプラットフォーム上での実行もサポートしています。

OK、パート1はAPISIXの簡単な紹介でした。次に、パート2では、APIゲートウェイにおけるカスタムプラグインの開発について紹介します。

カスタム開発は、オープンソースゲートウェイを使用する際に非常に重要なポイントであり、高いハードルがあります。ゲートウェイは、箱から出してすぐに使用できるソフトウェアではありません。これはデータベースやメッセージキューとは異なります。MQやデータベースはインストール後すぐに使用できますが、ゲートウェイはそうではありません。これは、ゲートウェイには多少なりともカスタム開発が必要だからです。

たとえば、会社に古いシステムがある場合、または金融やセキュリティ業界の特別なプロトコルがある場合、ゲートウェイレベルでいくつかのトランスコードを行う必要があります。

一方、APISIXは40以上のプラグインを提供していますが、企業のすべてのニーズを満たすことはできません。なぜなら、各企業には独自のニーズがあるからです。したがって、既存のプラグインをカスタマイズしてニーズを満たす必要があります。これは実際には大きな問題です。なぜなら、プラグイン開発にはまだ多くのスキルが必要だからです。プラグイン開発に関して、異なるオープンソースプロジェクトには異なるソリューションがあります。

まず、Kongを見てみましょう。これは有名なAPIゲートウェイプロジェクトで、5年の歴史があります。Kongの技術スタックは基本的にAPISIXと同じで、どちらもNGINXとLuaに基づいて実装されています。しかし、Kongの技術アーキテクチャはAPISIXと同じではありません。KongはPostgresやCassandraなどのRDSに基づいています。APISIXはetcdを使用し、APISIXのソリューションはKubernetesとクラウドネイティブに近いです。

KongとAPISIXの共通点は、開発者がLuaを使用してプラグインを開発する必要があることです。Luaは人気のあるプログラミング言語ではなく、多くの開発者はそれに詳しくありません。Lua自体はシンプルですが。したがって、プラグインをよりシンプルにする以外に、どのようなより良いソリューションがあるでしょうか？

Kongのソリューションは、goを使用してプラグインを書くことをサポートすることです。このアプローチにより、より多くのgo開発者がプラグインを書いて、自社のカスタムニーズを満たすことができます。これは良いアイデアですが、一方で、KongはNginxとLuaに基づいてネイティブに実装されており、goで書かれたプラグインは実際には別のプロセスを呼び出す必要があり、プロセス間通信が発生し、パフォーマンスの問題があります。

次に、2番目のものを見てみましょう。これは、東西トラフィックを処理する非常に有名なオープンソースデータプレーンプロジェクトであるEnvoyで、C++で書かれています。したがって、Envoyのプラグインも自然にC++で実装されています。したがって、初心者には簡単ではありません。

Envoyは他の言語での開発もサポートしています。たとえば、EnvoyはLuaフィルターをサポートしており、LuaフィルターはKongと同じ問題を抱えています。つまり、Luaに詳しい開発者が少ないことです。したがって、EnvoyはWASMもサポートしており、他の言語の開発者がプラグインを書くことを引き付けることができます。このソリューションは完璧ではなく、WASMの安定性とパフォーマンスはまだ改善の余地があります。

KongとEnvoyのソリューションは同じです：より多くの開発者がプラグインを開発する能力を持つことを望んでいます。それがgo、Lua、またはWASMを使用するかどうかに関係なく。したがって、APISIXに戻ると、私たちは銀の弾丸を見つけたいと考えています。

では、この銀の弾丸はどのようなものなのでしょうか？私たちは、ゲートウェイレベルで、次の2つの問題を最初に解決する必要があると考えています。

1つ目は、開発が必要な多くのプラグインが実際にはシンプルであることです。すでに存在する40以上のオープンソースプラグインをどのように再利用するか？

2つ目は、企業内のゲートウェイの需要側、たとえばプロダクトマネージャー、運用チーム、セキュリティチームが、できるだけ少ないコストでゲートウェイ上に自分のニーズを実装できるようにすることです。コードを書く必要がないことが最善です。

これらの2つの問題を解決できれば、開発者だけでなく、より多くの人々がAPゲートウェイを開発できるようになる機会があります。

まず、最初の問題である既存のプラグインの再利用をどのように解決するかを見てみましょう。マイクロサービスはすでに非常に人気のある技術です。したがって、この概念をAPIゲートウェイのプラグインに導入できるでしょうか？

各プラグインが1つの機能のみを行うようにすることができます。これは、Linuxのプロセスの設計と同じです。したがって、私たちはマイクロプラグインと呼ばれる概念を提案しました。

各プラグインは独立した機能のみを行います。次に、Linuxのパイプに似た設計が必要です。これらのマイクロプラグインを接続するためです。

たとえば、最初にuriブロックプラグインを呼び出します。呼び出しが完了した後、uriが実際にブロックされているかどうかを判断します。ブロックされている場合は、Kafkaプラグインを呼び出します。

このパイプ方式を使用して、これらのプラグインを接続できます。Apache APISIXには現在40以上のプラグインがあります。40以上のプラグインの順列は無限の可能性があり、ユーザーのニーズを満たすのに十分です。

しかし、現在の問題は、すべてのオープンソースAPIゲートウェイで、プラグインがコンテキストを共有せず、互いに協力できないことです。したがって、これらのプラグインを接続する必要があります。これを行うことで、マイクロプラグインを使用してプラグインの再利用の問題を解決できます。

2番目の問題は、マイクロプラグインを手に入れた後、APIゲートウェイの新しいプラグインの開発コストをできるだけゼロに近づけて、ユーザーのニーズを満たすことです。私たちは、非開発者、つまり技術的背景がなく、プログラミング方法を知らないプロダクトマネージャーやセキュリティ担当者が、開発なしで自分のニーズを実現できることを望んでいます。なぜなら、彼らが私たちのニーズを最も理解しているからです。

同時に、これによりAPIゲートウェイ開発のハードルが下がり、より多くの人々がAPゲートウェイに貢献できるようになります。スローガンを使用すると、「創造から創造へ」です。私たちは自分のアイデアを開発者向けのドキュメントに書くだけでなく、直接新しいプラグインを作成できます。

これは良いアイデアのように聞こえますが、実現できるでしょうか？実際、技術的な思考から飛び出して、他の業界がどのように解決しているかを見ることができます。

たとえば、医療業界のプロセスエンジンでは、GUI方式で構築されています。なぜなら、彼らのユーザーは医師だからです。次に、子供向けのレゴも同じです。限られた数のブロックを使用して、無限の可能性のある形状を構築できます。

GUIとレゴのアイデアを組み合わせると、実際にはスクラッチであることがわかります。これは子供がプログラミングを学ぶ方法で、ハードルが非常に低くなります。

前述の2つの問題を解決したことに基づいて、APISIXは独自に新しい概念を提案しました：プラグインオーケストレーション。以下はプラグインオーケストレーションのデモです。まずこの短い動画を見てみましょう。

この動画では、最初にuriブロックプラグインを作成し、次に条件判断を作成します。uriブロックがtrueの場合、フォールトインジェクションプラグインに追加します。uriブロックの結果がFalseの場合、Kafkaプラグインに渡してログを記録します。

次に、各プラグインと判断条件を設定します。最後に、curlを使用してこの新しいプラグインがゲートウェイのノードで実際に動作するかどうかを確認します。はい、動作します。

次に、このプラグインオーケストレーションがどのように実装されているかを説明します。これも皆さんが関心を持つ技術的な問題かもしれません。

プラグインオーケストレーションを実装するには、3つのステップを踏む必要があります。

ステップ1では、この新しいプラグインを記述するためにDAGを使用する必要があります。左側の矢印のあるグラフは実際にはDAG（有向非巡回グラフ）で、前の動画で説明したコードと同じです。これは人間にとって親しみやすい記述方法です。コンピュータにとっては、右側のデータ構造の記述言語に変換する必要があります。たとえば、1番目のノードの後に2、4、6が続く場合、1番目のノードが2番目、4番目、6番目のノードを指していることを意味します。3番目の値がnilの場合、3番目のノードの後には他のノードがないことを意味し、他のノードも同様です。このようにして、DAGをデータ構造の記述に変換します。

このデータ構造を取得した後、このデータ構造をJSON文字列に変換し、このJSON文字列をサーバーに渡します。右側のJSON文字列は、デモで見たプラグインから変換されたものです。

ステップ1の後、すでにjsonで記述された文字列がありますが、この文字列をAPISIXが実行できるコードに変換するにはどうすればよいでしょうか？

APISIXではLuaコードを実行していることを知っているので、コンパイラが必要です。jsonをAST（抽象構文木）に解析し、最終的にLuaコードを生成します。このステップでは、jsonschemaを使用しました。以下はオープンソースリポジトリです。

Luaコードを生成した後、APISIXのコントロールプレーンを使用して、管理APIを通じてLuaコードをetcdに書き込み、APISIXのデータプレーンノードがetcdを監視してLuaコードを取得します。APISIXには、サーバーレスプラグインのように、Luaコードを動的に実行する能力があります。

したがって、プラグインオーケストレーションによって生成された新しいプラグインは、DAGからデータノードの実際の実行まで、すべてのプロセスが動的です。これはAPISIXの非常に重要な特徴です。

ここまで見て、どこで試せるのかという疑問を持ったかもしれませんか？心配しないでください、ここにオープンソースプロジェクトがあり、オンラインデモもあります。

最後の部分では、APIゲートウェイの未来についての私たちの考えを話したいと思います。APIゲートウェイは長い間存在しています。10年以上前に多くの企業やオープンソースプロジェクトがAPIゲートウェイを行っていました。そして、クラウドネイティブの時代に、APIゲートウェイはユーザーの要求の変化に直面し、APゲートウェイに対してより高い要求が提起されています。

1つのトレンドは、従来の南北APIゲートウェイが東西マイクロサービストラフィックを処理し始めることです。たとえば、NGINXはNGINXコントロールとNGINXユニットを立ち上げました。KongとAPISIXもマイクロサービスAPIゲートウェイとして機能しています。

同時に、東西サービスのメッシュプロジェクトも南北アクセスゲートウェイとして機能しようとしています。したがって、オープンソースプロジェクトにとって、すべてのトラフィックを処理したいと考えています。

トラフィックを処理するオープンソースプロジェクトが花開いています。BaiduのbfeやAlibabaのMOSNを見ることができます。彼らはすべてトラフィックに焦点を当てています。

2つ目はローコードです。最良のソリューションは、PMがプラグインオーケストレーションを通じて直接機能を実装できるようにすることです。これにより、開発者はゲートウェイ自体により集中できます。

このようにして、ビジネスとAPIゲートウェイのコアが分離されます。技術やプラグイン開発を理解していない人々がオープンソースプロジェクトにプラグインを貢献できるようになります。これは非常に重要です。

3つ目はリアルタイムです。5GとIoTの普及、およびKubernetesの企業での展開により、設定のリアルタイム効果、リクエストの処理、リアルタイムデータ分析に対して非常に高い要求が提起されています。ゲートウェイにとって、リアルタイムで非常に高いパフォーマンスと非常に低いレイテンシを提供できない場合、次の3〜5年間で生き残ることはできません。

最後に、オープンソースです。ソフトウェアがハードウェアを食べ、オープンソースソフトウェアがソフトウェアを食べていることがわかります。最終的には、すべてのインフラソフトウェアがオープンソースになります。

APIゲートウェイも同じです。オープンソースにより、企業はベンダーロックインを心配することなく、より低いコストで使用できます。さらに、オープンソースの商業機会は、オープンソース開発者にもっと多くの利益をもたらします。これはウィンウィンの状況の良いモデルです。