Apache APISIX 通过 Service Mesh 实现全流量管理的统一

クラウドネイティブの急速な成長に伴い、Service Meshも注目を集め始めています。現在、多くの有名なService Meshソリューションが存在し、それぞれの製品には独自の利点があります。そのため、異なる業界やビジネス背景に直面した際のService Meshソリューションの選択は、人によって異なります。

Service Meshの現状と課題

Service Meshの出現は、現在のビジネスアーキテクチャの進化と強く関連しています。クラウドネイティブの隆盛に伴い、多くの企業がマイクロサービスへの移行を開始しました。その中で、アプリケーションがますます小さくなり、各アプリケーションには共通の要素が含まれるようになりました。そこで、「共通のシナリオを解決できる技術はないか？」と考え、Sidecarが登場しました。

Sidecarを使用することで、サービス登録と発見、トラフィック管理、可観測性、セキュリティなどの機能をSidecarに委譲し、ビジネスサービスはビジネスロジックの開発に集中できるようになります。

しかし、Sidecarの登場により、実践の中でいくつかの課題が明らかになりました。例えば：

選択したソリューションが多いため、一度選ぶと移行が難しい。 現在、多くのService Meshソリューションが存在し、それぞれの特性や機能が異なります。一度選択したソリューションは、その後変更することが難しくなります。しかし、ビジネスが拡大するにつれて新しい要件を満たせない場合、移行には大きなコストがかかります。
インフラストラクチャとの統合コストが高い。 実際にService Meshを実装する際には、従来のマイクロサービスアーキテクチャやMQ、データベースなどのインフラストラクチャコンポーネントとの統合が必要です。レガシーな問題や技術的負債も統合プロセスに抵抗を生むことがあります。
パフォーマンスの低下と追加リソースの消費。 現在、どのService Meshソリューションを選んでも、ある程度のパフォーマンス低下が発生します。また、Sidecarの存在により、ビジネスを構成する際に追加のリソースを割り当てる必要があります。
拡張性の難しさ。 一部のService Meshソリューションは、既存の設定方法ではプロトコルや機能の拡張が難しく、プラグイン方式でのカスタマイズも容易ではありません。

したがって、ビジネスの状況と課題を踏まえ、これらの問題を解決できる理想的なService Meshソリューションがあるかどうかを考え始めました。

理想的なService Meshとは？

ビジネスシナリオにおいて、Service Meshに対する要件は上記の通りです。つまり、リソース、パフォーマンス、トラフィック管理、拡張性の方向性で複数の次元の要件があります。もちろん、これら以外にも、他の次元でより詳細な要件があります。例えば：

まず、使用体験のレベルでは、導入コストを低く抑える必要があります。Service Meshを適用する際には、開発者よりも運用保守担当者が多く関わる可能性があるため、導入コストはソリューションを選ぶ際の重要な要素の一つです。
次に、技術的なレベルでは、コントロールプレーンの設定が簡単に始められる必要があります。同時に、関連する権限を厳密かつ安全に制御でき、設定が公的なレベルに近いものであるべきです。
データサイドでは、複数のプロトコルやカスタムプロトコルをネイティブでサポートすることが望ましいです。なぜなら、歴史的なシステム移行に伴う問題を考慮する必要があるからです。Sidecarの存在により、そのリソース消費も管理可能である必要があり、コストを効果的に制御できるようにする必要があります。また、カスタマイズのための拡張性も必要です。
最後に、製品のエコシステム全体において、コミュニティと製品の修正が「迅速な対応」の速度に合致している必要があります。

このように明確な要件と目標があるため、次はそのような理想に近いソリューションを実装し、構築することです。

APISIXベースのService Meshソリューション

Apache APISIXは、動的でリアルタイム、高性能なクラウドネイティブAPIゲートウェイであり、ロードバランシング、動的なアップストリーム、カナリアリリース、サーキットブレーカー、認証、可観測性などの豊富なトラフィック管理機能を提供します。

世界中の数百の企業がApache APISIXをビジネスクリティカルなトラフィックの処理に適用しており、金融、インターネット、製造、小売、通信事業者など、NASA、European Factory Platform、中国航空、中国移動、テンセント、ファーウェイ、微博、網易、贝壳找房、360、泰康、奈雪の茶などが含まれます。したがって、APISIXベースのService Meshソリューションは、使用レベルだけでなく、異なる業界セクターに直面した際にも強い需要があります。

現在のService Meshソリューションのアーキテクチャは、Istioをコントロールプレーンとし、APISIXをデータプレーンとしています。

まず、Istioをコントロールプレーンとして選択した理由は、Istioが現在最も人気のあるService Meshソリューションであり、活発なコミュニティを持っているためです。これにより、ほぼすべての主要なクラウドベンダーがIstioをサポートしており、現在の市場の需要と方向性をある程度反映しています。したがって、コントロールプレーンの選択においては、独自開発のモジュールではなく、Istioを採用する方が適切で、受け入れられやすいと考えました。

データプレーンは、Apache APISIXが力を発揮する場所です。クラウドネイティブAPIゲートウェイとして、APISIXはこのService MeshソリューションにおいてIstioのデータプレーンとしてどのような行動を取っているのでしょうか？

APISIXに詳しい方は、APISIXがetcdをデータストレージとして使用していることをご存知でしょう。しかし、APISIXをSidecarとして使用する場合、その設定はどこから来るのでしょうか？これが考慮すべき問題です。etcdコンポーネントをSidecarに含めると、リソース消費が非常に大きく、柔軟性が低くなります。

したがって、このプロセスでは、まずAPISIXにxDSという設定センターを追加し、etcdを不要にしました。次に、Ameshを導入しました。これは、APISIX起動時にロードされる動的リンクライブラリとしてコンパイルされたGoプログラムです。AmeshはxDSプロトコルを使用してIstioとやり取りし、取得した設定をAPISIXのxDS設定センターに書き込みます。これにより、特定のルーティングルールが生成され、最終的にAPISIXを使用して対応するリクエストをルーティングします。

上記のアーキテクチャを設定することで、以下の結果が得られます：

AmeshとAPISIXは同じライフサイクルを維持し、一緒にオン/オフできます。
APISIXがxDS Discoveryをネイティブでサポートしているため、xDSプロトコルを介してデータが相互変換され、リソース消費レベルが制御されます。
CRDを使用して、特にIstioがまだサポートしていない機能を迅速かつ簡単に拡張できます。例えば、APISIXに最も豊富なプラグイン設定をCRDで設定できます。コントローラーとIstioを一緒に使用することで、IstioとAPISIXのService Meshソリューションの拡張性が最大化されます。

ソリューションの具体的な性能

大幅なパフォーマンス向上

データは技術製品を最も直感的かつ効果的に示す方法です。Service Meshソリューションにおいて、APISIXとEnvoyをデータプレーンとして使用し、最大5,000ルートのボリュームでさまざまなシナリオでストレステストを行い、以下のデータ比較を提示しました。

テストシナリオは「5,000ルートのうち3,000番目のルートをマッチング」です。テストシナリオが多いため、以下では中間部分のルートマッチングについて説明します。また、先頭や末尾のルートマッチングのシナリオもあります。（データが多すぎるため、以下は3,000ルートのテスト結果です）。

上記のデータからわかるように、APISIXは同じ圧力と同じマシン構成で、QPSレベルで5倍のパフォーマンス向上を示しています。また、リクエストレイテンシのレベルでは、APISIXはEnvoyよりも桁違いに低く、APISIXはマイクロ秒単位、Envoyはミリ秒単位です。もちろん、この測定では、APISIXのCPU消費量は50%であり、EnvoyのCPUはすでにフル稼働していることもわかります。

リソース使用量の削減

Service MeshソリューションにSidecarを注入する際、通常は追加のリソースが消費されます。APIベースのソリューションでは、リソース消費を60%削減できます。なぜこれが可能なのでしょうか？

まず、設定はオンデマンドで配布されます。Istioには、Sidecarのリソース管理に関するオンデマンドポリシーがいくつかありますが、このプロセスはユーザーの操作に追加の精神的負担と管理の難しさをもたらします。

次に、設定が理解しやすいかどうかです。Envoyでルートを設定する場合、Dumpで確認すると、Envoyにはすでに数千のルーティング情報が存在しますが、実際にはそれほど多くはありません。これには多くの影響があり、起動速度に影響を与え、一部の設定が肥大化し、リソース使用量が増加します。

APISIXを使用すると、これらの問題をすべて回避できます。APISIXの設定はシンプルで明確であり、メモリに保存されるデータを削減し、その高性能と組み合わせることで、CPUリソースの消費を削減します。ソリューション全体のリソース消費は約60%削減されます。

低い学習コストと高いカスタマイズ能力

まず、Apache Software Foundationの活発なオープンソースプロジェクトとして、APISIXはコミュニティで豊富なドキュメントと学習リソースを提供しており、APISIXを始めたい人にとって学習コストを低く抑えています。

次に、APISIXのソースコードはLuaで実装されており、比較的読みやすく理解しやすいです。Luaは軽量なスクリプト言語であるため、APISIXのソースコードを閲覧する際にも明確です。

最後に、APISIXベースの二次開発は非常に簡単です。ビジネス向けにプラグインをカスタマイズしたい場合、ネイティブのLua言語だけでなく、Python、Java、Go、さらにはWasmなど、より慣れた言語でAPISIXのPlugin Runnerを使用して二次開発を実装できます。

APISIXのエコシステムの力も、製品の強力な拡張性によるものです。

APISIX自体は、セキュリティ、ロギング、可観測性などの豊富なプラグインを提供しています。これらのプラグインは、APISIXが従来のゲートウェイコンポーネントとして使用される場合に最大限に活用できます。しかし、APISIXがIstioと連携してコントロールプレーン上でサービスメッシュを作成する場合、Istioのコントロールプレーン上では多くのリソースが定義されていません。その場合、どうすればよいでしょうか？

そこで、カスタムCRDが役立ちます。例えば、フォールトインジェクションプラグインを作成したい場合、このプラグインはすでにAPISIXに存在するため、ここではいくつかの追加パラメータを設定するだけで済みます。もちろん、ここではフォールトインジェクションプラグインの例を示していますが、APISIXにはセキュアな認証、レートリミットなどの一般的なプラグインもあり、この方法でアクセスして細かい制御を実現できます。

このようにCRDを使用する最も直接的な利点は、拡張がよりネイティブになることです。宣言型の設定を使用することで、ユーザーが受け入れやすくなり、Istioの元の設定に侵入せずに完全な互換性を実現します。もう一つの利点は、すでにIstioソリューションを使用しているユーザーにとって、移行コストが低くなることです。

まとめると、APISIXベースのService Meshソリューションは、開発者やユーザーにとって使いやすく拡張可能であり、優れたパフォーマンスと豊富なエコシステムサポートを備えています。APISIX製品の能力により、プラグインやマルチプロトコルのレベルでも良好なサポートが得られます。年末には、次のバージョンのAPISIXベースのService Meshをお届けする予定です。ぜひご期待ください！

APISIXベースのService Meshソリューションの将来展望

振り返ると、APISIXベースのService Meshソリューションは、前述の課題に向けて既に取り組んでおり、理想的なService Meshソリューションに向かって進んでいます。

APISIXベースのService Meshソリューションでは、外部からのトラフィックがAPISIX Ingressを通過し、中間でAPISIXによって処理されます。このプロセスでは、APISIX Ingressが南北トラフィックを処理し、Amesh + Istioが東西トラフィックを処理します。

このようなデプロイメントアーキテクチャは、コスト削減や統一された技術スタックなど、ビジネスレベルの価値をもたらすことができます。従来のゲートウェイ内で使用されていた共通の機能をService Meshに迅速に複製できるため、ビジネスレベルで統一された管理が可能になり、コストを制御し、ゲートウェイ、Ingress、Service Meshでの経験を高度に再利用できます。

今後のイテレーションでは、APISIXベースのService Meshソリューションはさらに深化し、以下のような計画された方向性を達成する予定です：

APISIXの機能と連携してxRPC機能の実装を構築する。
ネイティブの異種マルチプロトコルサポートを実現する。
Istioを含むあらゆるシナリオと設定をカバーし、ユーザーの移行コストを大幅に削減する。

結論として、現在の技術トレンドの中で、Service Meshは将来の人気トレンドとなることは間違いありません。さまざまなソリューションがまだ完璧ではありませんが、全体的な状況は上向きです。もちろん、APISIXベースのService Meshも、皆が思い描く理想的なService Meshソリューションに向かって進んでいます。