Стратегії релізів: blue-green и canary
(Розділ: Технології та Інфраструктура)
Коротке резюме
Blue-green дає миттєве перемикання між двома повними стеками (Blue/Green) з найпростішим відкатом. Canary поступово збільшує частку трафіку на нову версію під контролем SLO-гейтів (латентність, error-rate, бізнес-метрики). Для iGaming це спосіб релізувати без даунтайму в піку турнірів і акцій, зберігаючи стабільний p99 і якість.
1) Коли що вибирати
Blue-green - швидкі релізи, мінімальна складність, потрібен «подвійний» кластерний/ресурсний бюджет. Хороший для API/фронту без складної state-міграції.
Canary - релізи підвищеного ризику (нові флоу, критичні зміни), дозволяє «зловити» деградації на 1-5% трафіку. Вимагає телеметрії і автоматичних гейтів.
2) Архітектурні принципи
1. Маршрутизація на рівні L7: балансувальник/Ingress/сервіс-меш (модулі зваженого трафіку, cookie/flag-routing).
2. Ізольовані залежності: конфігурації, фічефлаги, секрети, кеші - окремо для ревізій.
3. Сумісність даних: міграції БД вперед-сумісні (expand→migrate→contract).
4. Спостережуваність: окремі мітки/лейбли версій в метриках/логах/трейсах.
5. Автогейти: порівняння p95/p99, error-rate, бізнес-KPI; автоматичний rollback.
3) Blue-green: базовий патерн
Потік
1. Розгортаємо Green (копія Blue) → прогріваємо кеші/з'єднання.
2. Запускаємо health-/smoke-тести.
3. Перемикаємо трафік (DNS/LB/Ingress) на Green.
4. Тримаємо Blue в «теплому» стані як fallback до кінця вікна.
Приклад: перемикання на рівні Ingress (ідея)
yaml
Annotated/Backend Option - In Prod, it is usually controlled by the spec operator/rollout:
rules:
- host: api. example. com http:
paths:
- path: /
backend:
service:
name: api-green # used to be api-blue port:
number: 80Плюси/мінуси
Простий відкат (повернули Blue).
Передбачуваний час релізу.
Вимагає дублювання ресурсів.
Ризик «великого вибуху» без канареечного заміру.
4) Canary: поступове нарощування
Потік
1. Прогін shadow-трафіку (опціонально) → 1% реального трафіку → 5% → 25% → 50% → 100%.
2. На кожному щаблі - гейти по SLO/бізнес-метрикам.
3. При деградації - авто-відкат і збереження артефактів діагностики.
Приклад: Argo Rollouts (фрагмент)
yaml apiVersion: argoproj. io/v1alpha1 kind: Rollout metadata: { name: payments-api }
spec:
strategy:
canary:
canaryService: payments-canary stableService: payments-stable steps:
- setWeight: 5
- pause: { duration: 5m }
- analysis:
templates:
- templateName: slo-latency
- setWeight: 25
- pause: { duration: 10m }
- analysis:
templates:
- templateName: error-rate
- setWeight: 50
- pause: { duration: 20m }
- setWeight: 100Приклад: Flagger + Istio/NGINX (ідея)
yaml apiVersion: flagger. app/v1beta1 kind: Canary metadata: { name: games-api }
spec:
targetRef:
apiVersion: apps/v1 kind: Deployment name: games-api service:
port: 80 analysis:
interval: 1m threshold: 5 metrics:
- name: request-success-rate thresholdRange: { min: 99 }
- name: request-duration thresholdRange: { max: 300 }
webhooks:
- name: smoke url: http://tester/smoke5) Прогрів і управління станом
Кеші/джерела: прогрійте Redis/HTTP-кеш/CDN, підготуйте warm-pool з'єднань до БД/PSP.
ML/LLM/моделі: прогрузка ваг/індексів/ембеддингів, KV-кеш, первинні запити для «розігріву».
Файли/артефакти: статичний контент, шаблони, конфіги - подайте заздалегідь в локальні volume/sidecar.
Фічефлагі: rollout на 1-5% аудиторії/сегмента, можливість emergency-kill.
6) Бази даних: стратегія «expand → migrate → contract»
1. Expand: додати nullable/нові колонки/індекси, підтримати обома версіями.
2. Migrate: код використовує нову схему; старі шляхи залишаються валідними.
3. Contract: видаляємо старі поля/індекси після повного розкату.
У журналах фіксуйте версію схеми і клієнта; всі зміни - ідемпотентні.
Для важких міграцій - фонові джоби, throttling і «stop-the-world» вікна за погодженням.
7) Спостережуваність і гейти (SLO/SLA)
SRE-метрики: p50/p95/p99, error-rate, saturation (CPU/GPU/IO), queue-depth, час холодного старту.
Бізнес-метрики: конверсія платежів, успішність ставок, час виведення (TTW), відгуки промо.
Якість контенту/LLM: tokens/s, довжина відповіді, токсичність, RAG-score.
Гейти: авто-промоушен/відкат при виході за пороги і/або при падінні «корисної метрики».
gate:
p95_latency_ms <= 250 error_rate % <= 1. 0 payment_conv >= baseline - 0. 3%
action:
promote rollback8) Реліз-оркестрація та інтеграція з CI/CD
GitOps: зміни версій/ваги - через PR в маніфест-репозиторій.
Автоперевірки: smoke/e2e перед початком трафіку.
План релізу: розклад сходинок canary, відповідальні, канали ChatOps, вікна відкату.
Архівація артефактів: конфіги маршрутизації, сніпшоти дашбордів, логи порівняння метрик.
9) Мультирегіон і edge
Порядок: спочатку «найменш критичний» регіон/РОР, потім основні.
Latency-based routing: слідкуйте за локальними SLO; трафік не змішуйте без причини.
DR-бачення: Blue в регіоні-A може стати DR-майданчиком для Green в регіоні-B.
10) Безпека та комплаєнс релізу
Підписані образи/чарти, SBOM; перевірка сигнатур в admission-політиках.
Секрети: тільки зовнішні менеджери; незалежні версії для Blue/Green.
PII/регіональність: не відводьте трафік з PII через «чужий» регіон; маскуйте логи при порівнянні.
Аудит: хто промоутив, які гейти спрацювали, де відкат.
11) Приклади конфігурацій
NGINX: канаркова гілка по cookie/заголовку (ідея)
nginx map $http_x_canary $canary {
default 0;
"1" 1;
}
upstream api_stable { server stable:80; }
upstream api_canary { server canary:80; }
server {
location / {
if ($canary) { proxy_pass http://api_canary; }
proxy_pass http://api_stable;
}
}Feature-flag «fractional rollout» (псевдо)
yaml feature: new_checkout rollout:
percentage: 5 criteria:
country: ["TR", "BR", "MX"]
cohort: "new-users"
kill_switch: true12) Runbooks (типові сценарії)
Зростання p99 на канарі: зупинити промоушен → збільшити batch/timeout, відключити важкі фічі через прапори → перезапустити частину подів.
Падіння конверсії платежів: порівняти PSP-маршрути/фічі, включити shadow-логування, відкат на стабільну.
Проблема з міграцією БД: заморозити трафік на запис, включити read-only режим, відкат схеми (якщо можливо), аварійні джоби виправлення.
Інцидент PII: відрубати канареечную версію, ревокація секретів, звіт і аудит.
13) Чек-лист впровадження
1. Визначте політику: де blue-green, де canary; що вважається «критичним».
2. Налаштуйте зважену маршрутизацію (Ingress/меш/маршрутизатор).
3. Зафіксуйте SLO-порогові гейти та авто-відкати.
4. Реалізуйте expand→migrate→contract для БД; тести міграцій.
5. Увімкніть прогрів кешів/моделей і warm-pool з'єднань.
6. Введіть GitOps і журналювання всіх релізних дій.
7. Візуалізуйте порівняння метрик (канареечная vs стабільна).
8. Проведіть game-day: імітуйте відкат/провал гейта/проблему БД.
9. Документуйте runbooks і «червону кнопку» (kill-switch).
10. Плануйте мультирегіон релізи по черзі, а не одночасно.
14) Анти-патерни
Канареечний реліз без гейтів і телеметрії → пізніше виявлення деградацій.
Змішування схеми БД: руйнують міграції до розкату коду.
Один загальний кеш/черга для Blue і Green без ізоляції → взаємний вплив.
DNS-перемикання з низьким TTL без перевірки - «флаппінг» трафіку.
Секрети/конфіги спільні для обох ревізій → складний відкат.
Трафік в прод без shadow/smoke - ризик «великого вибуху».
Відсутність kill-switch/feature-flag для швидкого вимикання.
Підсумки
Blue-green забезпечує миттєве і просте перемикання, canary - керований ризик і раннє виявлення проблем. У iGaming обидва патерна поєднуються: канар на «гострих» змінах + blue-green як базовий механізм без даунтайму. Додайте SLO-гейти, GitOps, прогрів, сумісність БД і ізоляцію залежностей - і релізи будуть передбачуваними, відкати швидкими, а p99 і бізнес-метрики стабільними навіть в пікові періоди.