Strategie wydania: niebiesko-zielony i kanarka
(Sekcja: Technologia i infrastruktura)
Krótkie podsumowanie
Niebiesko-zielony daje natychmiastowy przełącznik między dwoma pełnymi stosami (Blue/Green) z najprostszym rollback. Canary stopniowo zwiększa udział ruchu do nowej wersji pod kontrolą bram SLO (opóźnienie, wskaźnik błędów, wskaźniki biznesowe). Dla iGaming, jest to sposób, aby zwolnić bez przestojów na szczycie turniejów i promocji, przy zachowaniu stabilnego p99 i jakości.
1) Kiedy wybrać
Niebiesko-zielone - szybkie wydania, minimalna złożoność, potrzebujesz „podwójnego” klastra/budżetu zasobów. Dobre dla API/front bez skomplikowanej migracji państwowej.
Kanaryjskie - uwolnienia wysokiego ryzyka (nowy przepływ, zmiany krytyczne), pozwala „złapać” degradację o 1-5% ruchu. Wymaga telemetrii i automatycznych bram.
2) Zasady architektoniczne
1. L7 level routing: balancer/Ingress/service-mesh (ważone moduły ruchu, cookies/flag-routing).
2. Izolowane zależności: konfiguracje, ficheflagi, sekrety, bufory - osobno dla rewizji.
3. Kompatybilność danych: trans-kompatybilne (rozszerzyć → migrate → umowa) migracje bazy danych.
4. Obserwowalność: poszczególne etykiety/etykiety wersji w metrykach/logach/utworach.
5. Autogates: porównanie p95/p99, wskaźnik błędów, KPI biznesowy; automatyczny zwrot.
3) Niebiesko-zielony: podstawowy wzór
Strumień
1. Rozwiń zielony (kopia niebieski) → rozgrzać bufory/połączenia.
2. Sprawdzić zdrowie/dym.
3. Przełączanie ruchu (DNS/LB/Ingress) na Green.
4. Niebieski utrzymujemy w „ciepłym” stanie jako upadek aż do końca okna.
Przykład: Przełączanie poziomu Ingress (idea)
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: 80Plusy/minusy
Prosty zwrot (zwrócony niebieski).
Przewidywalny czas zwolnienia.
Wymaga powielania zasobów.
Ryzyko „wielkiego wybuchu” bez pomiaru kanarkowego.
4) Kanaryjski: Stopniowe budowanie
Strumień
1. Ruch cieni (opcjonalnie) → 1% rzeczywistego ruchu → 5% → 25% → 50% → 100%.
2. Na każdym etapie - bramy przez SLO/metryki biznesowe.
3. Podczas degradacji - auto-rollback i zachowanie artefaktów diagnostycznych.
Przykład: Argo Rollouts (snippet)
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: 100Przykład: Flagger + Istio/NGINX (idea)
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) Ogrzewanie i zarządzanie stanem
Bufety/źródła: rozgrzać pamięć podręczną Redis/HTTP/CDN, przygotować połączenia ciepłej puli do bazy danych/PSP.
Modele ML/LLM/: obciążniki/indeksy/osadzanie, pamięć podręczna KV, podstawowe wnioski o „ocieplenie”.
Pliki/artefakty: zawartość statyczna, szablony, konfiguracje - prześlij z wyprzedzeniem do lokalnego tomu/bocznego.
Ficheflags: rollout przy 1-5% publiczności/segmentu, możliwość awaryjnego zabicia.
6) Bazy danych: „rozszerzyć → migrate → umowa” strategia
1. Rozwiń: dodaj nieważne/nowe kolumny/indeksy, obsługuj obie wersje.
2. Migruj: kod wykorzystuje nowy system; stare ścieżki pozostają ważne.
3. Umowa: usunąć stare pola/indeksy po pełnym odprężeniu.
W dziennikach, naprawić schemat i wersję klienta; wszystkie zmiany są idempotentne.
Dla ciężkich migracji - tle jabs, throttling i „stop-the-world” okna zgodnie z uzgodnieniem.
7) Obserwowalność i bramy (SLO/SLA)
Wskaźniki SRE: p50/p95/p99, szybkość błędów, nasycenie (CPU/GPU/IO), głębokość kolejki, czas zimnego rozruchu.
Metryki biznesowe: konwersja płatności, sukces oferty, czas wypłaty (TTW), odpowiedzi promocyjne.
Jakość zawartości/LLM: żetony/s, długość odpowiedzi, toksyczność, wynik RAG.
Bramki: automatyczna promocja/rolka podczas przekraczania progów i/lub gdy „użyteczna metryka” spada.
gate:
p95_latency_ms <= 250 error_rate % <= 1. 0 payment_conv >= baseline - 0. 3%
action:
promote rollback8) Orkiestra i integracja z CI/CD
GitOps: zmiana wersji/masy ciała - poprzez PR do repozytorium manifestu.
Automatyczne sprawdzanie dymu/e2e przed rozpoczęciem ruchu.
Plan wydania: kanarkowy harmonogram kroków, odpowiedzialny, kanały ChatOps, okna rollback.
Archiwizacja artefaktów: konfiguracje routingu, migawki deski rozdzielczej, dzienniki porównawcze metryczne.
9) Wielobranżowe i krawędziowe
Kolejność: najpierw region „najmniej krytyczny ”/ROR, a następnie główne.
Routing oparty na opóźnieniach: monitorowanie lokalnych SLO; nie mieszaj ruchu bez powodu.
DR-vision: Niebieski w regionie A może być DR-site dla Green w regionie B.
10) Bezpieczeństwo i zwolnienie zgodności
Podpisane wygląd/wykresy, SBOM; sprawdzanie podpisów w polityce przyjmowania.
Sekrety: tylko menedżerowie zewnętrzni; niezależne wersje dla Blue/Green.
PII/regionalność: nie przekierowywać ruchu z PII do obcego regionu; zamaskować dzienniki podczas porównywania.
Audyt: kto awansował, które bramy pracowały, gdzie zwrot.
11) Przykłady konfiguracji
NGINX: Canary Branch by Cookie/Header (Idea)
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;
}
}Funkcja-flaga „fractional rollout” (pseudo)
yaml feature: new_checkout rollout:
percentage: 5 criteria:
country: ["TR", "BR", "MX"]
cohort: "new-users"
kill_switch: true12) Książki startowe (typowe scenariusze)
Wzrost p99 na kanarku: zatrzymać promocję → zwiększyć partię/timeout, wyłączyć ciężkie funkcje poprzez flagi → ponownie uruchomić niektóre strąki.
Spadek konwersji płatności: porównaj trasy/funkcje PSP, umożliwiaj rejestrowanie cieni, odwrócenie do stabilnego.
Problem z migracją bazy danych: zamrozić ruch do zapisu, włączyć tryb tylko do odczytu, odwrócić schemat (jeśli to możliwe), awaryjnie naprawić jabs.
Incydent PII: odcięcie wersji kanaryjskiej, odwołanie tajemnic, raport i audyt.
13) Lista kontrolna wdrażania
1. Zdefiniować politykę: gdzie niebiesko-zielony, gdzie kanarka; który jest uważany za „krytyczny”.
2. Konfiguracja ważonej trasy (Ingress/mesh/router).
3. Uchwycić bramki progowe SLO i automatyczne rolki.
4. Wdrożenie rozszerzenia → migrate → kontrakt dla bazy danych; testy migracji.
5. Umożliwia rozgrzewanie buforów/modeli i połączeń ciepłej puli.
6. Wprowadź GitOps i zaloguj wszystkie akcje.
7. Wizualizuj porównanie metryk (kanaryjski vs stabilny).
8. Spędzić grę-day: Symuluj problem z rollback/fail/database.
9. Dokumentacja książek startowych i wyłącznika zabójstw.
10. Plan multiregion uwalnia z kolei, nie w tym samym czasie.
14) Anty-wzory
Kanaryjskie uwolnienie bez bram i telemetrii → późne wykrycie degradacji.
Mieszanie schematu DB: Zakłócające migracje do kodu Unwind.
Jedna wspólna pamięć podręczna/kolejka do niebieskiego i zielonego bez izolacji → wzajemny wpływ.
Przełączanie DNS z niskim TTL bez weryfikacji - ruch „klapowy”.
Sekrety/konfiguracje wspólne dla obu wersji → skomplikowany zwrot.
Ruch do żywności bez cienia/dymu to duże ryzyko wybuchu.
Brak przełącznika/flagi funkcji do szybkiego wyłączenia.
Podsumowanie
Niebiesko-zielony zapewnia natychmiastowe i łatwe przełączanie, kanaryjskie - zarządzane ryzyko i wczesne wykrywanie problemów. W iGaming, oba wzory są połączone: kanarka na „ostre” zmiany + niebiesko-zielony jako podstawowy mechanizm bez przestojów. Dodaj bramki SLO, GitOps, rozgrzewka, kompatybilność bazy danych i izolacja zależności - i wydania będą przewidywalne, rolki są szybkie, a p99 i metryki biznesowe są stabilne nawet w okresach szczytowych.