Как Zoom использует APISIX Ingress в своем конвейере непрерывной поставки?

Предыстория

В последние годы с развитием онлайн-встреч и удаленной работы появилось множество известных программ для проведения онлайн-конференций. Типичным примером является Zoom, который стал популярным инструментом для домашнего офиса, онлайн-обучения и социальных сценариев. Ежедневно в Zoom участвует 350 миллионов человек, а количество платных бизнес-клиентов, использующих платформу, составляет почти 470 000. Более того, последние данные показывают, что количество минут, используемых для проведения встреч, достигло более 3,3 триллионов в год.

Однако, как и другие SaaS-компании и интернет-компании, Zoom столкнулась с техническими вызовами по мере быстрого расширения своего бизнеса.

• Большое количество микросервисов: Из-за быстрого роста бизнеса и команд Zoom необходимо предоставлять более 100 бэкенд-сервисов. Однако управлять большим количеством микросервисов эффективно сложно.

• Различные среды развертывания: SaaS-компании часто сталкиваются с ситуациями, когда клиенты должны развертывать свои решения на выделенных облаках, частных облаках и мультиоблаках. Услуги Zoom охватывают весь мир, поэтому возникают технические сложности с большим количеством гибридных облачных сред.

• Сложная инфраструктура: Средние и крупные интернет-компании обычно имеют специализированные команды по инфраструктуре, отвечающие за API-шлюзы, центры конфигурации, управление ключами, логи, мониторинг, базы данных и т.д. Поскольку управляющие команды Zoom распределены по всему миру, интеграция этих сложных промежуточных программ и инфраструктуры в конвейер непрерывной поставки представляет собой большую проблему.

Вышеупомянутые вызовы не являются простой аддитивной зависимостью, а скорее мультипликативной. Другими словами, реальная ситуация гораздо сложнее. Однако инструменты с открытым исходным кодом, которые Zoom использовала ранее, больше не соответствуют текущим требованиям компании. Именно поэтому надежный конвейер непрерывной поставки так важен.

Ниже приведены подробные причины, по которым Zoom не продолжила использовать эти инструменты с открытым исходным кодом.

Из-за ограничений вышеупомянутых инструментов с открытым исходным кодом Zoom в конечном итоге исследовала некоторые основные решения для построения базового конвейера непрерывной поставки.

После нескольких раундов сравнения и проверки Zoom в конечном итоге выбрала APISIX Ingress Controller для поддержки своего нового конвейера непрерывной поставки.

Apache APISIX Ingress Controller

Что такое Apache APISIX Ingress Controller?

Apache APISIX Ingress Controller — это облачный контроллер входящего трафика, который использует Apache APISIX в качестве плоскости данных для обработки трафика и расширяет функциональность Kubernetes с помощью CRD (CustomResourceDefinition). Он отвечает за взаимодействие с API-сервером Kubernetes, применение контроля доступа на основе ролей (RBAC), мониторинг изменений, реализацию преобразования объектов внутри контроллера Ingress, сравнение изменений и их синхронизацию с Apache APISIX. Кроме того, он поддерживает пользовательские ресурсы, включая APISIX Route, APISIX Upstream и другие нативные Ingress-ресурсы Kubernetes, для управления внешним трафиком, обращающимся к сервисам, развернутым в Kubernetes.

Ниже приведена Диаграмма времени работы APISIX Ingress Controller.

Почему Zoom выбрала APISIX Ingress Controller?

С учетом вышеупомянутой предыстории возникает вопрос: какой конвейер непрерывной поставки хочет построить Zoom и как она использует APISIX Ingress для создания базового конвейера непрерывной поставки?

Ранее Zoom использовала NGINX в качестве API-шлюза. Однако с быстрым развитием бизнеса и увеличением количества микросервисов ограничения текущего решения на основе NGINX становятся все более очевидными.

Различные команды должны поддерживать NGINX отдельно, а тысячи строк конфигурационных файлов NGINX затрудняют поддержку. Кроме того, NGINX не может быстро масштабироваться при развертывании большого количества строк на облачном сервере. О режиме перезагрузки NGINX можно узнать в этом блоге. Бизнес Zoom начал эволюционировать в сторону Ingress Controller.

Команда API Gateway исследовала некоторые решения с открытым исходным кодом. После моделирования миграции и анализа фактической бизнес-конфигурации в NGINX и множества тестов производительности и сравнения экосистем плагинов Zoom в конечном итоге выбрала проект APISIX Ingress Controller Apache Software Foundation, исследуя более продвинутый облачный шлюз.

Учитывая свои бизнес-сценарии, Zoom уделила больше внимания двум аспектам, которые могут быть удовлетворены 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 демонстрирует устойчивость и стабильность в своей производительности, используясь во многих крупномасштабных сценариях трафика предприятий.

• Активное сообщество: Как проект с открытым исходным кодом, являющийся топовым и наиболее активным, Apache APISIX обладает активным сообществом и демонстрирует отличные темпы роста с первого дня.

• Богатая экосистема: Apache APISIX поддерживает протоколы уровня L7, включая HTTP(S), HTTP2, Dubbo, IoT-протокол MQTT и т.д. Кроме того, APISIX поддерживает протоколы уровня L4, такие как TCP/UDP. Также в Apache APISIX 3.0 добавлена полная поддержка ARM64.

• Множество плагинов: Официально выпущено почти 100 плагинов APISIX, которые пользователи могут использовать простым перетаскиванием. Горячая перезагрузка и динамическая оркестрация плагинов предоставляют пользователям большое удобство.

Кроме того, 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 Gateway столкнулась с новой задачей: как перенести исходную конфигурацию API-шлюза для сотен сервисов в APISIX Ingress? Команда инфраструктуры Zoom разрабатывала конвейер непрерывной поставки, который может значительно снизить затраты на миграцию при преобразовании из nginx.conf и других конфигураций Ingress в APISIX Ingress.

Процесс и функции построения конвейера непрерывной поставки

Конвейер непрерывной поставки Zoom

Конвейер непрерывной поставки — это сквозная система доставки приложений, которая реализует единую модель для объявления всех требований к доставке приложений и организации и выполнения всех шагов непрерывной поставки в одной линии.

Конвейер непрерывной поставки состоит из шести частей:

1. Подготовка: подготовка предустановленных ресурсов, включая инфраструктуру, промежуточное программное обеспечение, облачные сервисы и т.д.;

2. Конфигурация: подготовка конфигурационных файлов и ключей, необходимых для приложения;

3. Развертывание: использование K8s для развертывания в облачных сценариях (включая информацию о контейнерах, образах контейнеров, параметрах, версиях и экземплярах);

4. Доступ: создание Kubernetes Service и автоматическая настройка правил маршрутизации Apache APISIX Ingress, если развертывание требует внешнего доступа;

5. Наблюдение: выполнение конфигураций, связанных с наблюдаемостью, таких как мониторинг, оповещения, логирование и анализ трассировки;

6. Масштабирование: объявление динамических правил масштабирования KEDA (Kubernetes Event-driven Autoscaling) через метрики мониторинга.

Как использовать APISIX Ingress в конвейере

Управление проектами

Руководители проектов больше внимания уделяют итерациям разработки и тому, как лучше управлять прогрессом выпуска итераций и эффективностью персонала на временной шкале, соответствующей итерациям. Zoom использует рабочий процесс GitOps внутри компании для интеграции конфигурации API Gateway в модель доставки приложений. В этой модели определение правил маршрутизации APISIX интегрировано с этапом "Развертывание" и другими этапами, передавая управление изменениями в GitHub. С созданием и слиянием веток GitHub конвейер обеспечивает согласованность временных линий между выпуском и откатом конфигураций приложений и шлюзов.

# Фрагмент кода конвейера CD Zoom в репозитории 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 и рабочего процесса конвейера непрерывной поставки предоставляет разработчикам более удобный способ работы.

Управление окружениями

Сложные требования к управлению и контролю окружений часто возникают в сценариях B2B, и необходимо учитывать вопросы доставки в некоторых сценариях частных, выделенных и гибридных облаков.

Некоторые конфигурации APISIX Ingress были реализованы для удовлетворения требований по скрытию различий в окружениях. Таким образом, системные администраторы могут полностью контролировать различия в некоторых гетерогенных окружениях. Все сервисы, развернутые в окружении, эффективны, что позволяет избежать когнитивной нагрузки и специальных операций развертывания, вызванных различиями в окружениях для разработчиков приложений и операторов. Например, Zoom может использовать пользовательские конфигурации для отключения трассировки в некоторых окружениях, преобразования объектов ApisixRoute в нативные объекты Ingress и аннотации NGINX Ingress, а также использования различных образов для извлечения секретов.

Кроме того, требуется многопользовательская изоляция, когда несколько линий бизнеса используют окружение APISIX. APISIX Ingress предоставляет селектор аннотаций, который позволяет различным объектам ApisixRoute выбираться разными экземплярами APISIX Ingress Controller.

Управление инфраструктурой

Команде API Gateway необходимо контролировать все экземпляры APISIX, полностью настраивать политики безопасности, реализовывать мультизональность и т.д.

Каждый плагин конвейера предоставляет элементы конфигурации для инженеров инфраструктуры. В плагине ingress-apisix есть свойство defaultPlugins.

После настройки этого свойства командой API Gateway, настройка будет применяться ко всем сервисам, что подходит для единой стратегии безопасности и управления рисками.

Заключение

APISIX Ingress Controller играет важную роль в конвейере непрерывной поставки Zoom, снимая нагрузку с управления проектами, разработки приложений, управления окружениями, а также управления промежуточным программным обеспечением и инфраструктурой. Пример Zoom заслуживает изучения другими компаниями, и мы надеемся, что APISIX Ingress Controller внесет вклад в инновации большего числа компаний.

Кроме того, Apache APISIX Ingress официально выпустила версию V1.5 в августе 2022 года, которая унифицирует предложение всех ресурсов API Versions и обновляет все CRD API Versions до V2. В то же время она поддерживает большинство ресурсов Gateway API. Apache APISIX Ingress позволила ресурсам Ingress использовать произвольные плагины APISIX, добавив новую аннотацию “k8s.apisix.apache.org/plugin-config-name” к ресурсам Ingress. Это значительно повысит удобство использования APISIX Ingress Controller и снизит затраты для пользователей на миграцию с других контроллеров Ingress на APISIX Ingress Controller.

Для получения дополнительной информации, пожалуйста, ознакомьтесь с Apache APISIX Ingress V1.5.