Стратегии выпуска API с использованием API Gateway
December 22, 2022
После того как вы успешно разделили развертывание и выпуск, следующим шагом является выбор механизмов для управления постепенным выпуском функций. Важно выбрать стратегию выпуска, которая позволит вам снизить риски в производственной среде. Независимо от того, насколько тщательно вы тестируете новую версию вашего API перед выпуском, реальное тестирование происходит, когда вы, наконец, предоставляете его клиентам.
Мы можем снизить этот риск, выполнив тест или эксперимент с небольшой частью трафика и проверив результат. Если результат успешен, выпуск для всего трафика активируется. Определенные стратегии лучше подходят для конкретных сценариев и требуют различных уровней дополнительных сервисов и инфраструктуры. В этой статье мы рассмотрим 3 популярные стратегии выпуска API, которые используют API Gateway в настоящее время.
Зачем использовать API Gateway в развертывании API
Одним из преимуществ перехода на архитектуру, основанную на API, является возможность быстро итерировать и развертывать новые изменения в наших сервисах. Мы также имеем концепцию трафика и маршрутизации, установленную с помощью API Gateway для модернизированной части архитектуры. API Gateway предоставляет этапы, позволяющие иметь несколько развернутых API за одним шлюзом, и он способен выполнять обновления на месте без простоев. Использование API Gateway позволяет вам использовать множество функций управления API, таких как аутентификация, ограничение скорости, наблюдаемость (важные метрики для API), множественное версионирование API и управление этапами развертывания (развертывание API на нескольких этапах, таких как dev, test, stage и prod).
Открытые решения API Gateway (Apache APISIX и Traefik), Service Mesh (Istio и Linkerd) способны выполнять разделение трафика и реализовывать функции, такие как Canary Release и Blue-Green развертывание. С помощью канареечного тестирования вы можете критически оценить новый выпуск API, выбрав только небольшую часть вашей пользовательской базы. Мы рассмотрим канареечный выпуск в следующем разделе.
Канареечный выпуск
Канареечный выпуск представляет новую версию API и направляет небольшой процент трафика на канареечную версию. В API Gateway разделение трафика позволяет постепенно переносить или мигрировать трафик с одной версии целевого сервиса на другую. Например, новая версия v1.1 сервиса может быть развернута вместе с оригинальной версией v1.0. Переключение трафика позволяет вам тестировать или выпускать ваш новый сервис, сначала направляя только небольшой процент пользовательского трафика, скажем 1%, на v1.1, а затем постепенно перенося весь трафик на новый сервис.
Это позволяет вам отслеживать новый сервис, искать технические проблемы, такие как увеличение задержек или частоты ошибок, а также искать желаемый бизнес-эффект, такой как увеличение ключевых показателей эффективности, таких как коэффициент конверсии клиентов или средняя стоимость покупки. Разделение трафика позволяет вам проводить A/B или многовариантные тесты, разделяя трафик, предназначенный для целевого сервиса, между несколькими версиями сервиса. Например, вы можете разделить трафик 50/50 между вашими версиями v1.0 и v1.1 целевого сервиса и посмотреть, какая из них работает лучше за определенный период времени. Узнайте больше о функции разделения трафика в Apache APISIX Ingress Controller.
Там, где это уместно, канареечные выпуски являются отличным вариантом, так как процент трафика, подвергаемого канареечной версии, строго контролируется. Компромисс заключается в том, что система должна иметь хорошее мониторинг, чтобы быстро выявить проблему и откатиться при необходимости (что может быть автоматизировано). Это руководство показывает, как использовать Apache APISIX и Flagger для быстрой реализации решения канареечного выпуска.
Зеркалирование трафика
В дополнение к использованию разделения трафика для проведения экспериментов, вы также можете использовать зеркалирование трафика для копирования или дублирования трафика и отправки его в дополнительное место или серию мест. Часто при зеркалировании трафика результаты дублированных запросов не возвращаются вызывающему сервису или конечному пользователю. Вместо этого ответы оцениваются вне основного потока на предмет корректности, например, сравниваются результаты, сгенерированные рефакторингованным и существующим сервисом, или наблюдаются определенные операционные свойства, такие как задержка ответа или использование CPU, когда новая версия сервиса обрабатывает запрос.
Использование зеркалирования трафика позволяет вам "темно выпускать" сервисы, где пользователь остается в неведении о новом выпуске, но вы можете наблюдать за требуемым эффектом внутри.
Реализация зеркалирования трафика на краю систем становится все более популярной с годами. APISIX предлагает плагин proxy-mirror для зеркалирования клиентских запросов. Он дублирует реальный онлайн-трафик на зеркальный сервис и позволяет проводить специфический анализ онлайн-трафика или содержимого запросов без прерывания онлайн-сервиса.
Blue-Green
Blue-green обычно реализуется в точке архитектуры, где используется маршрутизатор, шлюз или балансировщик нагрузки, за которым находится полная синяя среда и зеленая среда. Текущая синяя среда представляет текущую рабочую среду, а зеленая среда представляет следующую версию стека. Зеленая среда проверяется перед переключением на рабочий трафик, и при запуске трафик переключается с синей на зеленую среду. Синяя среда теперь "выключена", но если обнаруживается проблема, это быстрый откат. Следующее изменение будет происходить с зеленой на синюю среду, чередуясь с первого выпуска.
Blue-green хорошо работает благодаря своей простоте и является одним из лучших вариантов развертывания для связанных сервисов. Также легче управлять постоянными сервисами, хотя вам все равно нужно быть осторожным в случае отката. Это также требует удвоения количества ресурсов для возможности работы в холодном режиме параллельно с текущей активной средой.
Управление трафиком с Argo Rollouts
Обсужденные стратегии добавляют много ценности, но сам процесс выпуска — это задача, которую вы не захотите управлять вручную. Здесь инструмент, такой как Argo Rollouts, ценен для практической демонстрации некоторых из обсуждаемых проблем.
Используя Argo, можно определить Rollout CRD (Custom Resource Definition), который представляет стратегию, которую вы можете использовать для выпуска нового канареечного API. CRD позволяет Argo расширять Kubernetes API для поддержки поведения выпуска. CRD — это популярный шаблон с Kubernetes, и он позволяет пользователю взаимодействовать с одним API с расширением для поддержки различных функций.
Вы можете использовать Apache APISIX и Apache APISIX Ingress Controller для управления трафиком с Argo Rollouts. Это руководство показывает, как интегрировать ApisixRoute с Argo Rollouts, используя его как взвешенный балансировщик нагрузки с циклическим перебором.
Итог
С ростом подхода Progressive Delivery, а также с более продвинутыми требованиями в рамках Continuous Delivery до этого, возможность разделения развертывания и выпуска сервиса (и соответствующего API) является мощной техникой. Возможность канареечного выпуска сервисов и использование функций разделения и зеркалирования трафика API Gateway может предоставить вашему бизнесу конкурентное преимущество как в снижении рисков неудачного выпуска, так и в более эффективном понимании требований ваших клиентов.