iQIYI、Apache APISIXでAPIゲートウェイの革新を実現

概要

課題

1. 大規模なトラフィックにより、毎日大量のCPU IDLEが低すぎるアラートが発生する。
2. システムアーキテクチャに依存するコンポーネントが多すぎる。
3. 運用保守（O&M）コストが高い。

目標

1. iQIYIの要件に合致する高性能なAPIゲートウェイを選択する。
2. 移行コストを最小限に抑える。
3. 活発なコミュニティと健全なエコシステムを持つAPIゲートウェイを見つける。
4. クラウドネイティブのトレンドに適した新しいAPIゲートウェイを構築する。

成果

1. パフォーマンスが以前の10倍に向上し、1日あたり数百万のQPSを処理できるようになった。
2. 9,000以上のAPIオンラインビジネスプロジェクトを容易にサポート。
3. 中国全土の複数サイトおよびレベルでのデータ災害復旧を成功裏に実現。

iQIYIの背景にあるストーリー

iQIYIのシニアR&DエンジニアであるCong He氏は、最近上海で開催されたApache APISIX Meetupで講演を行いました。彼はIIGインフラストラクチャ部門のコンピューティングクラウドチームに所属し、iQIYIのゲートウェイ開発と運用業務を担当しています。彼の講演とiQIYIのAPIゲートウェイのストーリーを通じて、Apache APISIXについてより深く理解しましょう。

2010年4月22日に中国最大のオンライン検索エンジンを運営するBaiduによって設立されたiQIYIは、現在世界最大のオンラインビデオサイトの1つであり、毎月約60億時間のサービス利用時間と5億人以上の月間アクティブユーザーを抱えています。

iQIYIは以前、Kongをベースにカスタム開発したSkywalkerという独自のAPIゲートウェイを開発していました。Skywalkerは現在、大規模なトラフィックを処理する必要があり、ゲートウェイサービスの1日のピークは100万QPSと数千のAPIルートに達します。しかし、この製品の欠点が徐々に明らかになってきました。

1. ゲートウェイのパフォーマンスがiQIYIの要件を満たさなくなり、大規模なトラフィックにより毎日大量のCPU IDLEが低すぎるアラートが発生する。
2. システムアーキテクチャに依存するコンポーネントが多すぎる。
3. 運用保守（O&M）コストが高すぎる。

今年このプロジェクトを引き継いだCong氏は、上記の課題と困難を解決するために類似のゲートウェイ製品を調査し、最終的にApache APISIXを見つけました。

Apache APISIXがKongを凌駕する理由

Apache APISIXを選択する前、iQIYIはすでにKongを使用していましたが、後にそれを放棄しました。

なぜKongを放棄したのか？

Kongを実際に使用した後、Cong氏は彼のチームがKongを放棄した理由を説明しました。以下はKongのコアな欠点のいくつかです。

1. Kongのルートはトラバーサルクエリを使用しており、高速ではない。
2. KongのPostgresデータベースは、デプロイが肥大化し、同期が非効率的で、可用性が低い。
3. コードの結合度が高い。

なぜAPISIXを選んだのか？

「調査中にApache APISIXとKongのパフォーマンスを比較したところ、驚くべきことにApache APISIXはパフォーマンス最適化の点でKongの10倍優れていることがわかりました。また、Apache APISIXを他の主要なゲートウェイ製品と比較したところ、Apache APISIXの応答遅延は常に他の製品よりも50%以上低いことがわかりました。さらに、Apache APISIXはCPU使用率が70%以上になっても安定して動作します。APISIXは本当に素晴らしいです！」とCong氏は語りました。

技術的には、Apache APISIXとKongはどちらもOpenRestyをベースに開発されており、移行コストが比較的低いです。さらに、Apache APISIXは優れた適応性を持ち、クラウドコンピューティングプラットフォームを含む多くの異なる環境に簡単にデプロイできます。

「同時に、Apache APISIXが非常に活発なオープンソースプロジェクトであり、問題を迅速に解決することもわかりました。そのクラウドネイティブフレームワークは、当社の今後の計画にも合致しています。そのため、APIゲートウェイとしてApache APISIXを選択しました。」

APISIX採用後のiQIYIのAPIゲートウェイアーキテクチャの革新

優れたAPIゲートウェイを選択した後、iQIYIは新しいAPIゲートウェイアーキテクチャの構築を開始しました。以下に示すように、ドメイン名、ゲートウェイ、サービスインスタンス、監視アラートが含まれています。

DPVSは、iQIYIがLVSをベースに開発したオープンソースプロジェクトです。Hubble監視アラートもオープンソースプロジェクトをベースにした深いカスタム開発であり、Consulのパフォーマンスと高可用性にいくつかの最適化が施されています。

成果1: クラスタとサービス管理のためのデータプレーンとコントロールプレーンを改善

データプレーンは主にフロントエンドユーザー向けであり、LBからゲートウェイまでのアーキテクチャ全体が災害復旧のために複数サイトおよび複数リンクでデプロイされているため、ユーザーは最も近いデータセンターにアクセスできます。

コントロールプレーンでは、複数のクラスタとサービスを管理するためのマイクロサービスプラットフォームが存在します。マイクロサービスプラットフォームにより、ユーザーはチケットを提出することなくワンストップサービスを体験でき、大幅な時間を節約できます。バックエンドでは、ゲートウェイコントローラーが主にすべてのAPIの設定（APIの作成やプラグインなど）を制御し、サービスコントローラーが登録、キャンセル、およびヘルスチェックを処理します。

成果2: セキュリティ制御、レートリミット、監視などの機能を追加

iQIYIは、Apache APISIXに適応した後、APIアーキテクチャにレートリミット、認証、アラート、監視などの基本的な機能を実装しました。

最初の部分はHTTPSに関するものです。セキュリティ制御のために、iQIYIはゲートウェイサーバーに証明書やキーを保存せず、専用のリモートサーバーに保存しています。しかし、Kongを使用している間はこれを実現するのが難しく、代わりにiQIYIはプレフィックスNGINXを使用してHTTPSオフロードを行っていました。Apache APISIXに移行した後、iQIYIはこの機能をApache APISIXで成功裏に実装し、リンク上の1層の転送を節約しました。

レートリミットに関しては、基本的なレートリミット機能に加えて、正確なレートリミットとユーザー粒度でのレートリミットも実装しました。認証に関しては、パスポート認証のための専用サービスを提供しました。さらに、iQIYIは会社のWAFセキュリティクラウドにアクセスして、アンダーグラウンド産業をフィルタリングできます。

監視アラート機能は、Apache APISIXの組み込みプラグインであるPrometheusを使用して実現されており、指標データは直接会社の監視システムに送信されます。Apache APISIXはまた、iQIYIにロギングとトレース分析サービスを提供します。

成果3: 動的サービスディスカバリーの更新プロセスを確立

上記のサービスディスカバリーに関しては、主にサービスセンターを介してConsulクラスタにサービスを登録し、DNSサービスディスカバリーを使用して動的に更新します。図中のQAEは、当社内で使用されているマイクロサービスプラットフォームです。インスタンスの更新プロセスを簡単に説明するために例を使用しましょう。

インスタンスを更新する際、まずConsulから対応するノードをログアウトし、APIゲートウェイコントローラーを介してゲートウェイにDNSキャッシュの更新リクエストを送信します。キャッシュが正常に更新された後、コントローラーはQAEプラットフォームにリクエストを送り返し、関連するバックエンドアプリケーションノードをすべて停止して、オフラインノードにトラフィックが再転送されないようにします。

成果4: 方向性のあるルート機能を改善

ゲートウェイは複数サイトでデプロイされており、事前に完全な複数サイトバックアップリンクが構築されています。それに加えて、Cong氏はユーザーがバックエンドサービスのために複数サイトの最寄りアクセスデプロイメントを持つことを提案しています。これにより、ユーザーはSkywalkerゲートウェイプラットフォームでAPIサービスを作成でき、コントローラーはAPIルートをすべてのDCゲートウェイクラスタにデプロイします。同時に、サービスドメインのデフォルトCNAMEは統一されたゲートウェイドメイン名にルーティングされます。

Apache APISIXは、最寄りアクセスの複数サイトデプロイメントと災害復旧のためのフェイルオーバー機能を直接提供でき、ユーザーが定義したカスタムルート解決をサポートします。さらに、ユーザーはフェイルオーバー、ブルーグリーンデプロイメント、カナリアリリースが必要な場合、UUIDドメイン名を通じてルート解決の設定をカスタマイズできます。また、Apache APISIXはバックエンドサービスの回復のカスタムスケジューリングもサポートします。

成果5: 複数サイトおよび複数レベルの災害耐性を改善

大規模なトラフィック、多数のクラスタ、広範なクライアントを扱うために、iQIYIは運用レベルで最寄りのサービスへのアクセスと災害復旧を必要としています。

複数サイトおよび複数リンクのバックアップに加えて、iQIYIは複数レベルおよび複数ノードの状況についても考慮する必要があります。APISIXはこれに役立ちます。クライアントがダウンしたノードに近いほど、ビジネスとトラフィックへの影響が大きくなります。

1. 最も遠いバックエンドサービスのノードがダウンした場合、iQIYIはサービスセンターとゲートウェイのヘルスチェックメカニズムを通じて、ダウンしたDCの単一ノードカットオフまたはフェイルオーバーを実現できます。これにより、影響は特定のサービスに限定され、ユーザーには影響しません。
2. ゲートウェイがダウンした場合、iQIYIはL4 DPVSのヘルスチェックメカニズムを使用して、失敗したゲートウェイノードをカットオフできます。影響は比較的小さく、ユーザーには影響しません。
3. 上記のサーキットブレーカーの措置でダウンしたノードを修復できない場合、iQIYIは外部ネットワークでのドメイン名粒度の複数ノード可用性デイリーテストを通じてDNSでの自動フェイルオーバーを実現できます。ただし、この方法は比較的遅く、他の多くのサービスに影響を与える可能性があり、ユーザーはこれを認識できます。

iQIYIの将来の計画

APISIXとの統合において、iQIYIはビジネスにより適した形でいくつかの問題を最適化しようとしています。

1. etcd、Prometheus監視、ロギングサービスなどの依存コンポーネントのボトルネックを考慮し、iQIYIはハイブリッドデプロイメント方法を使用する予定です。つまり、大規模なクラスタ内で情報を共有し、小規模なクラスタを独立させます。例えば、重要なサービスは小規模なクラスタでデプロイされます。

2. Prometheus監視メトリクスの対応する削減と最適化が行われます。特にDNSサービスディスカバリーに関してです。

Cong氏は、「将来の開発と更新において、Apache APISIXがより多くの機能をサポートし、優れたパフォーマンス効率と安定性を維持することを期待しています」と述べました。

APISIXのサポートをお探しですか？

iQIYIのように自信を持って開発を加速したいですか？APISIXのサポートを最大限に活用するには、API7が必要です。私たちは、APISIXとAPI管理ソリューションに基づいて、ニーズに応じた深いサポートを提供します！

いつでもご連絡ください: https://api7.ai/contact。