DevOps: Реализуем итеративный подход к внедрению смешанной стратегии непрерывного развертывания

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

Всем привет! Меня зовут Дмитрий Гаманенко, я DevOps Engineer в Techstack. Более шести лет я работаю DevOps-практиками, и одной из немаловажных моих задач является выбор и реализация непрерывной стратегии развертывания.

В этой статье предлагаю поговорить о классических стратегиях развертывания, их комбинировании и итеративной реализации. Здесь вы не найдете примеров кода и отсылок к конкретным клауд-провайдерам по двум причинам: во-первых, все нижесказанное может быть применено для любого окружения, во-вторых, хотелось бы, чтобы эта статья была полезна не только тем, кто занят в DevOps направлении, а всей команде разработки.

Выбор стратегии непрерывного развертывания

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

К большому сожалению, зачастую выбор стратегии ограничивается либо же выделенным временем на реализацию, либо же бюджетом на инфраструктуру. Даже если по прошествии времени появляется возможность улучшить то, что уже давно реализовано, сделать это достаточно сложно, если заранее не продумать весь путь «идеального» пайплайна.

Говоря о best practices, выделяют следующий набор стратегий:

  • Recreate: Версия v1.0 терминируется, затем выкатывается версия v1.1.
  • Ramped (также известная как rolling-update или incremental): Версия v1.1 постепенно разворачивается и заменяет версию v1.0.
  • Blue/Green: Версия v1.1 релизится параллельно с версией v1.0, затем трафик переключается на версию v1.1.
  • Canary: Версия v1.1 релизится для подмножества пользователей, затем происходит полное развертывание.
  • A/B testing: Версия v1.1 релизится для подмножества пользователей при определенных условиях.
  • Shadow: версия v1.1 получает реальный трафик наряду с версией v1.0 и не аффектит на респонс.

Рассмотрим каждую стратегию подробнее.

Recreate

Стратегия представляет собой фиктивное развертывание, которое заключается в отключении версии v1.0, а затем развертывании версии v1.1 после отключения версии v1.0. Эта стратегия подразумевает время простоя сервиса, которое зависит от продолжительности остановки и загрузки приложения.

Плюсы:

  • Простота настройки.
  • Состояние приложения полностью обновлено.

Минус:

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

Подход имеет право на жизнь в пре-production окружениях. На боевом же production-окружении выбор стратегии чреват простоем.

Ramped

Стратегия постепенного развертывания заключается в медленном развертывании версии приложения путем замены экземпляров один за другим, пока не будут развернуты все экземпляры. Обычно это происходит следующим образом: с пулом версии v1.0 за балансировщиком нагрузки развертывается один (или же несколько) экземпляр версии v1.1. Когда сервис готов к приему трафика, экземпляр добавляется в пул. Затем один экземпляр версии v1.0 удаляется из пула и отключается.

В зависимости от системы, обеспечивающей постепенное развертывание, можно изменить следующие параметры, чтобы увеличить время развертывания:

  • Параллелизм, максимальный размер пакета: количество параллельных экземпляров для развертывания.
  • Max surge: количество экземпляров, которое нужно добавить в дополнение к текущему количеству.
  • Max unavailable: Количество недоступных экземпляров во время процедуры скользящего обновления.

Плюсы:

  • Легко настраивается.
  • Версии медленно распространяются по всем экземплярам.
  • Удобно для приложений с состоянием, которые могут обрабатывать перебалансировку данных.

Минусы:

  • Откат может занимать время.
  • Поддержка нескольких API затруднена.
  • Отсутствие контроля над трафиком.

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

Blue/Green

Стратегия развертывания Blue/Green отличается от постепенного развертывания: версия v1.1 (green) развертывается вместе с версией v1.0 (blue) с тем же количеством экземпляров. После проверки соответствия новой версии всем требованиям, трафик переключается с версии v1.0 на версию v1.1 на уровне балансировщика нагрузки.

Плюсы:

  • Мгновенный откат.
  • Отсутствие необходимости проверки версий: все состояние приложения изменяется за один раз.

Минусы:

  • Дороговизна: требует удвоения ресурсов.
  • Перед выпуском в production необходимо провести надлежащее тестирование всей платформы.
  • Работа с приложениями с измененным состоянием может быть сложной.

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

Canary

Канареечное развертывание заключается в постепенном переводе production-трафика с версии v1.0 на версию v1.1. Обычно балансировка трафика происходит на основании «веса». Например, 90 процентов запросов идет на версию v1.0, 10 процентов — на версию v1.1.

Плюсы:

  • Версия выпускается для подмножества пользователей.
  • Удобно для мониторинга частоты ошибок и производительности.
  • Быстрый откат.

Минус:

  • Медленное развертывание.

Стратегия особенно хороша, когда покрытие тестами не полное. Вы, по сути, ограничиваете аудиторию, которую аффектит неудачный релиз до того, как будет выполнен откат версии.

A/B testing

Развертывание A/B-тестирования заключается в направлении подмножества пользователей к новой функциональности при определенных условиях. Обычно это стратегия принятия бизнес-решений на основе статистики, а не стратегия развертывания. Однако она может быть реализована путем добавления дополнительной функциональности к Canary, поэтому мы кратко обсудим ее здесь.

Стратегия широко используется для тестирования конверсии определенной функции и развертывания только той версии, которая конвертирует больше всего.

Список условий, которые можно использовать для распределения трафика между версиями:

  • Cookie браузера.
  • Параметры запроса.
  • Геолокализация.
  • Технический стэк: версия браузера, размер экрана, операционная система и т.д.
  • Язык.

Плюсы:

  • Несколько версий работают параллельно.
  • Полный контроль над распределением трафика.

Минусы:

  • Требуется интеллектуальный балансировщик нагрузки.
  • Сложно устранять ошибки для конкретной сессии, распределенная трассировка становится обязательной.

Shadow

Теневое развертывание заключается в выпуске версии v1.1 наряду с версией v1.0, перехвате входящих запросов версии v1.0 и отправке их на версию v1.1 без влияния на трафик. Это особенно полезно для тестирования production нагрузки на новую функцию. Развертывание приложения начинается, когда стабильность и производительность соответствуют требованиям.

Эта техника довольно сложна в настройке и требует особых требований, особенно в отношении исходящего трафика.

Плюсы:

  • Тестирование производительности приложения с production-трафиком.
  • Отсутствие влияния на пользователя.
  • Отсутствие развертывания до тех пор, пока стабильность и производительность приложения не будут соответствовать требованиям.

Минусы:

  • Дороговизна: требует удвоения ресурсов.
  • Не является настоящим пользовательским тестированием и может вводить в заблуждение.
  • Сложность в настройке.
  • Для некоторых случаев требуется mocking.

Комбинирование стратегий

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

Ramped + Blue/Green

Тут все просто. Совместив эти стратегии, получаем постепенное развертывание и возможность мгновенного отката.

Positive flow:

Negative flow:

Ramped + Blue/Green + Canary

Добавление Canary в наш пайплайн позволит принять решение об откате на предыдущую версию на основании ошибок, которые успели зааффектить только часть наших пользователей.

Positive flow:

Negative flow:

Ramped + Blue/Green + Canary + Shadow

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

Shadow-стратегия сложна и требует дополнительной работы по имитации исходящего трафика. Тем не менее, эта техника может быть полезна при переходе на новую технологию баз данных и использования теневого трафика для мониторинга производительности системы под нагрузкой.

Ramped + Blue/Green + Canary + Shadow + A/B testing

Допустим, параллельно разрабатываемая версия приложения частично готова к тестированию, например, только для пользователей мобильных приложений. В этом случае может возникнуть необходимость тестирования нового функционала, не изменяя текущих production версий. Добавив A/B testing к предыдущему варианту, получим вполне боевой вариант.

Понимая базовые стратегии развертывания, являющиеся на данный момент best practice, вы ограничены только полетом фантазии в рамках требований к процессу развертывания, а значит, комбинаций может быть намного больше.

Подведем итоги

Существует несколько способов развертывания новой версии приложения. Зачастую выбор стратегии зависит от потребностей приложения и бюджета.

Хорошим стартом для построения пайплайна будет Ramped или Blue/Green, но при этом необходимо проводить надлежащее тестирование новой платформы.

В свою очередь, Blue/Green и Shadow оказывают большую нагрузку на бюджет, поскольку требуют удвоения мощностей. Если приложению не хватает тестов, или если нет уверенности в стабильности, то можно использовать Canary, A/B testing или Shadow. Если ваш бизнес требует тестирования новой функции среди определенного пула пользователей, которые могут быть отфильтрованы в зависимости от параметров, таких как геолокация, язык, операционная система или особенности браузера, тогда вы можете использовать A/B testing.

При этом комбинирование стратегий позволяет использовать преимущества каждой из них и идти в сторону «идеального» пайплайна, а итеративный подход к расширению снижает вероятность ошибок в его построении.

DevOps: Реализуем итеративный подход внедрения комбинируемой стратегии непрерывного развертывания

👍НравитсяПонравилось13
В избранноеВ избранном8
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

Blue/Green

вот только описание и картинка на самом деле от red-black deployment

In blue-green deployment, both versions may be getting requests at the same time temporarily, while in red-black only one of the versions is getting traffic at any point in time

соответственно и картинка с canary из крошечной канарейки (на которой просто проверяют — сдохнет она или нет) внезапно превращается в полноценный blue-green

Да, согласен — есть отдельный холивар о blue/green и red/black, подмечено верно. Вот только я не встречал на практике, может конечно просто просто не сложилось, боевого сетапа blue/green с подходом both versions may be getting requests at the same time temporarily. Зачастую blue/green применяют именно как red/black и просто говорят что это одно и то же. Если же мы хотим явно указать на эту разницу, то нужно заметить что canary, всё же, делает акцент именно на процентное отношение в распределении трафика (хотя, опять же, тут тоже нет предела фантазии).

canary, всё же, делает акцент именно на процентное отношение в распределении трафика

canary делает акцент на судьбе канарейки
а % должен исходить не от предела фантазии, а от SLA — чтобы возможная смерть канарейки, ограничилась только ей и не затронула всю смену шахтеров

Подписаться на комментарии