DevOps: Реализуем итеративный подход к внедрению смешанной стратегии непрерывного развертывания
Усі статті, обговорення, новини про DevOps — в одному місці. Підписуйтеся на DOU | DevOps!
Всем привет! Меня зовут Дмитрий Гаманенко, я 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: Реализуем итеративный подход внедрения комбинируемой стратегии непрерывного развертывания
4 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів