Blue-Green и Canary релизы

(Раздел: Архитектура и Протоколы)

1) Зачем нужны “безопасные выкаты”

В современных системах релиз — это не только доставка кода, но и управляемый эксперимент в проде: мы одновременно минимизируем риск (не ломаем пользователей) и сокращаем время обратной связи (быстро видим эффект). Две классические стратегии — Blue-Green и Canary — решают это по-разному, но с общей целью: нулевой даунтайм, быстрый откат, наблюдаемость по SLO.

2) Базовые определения

Blue-Green

Держим две полноценных копии прод-окружения: активная (Blue) обслуживает трафик, пассивная (Green) готовит новую версию. Переключение — атомарное (switch/flip) на уровне балансировщика/маршрутизатора. Если стало хуже — мгновенно возвращаемся к Blue.

Canary

Выкатываем частями: сначала малому % трафика (например, 1–5%), наблюдаем метрики/SLO, затем пошагово увеличиваем долю (10% → 25% → 50% → 100%). При деградации — откат или остановка на предыдущем стабильном шаге.

3) Когда какой подход лучше

• Нужен моментальный откат без сложных маневров.
• Архитектура/бюджет позволяет двойное инфраструктурное дублирование.
• Хотим провести масштабные миграции или обновления платформы (OS/JDK/рантайм) изолированно.
• Приложение/пулы соединений чувствительны к постепенному “смешанному” состоянию.

• Нужно минимизировать blast radius и видеть поведение на доле пользователей.
• Высокая частота релизов, прогрессивная доставка как норма.
• Есть зрелая наблюдаемость и автоматические гейты (error budget, latency, conversion).
• Продуктовая команда хочет проверять гипотезы: влияние на конверсию, удержание, LTV и т. п.

4) Общие принципы успешного релиза

Идемпотентные билд-артефакты: один и тот же образ/пакет на всех этапах.
Детерминированная конфигурация: конфиг как код, сравнимость окружений.
Наблюдаемость by design: логи, метрики, трассировки, алерты; SLI/SLO заранее.
Быстрый, автоматируемый откат: кнопка/команда отката — часть пайплайна, а не ручная магия.
Совместимые изменения схем: стратегия expand-migrate-contract (см. §10).
Маршрутизация на уровне L7 (желательно): гибкость по заголовкам/куки/путям/версиям API.

5) Blue-Green: архитектура и процесс

5.1 Топология

Два прод-стека: Blue (активный) и Green (кандидат).
Общие внешние зависимости: CDN, внешние API, очереди; БД — особый случай (см. §10).
Точка переключения: балансировщик/Ingress/Gateway.

5.2 Пошаговый флоу

1. Поднимаем Green под новым артефактом (vNext), проводим смок-тесты.
2. Прогон автотестов против Green (e2e, контрактные, регрессионные).
3. Прогреваем кэш/сессионы (если применимо), синхронизируем фоновые джобы/очереди.
4. Переключаем трафик на Green: атомарный flip (DNS TTL низкий, Route/Listener swap, Ingress weight=100%).
5. Наблюдаем SLO в первые минуты/часы (golden signals: latency, errors, saturation + бизнес-метрики).
6. При проблемах — мгновенный возврат на Blue (flip back).

5.3 Плюсы/минусы

Плюсы: мгновенный откат, простая ментальная модель, чистая изоляция.
Минусы: удвоение инфраструктуры, сложность с stateful компонентами и миграциями данных.

6) Canary: архитектура и процесс

6.1 Топология

Единый прод-кластер; несколько версий сервиса (stable и canary) за единым фронтом.
Трафик делится по весам (1–5–10–25–50–100%) или по таргетам (по заголовку/куке/ID).

6.2 Пошаговый флоу

1. Деплой canary-версии в тот же кластер/ASG/NSG.
2. Маршрутизация части трафика (например, 1–5%) на canary.
3. Автоматические проверки SLI/SLO и бизнес-метрик; гейты в CI/CD (error rate, p95 latency, CPU/RES, конверсия, отказ/возврат).
4. Пошаговое увеличение доли трафика при прохождении гейтов.
5. Полный rollout до 100% и деактивация старой версии; при деградации — авто-rollback.

6.3 Плюсы/минусы

Плюсы: минимальный риск для большинства пользователей, data-driven решение.
Минусы: нужна зрелая наблюдаемость, грамотная маршрутизация, риск “version skew” между инстансами.

7) Маршрутизация трафика

Уровень L4: баланс по IP/портам; просто, но мало гибкости.
Уровень L7: HTTP/S-правила — по пути, хосту, заголовку, кукам, User-Agent, GeoIP, SNI.

• Weighted routing (веса 1–100%).
• Header-based / Cookie-based (фиксация пользователя в группу).
• Session stickiness (важно для stateful/кешированных сценариев).
• Shadow/Traffic mirroring (зеркалируем запросы в новую версию “втихую”).

8) Инструменты и реализации (примеры)

Kubernetes: Ingress (NGINX, Contour), Service Mesh (Istio/Linkerd), Argo Rollouts, Flagger.
Облака: AWS ALB/ELB, Route 53 weighted records, ECS/EKS; GCP Load Balancing + NEG; Azure Front Door/App Gateway.
Платформы CD: Spinnaker, Argo CD, GitHub Actions + Progressive Delivery плагины, GitLab/CD.

9) Наблюдаемость, SLI/SLO и гейты

Golden signals: Latency (p95/p99), Error rate (5xx/4xx по типам), RPS, Saturation (CPU/Memory/GC), Queue lag.
Бизнес-метрики: конверсия, авторизации, платежи/успехи, средний чек, отказ по шагам воронки.

• Порог ошибки (например, error rate canary ≤ baseline + X%).
• Латентность p95 не хуже baseline более чем на Δ.
• Бизнес-порог (например, падение конверсии < Y%).
• Error budget по SLO не должен сгорать ускоренно.

Продолжительность шага: минимум время, достаточное для статистической значимости (зависит от трафика).

10) Миграции БД и совместимость схем

Главное правило: релизы безопасны, если версии назад и вперед совместимы.

1. Expand: добавляем новые столбцы/индексы/таблицы, не ломая старую версию.

2. Deploy app vNext (читает/пишет в новую схему, но умеет работать и со старой).

3. Migrate data (бэкграунд/батч, идемпотентно, с чекпоинтами).

4. Contract: удаляем старые поля/фичи после стабилизации.

Анти-паттерны: миграции, требующие эксклюзивной блокировки в момент переключения Blue-Green; невозможность даунгрейда схемы; “двойная запись” без дедупликации.

11) Откат (rollback) и планы аварий

Blue-Green: мгновенный flip на Blue; мониторим “хвосты” фоновых джобов Green.
Canary: откат веса (например, с 25% назад на 5% или 0%); автоматический abort при алертах.
Данные: продуманная политика повторов/компенсаций (idempotency keys, “inbox/outbox” паттерн, дедупликация сообщений).
Фичефлаги: быстрый kill switch для отключения частично выкатанных возможностей.

12) Работа со стейтом и сессиями

Sticky sessions для канареек, либо хранение сессий внешне (Redis/Memcached), чтобы версии были взаимозаменяемы.
Кэш прогревать заранее (Green warm-up) и учитывать invalidation при flip.
Фоновые воркеры: не допускайте “гонок” между версиями — разделение очередей или “лидерство” по версии.

13) Безопасность и соответствие

Доступ к Green/Canary — по Zero Trust: сервисные аккаунты, минимально необходимые роли.
Секреты и ключи — через KMS/Secrets Manager; включите ротацию.
Трафик — только TLS; версии endpoint’ов четко размечены; аудит маршрутизации и релизных действий.

14) Стоимость и производительность

Blue-Green удваивает инфраструктуру (на время релиза или постоянно) — закладывайте бюджет.
Canary экономнее, но требует инструментов наблюдаемости и инженерного времени на автоматизацию.
Оптимизация: автоскейлинг, ephemeral окружения, сокращение окна параллельного существования версий.

15) Чек-листы

Перед релизом

• Образ/билд промотирован из одного источника, подписи проверены.
• Тест-план, алерты и SLO-гейты настроены.
• Миграции БД — в режиме expand, доступны даунгрейд-планы.
• План отката — проверен в staging/production-like.

Во время релиза

• Метрики и логи сравниваются с baseline.
• Для Canary — шаги и пороги зафиксированы; для Blue-Green — готовность flip-back.
• Команды on-call в курсе, есть окно обратной связи.

После релиза

• SLO не просел, error budget в норме.
• Пост-релизные миграции/очистки завершены.
• Ретроспектива и обновление плейбуков.

16) Частые ошибки и анти-паттерны

Выкат без метрик: нет данных — нет управляемого решения.
Смешение несовместимых схем БД, отсутствие стратегии даунгрейда.
Случайное перемешивание трафика: нет stickiness, пользователи “прыгают” между версиями.
Скрытые stateful-зависимости (локальные диски, in-memory кэши).
Долгое DNS-TTL мешает быстрому flip (Blue-Green).
Отсутствие автогейтов: ручные “на глаз” решения тормозят и увеличивают риски.

17) Комбинированные подходы

Blue-Green + Canary: сначала выкатить Green, затем внутри Green раскатывать Canary для отдельных сервисов.
Shadow/мигрирующий трафик: перед Canary прогоняем зеркальный трафик в новую версию.
Feature flags (progressive delivery): функционал включается поверх стабильной версии “темными” флагами по сегментам.

18) Примеры сценариев (эскизы)

1. Разворачиваем Green (v2) за новым Listener/Ingress.

2. Прогреваем кэши, выполняем readonly-проверки, smoke.

3. Переключаем вес на Green = 100%.

4. Наблюдаем SLO 30–60 минут; если все ок — выключаем Blue.

1. Деплой canary vNext (реплики 5%).

2. Включаем трафик 5% для внутренних аккаунтов/тест-сегмента.

3. Автогейт: error rate ≤ baseline+0.3%, p95 ≤ +20ms.

4. Поднимаем 10% → 25% → 50% каждые N минут при прохождении гейтов.

5. На 100% переводим фичефлаг по всем сегментам; удаляем старую версию.

19) Вариации для разных архитектур

Монолит: Blue-Green проще, Canary сложнее из-за неделимости фич; используйте фичефлаги.
Микросервисы: Canary естественен; следите за межсервисными контрактами (consumer-driven contracts).
Stateful сервисы: предпочтите Blue-Green с тщательно проработанными миграциями и stickiness.

20) Краткое сравнение (резюме)

Скорость отката: Blue-Green = мгновенно; Canary = быстро, но с откатом веса.
Стоимость инфраструктуры: Blue-Green ↑; Canary ↔︎/↓.
Риск для пользователей: Canary ниже (контролируем долю).
Сложность внедрения: Blue-Green проще стартовать; Canary требует сильной наблюдаемости и автоматизации.
Совместимость данных/схем: критична для обоих; планируйте expand-migrate-contract.

21) Итог

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