## 背景

近年、オンライン会議やリモートワークの発展に伴い、多くの有名なオンライン会議ソフトウェアが登場しました。その代表的なものとして、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？

## 概要

2021年5月以来、[vivo](https://www.vivo.com/en)は[Apache APISIX](https://apisix.apache.org/)をAPIゲートウェイとして導入しました。vivoでの1年以上の実践を経て、APISIXは多くの技術的およびビジネスの課題を解決し、大規模に使用されています。

### APISIX使用前の課題

- **ビジネスシナリオとシステムメンテナンスの複雑な管理**

    ビジネスの急速な成長により、さまざまなシナリオとそれらをサポートするシステムが存在し、vivoはそれらを統一して管理する方法を必要としていました。

- **データプレーンとコントロールプレーン間の相互作用**

    vivoのような中規模から大規模な企業にとって、データプレーンで発生する小さなトラブルがコントロールプレーンに影響を与えることは予期せぬことでした。

- **多次元リソースのサポートがない**

    多様なプロジェクトにより、さまざまなドメイン名とURLが存在します。ビジネス部門は、異なるリソース次元に従って検索する必要があります。

- **問題の影響が制御不能**

    vivoのプロジェクトは複雑であり、遭遇する問題の影響が制御不能です。一部の複雑なプラグインの使用がこれをさらに悪化させます。

APISIXをNGINXに置き換えることで、vivoは最終的に以下のような一連の成果を達成しました。

### APISIX使用後の成果

- **高可用性**

    APISIXがvivoで導入されて以来、重大な障害は発生しておらず、システムの可用性は**99.99%**を超えています。

- **高性能**

    重要なオンライントラフィックを引き受け、多数のサービスを提供しており、現在のオンライン転送トラフィックは**100万QPS**（クエリ/秒）に近づいています。

- **豊富な機能**

    APISIXの[豊富な機能](https://apisix.apache.org/blog/2022/11/02/apache-apisix-v3-preview/)により、APISIXはほぼすべての一般的なNGINXプロキシシナリオをカバーできます。vivoのプロジェクトの約50%がNGINXからAPISIXクラスタに移行されました。

- **クラウドネイティブの構築と開発のサポート**

    コンテナ化をサポートするK8sベアメタルは**10,000**の規模に達しています。プロジェクトの約40%がベアメタルと仮想マシンからK8sコンテナプラットフォームに移行され、vivoのコンテナ化の進展をサポートし、促進しています。

## APISIXに基づくvivoのシステム設計

次に、APISIXを採用した後のvivoのシステム設計を見てみましょう。

### APISIX上のカスタマイズされたアーキテクチャ表示

![vivoのAPISIXを使用したAPIゲートウェイアーキテクチャ](https://static.api7.ai/2022/11/23/637dc2f51318e.jpg)

上記の図から、vivoは以下を達成したことがわかります。

- **レイヤー4**と**レイヤー7**のトラフィックゲートウェイの構築を完了し、APISIXによってサポートされています。
- ベアメタル、仮想マシン、コンテナのトラフィックアクセスと混合デプロイを実現しました。
- APISIXクラスタ管理を実装しました。
- 内部のDevOpsプラットフォームとビジネスデプロイサービスを接続し、トラフィックを迅速かつ自動的にアクセスできるようにしました。
- 監視構築を改善しました。

### 構成管理と起動の改善

ビジネス部門の実際のニーズをよりよく満たすために、vivoはAPISIXに一連の適応を行いました。以下は、コントロールプレーンの変更、クラスタ分離管理、データ転送などの調整の一部です。

#### コントロールプレーンの変更

全体のプロセスは以下の通りです。

A6変更プラットフォームでデータが構成されると、情報はRPC通知を通じてManagerAPIに配信されます。ManagerAPIは、vivoがオープンソースの[APISIX Dashboard](https://github.com/apache/apisix-dashboard)に基づいて構築したものです。

その後、トラフィックは`apisix-agent`に送信されます。APISIXは特権プロセスを通じて定期的にapisix-agentをポーリングし、変更タスクをバッチで取得します。次に、特権プロセスは共有キューを通じて`worker`に通知し、メモリ内の変更を実現します。

その間、APISIXはタスクの結果を`apisix-agent`に通知し、それをManagerAPIに配信します。さらに、A6変更プラットフォームはManagerAPIをポーリングしてタスク結果を取得できます。

![vivoの管理と公開モード](https://static.api7.ai/2022/11/25/638036da44e7f.jpeg)

[etcd](https://etcd.io/docs/v3.5/learning/why/#comparison-chart "etcd")はAPISIXのハイライトであり、コントロールプレーンとデータプレーンの独立した操作を可能にします。そのアーキテクチャの独自性を考慮して、vivoは上記のプロセスでetcdを廃棄しました。以下はその理由です。

vivoのプロジェクトの多様性により、さまざまなドメイン名とURLが存在します。さらに、ビジネス部門は異なる次元でクエリを行う必要があります。APISIXがetcdだけでなく、さまざまなデータベースにも適応できるため、vivoはMongoDBなどのデータベースを簡単に利用してAPISIXと連携することができました。

さらに、vivoはApache APISIXとの互換性を確保するために以下の貢献を行いました。

- **エージェントコンポーネントの開発**

    2021年5月以来、vivoはApache APISIXを導入しました。技術的背景と文脈を考慮して、vivoはOpenRestyとLuaの経験がないため、APISIXを採用できないのではないかと不安を感じていました。さらに、ログ収集や監視処理などの非転送タスクが多く、データプレーンの管理の複雑さを増す可能性がありました。その結果、vivoは開発の複雑さを軽減するためにエージェントコンポーネントを開発しました。

- **ディスクへのデータ書き込み**

    システムを調整可能にし、データプレーンが独立して動作できるようにするため、vivoは設定ファイルをディスクに書き込みました。APISIXが起動すると、設定センターから完全にプルすることをサポートし、ローカルディスクのファイルディレクトリから直接設定リソースを取得することもサポートします。これにより、データの独立性とシステムの堅牢性が大幅に向上します。さらに、ディスクに配置された設定されたルートとアップストリーム情報を直感的に理解できるため、トラブルシューティングに役立ちます。

- **変更タスク結果のコールバック**

    大規模な企業であるvivoは、ルーターやアップストリームなどのリソースへの変更が確実に有効かつ成功することを確認し、これらの変更が失敗した場合でもシステムがエラーを報告できるようにする必要があります。このACK（確認コード）のロジックにより、マシン上のNGINXワーカーがコールバックできるようになります。コールバックタスクが成功すると、APISIX上のすべてのワーカーがリソース変更を関連するメモリに更新します。

#### クラスタ分離管理

![クラスタ分割管理](https://static.api7.ai/2022/11/25/6380381595b00.jpeg)

APISIXのオープンソースバージョンは、[etcd](https://apisix.apache.org/docs/apisix/FAQ/#why-does-apache-apisix-use-etcd-for-the-configuration-center)を提供しています。しかし、企業のプロジェクトは複雑であり、遭遇する問題は制御不能です。さらに、複雑なプラグインを使用することは避けられず、システムのパフォーマンスに影響を与えます。

そのため、クラスタ分離によって管理され、APISIX上のクラスタ構成の分離を実現し、以下が可能です。

- 障害ドメインを制御し、他のプロジェクトに影響を与えずにプロジェクトの複雑さを効果的にサポートします。
- コンテナノードが頻繁に変更される場合に、APISIXの非転送層による負荷を効果的に軽減します。
- ヘルスチェックによる負荷の影響を軽減します。

#### HTTPSによるQPSの増加

中国の工業情報化省の関連要件に従い、外部ネットワークトラフィックはHTTPSプロトコルを経由する必要があります。TLSベースのHTTP暗号化プロトコルであるHTTPSは、暗号化と復号化のプロセスでCPUに大きな負荷をかけます。

ルーティングやその他の設定が同じ場合、HTTPSが引き受けられるトラフィックはHTTPの約**1/8 - 1/10**です。

Intel® QAT（QuickAssist Technology）アクセラレータカードにパッチを適用した後、vivoは復号化処理をQATアクセラレータカードに委託し、CPUを解放することで、単一マシンでのHTTPSによるQPSを増加させました。以下の図からわかるように、**単一マシンのHTTPS負荷能力は約2倍になりました**。

![vivoのトラフィック負荷能力の改善を示すデータ](https://static.api7.ai/2022/11/23/637dc306a5fa1.jpg)

## vivoがビジネスとAPISIXをどのように組み合わせているか

### コンテナ化開発のサポート

コンテナ化開発をサポートするために、vivoはK8s ingressコントローラーを独自に開発しました。以下はその機能の一部です。

1. vivoの変更された非同期プッシュ構成変更メカニズムに適応する

2. 複数のK8sクラスタイベント処理通知をAPISIXに実施する

3. 以下のような複雑なプロジェクトシナリオに対応する：

- 1つのサーバーに複数のポートがある場合

- DubboやgRPCなどの他のRPCフレームワークサーバーがK8sに接続されている場合、プロジェクトの構成特性に応じてAPISIXや他のフレームワークにポート情報を通知するための統一された処理ロジックが必要です。

4. 企業内部のDevOpsやその他の自動化シナリオの特定のニーズに適応し、迅速なデプロイを容易にし、トラフィックを有効にします。

### NGINXからAPISIXへのプロジェクト移行の支援

vivoのプロジェクトは既存のNGINXクラスタにデプロイされており、長期間安定して稼働しています。しかし、非ビジネスワークロードとプロジェクトの不安定性をもたらします。そのため、移行を行うことは困難です。では、どのようにしてプロジェクトをAPISIXに移行するのでしょうか？

- まず、協力部門のプロジェクトを見つけ、ビジネス部門に良いサービスを提供してベンチマークを設定し、技術的なガイダンスとトレーニングを提供します。

- ビジネスアクセスとビジネス部門の多次元管理を容易にする使いやすいコントロールプレーンシステムを構築します。

- NGINX構成からAPISIX構成への自動変換機能と基本構成を提供します。

### APISIXのアップグレードとオープンソースバージョンのサポート

APISIX 2.4バージョンに基づいて、vivoはいくつかの調整を行い、新しいバージョンをリリースしました。今年の第2四半期には、さらに新しいバージョンにアップグレードされました。

一方で、APISIXのモジュールアーキテクチャのおかげで、vivoの変更されたLuaコードをAPISIXの上位バージョンのブランチに統合するのは比較的簡単です。一方で、vivoはOpenRestyセクションもアップグレードしており、約1年に1回のバージョンアップを行っています。vivoは多くのPATCHとQATなどの有用な機能を利用しているため、このコンポーネントのアップグレードは困難で労力がかかります。

NGINXコミュニティの無料バージョンの機能は更新が遅く、活発ではありません。vivoはAPISIXと共同で構築するかどうかを検討しています。関連するシステムテストに必要な人材を削減するために、vivoはシステム統合テストのための汎用テスト自動化フレームワークであるRobot Frameworkを採用しました。彼らは、ユニットテストのカバレッジとTDD（テスト駆動開発）の開発モデルのための関連コンポーネントを推進しています。

## vivoの将来の計画

来年、vivoは[APISIX](https://apisix.apache.org/blog/2022/09/13/why-is-apache-apisix-the-best-api-gateway/)をトラフィックゲートウェイからAPIゲートウェイに拡張し、[レート制限](https://apisix.apache.org/docs/apisix/plugins/limit-count/#attributes)、[認証](https://apisix.apache.org/docs/ingress-controller/tutorials/mtls/)、サーキットブレーカーなどの利点を活用する予定です。APISIXとDPDK-NGINXを組み合わせることを検討しており、技術者を育成し、コミュニティの設立に参加する予定です。さらに、基本的なスキルを強化し、トラフィックとサービスガバナンスの基盤を築く予定です。

Apache APISIXについてもっと学びたい方は、[https://api7.ai/contact](https://api7.ai/contact)でお問い合わせください。


How does the famous mobile manufacturer vivo adopt APISIX as its API gateway and adjust it to fit its businesses?

vivo 如何与 APISIX 集成

## 概要

### 課題

- Airwallexのビジネスが世界中に拡大するにつれ、データガバナンスにおける重要な課題が生じている
- 複数のシステムとその相互接続の複雑な管理により、1つの問題が発生すると他のシステムにも問題が波及する

### 成果

- **15ヶ月間**の本番環境での安定したパフォーマンスを実現
- 動的ルーティング、マルチテナントのレートリミット、マルチテナントのIPホワイトリスト、認証、認可が有効な状態で、**99%**の応答遅延が**23ミリ秒**以内に収まる
- **130以上の国と地域**で**50以上の通貨**をカバーするデータ主権を安全かつ効率的にサポート

## Airwallexについて

グローバルなフィンテック企業である[Airwallex](https://www.airwallex.com/us)は、世界中の130以上の国と地域で50以上の通貨をカバーする支払いネットワークを構築し、企業向けのデジタルフィンテック製品を提供しています。

![Airwallex Business](https://static.api7.ai/apisix-webp/202108/1646626634389-7d9a0a82-a76c-4645-93b6-8a431bb1f9a1.webp)

> この記事は、Apache APISIXのコミッターであり、Airwallexの技術プラットフォームリードを務める楊莉博士へのインタビューに基づいています。楊博士は、Airwallexの技術プラットフォームの進化を担当しています。

## データ主権がAirwallexに与える課題

[データ主権](https://api7.ai/blog/leveraging-api-gateway-for-data-sovereignty-and-data-compliance)は、サイバースペースのデータガバナンスにおいてますます重要になっています。Airwallexはさまざまな地域のユーザーにサービスを提供しており、自然とデータ主権の問題が発生します。

以前は、データ主権の要件がなかったため、データをヨーロッパに配置し、アジアや世界の他のデータセンターに同期することができました。データの相互作用図は以下のようになります。

![Multi-cluster Interaction](https://static.api7.ai/202108/1635907812257-962b1247-f5ca-448f-904d-fd47c3ea4586.png)

しかし、データ主権が重視される時代においては、データは管理下に置かれ、以前のアーキテクチャを採用することはできません。ヨーロッパではヨーロッパのデータのみを処理し、同様にアジアではアジアのデータのみを処理します。データの相互作用は以下のように変化します。

![Interaction under data sovereignty environment](https://static.api7.ai/uploads/2023/02/01/63Z7AhJx_2.webp)

その結果、データ主権はAirwallexのグローバルビジネスにとって重要な課題となっています。Airwallexはヨーロッパから他の地域にデータを移行することを計画しており、EUのデータ主権要件と第三国の要件が一致していることを確認する必要があります。

## AirwallexがAPISIXを選んだ理由

APIゲートウェイを選択する際、Airwallexは主に6つの観点から主要なゲートウェイ製品を比較しました。

- **安定性**: AirwallexはAPIゲートウェイの安定性を非常に重視しています。世界のトップ1000ウェブサイトのうち、**62.1%がNGINXベース**であり、NGINXベースのウェブサーバーが本番環境での複雑で多様なシナリオを通過していることを示しています。Apache APISIXはNGINXをベースとしています。さらに、**Apache APISIXの[完全動的](https://api7.ai/blog/how-nginx-reload-work)**機能の設計により、リロードなしでルートを変更し、クライアントの長い接続を維持することが可能です。また、**AirwallexはApache APISIXにストレステストを実施し、CPU使用率が70%を超えても安定して動作することを確認しました。**

- **パフォーマンス**: すべてのAPIリクエストはAPIゲートウェイを通過します。ゲートウェイの[パフォーマンス](https://api7.ai/blog/apisix-kong-3-0-performance-comparison)損失を減らすことで、AirwallexのAPI全体の応答時間を大幅に短縮できます。
  
    > 「PoCでは、主要なゲートウェイ製品を比較しました。**Apache APISIXの応答遅延は他のゲートウェイよりも50%以上低い**です。さらに、Apache APISIXの独立したデータプレーンにより、クラスター内で独立したインスタンスを実現し、水平拡張を本質的にサポートしています。」と李は述べました。

- **拡張性**: Airwallexは、複雑な**[認証](https://api7.ai/blog/api-gateway-authentication)、権限制御、[サービスディスカバリー](https://api7.ai/blog/what-is-service-discovery-in-microservices)、[レートリミット](https://api7.ai/blog/rate-limiting-in-api-management)、ダウングレード、ロードバランシング、ホワイトリスト、動的ルーティング**をサポートするAPIゲートウェイとしてAPISIXを必要としています。

- **活発なコミュニティ**: 活発なコミュニティは、APIゲートウェイが技術の進化に追いつくための鍵です。

    > **Apache APISIXの[コミュニティ](https://api7.ai/category/community)は、Apacheインキュベーションプロジェクトであった時から活発で、貢献者数、Issueの応答時間、Pull Requestの数から判断できます。**と李は共有しました。

- **プライベートデプロイメント**: APIゲートウェイはAirwallexのコア技術アーキテクチャコンポーネントであり、自社のプライベートネットワークのエッジにAPIゲートウェイをデプロイします。**Apache APISIXは環境適応性が高く、クラウドコンピューティングプラットフォームを含むさまざまな環境に簡単にデプロイできます。**

- **ビジネスフレンドリーなオープンソースライセンス**: Apache 2.0ライセンスにより、AirwallexはAPISIXのコードを変更し、商用化することができ、ベンダーロックインを心配する必要がありません。

## Apache APISIXのインテリジェントルーティングソリューション

**AirwallexはApache APISIXを選択し、インテリジェントルーティングソリューションを実現しました**。データをどこで処理するかは、Apache APISIXゲートウェイが決定します。

![Airwallex's two-layer gateway](https://static.api7.ai/uploads/2023/02/01/cGg9YfNp_3.webp)

ゲートウェイは2層で構成されています。第1層はリクエストのルーティングを担当し、条件に基づいてリクエストがどのデータセンターに到達すべきかを決定します。第2層はトラフィックの転送を担当します。

さらに、**Airwallexは主要な機能をカスタム[プラグイン](https://api7.ai/blog/how-to-implement-plugin-orchestration-in-api-gateway)として実装し、いつでも新しいバージョンのApache APISIXにアップグレードできるようにしました**。これにより、AirwallexのコードライブラリとApache APISIXのメインリポジトリのコアコードとの間に競合条件が発生しません。ただし、コアコードを変更する必要がある場合もあります。その場合、李はできるだけオープンソースコミュニティでこれらの機能を実装しようとします。**コミュニティの貢献者は機能の実装について熱心に議論し、ほとんどの場合、すぐに利用可能なソリューションを提供できます。**

## AirwallexがAPISIXを使用することで得られるメリット

以下は、AirwallexがAPISIXと統合した図です。

![Integration Diagram of Airwallex and APISIX](https://static.api7.ai/uploads/2023/01/31/Q0LbIb0E_88.webp)

AirwallexはApache APISIXをマイクロサービスゲートウェイモデルのコアコンポーネントとして採用しています。ネットワークのエッジにデプロイされ、Airwallexに入るすべてのトラフィックに対して一般的なゲートウェイ機能を提供します。解決する問題は以下の通りです。

- **データ主権**: 国境を越えて運営される金融インフラストラクチャにとって、データ主権は重要な規制要件です。このため、**AirwallexはApache APISIXの動的上流選択機能を活用して、規制に準拠した動的ルーティングプラグインを開発しました**。動的ルーティングは、ユーザーリクエストの特性に応じて上流をインテリジェントに選択し、複数のデータセンター間の協調問題をサービス層からゲートウェイ層に抽象化します。動的ルーティングの本質は、上流をどのようにグループ化するか、およびリクエストとグループをどのようにマッチングするかという2つの質問に答えることです。

- **マイクロサービス内の分離**: Airwallexは、各マイクロサービスのエンジニアリングチームが独自のサービスを独立して制御できることを望んでおり、コミュニケーションと調整のコストを効果的に削減し、エンジニアリング効率を向上させます。このアーキテクチャの概念では、APIゲートウェイなどのさまざまなチームが共有するインフラストラクチャコンポーネントがテナント分離をサポートできる必要があります。**APISIXはテナント分離を満たすのに最適です。**システム全体の堅牢性とコスト管理を確保しながら、APISIXはビジネスチームが独自のニーズに応じてゲートウェイ機能を設定および拡張できるようにし、マイクロサービスチームとサービスの独立性を維持します。

- **マルチテナントのレートリミット**: マルチテナント環境では、各テナントのトラフィック特性が異なります。異なるテナントに同じレートリミットを適用することは、商業的なニーズを満たすことができません。**マルチテナントの[レートリミット](https://api7.ai/blog/rate-limiting-in-api-management)は、ユーザー特性に基づいてより適切に行うことができます。**

- **マルチテナントのIPホワイトリスト**: マルチテナント環境では、各テナントのアクセスIPが異なります。**マルチテナントのIPホワイトリストにより、各テナントは他のユーザーが自分のリソースに侵入することを心配することなく、独自のホワイトリストを制御できます。**

- **認証**: 頻繁なキー更新は、ユーザーリソースの安全性を確保するための重要なリンクです。**APISIXはリクエストの[認証](https://api7.ai/blog/understanding-microservices-authentication-services)だけでなく、動的なキー更新もサポートしています。**

- **認可**: 企業アプリケーションの権限管理は非常に複雑で、異なるアプリケーションシナリオでは完全に異なる権限管理モデルがあります。**APISIXはルーティング設定に基づいて、リクエストユーザーがインターフェースにアクセスするための十分な権限を持っているかどうかを検証し、不正なトラフィックを最初に遮断できます。**

Airwallexの本番環境は**15ヶ月間**稼働しており、全体的なパフォーマンスは非常に安定しています。動的ルーティング、マルチテナントのレートリミット、マルチテナントのIPホワイトリスト、認証、認可などの機能が有効な状態で、**99%の応答遅延が23ミリ秒以内に収まります**。

**Apache APISIXの優れたプラグインメカニズムのおかげで、Airwallexはコアコードを変更することなく、ビジネスニーズに合ったプライベートプラグインを追加できます。**完全なテストシステムはソフトウェア品質をさらに保証し、元のコアロジックを損なうことなくプラグインの個別要件を安全に増やすことができます。

## 今後の計画

Airwallexの今後の計画は主に以下の3つの側面を含みます。

1. マルチレイヤーネットワークを使用して、ゲートウェイロジックを異なるレイヤーに分割し、データ主権やその他のゲートウェイロジックに基づいてトラフィックを分散します。

2. 読みやすく使いやすいルーティング管理は、APIゲートウェイの成功にとって重要です。ルーティング管理は開発者にとってフレンドリーである必要があり、開発者がゲートウェイが何を提供できるか、どのように設定および公開するかを簡単に理解できるようにする必要があります。

3. カラーコードリクエストを使用して、本番環境テストを実装します。APIゲートウェイのカラーコードリクエストを使用して本番環境テストを実装することで、より多くの柔軟性と使いやすさをもたらすことができます。

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

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

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

今すぐお問い合わせください: [https://api7.ai/contact](https://api7.ai/contact).

インタビュー対象者についての詳細:

![Yang Li, Airwallex](https://static.api7.ai/uploads/2023/01/31/uGbiZnt5_Airwallex2.webp)


Airwallex resolves technical challenges that data sovereignty brings and makes intelligent routing solutions with the help of Apache APISIX.

What is Apache APISIX?

Why Apache APISIX?

APISIX vs alternatives

To Maximize APISIX, You Need API7

Case Studies

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

vivo 如何与 APISIX 集成

Airwallex 如何利用 Apache APISIX 赋能全球支付？

Looking for Apache APISIX Support?