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 більш ніж на Δ.
• Бізнес-поріг (наприклад, падіння конверсії
• 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 - не взаємовиключні стратегії, а елементи прогресивної доставки. Вибір залежить від обмежень по вартості, зрілості спостережуваності і характеру змін. Незалежно від підходу, стійкий реліз тримається на чотирьох опорах: автоматизація, спостережуваність, зворотна сумісність і швидкий відкат.