腾讯基于Apache APISIX的API网关实践

APIゲートウェイとは何か？

従来のアーキテクチャ

APIゲートウェイを統合する前に、いくつかの一般的な機能を再利用する方法がありました。例えば：

セキュリティ：認証、認可、リプレイ防止、改ざん防止、DDoS対策など。
信頼性：サービス低下、フェイルセーフ、トラフィック制限など。

従来のアーキテクチャでは、これらの機能をサービスフレームワークに組み込み、AOP（Aspect-Oriented Programming）を通じて実装するのが一般的でした。以下のようなアーキテクチャ図がその例です：

従来のアーキテクチャ

従来のアーキテクチャ図には以下のモジュールが含まれています。

バックエンド：バックエンドサービス
AOP：フレームワークによって提供されるAOP層
SD：サービスセンター、内部サービスのディスカバリーに使用。クラウドネイティブ技術では、Serviceがこのコンポーネントを置き換えることが多い。
LB：ロードバランサー、外部トラフィックのエントリーポイントとしてネットワーク境界で使用。

このようなアーキテクチャは初期の設計で広く採用され、DubboやSpringCloudなどの包括的なサービスフレームワークが生まれました。これらのフレームワークには多くの類似した機能があります。

このアーキテクチャの利点は、上流と下流の関係が明確で、ネットワーク伝送における転送回数が少ないことです。しかし、以下のような欠点もあります：

標準機能がビジネスサービスの更新を強制する：コード参照を使用しているため、機能を有効にするにはビジネスサービスを再コンパイルする必要があります。ローリングリリースを実現していないチームでは、ビジネスの閑散期にリリースする必要があります。
バージョン管理が難しい：すべてのサービスを最新バージョンにアップグレードできないため、時間が経つと各サービスのパフォーマンスが一貫しなくなります。

これらの共通機能を独立したサービスに分離し、個別にアップグレードやメンテナンスを行うことはできないでしょうか？

ゲートウェイモード

従来のアーキテクチャと比較して、バックエンドサービスとLBの間に追加されたコンポーネントがあります：ゲートウェイ。

ゲートウェイには通常、認証、トラフィック管理などの標準的で再利用可能な機能が含まれています。以下にその利点を示します：

ゲートウェイはシステムの依存コンポーネントであり、より良いメンテナンス体験を提供できます。
ゲートウェイは言語に依存しません。

しかし、ゲートウェイモードにも欠点があります：

トラフィックをゲートウェイにプロキシするため、転送回数が増え、レイテンシが高くなります。これにより、問題のトラブルシューティングが複雑になります。
ゲートウェイが正常に動作しない場合、システム全体のボトルネックになる可能性があります。

ゲートウェイモデルの利点と欠点をどのようにバランスさせるかは、技術チームにとっての課題です。TencentのOTeamがApache APISIXとどのように連携しているかを見てみましょう。

イントロダクション

OTeam

TencentのOTeamは、複数のチームからなるグループで、各チームが1つまたは複数の技術製品を維持しています。彼らの目的は、内部システム向けに安定したが強力なミドルプラットフォームを構築することです。そのうちの1つのOTeamが、Tencent内部のApache APISIXカスタマイズディストリビューションをサポートしています。

社内の重複した技術を統合し、技術的な基盤を強化するために、Tencentは同じ性質の技術製品を同じOTeamにまとめ、メンテナンススタッフを統合し、徐々に1つの包括的な製品に統合していきます。これがOTeamです。

一部のOTeamには10以上の製品が含まれている場合もありますが、Apache APISIXが属するOTeamは1つの製品のみを管理しています。このOTeamの当初の目的は、Tencent内部でのApache APISIXのカスタマイズ機能を維持することでした。

Apache APISIX

Apache APISIXはApache Software Foundationのトップレベルプロジェクトで、以下にいくつかの重要なポイントを示します：

Apache APISIXは、OpenRestyに基づくクラウドネイティブの動的APIゲートウェイで、Kongよりも高いルーティング性能を提供します。
Apache APISIXは、ロードバランシング、動的アップストリーム、カナリアリリース、サーキットブレーカー、認証、可観測性などの豊富なトラフィック管理機能を提供します。
Apache APISIXは、従来の南北トラフィックだけでなく、サービス間の東西トラフィックも扱うことができます。また、k8s ingressコントローラーとしても使用できます。
Apache APISIXはデフォルトでETCDを設定センターとして使用し、設定を数秒で更新できます。
Apache APISIXはApache Software Foundationを卒業し、わずか数ヶ月でトップレベルプロジェクトになりました。

Tencent OTeamの運用戦略

OTeam運用戦略

上記の図は、OTeamがApache APISIXのコミュニティとどのように連携しているかを示しています：

ユーザーはGitHub Issueを通じてフィードバックや要件を提供します。
OTeamメンバーは週次ミーティングで解決策を議論するか、Issueに直接返信します。
議論に基づいて機能を実装したり、バグを修正します。
コードレビューとCIチェックを行い、必要に応じてリリースします。

このプロセスは他のオープンソースプロジェクトと同様です。以下にいくつかの重要なポイントを示します：

Issueを解決した後、Tencentのエンジニアはその問題がコミュニティにとっても共通の問題かどうかを判断します。もしそうであれば、コミュニティにPRを提出します。
Tencent OTeamは定期的にApache APISIXの新機能をレビューし、それが安定しているか、Tencentにとっても痛みのポイントかどうかを判断します。もしそうであれば、関連するコードを取り込みます。

当初、OTeamはApache APISIXのコードを12時間ごとに同期し、迅速に追従できるようにしていましたが、このアプローチにはいくつかの問題がありました：

Apache APISIXのコードを同期した後、規制が正しいことを確認できますが、コードが安定しているかは保証できません。並行処理の場合に偶発的なエラーが発生することがありました。
マージされたコードが論理的に複数のPRの競合を引き起こすことがありますが、Apache APISIXとOTeamのCIはこのケースを検出できません。PRをマスターブランチにマージした後に問題が発覚することがあります。

これらの理由から、OTeamは現在、内部レビューの後に必要な機能のコードを取り込む方式に移行しています。

OTeamのトレンド

2021年5月現在、OTeamはTencent内の10以上のチームにApache APISIXを導入し、1日あたりのビジネスリクエストトラフィックは10億を超えています。同時に、OTeamはApache APISIXに対して10以上の機能を開発し、Service Discovery、RPCプロトコル変換、監視プラットフォームとの連携などを実現しています。

また、OTeamはApache APISIXのコミュニティにいくつかの標準機能を貢献しています。現在、OTeamの2人のメンバーがApache APISIXのPMC（Project Management Committee）であり、OTeamはコミュニティに50以上のPRを提供しています。今後もOTeamはApache APISIXコミュニティと協力し続けることを信じています。

OTeamの内部機能

内部の課題

OTeamの主な責任は、Tencent向けのApache APISIXの機能を維持することです。OTeamが直面した課題を見てみましょう。

RPCフレームワークがフロントエンドに非友好的：Tencent内にはTARSフレームワークを使用する多くのレガシープロジェクトがあります。TRPCのようにHTTPプロトコルを直接サポートせず、RPCフレームワークの最も伝統的なTCPプロトコルのみをサポートし、転送内容は特定のバイナリプロトコルを使用します。これらのインターフェースをフロントエンドに友好的なHTTP + JSON形式に変換するために、中間サービスを維持する必要があります。
サービスセンターの多様化：Tencentの内部サービスにはCL5、L5、Polarisなど多くのサービスセンターがあります。同じサービスセンターを使用するようになるまで、複数のサービスセンターを同時に使用する必要があります。初期のApache APISIXはこれをサポートしていませんでした。
アラーム：ゲートウェイとして、アラームは本来注目すべき方向ではありませんが、基本的なコンポーネントとして、アラームはチームにとって必須のコンポーネントです。アラームの問題をどのように解決するかも課題です。
セキュリティ：Tencentは大量のトラフィックとセキュリティ要件を抱えています。多くのtoC製品がOTeamを使用しており、ネットワークからのユーザーの誤用や攻撃に直面しています。最も典型的なケースはDDoS、リプレイ、リクエストの改ざんなどです。これらの問題をゲートウェイ層で解決できるでしょうか？

問題解決

OTeamアーキテクチャ

上記の図は、Tencent内の導入ケースを簡略化したものです。先に挙げたいくつかの問題がOTeamで解決されていることがわかります：

プロトコル変換：Apache APISIXを基に、OTeamはTRPCとTARSのプロトコル変換を実現しました。HTTPをサポートしないレガシーサービスは、中間サービスを書くことなく、ゲートウェイの変換プラグインを使用してHTTPとRPCの転送要件を満たすことができます。
複数のサービスセンター：この機能をコミュニティに貢献しました。監視プラットフォームへのレポート：Tencent OTeamはプラグインを使用して監視プラットフォームと連携します。ユーザーはいくつかの設定を行うだけで、システムが自動的にメトリクスやログを報告します。また、ユーザーは監視プラットフォーム上でアラームポリシーを設定できます。
リプレイ防止と改ざん防止：OTeamはリプレイ防止と改ざん防止のプラグインを実装し、これらの機能を必要とする外部ビジネスがすぐに使用できるようにしました。

これらの例が、Apache APISIXの使用シナリオをさらに探求し、便利なプラットフォームとして活用するのに役立つことを願っています。例えば、Tencent Cloudのポリシーに従ってAPI仕様を強制するためにゲートウェイを使用するケースもあります。

まとめ

OTeamはビジネスチームの課題を解決し、Tencent内のApache APISIXの機能を継続的に改善し、コミュニティの発展と共に前進しています。

もしあなたのチームにゲートウェイがない場合、Apache APISIXについてさらに学び、Apache APISIXコミュニティに参加することをお勧めします。