გამოშვების სტრატეგიები: ცისფერი-მწვანე და კანარი

(განყოფილება: ტექნოლოგიები და ინფრასტრუქტურა)

მოკლე რეზიუმე

Blue-green იძლევა მყისიერ გადასვლას ორ სრულ დასტის (Blue/Green) შორის უმარტივესი გამოტოვებით. Canary თანდათანობით ზრდის ტრაფიკის წილს ახალ ვერსიაზე SLO კარიბჭეების კონტროლის ქვეშ (ლატენტობა, error-rate, ბიზნეს მეტრიკა). IGaming- ისთვის, ეს არის ტურნირებისა და აქციების მწვერვალზე ხმის მიცემის საშუალება, სტაბილური p99 და ხარისხის შენარჩუნება.

1) რა უნდა აირჩიოს

Blue-green - სწრაფი გამოშვებები, მინიმალური სირთულე, საჭიროა „ორმაგი“ კასეტური/რესურსების ბიუჯეტი. API/ფრონტისთვის კარგია რთული სახელმწიფო მიგრაციის გარეშე.
კანარი - გაზრდილი რისკის გამოშვებები (ახალი flow, კრიტიკული ცვლილებები), საშუალებას გაძლევთ „დაიჭიროთ“ დეგრადაცია ტრეფიკის 1-5% -ით. მოითხოვს ტელემეტრიას და ავტომატურ კარიბჭეებს.

2) არქიტექტურული პრინციპები

1. მარშრუტიზაცია L7 დონეზე: დაბალანსება/Ingress/სერვისის მესა (შეწონილი ტრაფიკის მოდულები, cookie/flag-routing).
2. იზოლირებული დამოკიდებულებები: კონფიგურაცია, ჩიჩეფლაგები, საიდუმლოებები, ქეში - ცალკე გადასინჯვებისთვის.
3. მონაცემთა თავსებადობა: BD- ის მიგრაცია წინასწარ თავსებადია (გაფართოება - შერწყმა).
4. დაკვირვება: ცალკეული ეტიკეტები/ეტიკეტები ვერსიები მეტრიკებში/ლოგოებში/ტრეისებში.
5. Autogates: შედარება p95/p99, error-rate, Business-KPI; ავტომატური rollback.

3) ცისფერი მწვანე: ძირითადი ნიმუში

ნაკადი

1. აღმართეთ მწვანე (ლურჯი ასლი) და გაათბეთ ქეში/ნაერთები.
2. ჩვენ ვიწყებთ health/smoke ტესტებს.
3. ჩვენ გადავდივართ ტრეფიკს (DNS/LB/Ingress) მწვანე.
4. ჩვენ ცისფერი გვაქვს „თბილ“ მდგომარეობაში, როგორც 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

დადებითი/დადებითი

მარტივი გამოტოვება (დაუბრუნდა ცისფერი).
პროგნოზირებადი გამოშვების დრო.
მოითხოვს რესურსების დუბლირებას.
„დიდი აფეთქების“ რისკი კანარის გაზომვის გარეშე.

4) Canary: თანდათანობითი განვითარება

ნაკადი

1. Progon 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/smoke

5) გაათბეთ და მართეთ მდგომარეობა

ქეში/წყაროები: გაათბეთ Redis/HTTP ქეში/CDN, მოამზადეთ warm-pool ნაერთები BD/PSP.
ML/LLM/მოდელები: წონის/ინდექსების/ემბედინგის დატვირთვა, KV ქეში, პირველადი მოთხოვნები „გათბობისთვის“.
ფაილები/არტეფაქტები: სტატიკური შინაარსი, შაბლონები, კონფიგურაციები - წინასწარ წარუდგინეთ ადგილობრივ volume/sidecar.
ფიჩეფლაგები: rollout აუდიტორიის/სეგმენტის 1-5%, განვითარების შესაძლებლობა.

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 სკორეტი.
კარიბჭეები: ავტომობილი/გამოტოვება ბარიერებზე გასვლისას ან/და „სასარგებლო მეტრიკის“ დაცემისას.

gate:
p95_latency_ms <= 250 error_rate %  <= 1. 0 payment_conv  >= baseline - 0. 3%
action:
promote      rollback

8) გამოშვება-ორკესტრი და ინტეგრაცია CI/CD- სთან

GitOps: ვერსიების/წონის ცვლილებები - PR- ის საშუალებით მანიფესტის საცავში.
მანქანის შემოწმება: smoke/e2e ტრაფიკის დაწყებამდე.
გამოშვების გეგმა: საკვანძო, პასუხისმგებელი, ChatOps არხების გრაფიკი, დაბრუნების ფანჯრები.
არტეფაქტების არქივირება: მარშრუტიზაციის კონფიგურაცია, დაშბორდის ჩაქრობა, მეტრიკის შედარების ლოგოები.

9) მულტირეგიონი და edge

ბრძანება: ჯერ „ყველაზე ნაკლებად კრიტიკული“ რეგიონი/ROR, შემდეგ მთავარი.
Latency-based routing: დააკვირდით ადგილობრივ SLO; ნუ აურიეთ ტრაფიკი უპრობლემოდ.
DR ხედვა: ცისფერი რეგიონში-A შეიძლება გახდეს DR პლატფორმა მწვანე რეგიონში 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: true

12) Runbooks (ტიპიური სცენარები)

ზრდა p99 კანარზე: შეჩერდით პოპულარიზაციას, გაზარდეთ batch/timeout, გამორთეთ მძიმე ფიჩხები დროშებით და განაახლეთ ქვესადგურების ნაწილი.
გადახდის კონვერტაციის ვარდნა: შეადარეთ PSP მარშრუტები/ფიჩები, ჩართეთ shadow-logiration, დაბრუნება სტაბილურად.
BD- ს მიგრაციის პრობლემა: გაყინვა ტრაფიკი ჩანაწერზე, ჩართოთ read-only რეჟიმი, გამოტოვოთ სქემები (თუ ეს შესაძლებელია), გადაუდებელი კორექტირების ჯობი.
ინციდენტი PII: კანარის ვერსიის მოჭრა, საიდუმლოებების გადაკეთება, მოხსენება და აუდიტი.

13) განხორციელების შემოწმების სია

1. განსაზღვრეთ პოლიტიკა: სად არის ცისფერი-მწვანე, სად არის კანარი; რაც ითვლება „კრიტიკულად“.
2. გაწონასწორებული მარშრუტიზაციის პარამეტრები (Ingress/mesh/routivator).
3. ჩაწერეთ SLO ბარიერი კარიბჭეები და მანქანების გამოტოვება.
4. გააცნობიერეთ გამოცდა და კონტრაქტი BD- სთვის; მიგრაციის ტესტები.
5. ჩართეთ ქეში/მოდელები და warm-pool ნაერთები.
6. შეიყვანეთ GitOps და ყველა გამოშვებული მოქმედების ჟურნალები.
7. ვიზუალიზაცია მოახდინეთ მეტრიკის შედარებაზე (კანარის სტაბილური).
8. გაატარეთ თამაშის დღე: მიბაძეთ კარიბჭის გამოტოვებას/მარცხს/BD- ს პრობლემას.
9. აღწერეთ runbooks და „წითელი ღილაკი“ (kill-switch).
10. დაგეგმეთ მრავალრიცხოვანი გამოშვებები თავის მხრივ და არა ერთდროულად.

14) ანტი შაბლონები

კანარის გამოშვება კარიბჭეებისა და ტელემეტრიის გარეშე არის დეგრადაციის მოგვიანებით გამოვლენა.
DD სქემის შერევა: მიგრაციის განადგურება კოდის გათიშვამდე.
ერთი საერთო ქეში/ხაზი ცისფერი და მწვანე იზოლაციის გარეშე არის ურთიერთგამომრიცხავი.
DNS გადართვა დაბალი TTL- ით შემოწმების გარეშე - „flapping“ ტრაფიკი.
ორივე გადასინჯვისთვის საერთო საიდუმლოებები/კონფისკაცია რთული გამოტოვებაა.
პროტესტის ტრეფიკი shadow/smoke გარეშე არის „დიდი აფეთქების“ რისკი.
სწრაფი გამორთვისთვის კილ-switch/feature-flag არარსებობა.

შედეგები

ცისფერი მწვანე უზრუნველყოფს მყისიერ და მარტივ გადართვას, კანარი არის კონტროლირებადი რისკი და პრობლემების ადრეული გამოვლენა. IGaming- ში ორივე ნიმუში შერწყმულია: თოკი „მწვავე“ ცვლილებებზე + ცისფერი-მწვანე, როგორც ძირითადი მექანიზმი დაუცველი. დაამატეთ SLO კარიბჭეები, GitOps, დათბობა, მონაცემთა ბაზის თავსებადობა და დამოკიდებულების იზოლაცია - და გამოშვებები პროგნოზირებადი იქნება, სწრაფი გამოტოვება, ხოლო p99 და ბიზნეს მეტრიკა სტაბილურია პიკის პერიოდებშიც კი.