xRPCがリリースされます、APISIXエコシステムの詳細を確認しましょう

API7.ai

January 21, 2021

Ecosystem

ビジネスシナリオや要件がますます複雑化・多様化する中、多くの標準やプロトコルが登場しています。Apache APISIXは、Apache Foundationのトップオープンソースプロジェクトとして、関連するエコシステムの拡大に積極的に参加し、推進してきました。

この記事では、Apache APISIXの今後のxRPCフレームワークと多言語プラグインの例を、マルチプロトコルプロキシと多言語サポートの2つの観点から紹介します。

マルチプロトコルプロキシ

Apache APISIXでは、各リクエストはRouteオブジェクトに対応します。現在、Apache APISIXには主に2つのプロキシシナリオがあります。

2つのプロキシシナリオ

1つ目はHTTPプロトコルプロキシで、現在APISIXで最も一般的に使用されているリクエストプロキシです。HTTPプロトコルプロキシを基盤として、Apache APISIXは現在、細かい粒度のフロー制御、セキュリティ、可観測性など、数十のトラフィック管理機能を実装しています。

2つ目はTCPおよびUDPベースの動的プロトコルプロキシとロードバランシングで、最も基本的なトラフィック許可機能とリンクレベルのロギング機能を提供します。このプロキシモデルは、MySQL、Redis、Mongo、DNSなど、TCP/UDPプロトコルベースのリクエストをプロキシできます。ただし、上位のアプリケーションレイヤープロトコルを持たないTCP/UDPベースのプロキシであるため、四元組に関する基本的な情報しか取得できず、拡張性の面でやや弱いです。

xRPCの必要性

Stream Routeのプロトコルプロキシにおける制限と、APISIXでより多くのアプリケーションレイヤープロトコルをサポートして、より多くのユーザーやアプリケーションシナリオに対応したいという要望から、xRPCフレームワークが誕生しました。

xRPCフレームワークは、特定のプライベートデータプロトコルを含むプロトコル機能の拡張を非常に簡単にし、HTTPプロトコルプロキシと同様の正確な粒度と高レベルの7層制御を提供します。例えば、リクエストレベルの可観測性、高度なアクセス制御、プロキシポリシーなどです。

xRPCとは

xRPCは文字通り、Xがプロトコルリソースの抽象的な表現であり、RPCはゲートウェイを通過するすべてのリソースをプロセスディスパッチとして扱うことを意味します。つまり、プロトコル拡張フレームワークです。したがって、xRPCは特定のプロトコルの実装ではなく、ベースフレームワークとして位置づけられます。

xRPCアーキテクチャ

上記のアーキテクチャからわかるように、xRPCはAPISIX Coreの拡張に基づくフレームワークです。このフレームワーク上で、ユーザーはRedis、MySQL、Mongo、Postgresなどの異なるアプリケーションレイヤープロトコルを実装できます。異なるプロトコルの上で、共通の要素を抽象化し、関連するプラグイン機能を実装することで、異なるプロトコルがこれらの機能を共有できるようになります。

したがって、xRPCの主な役割は、標準化されたアプリケーションレイヤープロトコルへのアクセスを提供し、クロスプロトコル機能の共有をサポートし、ユーザーがカスタムプロトコルを拡張する能力を獲得できるようにすることです。

サンプルアプリケーションシナリオ

xRPCプロトコルフレームワークを利用することで、どのようなシナリオに対応できるでしょうか?以下にいくつかの例を示します。

  • 例1: Redisの初期バージョンではTLSをサポートしていません。システム内に複数のバージョンのRedisがあり、何らかの理由で本番環境でRedisをアップグレードできないが、TLS機能を追加する必要がある場合。この場合、xPRCベースのRedisプロトコルを使用して上記の状況を解決できます。
  • 例2: 特定のIPや呼び出し元の頻度を制限し、各呼び出し元の頻度を可視化したい場合。Redisはこれをサポートしていませんが、xRPCによって拡張されたRedisプロトコルを使用することで、この問題を完全に解決できます。
  • 例3: MySQLで一時的にスロークエリ機能を有効にしたい場合、MySQLプロトコルにアクセスし、APISIXで関連するポリシーを設定するだけで、インスタンスマシンにログインする手間を省けます。

もちろん、これ以外にも多くの類似したアプリケーションシナリオがあります。この機能がリリースされた後、実際のアプリケーションでさらに体験し、実践することを期待しています。xPRCの呼び出しプロセスは以下の図のようになります。

呼び出しプロセス

上流サービスがApache APISIXに引き継がれると、異なる上流アプリケーションサービスを一元管理できます。ロギング、モニタリング、セキュリティ、トラブルシューティングなどの機能は、すべて標準化されたポリシーセットを通じて実現できます。

計画された実装フェーズ

現在、Apache APISIX xRPCフレームワークの設計は、初期段階で5つのフェーズに分かれています。

xRPCの5つのフェーズ

  • フェーズ1: データの読み取りとプロトコルデコード。
  • フェーズ2: アクセスフェーズ。プラグインアクセス機能を提供し、セキュリティ、フロー制御、アクセスの需要シナリオを実現できます。
  • フェーズ3: データ転送とロードバランシング。カスタムロードバランシングポリシーとアルゴリズムのサポートを提供します。
  • フェーズ4: データの送信とプロトコルエンコード。
  • フェーズ5: ロギングフェーズ。ロギングとログ記録の需要シナリオを実現するためのプラグインアクセスを提供します。

多言語エコシステム

ますます豊富で大規模なコンピューティング言語ベースに対応するため、多言語環境でのコードサポートを作成することが、将来の技術開発に対応するための最初のハードルとなっています。Apache APISIXも、多言語開発の道で多くの探求と実践を行ってきました。

例えば、最近ではWebAssemblyのサポートを実装しました。詳細と機能については、記事「Apache APISIX Embraces WASM Ecology」を参照してください。もちろん、Apache APISIXでのWASMサポートはまだ実験段階であり、今後もWASMサポートを改善していきます。このプロジェクトに興味がある方は、wasm-nginx-moduleプロジェクトに貢献してください。

一方、WASMサポートが実装される前に、Apache APISIXは「xPluginRunner多言語プラグインランタイム」を通じて複数の開発言語をサポートしています。つまり、APISIXプラグインを開発する際、ユーザーはAPISIXがネイティブでサポートするLuaコードだけでなく、Go、Java、Pythonなど、自分が慣れ親しんだ言語でAPISIXプラグインを記述・拡張できます。

xPluginRunner

xPluginRunnerの実装

xPluginRunnerの実装は上記の図のようになります。通信プロセス全体は、組み込みプラグインの実行「前」と「後」に、APISIXが各言語のプラグインランタイムに対してローカルRPCリクエストを開始します。プラグインランナー内で、各プラグイン内の計算とポリシー処理が実装され、最終的にAPISIXに応答が返され、応答結果に基づいて後続の意思決定が行われます。

xPluginRunnerは、Apache APISIXとの通信の橋渡し役として、プライベートデータプロトコルの解析とRPCメッセージのカプセル化・非カプセル化を主に実装します。

現在、Apache APISIX xPluginRunnerソリューションは比較的安定した段階にあり、コミュニティからのフィードバックによると、一部の企業が本番環境での試用を開始しています。このプロジェクトに興味がある方は、さまざまな開発言語のプラグインプロジェクトに参加してください。

最後に、簡単なJavaの例を使って、Java Plugin Runnerに基づいてAPISIXプラグインを開発する方法を紹介します。

Java Plugin Runnerの例

まず、プラグインを開発する際に、PluginFilterのインターフェースを実装する必要があります。インターフェース内のnameメソッドは主にプラグイン名を識別・抽出するために使用され、filterメソッドはリクエストをフィルタリングするために使用されます(つまり、プラグイン本体のロジックを実行します)。

プラグイン

上記のコードに現れるrequestresponseパラメータには、Runner内で固定のロジックがあります(すべてのRunnerに適用されます):

  1. リクエストを継続して転送し、いくつかのポリシー設定(リクエストパラメータやヘッダーの書き換えなど)のみを行いたい場合、requestオブジェクトを操作するだけで済みます。
  2. リクエストを終了させたい場合、responseオブジェクトで行えます(レスポンスボディ、レスポンスヘッダー、ステータスコードなどを設定)。

APISIXは、Runner内のresponseオブジェクトが操作されたことを感知すると、現在のリクエストを終了します。

プラグインの開発が完了したら、APISIXでの実践を開始します。

まず、Runnerとプラグインをプロジェクト内でjarパッケージにコンパイルし、jarパッケージの絶対パスを以下の方法でメインのAPISIX設定ファイルに設定します。

jarパッケージをメインのAPISIX設定に配置

最後に、Apache APISIXを再起動し、ルーティングとプラグイン設定、リクエスト検証セッションの準備が整います。

ルート設定

まとめ

この記事では、Apache APISIXの今後のxRPCフレームワークのリリースと関連する詳細、および多言語開発サポートにおけるApache APISIXの詳細なデモンストレーションを紹介しました。

また、Apache APISIXの多言語開発サポートの詳細を示しました。マルチプロトコルプロキシと多言語サポートの両方の観点から、Apache APISIXのエコシステム指向の取り組みを示しています。

GitHub Discussionsでディスカッションを開始したり、メーリングリストを通じてコミュニケーションを取ることもできます。

Tags: