Blue/Green Deployment: когда нужен мгновенный переключатель и мгновенный откат
Представьте: ваша команда только что закончила масштабный редизайн главной страницы. Или, возможно, вы заменили ключевую библиотеку, от которой зависит всё приложение. Такие изменения сложно идеально протестировать на стейджинге — данные и поведение пользователей в проде никогда не совпадают с тестовыми. Можно попробовать rolling update, но если что-то пойдёт не так, половина пользователей увидит сломанную версию, а вторая половина — старую. А откат? Придётся ждать, пока каждый инстанс переключится обратно один за другим. Это не мгновенно.
Здесь на помощь приходит blue/green deployment. Он решает конкретную задачу: как переключить всех пользователей на новую версию сразу и как так же быстро вернуть их обратно, если что-то пошло не так.
Два идентичных окружения, одно активно в каждый момент
Идея проста. Вы поддерживаете два идентичных окружения. Назовём одно blue, другое green. Оба работают на одинаковой инфраструктуре, с одинаковой конфигурацией и одинаковой мощностью. Разница только в том, какое из них в данный момент обслуживает пользователей.
Давайте посмотрим, как это работает на практике.
Диаграмма ниже показывает два состояния и переходы между ними.
Допустим, ваши пользователи сейчас обращаются к blue-окружению, где работает версия 1 приложения. Green-окружение тоже запущено, но не принимает пользовательский трафик. Возможно, ваша команда использует его для внутреннего тестирования, или оно просто простаивает. Когда приходит время релизить версию 2, вы разворачиваете новую версию в green-окружении. Теперь на green — версия 2, а blue продолжает обслуживать пользователей версией 1.
На этом этапе вы можете протестировать версию 2 в окружении, идентичном продуктивному. Запустить health checks. Проверить функциональность. Попросить нескольких внутренних пользователей опробовать новую версию. Всё это происходит без влияния на реальных пользователей.
Как только вы убедились, что всё работает, вы выполняете cutover. Cutover — это переключение пользовательского трафика с blue на green. Вы можете обновить конфигурацию балансировщика нагрузки, изменить DNS-записи или перенастроить маршрутизацию в service mesh. За секунды все пользователи начинают работать с версией 2. Простоя нет, потому что green уже был запущен с тёплыми серверами, открытыми соединениями с базой данных и полностью инициализированным приложением.
Киллер-фича: мгновенный откат
Самое большое преимущество blue/green deployment — скорость отката. Если после переключения пользователей на версию 2 обнаружилась проблема, вы просто переключаете трафик обратно на blue. Пользователи мгновенно возвращаются на версию 1. Никакого ожидания переразвёртывания. Никакого повторного запуска пайплайна. Откат — это просто изменение маршрутизации.
Сравните с rolling update. Если нужно откатить rolling update, придётся обратить процесс инстанс за инстансом. Каждый требует времени на перезапуск и переподключение. В это время часть пользователей всё ещё может обращаться к сломанной версии. При blue/green старая версия всё ещё работает и готова обслуживать. Вы просто переключаете тумблер — и готово.
Компромисс по стоимости
У blue/green deployment есть очевидный недостаток: стоимость. Вам нужно одновременно запускать два полных окружения. Если ваша продуктивная нагрузка требует 10 серверов, blue/green означает, что во время переходного периода у вас работает 20 серверов. Вы платите за двойную мощность.
Некоторые команды снижают стоимость, уменьшая масштаб простаивающего окружения. Например, green может работать всего на 2 серверах, пока не обслуживает трафик, а затем масштабироваться до 10 серверов прямо перед cutover. Такой подход требует автоматизации масштабирования и всё равно дороже rolling update. Но для высокорисковых изменений эта цена может быть оправдана.
Когда использовать blue/green
Эта стратегия подходит для изменений с высоким риском, где откат должен быть мгновенным. Подумайте о:
- Масштабных редизайнах UI, влияющих на взаимодействие пользователей с продуктом
- Замене ключевых зависимостей или библиотек
- Изменениях схемы базы данных, которые сложно откатить
- Обновлениях, связанных с комплаенсом или регуляторными требованиями, где нужен чистый cutover
Но не каждое изменение требует двух полных окружений. Если вы разворачиваете небольшое исправление бага, которое тщательно протестировано, rolling update будет эффективнее и дешевле. Вопрос в том, какой уровень риска вы готовы принять и как быстро нужно восстановиться в случае проблем.
Практический чек-лист
Прежде чем внедрять blue/green deployment, убедитесь, что выполнены следующие условия:
- Идентичные окружения. Оба окружения должны работать на одинаковой инфраструктуре, конфигурации и мощности. Различия между ними сводят на нет всю идею.
- Stateless-приложения или приложения с внешним управлением сессиями. Если ваше приложение хранит данные сессии локально, пользователи потеряют сессии при cutover. Используйте внешние хранилища сессий, например Redis, или проектируйте приложение как stateless.
- Автоматизированный cutover. Ручное переключение чревато ошибками. Автоматизируйте переключение трафика, чтобы оно занимало секунды, а не минуты кликов.
- Health checks в новом окружении. Не разворачивайте и сразу не переключайте. Убедитесь, что новая версия проходит health checks, прежде чем направлять на неё трафик.
- Мониторинг во время и после cutover. Сразу после переключения следите за частотой ошибок, задержками и бизнес-метриками. Если что-то выглядит не так, откатывайте быстро.
Конкретный вывод
Blue/green deployment даёт возможность мгновенно переключить всех пользователей на новую версию и так же быстро вернуть их обратно. Цена — два работающих окружения, но выгода — страховочная сетка для высокорисковых изменений. Если ваша команда делает крупные релизы и вы беспокоитесь о времени восстановления, blue/green стоит вложений. Для небольших изменений используйте rolling update. Правильная стратегия зависит от риска, а не от того, какая звучит круче.