APISIX 推动腾讯蓝鲸API网关升级

このケーススタディは、Tencent IEG（Interactive Entertainment Group）のBlueKing PaaSプラットフォームの技術ディレクターであるLei Zhu氏によって共有されました。

BlueKingについて

BlueKingは、Tencent IEG（Interactive Entertainment Group）内で孵化された内部統合研究および運用PaaSのセットであり、複数のビジネスユニットと内部プラットフォームにサービスを提供しています。その役割は、CI（継続的インテグレーション）、CD（継続的デリバリー）、およびCO（継続的運用）の段階で会社のプロジェクトにフルライフサイクルサービスを提供することです。

概要

課題

• 低パフォーマンス: 高並列条件下でのルーティングのアルゴリズムとパフォーマンスが低く、ルーティングのマッチングと転送が遅い
• 巨大なDB負荷: ルーティングポリシーはMySQLに保存されているため、データベースが多くの検索リクエストにさらされる
• 高コスト: Redisが多くのシナリオで広く使用されており、高いオーバーヘッドコストが発生している
• 分離不足: 物理的な分離を実現できず、長期的な接続が不安定
• 単一プロトコルのサポート: HTTPプロトコルのみをサポート
• 動的ルーティングのサポートなし: カナリアリリースに不親切で、シナリオベースの組み合わせとカプセル化ができない
• サービスディスカバリの欠如: マイクロサービスアーキテクチャに不親切

目標

• プラットフォームの機能を独立したマイクロサービスに変換し、マイクロサービス化を進めてPaaSアーキテクチャを形成する
• 低コード技術を使用してSaaSを効率的に開発し、PaaSプラットフォームのマイクロサービス機能を活用する
• さまざまなSaaSを通じて異なるサービスシナリオに柔軟に対応する

結果

• K8sが提供するCRDカスタムリソースを使用して、ゲートウェイの統一的な操作と拡張を実現
• APISIXを統合したより豊富な機能を提供：リソース管理、バージョンリリース、自動ドキュメント、権限管理、可観測性、監視、セキュリティ保護
• サービスディスカバリシナリオのサポートコストを削減し、統一された開発者インターフェースと規約を提供

ゲームの多様性と複雑性がBlueKing APIゲートウェイを必要とする

Tencent内には数千のゲームが存在する可能性があります。自社開発のゲームを除いて、他のゲームは代理店に属しています。ゲームは言語、依存するストレージ、アーキテクチャスタイルが異なるため、BlueKingは独自のAPIゲートウェイを開発しました。

このような複雑なビジネスシナリオに直面し、多数の異種アーキテクチャが関与する中で、BlueKingは内部プラットフォームとして、APIゲートウェイを変換してPaaSアーキテクチャを開発し、低コード技術を使用してSaaSを効率的に開発し、PaaSのマイクロサービス機能を活用し、さまざまなSaaSを使用してサービスシナリオを処理する必要があります。

BlueKingのアーキテクチャを抽象化すると、以下のようなAPI図が得られます。

• 一方で、BlueKingは複雑なプラットフォームであり、統一ゲートウェイに対する複雑な要件があります。プラットフォームのAPIを呼び出すプロキシとして機能するだけでなく、BlueKingはサービスディスカバリ、認証と認可、動的ルーティング、カナリアリリース、レートリミットなどのゲートウェイ機能を必要としています。

• 他方、クラウドネイティブ技術の発展に伴い、多くの内部SaaSとプラットフォームがK8sクラスターにデプロイされるようになりました。このシナリオでは、統一されたトラフィックゲートウェイまたはAPIゲートウェイを通じて外部呼び出しリクエストの統一的なトラフィック制御を行うなど、新しい要件が提起されています。

同時に、一部の内部ビジネスシステムは、BlueKingプラットフォームのインフラストラクチャ機能（コンテナ管理や監視など）を使用しています。これらも、すべての呼び出しトラフィックを管理するための統一されたサービスゲートウェイを必要としています。

内部ビジネス要件の発展に伴い、BlueKingのAPIゲートウェイはますます多様なシナリオをサポートする必要があります。

BlueKing APIゲートウェイ 1.0

BlueKing APIゲートウェイ 1.0は、プラットフォームの呼び出し元（さまざまなSaaSやプロセスエンジンを含む）がAPIゲートウェイを直接呼び出し、ゲートウェイを通じてプロトコル変換と権限検証を完了できるようにすることを目的としていました。

アーキテクチャも比較的シンプルで、サーバーサイドと管理サイドの2つの部分に分かれていました。プラットフォームは管理サイドにアクセスし、プラットフォームのAPIリソースアドレスとそれに対応する権限を設定し、最終的にAPIゲートウェイにサービスを登録する必要がありました。

数年後、リクエストの増加と複雑なシナリオに伴い、BlueKing APIゲートウェイ 1.0の欠点が徐々に明らかになりました。例えば：

• フレームワークのパフォーマンスが低い: Djangoフレームワークが実装に選択されましたが、高並列シナリオでのパフォーマンスは平均的で、大量のリクエストを処理する際に限界が見られました。

• ルーティング実装のパフォーマンスが平均的: APIルーティングで使用されるアルゴリズムのパフォーマンスが低く、ルートのマッチングと転送速度に影響を与えました。

• データベースの負荷が大きい: すべてのルーティングポリシーがMySQLに保存されているため、ルールが多い場合、多くの検索リクエストが発生し、クエリの負荷が大きくなります。

• ネットワークコストが高い: Redisがさまざまなシナリオで広く使用されており、ネットワークオーバーヘッドコストが高くなります。

BlueKing APIゲートウェイ 2.0

上記の問題を解決するために、BlueKingはバージョン1.0を基にイテレーションを行い、バージョン2.0を設計および実装しました。前世代と比較して、バージョン2.0の最も大きな変更点は、ゲートウェイフレームワークと転送層をGolangで再実装したことです。GolangはPythonよりも大規模な並列リクエストを処理するのに優れているためです。

その他の最適化変更も行われました。例えば、より効率的なルーティング実装がメモリ内で維持され、中間層にメモリベースのキャッシュが導入され、Redisへの依存が減少しました。新しいアーキテクチャでは、複数のバージョンと環境でのゲートウェイのライフサイクル管理が追加され、拡張プラグインメカニズムが導入され、開発者がプラグインを通じてゲートウェイ機能を拡張できるようになりました。

全体的に見て、BlueKing APIゲートウェイ 2.0はパフォーマンスの問題とバージョン1.0で遭遇したほとんどの課題を解決しました。しかし、時間が経つにつれて、新しい問題が徐々に表面化し始めました。

• 分離不足: 真の物理的な分離を実現できず、リリースプロセスにより長期的な接続が切断される

• 単一プロトコルのサポート: HTTPのみをサポートし、実際のシナリオでは非HTTPプロトコルの需要が増加している

• 動的ルーティングルールのサポートなし: 条件に基づいて動的ルーティングルールをサポートせず、カナリアリリースシナリオに不親切で、シナリオベースの組み合わせとカプセル化ができない

• サービスディスカバリ機能の欠如: 自動サービスディスカバリ機能がなく、マイクロサービスアーキテクチャに不親切

BlueKing APIゲートウェイの技術選定でAPISIXが優位

会社内にはAPIゲートウェイを使用する必要がある多くの製品システムがあります。ゲートウェイに対する多様な要件をすべて同じゲートウェイに統合することは非常に困難です。

そのため、分散ゲートウェイを設計するアイデアが生まれました。つまり、大きなゲートウェイを多くのマイクロゲートウェイに分割し、異なるシステムのゲートウェイ要件の違いをバランスさせることです。」とZhu氏は述べました。

分散ゲートウェイアーキテクチャのコンポーネントは、主に管理サイドとマイクロゲートウェイインスタンスの2つのカテゴリに分かれます。

管理サイドは各マイクロゲートウェイを統一して管理および制御し、各ゲートウェイの管理者がゲートウェイを設定および管理します。マイクロゲートウェイインスタンスは独立してデプロイされた個別のゲートウェイサービスであり、各特定のサービスグループのアクセストラフィックを引き受け、管理サイドの設定に従って関連するアクセス制御を実行します。すべてのマイクロゲートウェイインスタンスは同じ管理サイドによって制御されます。

「マイクロゲートウェイの技術選定において、市場で人気のあるいくつかのオープンソースゲートウェイを参照しました。例えば、KongやTykなどです。人気、技術スタック、プロトコルサポートなどのレベルを比較した後、最終的にAPISIXをマイクロゲートウェイの最も重要なバックエンド技術として選択しました。」とZhu氏は述べました。

Zhu氏は、BlueKingがAPISIXを選択した理由として、NGINX + Luaに基づいて実装されているため、Golangベースのゲートウェイと比較して全体的なパフォーマンスに優れている点を挙げました。さらに、APISIXは拡張性が非常に優れており、複数のプログラミング言語プラグインを通じて機能を拡張することもサポートしています。多くの典型的なユースケースが確認されています。

また、優れた互換性のおかげで、APISIXはBlueKingのニーズに応じてカスタマイズできます。例えば、APISIXを基に、BlueKingは内部要件に応じてAPISIXのコントロールプレーンをカスタマイズしました。

APISIXに基づくBlueKing APIゲートウェイ 3.0

クラウドネイティブ環境では、K8sが最も重要な基本コンポーネントであり、注目すべきです。マイクロゲートウェイ全体がクラウドネイティブ環境向けに設計されているため、バージョン3.0ではK8sに基づいた新しいアーキテクチャ設計が行われました。

コア部分は、K8sが提供するCRDカスタムリソースを使用して、APIゲートウェイの一連の操作と拡張を実現することです。

上図に示すように、ゲートウェイにはBkGatewayStage（ゲートウェイ環境）、BkGatewayService（バックエンドサービス）などのK8s CRDリソースが導入されています。これらのCRDを通じて、BlueKingは各マイクロゲートウェイインスタンスの具体的な動作を制御できます。

図中のいくつかの「Operators」は、このアーキテクチャのコア部分です。上部にはPlugin Operatorsサービスがあり、一連のプラグインオペレーターが含まれています。例えば、サービスディスカバリを担当するオペレーターは、サービスディスカバリセンターに登録されたバックエンドサービスのアドレスをK8sクラスターに書き込みます。

中央のコアオペレーターは、すべてのゲートウェイ関連のCRDリソースを監視します。リソースリコンシラーは、ゲートウェイ設定をAPISIXマイクロゲートウェイインスタンスが理解できる形式に変換し、マイクロゲートウェイのフルライフサイクル管理を実現します。

このマイクロゲートウェイは、2つのデプロイメントタイプに分かれています：

• 共有ゲートウェイ: デフォルトのタイプで、プラットフォーム上にデプロイされ、APIアクセスアドレスはプラットフォームによって統一生成および管理されます。

• 専用ゲートウェイ: ユーザーが「マイクロゲートウェイ」インスタンスをデプロイし、プラットフォームにアクセスすると「専用ゲートウェイ」になります。APIアクセスアドレスは手動で管理され、トラフィックは「専用ゲートウェイ」から直接バックエンドサービスに流れます。

統一された管理サイドは1つだけであり、複数環境管理やアクセス制御などの機能はすべてのゲートウェイで共有されます。ただし、管理する異なるタイプのマイクロゲートウェイインスタンス間で、サポートされる機能セットは異なります。

共有ゲートウェイインスタンスを例にとると、サポートされる機能セットは比較的基本的で、主に統一ログイン認証、レートリミット、およびマルチプロトコルサポートが含まれます。しかし、独立した専用ゲートウェイインスタンスは独自の個別化された機能を持っています。専用ゲートウェイとビジネスが同じクラスターに属しているため、動的ルーティング、カスタムサービスディスカバリなどを迅速に実現し、APISIXの強力な拡張性を活用してさらに多くの機能をカスタマイズできます。

上記のアーキテクチャとモードに基づいて、BlueKing APIゲートウェイ 3.0はAPISIXのサポートにより、より豊富な機能を提供します。例えば、リソース管理、バージョンリリース、自動ドキュメント、SDK、権限管理、可観測性、監視とアラート、セキュリティ保護などです。

APISIXを使用したBlueKingゲートウェイ 3.0の実践シナリオ

Tencent内には、サービスディスカバリ、統一認証、動的ルーティング、クライアントのライセンス管理という4つの典型的な実践シナリオがあります。

サービスディスカバリ

サービスディスカバリは、マイクロサービスアーキテクチャに必要な基本的な機能です。内部では、カスタムリソースCRDを通じて実装できます。有効なサービスディスカバリYAML定義は、下図の右側のコードに示されています。

上記のCRDリソースがK8sクラスターに書き込まれると、サービスディスカバリ関連のコントローラーの関連アクションがトリガーされます。その後、リコンシラーは対応するサービスディスカバリ設定をキャプチャし、サービスディスカバリ関連のプログラムオブジェクトを作成します。

次に、リコンシラーはWatcherやListerなどの組み込みサービスディスカバリインターフェースを通じてサービスディスカバリセンターの関連アドレス情報を読み取り、取得したアドレスをCRDリソースBkGatewayEndpointsを通じてK8sクラスターに書き戻します。

右側のコアオペレーターによる複雑な処理の後、これらのエンドポイントは最終的にAPISIXの対応するアップストリームに同期されます。これにより、完全なサービスディスカバリプロセスが完了します。

開発を容易にするため、BlueKingは一般的なサービスディスカバリフレームワークを実装し、統一された開発インターフェースと規約を提供し、他のタイプのサービスディスカバリシナリオを低コストでサポートできるようにしました。

統一認証

統一認証の部分は比較的シンプルです。日常の実践では、ブラウザ、プラットフォーム、および個々のユーザーからのリクエストがあります。APISIXを基に、BlueKingは認証プラグインBK-Authをカスタマイズし、統一認証を実現しました。

具体的な実装プロセスは上図に示されています。リクエスト後、プラグインはヘッダーから関連する認証情報を読み取り、統一してBK-Auth認証サービスを呼び出して認証情報を検証し、対応するSaaS情報を読み取ります。その後、プラグインはバックエンドと合意した秘密鍵を使用してJWTトークンを発行し、リクエストヘッダーに書き込み、最終的にAPISIX変数に書き込みます。

統一認証に加えて、内部プロジェクトにはいくつかの複雑な認証シナリオもあります。その主な機能は、SaaSがプラットフォームの特定のリソースを呼び出す際に、SaaSがそのリソースに対する権限を持っているかどうかを判断することです。統一リソース認証も、APISIXプラグインを通じてGolangで実装されています。下図に示すように。

クライアントリクエストは、まず認証リンクを通じてSaaSアプリケーション情報を取得し、ext-pluginを通過する際にRPCベースの認証プラグインと対話します。この時、認証プラグインは、管理サイドがフルおよび増分メカニズムを通じて同期したキャッシュ内の認証関連データを直接クエリし、認証を完了します。

動的ルーティング

典型的な動的ルーティングのアプリケーションシナリオは、BlueKingのコンテナ管理プラットフォームから来ています。BlueKingコンテナプラットフォームは多くのK8sクラスターを管理しており、その中にはサービスクラスターとデータクラスターがあります。

ユーザーとして、これらのクラスターのAPIServerにリクエストを送信する必要があることがよくあります。ユーザーリクエストがマイクロゲートウェイに入ると、ゲートウェイはリクエストパスに基づいてどのクラスターのAPIServerに転送するかを決定します。

リクエストが入ると、動的ルーティングプラグインはまずクラスターのID情報を抽出し、ルートを書き換え、その後クラスターが直接接続されているかどうかを判断します。

直接接続されていないクラスターの場合、まずBCSクラスターマネージャーのアップストリームを生成し、それを通じてBCSエージェントと対話し、最終的にリクエストをクラスターのAPIServerに渡します。

直接接続されているクラスターの場合、プロセスは上記の統一認証プラグインと似ており、プラグインは定期的にクラスター関連の基本情報を同期します。クラスター情報を見つけた後、関連するアップストリームを生成し、APISIXプラグインを通じて接続ロジックを再定義し、最終的にリクエストをクラスターAPIServerに送信します。

クライアント証明書管理

BlueKingの実践シナリオでは、ゲートウェイにリソースを登録する際に、より複雑なクライアント証明書検証モードを使用するクラスのシステムがあります。そのため、ユーザーがそのリソースをリクエストするには、有効なクライアント証明書を提供する必要があります。

具体的な実装は上図に示されています。ゲートウェイマネージャーは、管理サイドで異なる環境で使用されるクライアント証明書を設定する必要があります。設定後、証明書はK8sクラスターに公開され、対応するマイクロゲートウェイが配置されています。

このプロセスでは、K8sの公式Secretリソースと一部のCRDリソースを使用し、コアオペレーターサービスによって継続的に調整されます。例えば、ドメイン名に基づいて対応する証明書を見つけるなどです。有効なクライアント証明書設定は、最終的にAPISIX Serviceの関連設定に反映されます。（上図の右上の赤いボックスに示されています）

まとめ

Apache APISIXは、すべてのAPIとマイクロサービスのためのオープンソースで動的、拡張可能、高性能なクラウドネイティブAPIゲートウェイです。API7.aiによってApache Software Foundationに寄贈され、APISIXはトップレベルのオープンソースApacheプロジェクトに成長しました。

マイクロサービスアーキテクチャと内部ビジネスプロジェクトの発展に伴い、以前のAPIゲートウェイはもはやニーズを満たせなくなりました。Tencent BlueKingはこの問題を解決しただけでなく、APISIXを活用してより豊富な機能を提供しました。