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

背景

近年、オンライン会議やリモートワークの発展に伴い、多くの有名なオンライン会議ソフトウェアが登場しました。その代表的なものとして、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は、Apache APISIXをデータプレーンとしてトラフィックを運び、Kubernetesの機能をCRD（CustomResourceDefinition）を使用して拡張するクラウドネイティブなIngressコントローラーです。Kubernetes APIサーバーとのやり取り、ロールベースのアクセス制御（RBAC）の適用、変更の監視、Ingressコントローラー内でのオブジェクト変換の実装、変更の比較、そしてApache APISIXへの同期を担当します。さらに、APISIX Route、APISIX Upstream、およびKubernetesのネイティブIngressを含むカスタムリソースをサポートし、Kubernetesにデプロイされたサービスに外部トラフィックがアクセスするのを制御します。

以下はAPISIX Ingress Controllerのタイミング図です。

APISIX Ingressのタイミング図

ZoomがAPISIX Ingress Controllerを選んだ理由

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

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

異なるチームが個別にNGINXを保守する必要があり、数千行のNGINX設定ファイルが保守を困難にしています。さらに、NGINXはクラウドサーバー上で多数の行をデプロイする際に迅速にスケールできません。NGINXのリロードモードについては、このブログを参照してください。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はそのパフォーマンスにおいて弾力的で安定しており、多くの企業の大規模トラフィックシナリオで使用されています。
活発なコミュニティ: トップレベルで最も活発なオープンソース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アーキテクチャ

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

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

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

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

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

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

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

準備: インフラストラクチャ、ミドルウェア、クラウドサービスリソースなどの事前設定リソースを準備します。
設定: アプリケーションに必要な設定ファイルとキーを準備します。
デプロイ: クラウドネイティブシナリオでK8sを使用してデプロイします（コンテナ、コンテナイメージ、パラメータ、バージョン、インスタンスに関する情報を含む）。
アクセス: Kubernetes Serviceを作成し、デプロイが外部アクセスを必要とする場合、Apache APISIX Ingressのルーティングルールを自動的に設定します。
監視: 監視、アラーム、ログ、トレース分析などの監視関連の設定を実行します。
スケーリング: 監視メトリクスを通じてKEDA（Kubernetes Event-driven Autoscaling）の動的スケーリングルールを宣言します。

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

Zoomのパイプラインアーキテクチャ概要

プロジェクト管理

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

# 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をご覧ください。