Open-Source Project

Community-Driven

High Availability, Stability

Ultimate Performance,

Developer Friendly

Go for Apache APISIX

Looking for the best API Gateway?

Companies choose Apache APISIX as their API gateway after comparing it with Kong. Not only is Apache APISIX is faster, but the experience is also excellent.

Apache APISIX vs Kong:

## 背景

近年、オンライン会議やリモートワークの発展に伴い、多くの有名なオンライン会議ソフトウェアが登場しました。その代表的なものとして、Zoomは在宅勤務、オンライン教育、ソーシャルシナリオにおいて人気のある会議ツールとなっています。Zoomは1日あたり3億5000万人の会議参加者と約47万の有料ビジネス顧客を抱えています。さらに、最近のデータによると、会議の促進に使用される時間は年間3.3兆分以上に達しています。

しかし、他のSaaSやインターネット企業と同様に、Zoomもビジネスの急速な拡大に伴い技術的な課題に直面しています。

- **多数のマイクロサービス**: Zoomのビジネスとチームの急速な成長により、100以上のバックエンドサービスを提供する必要があります。しかし、多数のマイクロサービスを効率的に管理することは困難です。

- **多様なデプロイ環境**: SaaS企業は、顧客が専用クラウド、プライベートクラウド、マルチクラウドにデプロイする必要があるシナリオに頻繁に遭遇します。Zoomのビジネスサービスは世界中に展開されているため、多数のハイブリッドクラウド環境における技術的な課題があります。

- **複雑なインフラストラクチャ**: 中規模および大規模のインターネット企業は、一般的にAPIゲートウェイ、設定センター、キー管理、ログ、監視アラーム、データベースなどを担当する専用のインフラストラクチャチームを持っています。ZoomのR&Dチームは世界中に分散しているため、これらの複雑なミドルウェアとインフラストラクチャを継続的デリバリーパイプラインに統合することは大きな課題です。

**上記の課題は単純な加算関係ではなく、乗算関係です。つまり、実際の状況ははるかに複雑です。** しかし、Zoomが以前使用していたオープンソースツールは、Zoomの現在の要件を満たすことができなくなりました。そのため、信頼性の高い継続的デリバリーパイプラインが非常に重要です。

以下は、Zoomがこれらの以前のオープンソースツールを選択しなかった詳細な理由です。

| Helm/Kustomize  | Terraform/Pulumi  | KubeVela + Crossplane  |
| ------------ | ------------ | ------------ |
| Kubernetes以外のシステムに接続できない  | Kubernetesとミドルウェア層でTerraformを使用するのが難しい（追加のProviderを開発しない限り）  | 技術スタックが新しすぎて更新が速く、本番環境で採用するには安全で安定していない  |
| Gitサブリポジトリモードでプラットフォームを集中管理するのが難しい  | 別の設定管理言語（hcl）を学ぶコストが増加する  | KubevelaのTrait + Cuelangテンプレートの定義とそのプログラミング表現能力が、Kubernetesシステム外のさまざまな非クラウドネイティブミドルウェアプラットフォームをカバーするのに十分でない  |
| Helm Chart Templateの複雑なロジックにより、保守とデバッグが難しい  | Mono Repo集中管理モードは大規模チームに適していない  | /  |
| 多数の環境で動的パラメータを管理するための強力なパラメータシステムがない  | /  | /  |

上記のオープンソースツールの制限により、Zoomは最終的に継続的デリバリーパイプラインの基盤を構築するためのいくつかの主流ソリューションを調査しました。

いくつかの比較と検証を経て、Zoomは最終的に新しい継続的デリバリーパイプラインをサポートするためにAPISIX Ingress Controllerを選択しました。

## Apache APISIX Ingress Controller

### Apache APISIX Ingress Controllerとは？

[Apache APISIX Ingress Controller](https://github.com/apache/apisix-ingress-controller)は、Apache APISIXをデータプレーンとしてトラフィックを運び、Kubernetesの機能をCRD（CustomResourceDefinition）を使用して拡張するクラウドネイティブなIngressコントローラーです。Kubernetes APIサーバーとのやり取り、ロールベースのアクセス制御（RBAC）の適用、変更の監視、Ingressコントローラー内でのオブジェクト変換の実装、変更の比較、そしてApache APISIXへの同期を担当します。さらに、APISIX Route、APISIX Upstream、およびKubernetesのネイティブIngressを含むカスタムリソースをサポートし、Kubernetesにデプロイされたサービスに外部トラフィックがアクセスするのを制御します。

以下は[APISIX Ingress Controllerのタイミング図](https://apisix.apache.org/docs/ingress-controller/design/#timing-diagram)です。

![APISIX Ingressのタイミング図](https://static.api7.ai/2022/10/27/635a5613af56a.jpeg)

## ZoomがAPISIX Ingress Controllerを選んだ理由

上記の背景を踏まえて、Zoomがどのような継続的デリバリーパイプラインを構築したいのか、そしてAPISIX Ingressをどのように採用してその基盤となる継続的デリバリーパイプラインを確立したのかという疑問が生じます。

Zoomは以前、APIゲートウェイとしてNGINXを使用していました。しかし、ビジネスの急速な発展とマイクロサービスの増加に伴い、現在のNGINXソリューションの限界が明らかになってきました。

異なるチームが個別にNGINXを保守する必要があり、数千行のNGINX設定ファイルが保守を困難にしています。さらに、NGINXはクラウドサーバー上で多数の行をデプロイする際に迅速にスケールできません。NGINXのリロードモードについては、[このブログ](https://api7.ai/blog/how-nginx-reload-work)を参照してください。ZoomのビジネスはIngress Controllerに向けて進化し始めました。

APIゲートウェイチームはいくつかのオープンソースソリューションを調査しました。NGINXでの実際のビジネス設定の移行シミュレーションと分析、およびパフォーマンスとプラグインエコシステムの比較のための多数のベンチマークテストを行った後、Zoomは最終的にApache Software FoundationのAPISIX Ingress Controllerプロジェクトを選択し、より先進的なクラウドネイティブゲートウェイを探求しました。

ビジネスシナリオを考慮して、Zoomは以下の2つの部分に重点を置きました。これらはAPISIX Ingressによって満たすことができます。

- **データセキュリティ**: Zoomは顧客のプライバシーとサービスのセキュリティを重視しているため、オンライン会議室や電話通話でmTLS認証と検証が広く使用されています。しかし、多くの類似のAPIゲートウェイはエンタープライズ版でのみこのようなサービスを提供できますが、APISIX Ingressはこの目標を達成するための高い実現性と利便性を提供します。

- **サービスの安定性**: Zoomのバックエンドサービスは、異なるリージョンでの高可用性のためにMulti-AZ（マルチアベイラビリティゾーン）デプロイメントを必要とします。一般的に、ビジネスを他のデータセンターに配置します。元のデータセンターでエラーが発生した場合、クライアントトラフィックを別のデータセンターに転送する必要がありますが、APISIX Ingressはこの要件を満たすことができます。

### Apache APISIX Ingress Controllerの特徴

Apache APISIXをデータプレーンとしてビジネストラフィックを運ぶApache APISIX Ingress Controllerは、Apache APISIXから以下の利点を継承しています。

- **高性能と安定性**: 高性能な動的オープンソースAPIゲートウェイとして、Apache APISIXはそのパフォーマンスにおいて弾力的で安定しており、多くの[企業の大規模トラフィックシナリオ](https://apisix.apache.org/blog/tags/case-studies/)で使用されています。

- **活発なコミュニティ**: トップレベルで最も活発なオープンソースAPIゲートウェイプロジェクトとして、Apache APISIXは活発なコミュニティを持ち、初日から優れた成長率を維持しています。

- **豊富なエコシステム**: Apache APISIXはHTTP(S)、HTTP2、Dubbo、IoTプロトコルMQTTなどのL7プロトコルをサポートしています。さらに、APISIXはTCP/UDPなどのL4プロトコルもサポートしています。また、Apache APISIX 3.0ではARM64の完全サポートが提供されています。

- **多数のプラグイン**: APISIX公式からリリースされているプラグインはほぼ100個あり、ユーザーは簡単にドラッグして使用できます。プラグインのホットリロードと動的オーケストレーションは、ユーザーに大きな利便性を提供します。

さらに、APISIX Ingress Controllerには以下の独自の利点もあります：

- **良好な互換性**: APISIX Ingress Controllerは複数のバージョンのIngressリソースをサポートし、異なるKubernetesバージョンと互換性があります。

- **動的更新**: ルート、証明書、その他の設定を変更する際にサービスをリロードする必要がなく、ビジネスのスムーズな運営を確保します。

- **柔軟なスケーリング**: APISIX Ingress Controllerはコントロールプレーンとデータプレーンを分離した構造を採用しているため、Apache APISIXのデータプレーンクラスタを独立して拡張できます。

![APISIX Ingress Controllerアーキテクチャ](https://static.api7.ai/2022/10/27/635a56148940c.jpeg)

- **運用と保守に優しい**: 現在のアーキテクチャでは、ユーザーは実際の状況に応じてデータプレーンAPISIXクラスタをKubernetesクラスタまたは物理ベアメタルマシン環境にデプロイすることを選択できます。さらに、APISIX Ingressのアーキテクチャの分離により、データプレーン上のAPISIXがトラフィックを運び、APISIX Ingress Controllerはコントロールプレーンコンポーネントです。そのため、APISIX Ingress Controllerの障害はビジネストラフィックに影響を与えません。

ゲートウェイの選択が完了した後、APIゲートウェイチームは新しい課題に直面しました：数百のサービスの元のAPIゲートウェイ設定をAPISIX Ingressに移行する方法です。Zoomのインフラストラクチャチームは、nginx.confや他のIngress設定からAPISIX Ingressへの変換コストを大幅に削減できる継続的デリバリーパイプラインを開発していました。

## 継続的デリバリーパイプラインの構築プロセスと機能

### Zoomの継続的デリバリーパイプライン

継続的デリバリーパイプラインは、すべてのアプリケーションデリバリー要件を宣言し、すべての継続的デリバリーステップを1行で配置および実行するエンドツーエンドのアプリケーションデリバリーシステムです。

![Zoomの継続的デリバリーパイプライン](https://static.api7.ai/2022/10/27/635a56149b270.jpg)

継続的デリバリーパイプラインには6つの部分があります：

1. **準備**: インフラストラクチャ、ミドルウェア、クラウドサービスリソースなどの事前設定リソースを準備します。

2. **設定**: アプリケーションに必要な設定ファイルとキーを準備します。

3. **デプロイ**: クラウドネイティブシナリオでK8sを使用してデプロイします（コンテナ、コンテナイメージ、パラメータ、バージョン、インスタンスに関する情報を含む）。

4. **アクセス**: Kubernetes Serviceを作成し、デプロイが外部アクセスを必要とする場合、Apache APISIX Ingressのルーティングルールを自動的に設定します。

5. **監視**: 監視、アラーム、ログ、トレース分析などの監視関連の設定を実行します。

6. **スケーリング**: 監視メトリクスを通じてKEDA（Kubernetes Event-driven Autoscaling）の動的スケーリングルールを宣言します。

### パイプラインでAPISIX Ingressを採用する方法

![Zoomのパイプラインアーキテクチャ概要](https://static.api7.ai/2022/10/27/635a5616254ed.jpg)

**プロジェクト管理**

プロジェクトマネージャーは、R&Dイテレーションと、タイムライン上でイテレーションに対応するリリース進捗と人員効率をより良く管理することに重点を置いています。Zoomは内部でGitOpsワークフローを使用して、APIゲートウェイ設定をアプリケーションデリバリーモデルに組み込んでいます。このモデルでは、APISIXルーティングルールの定義が「デプロイ」などのリンクと統合され、変更管理をGitHubに委ねます。GitHubブランチの作成とマージにより、パイプラインはアプリケーションとゲートウェイ設定のリリースとロールバックの間の一貫したタイムラインを実現します。

```yaml
# ZoomのCDパイプラインのGitリポジトリ内のコードスニペット
deploy:
  type: Deployment
  replicas: ~{ replicas, 2 }
  version: "latest"
  containers:
    - name: my-app
      image: "busybox"
      command: "echo 'Demo' && sleep 99d"
access:
  - protocol: https
    host: my-domain.my-org.com
    cert: my-tls-cert
    apisix:
      routes:
        http:
          - name: my-api
            authentication:
              # ......
            match:
              paths:
                - /my-api/*
```

この方法により、リリース管理をGitHub内のワークフロー管理に簡素化し、複数のイテレーションが同時に進行する際の上流と下流システムの変更のタイムラグの問題を解決します。

**アプリケーション開発**

開発者は主にAPIのルーティングと認証機能に焦点を当てており、これらはビジネスサービスと強く関連しており、自動化効果を達成するために開発者が記入する必要があります。さらに、彼らはビジネス機能と上位レベルのビジネスの開発と実装に重点を置き、すぐに使用できるインフラストラクチャを構築することを望んでいます。

上記のコードから、開発者はこの継続的デリバリーパイプラインで`Authentication`と`Match`を定義するだけでよいことがわかります。彼らは以下のロジックを知る必要はありません：

- まず、Kubernetes DeploymentとServiceに変換します。
- 次に、プラットフォームAPIを呼び出してパスの正確性を検証します。
- 最後に、ApisixRouteオブジェクトに変換します。

APISIXの設定と継続的デリバリーパイプラインのワークフローを統合することで、開発者により労力を節約する方法を提供します。

**環境管理**

複雑な環境管理と制御要件は、toBシナリオで頻繁に発生し、プライベートクラウド、専用クラウド、ハイブリッドクラウドシナリオでのデリバリー問題を考慮する必要があります。

環境の違いを隠蔽するために、APISIX Ingressの一部の設定が実装されました。これにより、システム管理者は一部の異種環境の違いを包括的に制御できます。環境にデプロイされたすべてのサービスが有効であり、環境の違いによるアプリケーションと運用開発者の認知負荷と特別なデプロイ操作を回避できます。例えば、Zoomはカスタマイズされた設定を使用して、一部の環境でトレーシングを無効にし、ApisixRouteオブジェクトをネイティブIngressオブジェクトとNGINX Ingress Annotationに変換し、異なるイメージを使用してシークレットをプルすることができます。

さらに、複数のビジネスラインがAPISIX環境を使用する場合、マルチテナント分離が必要です。**APISIX IngressはAnnotationセレクターを提供**し、異なるApisixRouteオブジェクトが異なるAPISIX Ingress Controllerインスタンスによってピックアップされることを可能にします。

**インフラストラクチャ管理**

APIゲートウェイチームは、すべてのAPISIXインスタンスを制御し、セキュリティポリシーを包括的に設定し、マルチアベイラビリティゾーンを実装する必要があります。

パイプラインの各プラグインは、インフラストラクチャエンジニア向けの設定項目を提供します。プラグイン`ingress-apisix`には、`defaultPlugins`プロパティがあります。

APIゲートウェイチームがこのプロパティを設定すると、設定はすべてのサービスに適用され、統一されたセキュリティとリスク管理戦略に適しています。

## 結論

APISIX Ingress Controllerは、Zoomの継続的デリバリーパイプラインにおいて重要な役割を果たし、プロジェクト管理、アプリケーション開発、環境管理、ミドルウェアおよびインフラストラクチャ管理の負担を軽減します。Zoomのケースは他の企業にとって学ぶ価値があり、APISIX Ingress Controllerがより多くの企業のイノベーションに貢献することを期待しています。

さらに、Apache APISIX Ingressは2022年8月にV1.5を正式にリリースし、すべてのリソースAPIバージョンの提案を統一し、すべてのCRD APIバージョンをV2にアップグレードしました。同時に、Gateway APIリソースの大部分をサポートしています。Apache APISIX Ingressは、Ingressリソースに新しいAnnotation「k8s.apisix.apache.org/plugin-config-name」を追加することで、Ingressリソースが任意のAPISIXプラグインを使用できるようにしました。これにより、APISIX Ingress Controllerの使いやすさが大幅に向上し、他のIngress ControllerからAPISIX Ingress Controllerへの移行コストが削減されます。

詳細については、[Apache APISIX Ingress V1.5](https://apisix.apache.org/blog/2022/08/05/apisix-ingress-1.5rc1-release/)をご覧ください。


Zoomは、プロジェクト、アプリケーション、環境、およびインフラストラクチャ管理の全体管理を実現するために、継続的デリバリーパイプラインにAPISIX Ingress Controllerを統合しています。

Zoom 如何在持续交付管道中使用 APISIX Ingress？

## 概要

### 課題

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

2010年4月22日に中国最大のオンライン検索エンジンを運営するBaiduによって設立された[**iQIYI**](https://www.iq.com/?lang=en_us)は、現在世界最大のオンラインビデオサイトの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ゲートウェイアーキテクチャの構築を開始しました。以下に示すように、ドメイン名、ゲートウェイ、サービスインスタンス、監視アラートが含まれています。

![iQIYIのAPIゲートウェイアーキテクチャ図](https://static.api7.ai/2022/12/02/6389647220deb.jpeg)

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

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

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

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

![マイクロサービスゲートウェイ.webp](https://static.api7.ai/2022/11/21/637b4c61c02c0.webp)

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

iQIYIは、[Apache APISIX](https://github.com/apache/apisix)に適応した後、APIアーキテクチャにレートリミット、認証、アラート、監視などの基本的な機能を実装しました。

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

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

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

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

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

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

![iQIYIの動的サービスディスカバリー更新プロセス](https://static.api7.ai/2022/12/02/63897fa31ff83.jpeg)

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

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

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

![iQIYIの方向性のあるルート図](https://static.api7.ai/2022/12/02/63898546bd508.jpeg)

### 成果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](https://api7.ai/contact)。


iQIYIの技術チームは、APISIXとKongを比較し、iQIYIのインフラストラクチャを更新・統合することで、まったく新しいAPIゲートウェイの構築に成功しました。

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

## 概要

世界をリードする企業向けコンソーシアムブロックチェーン基盤インフラストラクチャおよびソリューション提供者である[Hyperchain Technologies](https://www.hyperchain.cn/en/about/company)は、革新的なインフラストラクチャを構築し、社会のデジタル化を推進することを使命としています。急速な成長の中で、HyperchainはHyperchainブロックチェーンプラットフォームを構築する際に以下のような多くの問題に直面しました：

- 標準化されたトラフィック管理がなく、システム崩壊のリスクがある
- セキュリティ制御と認証管理が不完全
- 権限制御が不便
- パブリックネットワークIPアドレスのコストが高い
- ブロックチェーンノードが不安定：単一ノードが攻撃を受けやすい
- 複数のプロトコルの統一管理が欠如

HyperchainはKongやNGINXを試しましたが、残念ながらHyperchainのビジネスシナリオを満たすことができませんでした。**しかし、Apache APISIXを採用した後、上記の問題はすべて解決され、Hyperchainブロックチェーンプラットフォームに無限の活力を与えました。**

### Hyperchainブロックチェーンプラットフォームについて

Hyperchainブロックチェーンプラットフォームは、ブロックチェーンフレームワークをクラウドコンピューティングプラットフォームに組み込み、クラウドサービスのインフラストラクチャの展開と管理の利点を活用することを指します。これは、開発者に便利で高性能なブロックチェーンエコシステムと関連サポートサービスを提供し、web3でのビジネス拡張と運用をサポートするオープンなブロックチェーンプラットフォームです。

**Hyperchainブロックチェーンプラットフォームは、ブロックチェーンネットワークを迅速かつ柔軟に構築できます。このプラットフォームを使用することで、企業はブロックチェーン業務を一元的に管理できます。** 例えば、プラットフォームを通じて統合開発環境で契約を締結し、その後作成したブロックチェーンネットワークに契約をデプロイできます。上位サービスモジュールはブロックチェーン関連の契約を呼び出してビジネスプロセスを継続できます。

チェーン内には多くのノードがあり、数十から数千に及ぶため、プラットフォームのサポートなしではチェーンの運用を監視および維持することが困難です。**Hyperchainブロックチェーンプラットフォームを使用することで、ユーザーはコストを節約するだけでなく、ブロックチェーンをより便利に管理し、システム全体のセキュリティを強化できます。**

Hyperchainを例に、なぜブロックチェーン企業が多くのAPIゲートウェイの中からApache APISIXを選択すべきかを説明します。以下では、APISIXのHyperchainブロックチェーンプラットフォームとブロックチェーンノードでの応用を分析します。

## HyperchainブロックチェーンプラットフォームでのAPISIXの応用

以下は、HyperchainブロックチェーンプラットフォームでのAPISIXの応用インタラクションダイアグラムです。バックエンドサービスは、そのビジネス特性に応じてetcdにサービス情報を登録し、その後ルート登録モジュールを通じてAPISIXにサービスを登録します。

APISIXはシステム内の内部マイクロサービスの統一エントリとして機能します。外部リクエストはまずAPISIXに送信され、認証を通過した後、APIを介してアクセス層にアクセスし、その後RPC（リモートプロシージャコール）を介してコアサービスにアクセスします。

![Hyperchain応用インタラクションダイアグラム](https://static.api7.ai/2022/11/15/637335a53d73c.png)

### ルート転送

時には、APIを同じドメイン名の下に公開することが期待されます。この場合、同じサービスのAPIパスにいくつかのプレフィックスを追加できます。例えば、`/baas-core`や`/baas-other`などです。クライアントがこれらのAPIをリクエストする場合、APIゲートウェイは追加されたプレフィックスを取り除き、リクエストをバックエンドサービスに転送する必要があります。APISIXの[proxy-rewriteプラグイン](https://apisix.apache.org/docs/apisix/plugins/proxy-rewrite/)は、このようなケースを便利に処理するのに役立ちます。

例えば：
訪問時：http://apisix:8080/baas-{service}/api/v1/…
リクエストはhttp://{service}/api/v1/…に転送されます
正規表現を記述することで：`^/baas-core/(.*)$,/$1`

![proxy-rewriteプラグイン編集](https://static.api7.ai/2022/11/15/637335b538dc0.png)

### トラフィック制限管理

ユーザーはHyperchainだけでなく、IBMデータファブリック、Baidu XuperChainなど、ニーズに応じてコンソーシアムブロックチェーンを選択できます。したがって、Hyperchainはシステム内のすべてのコンソーシアムブロックチェーンのライフサイクル管理を行う必要があります。

コンソーシアムチェーンを作成する際、Hyperchainはブロックチェーンプラットフォームにハードコードを記述し、プラガブルドライブコンポーネントをブロックチェーンプラットフォームにアップロードして呼び出し、コンソーシアムチェーンを作成します。一部のプライベートデプロイメントケースでは、プラガブルドライブコンポーネントが迅速にサポートできます。

ドライブコンポーネントへの呼び出しは制限が必要なプロセスであり、特に数が多い場合に重要です。したがって、APISIXの[limit-reqプラグイン](https://apisix.apache.org/docs/apisix/plugins/limit-req/)は、プラットフォームのトラフィック入出力を制限し、安定性を確保するのに役立ちます。

limit-reqプラグインでは、レートとバーストに関するカスタマイズ設定が可能です。

![limit-reqプラグインモデル](https://static.api7.ai/2022/11/15/637335b790f49.jpeg)

### セキュリティ制御と権限管理

APISIXと連携するため、Hyperchainはプライベートデプロイメント環境向けのプラグインを開発しました。パーティAはしばしば独自の認証サービスやサービスアカウントシステムを使用することを好みます。フロントエンドトラフィックがウェブサイトにアクセスする際、まずAccess-authプラグインを通過し、認証を通過した場合にのみバックエンドBFF（Backend for Frontend）にアクセスできます。

![認証プロセスダイアグラム](https://static.api7.ai/2022/11/15/637335b994030.png)

Restful標準仕様の3つの主要要素（認証情報、Restfulパス、およびGET、POST、PUT、DELETE、PATCHなどのHTTP動詞）に基づいて、アカウント-ロール-権限認証が行われます。認証が通過した場合、ユーザー情報がヘッダーに返されます。認証が失敗した場合、403が返されます。

![API認証パス](https://static.api7.ai/2022/11/15/637335bd3e080.png)

### ホットリローディング

APISIXは、内部で開発されたプラグインの[ホットリローディング](https://apisix.apache.org/docs/java-plugin-runner/hot-reloading/)を提供します。これにより、開発中に時間を節約し、プラグインランナー全体を再起動することなくコードの一部を変更できます。この方法で、開発者はバックエンドでインターフェースを調整し、即座に反映させることができ、オンラインリリースに便利でフレンドリーです。

### なぜKongではないのか？

Hyperchainは以前Kongを使用していましたが、最終的にApache APISIXに置き換えました。主な理由は以下の通りです：

- **高いデプロイメントとメンテナンスコスト**

    KongクラスターはPostgresqlデータベースと連携する必要があり、高可用性のために特定のデータベース管理者が必要です。Postgresqlデータベースのクラスター展開は比較的難しく、後続の運用とメンテナンスのコストを増加させます。

- **システムの複雑さと故障率の増加**

    HyperchainブロックチェーンプラットフォームはMySQLデータベースを使用しており、Kongを採用するとシステム内に2つのリレーショナルデータベースが存在することになり、システムがより複雑になります。また、2つのデータベース間の互換性を向上させる際に故障率が増加します。

## ブロックチェーンノードでのAPISIXの応用

![Hyperchainブロックチェーンダイアグラム](https://static.api7.ai/2022/11/15/637335bfa08dc.png)

### パブリックネットワークIPアドレスのコスト削減

ユーザーはHyperchainブロックチェーンプラットフォームを通じてブロックチェーンを購入します。その後、上位ビジネスと開発者クライアントはノードに接続できます。サービスは1つ以上のノードに接続し、ユーザーは1つ以上のノードにアクセスする可能性があり、これにより問題が発生します：ほとんどすべてのノードが訪問され、単一ノードの訪問負荷が高くなります。

一部のプライベートデプロイメント環境では比較的簡単に処理できます。しかし、インターネットユーザーを対象としたシステムでは、多くのノードとパブリックネットワークIPが必要です。4メガバイトのトラフィックを持つ各パブリックネットワークIPの価格は、月額約200元に達する可能性があります。Hyperchainプラットフォームには数千のノードがあり、高いパブリックIPコストがかかります。

APISIXはすべての訪問リクエストを管理し、対応するブロックチェーンノードにトラフィックを分散します。これにより、Hyperchainは高いコストを節約しました。

![APISIXを使用したHyperchainのモード](https://static.api7.ai/2022/11/15/637335c23f4f8.png)

### 便利な権限制御

Hyperchainブロックチェーンプラットフォームにはさまざまなブロックチェーンがあり、各チェーンには複雑なRBAC権限制御があります。したがって、クライアント側にTLS証明書など、さまざまな種類の証明書を追加する必要があり、ユーザーを困惑させます。

現在、APISIXの[key-authプラグイン](https://apisix.apache.org/docs/apisix/plugins/key-auth/)を使用してこの問題を効率的に解決できます。認証されたユーザーは、権限設定を気にすることなく直接ブロックチェーンにアクセスできます。APISIXは基盤となるチェーンを統一します。

### クラスタリングによるノードの安定性向上

前述のように、ノードは頻繁に訪問されます。銀行ユーザーの多くは高並列性があり、TPS（1秒あたりのトランザクション数）は40,000-50,000回に達する可能性があります。

ブロックチェーンの単一ノードは脆弱であることが判明しています。各トランザクションは訪問されたノードに影響を与えます。

HyperchainはKubernetes上にApache APISIXをデプロイし、Horizontal Pod Autoscalerを使用しています。APISIXは動的な拡張性が優れたetcdを使用しているため、単一ポイントのトラフィック影響の問題を効果的に解決できます。

### 複数のプロトコルのサポート

Hyperchainブロックチェーンプラットフォーム上の異種チェーンのプロトコルは多様です。例えば、HTTPプロトコル、Websocketプロトコル、gRPCプロトコル、TCPプロトコル、UDPプロトコルなどです。

APISIXは複数のプロトコルをサポートし、異なるブロックチェーンの基盤層に柔軟に適応し、開発コストを削減します。

### なぜNGINXではないのか？

HyperchainはNGINXを使用して問題を解決できるように思えます。しかし、試用後、HyperchainはNGINXを放棄しました。その理由は以下の通りです：

- **動的拡張に不向き**

    Hyperchainはブロックチェーンプラットフォームで頻繁にノードを追加および削除する必要があり、再起動後にのみ有効になります。これは開発者にとって不便です。さらに、開発者はNGINXのconfファイルに複雑なルールコードを記述する必要があります。

- **クラスタリングが困難**

    NGINXはクラスタリングをサポートしておらず、ユーザーにとって比較的複雑でフレンドリーではありません。

- **TCPおよびUDPの直接サポートがない**

    NGINXは7層プロトコルのみをプロキシでき、4層プロトコルを直接サポートできません。さらに、モジュールはデフォルトでコンパイルされておらず、追加の処理が必要です。

- **ダッシュボードがない**

    NGINXには視覚化されたインターフェースがなく、多くのノードを管理するのが開発者とオペレーターにとって困難です。

## まとめ

上記の内容から、Apache APISIXがブロックチェーン領域で応用できる動的APIゲートウェイであることがわかります。さらに、Apache APISIXはロードバランシング、動的アップストリーム、カナリアリリース、サーキットブレーカー、認証、可観測性などの豊富なトラフィック管理機能を提供します。

APISIXがより多くのブロックチェーン企業を次の開発段階に進めることを願っています。
Apache APISIXについてもっと学びたい方は、https://api7.ai/contact でお問い合わせください。


区块链独角兽公司Hyperchain如何利用开源API网关APISIX，赋能Hyperchain区块链平台管理web3中的区块链流量，并提及APISIX、Kong和NGINX之间的对比。

Apache APISIX vs Kong:
93x Faster & 200% QPS

APISIX vs Kong Performance Report

Looking for the best API Gateway?

Go for Apache APISIX

Community-Driven

Open-Source Project

Ultimate Performance,

High Availability, Stability

Developer Friendly

Apache APISIX vs Kong

Case Studies

Zoom 如何在持续交付管道中使用 APISIX Ingress？

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

API Gateway for Web3: APISIX 如何赋能 Hyperchain

APIの管理を始めますか？

Apache APISIX vs Kong:.css-j8kk69{background-image:var(--chakra-colors-gradient-600);color:transparent;-webkit-background-clip:text;background-clip:text;}93x Faster & 200% QPS

APISIX vs Kong Performance Report

Looking for the best API Gateway?

Go for Apache APISIX

Community-Driven

Open-Source Project

Ultimate Performance,

High Availability, Stability

Developer Friendly

Apache APISIX vs Kong

Case Studies

Zoom 如何在持续交付管道中使用 APISIX Ingress？

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

API Gateway for Web3: APISIX 如何赋能 Hyperchain

APIの管理を始めますか？

Apache APISIX vs Kong:
93x Faster & 200% QPS