Shadow ტრაფიკი და შედარება

1) რა არის Shadow ტრაფიკი და რატომ არის ეს საჭირო

Shadow ტრაფიკი (aka traffic mirroring/dark launch) არის რეალური მოთხოვნის/მოვლენების უსაფრთხო „გადახრა“ სამსახურის ახალი ვერსიისთვის, წარმოების ვერსიის პარალელურად, მომხმარებლებზე გავლენის გარეშე. ახალი ვერსიის შედეგები არ უბრუნდება კლიენტს და არ აწარმოებს გარე გვერდითი ეფექტებს, მაგრამ იკრიბება შედარების სისტემაში.

• თავსებადობის შემოწმება: სქემები, კონტრაქტები, ბიზნეს ლოგიკა.
• პროდუქტიულობის შეფასება: ლატენტობა, რეალური დატვირთვის წინააღმდეგობა.
• დრიფტის გამოვლენა: განსხვავებები პასუხებში, განაწილებებში, შეცდომების სიხშირეში.
• კანარის გამოშვებისთვის მზადება: რისკის შემცირება ტრაფიკის რეალურ გადართვამდე.

• ბირთვის/ალგორითმების გადაწერა, BD/ქეშის მიგრაცია, სხვა ranthim/SDK- ზე გადასვლა, გარე API პროვაიდერის შეცვლა.

2) Shadow ტრაფიკის არქიტექტურული ნიმუშები

2. 1 L7 მარიონეტული/კარიბჭე (HTTP/gRPC)

მარქსი იღებს თხოვნას, აძლევს საბრძოლო პასუხს ძველი ვერსიიდან, ასინქრონულად ახდენს მოთხოვნის ასლს „ჩრდილში“.

შესაფერისია სინქრონიზებული API- სთვის.
მარცვლეულის წილის/ფილტრების მართვა: გზაზე, ქედერი, მომხმარებელი, ტენანტი.

yaml route:
route:
cluster: prod-v1 request_mirror_policies:
- cluster: shadow-v2 runtime_fraction:
default_value:
numerator: 10 # 10% denominator: HUNDRED trace_sampled: true

nginx location /api/ {
proxy_pass http://prod_v1;
mirror/shadow; # request copy
}
location = /shadow {
internal;
proxy_pass http://shadow_v2; # answer ignored
}

2. 2 მოვლენების საბურავები (კაფკა/ნაკადები)

• პროდიუსერი წერს, ჩვეულებისამებრ, კონსერვატორებს კითხულობს.
• პარალელურად, „ჩრდილი“ კითხულობს იმავე ნაკადს ცალკეულ ქვიშის ყუთში.

პარამეტრები: MirrorMaker/Replicator, ორმაგი write (ფრთხილად), bridges „წყარო - + shadow“.

2. 3 Replayer (ჩანაწერი/რეპროდუქცია)

რეალური მოთხოვნების/ტრეისების სურათი (PCAP/NGINX Access, grRPC taps) - „ჩრდილში“ დაკვრა კონტროლირებადი ტემპით.

2. 4 სინთეზური ჩრდილი

დატვირთვის პროფილის წარმოქმნა პროდ-ლოგებიდან + რეგიონალური საქმეების შევსების ფაზიდან - სასარგებლოა კონფიდენციალურობის შეზღუდვებით.

3) სახელმწიფო იზოლაცია და გვერდითი ეფექტები

ოქროს წესი: ჩრდილი არ ცვლის გარე სამყაროს.

Rid-only წვდომა BD/ქეში ან ცალკე ქვიშის ყუთში (snapshot/რეპლიკა).
გამავალი გვერდების აკრძალვა: გადასახადები, წერილები, ქვემეხები, webhooks - stub/blackhole/record-only.
Idempotention ბრძანების დონეზე/POST: Shadow არ უნდა იყოს რეგისტრირებული ორიგინალის განმეორებით.
PII/საიდუმლოებების შენიღბვა, ტესტის პროვაიდერების ნიშნები.

მაგალითი: შენიღბვა სარკეში

yaml shadowFilter:
headers:
redact:
- Authorization
- X-Api-Key body:
jsonPaths:
- replace "$ .email" # with token
- "$.card. number"

4) სემპლაციის სტრატეგიები და უსაფრთხო დატვირთვა

ტრაფიკის წილი: დასაწყისში 1-10%; გაზარდეთ, თუ v2 ჯდება ბიუჯეტში.
შერჩევის კრიტერიუმები: მარშრუტზე, მომხმარებელზე, მოთხოვნის ზომაზე, ოპერაციის ტიპზე (GET უსაფრთხოა).
მარგალიტის ბიუჯეტი: მარცვლეულმა არ უნდა გაზარდოს p95/p99 საბრძოლო მომსახურება. ჩრდილი ყოველთვის ასინქრონულია.
Back-pressure: გადახურვის დროს, shadow ჯაჭვები არის ჩრდილის დაშლა და არა საბრძოლო მოთხოვნები.
დრო: მინიმუმ 24-72 საათი ყოველდღიური და პიკის ნიმუშების დასაფარად.

5) შედეგების შედარება: მეთოდები და დონეები

5. 1 შედარება

1. ბაიტი: პასუხის სხეული/ერთი მოვლენა. უბრალოდ, მაგრამ მყიფე (დრო, გასაღების შეკვეთა).
2. სემანტიკა: ჩვენ ვატარებთ ნორმალიზებას და ვაყენებთ ველს, უგულებელყოფთ ეპემერიდებს (tracaID, timestamps, counters).
3. ბიზნეს ინვარიანტები: იგივე თანხები, სტატუსები, რაოდენობა, საზღვრები.
4. სტატისტიკური ანალიზი: მეტრიკის განაწილება ემთხვევა? (p50/p95, KS ტესტი, s ² კატეგორიული).

5. 2 შედარებითი პოლიტიკა

ნიღბები/ignore ველების სიები (მაგ., 'განახლება', 'etag').
სიზუსტე: რიცხვების აბსოლუტური/ფარდობითი შეცდომა (მაგალითად, ± 1e-6).

Tolerance bands: "ფასის სხვაობა 0. 01“, „შეცდომები აღარ არის + 0. 1% შედარებით."

კომპარატორის ფსევდოკოდი

pseudo compare(prod, shadow, policy):
a = normalize(prod, policy)
b = normalize(shadow, policy)
diffs = deepDiff(a, b, ignore=policy. ignore, floatTol=policy. floatTol)
invariants_ok = checkInvariants(a, b, policy. invariants)
return Result(diffs, invariants_ok)

5. 3 მოთხოვნის შედარება - პასუხი

სავალდებულოა Correlation-ID (გადაყარეთ ჩრდილში).
Spans linkovka: shadow ტრეკი იღებს ლინკს საბრძოლო.

6) შედარება და არტეფაქტები

• `shadow_requests_total{route,...}`
• `shadow_discrepancies_total{type=byte|semantic|invariant}`
• `shadow_error_ratio` и `shadow_slo_breach_total`
• პერფი: 'shadow _ latencies _ ms {p50, p95, p99'
• დიფების ლოგოები: კომპაქტური JSON დელტა კლავიშებზე.
• ანგარიში: ყოველდღიური ანგარიში ტოპ N განსხვავებებიდან, თერმული ბარათები მარშრუტებზე/ტენანტებზე.
• UI „diff Explorer“: ფილტრები ტიპის, მარშრუტის, ველის, ექსპორტი CSV- ში.

7) განსაკუთრებული შემთხვევები და დახვეწილობა

7. 1 თანმიმდევრობა და თანმიმდევრულობა

Shadow მოთხოვნები შეიძლება მოგვიანებით/ადრე მოვიდეს; ნორმალიზება/საათების მიხედვით (Lamport/vector) ან ფანჯრის გასწვრივ.
Read-after-write: ჩრდილი read-replica- სთან სინქრონული რეპლიკაციის გარეშე მისცემს სხვადასხვა პასუხებს - შეადარეთ ლამპის ფანჯრები.

7. 2 კეში/რეკომენდაციები

ნუ შეურიეთ ქეში და shadow.
ML/რეკომენდატორებისთვის შეადარეთ ონლაინ მეტრიკა და ოფლაინ მეტრიკა ცალკე; დააკვირდით შეყვანის ნიშნებს.

7. 3 გარე პროვაიდერები

გადააკეთეთ მომხმარებლები ჩანაწერების რეჟიმში.
გაანგარიშებული მომსახურებისთვის (გადასახადები, კურსები) - ჩაწერეთ საცნობარო წიგნების სურათი ორივე მხარისთვის.

8) კანარის შედარება/ცისფერი-მწვანე

Shadow: მომხმარებლებისთვის ნულოვანი რისკი, მაგრამ არ არსებობს რეალური გვერდითი ეფექტები; მშვენიერია ლოგიკისთვის და პერფისთვის.
Canary: ახალი ვერსიიდან რეალური პასუხების მცირე პროცენტი; მოითხოვს მზა დაბრუნების სტრატეგიას და SLA.
Blue-green: მყისიერი გადართვა ვალიდაციის შემდეგ; Shadow ხშირად გამოიყენება მის წინ.

9) განხორციელების გეგმა (GitOps სტილი)

1. მიზნები და მეტრიკა: რომელი ინვარიანტები და დაშვება ვამოწმებთ რა SLO- ს განსხვავებებს.
2. ტრეკერი: Correlation-ID, განაწილებული ტრეისი ხაზები.
3. მარიონეტული კონფიგურაცია: mirror პოლიტიკა, sexaction, redaction.
4. იზოლაცია: BD/ქეში ქვიშის ყუთი, გვერდითი დანამატები, ტესტის გასაღებები.
5. კომპარატორი: ნორმალიზაცია, ignore-maps, ინვარიანტები, მოხსენებები.
6. დატვირთვის გეგმა: დაწყება 1-5% -ით, ზრდა 20-50% -მდე მწვანე მეტრებში.
7. დაკვირვება: დაშბორდები „შეუსაბამობა/პერფი/მოცულობა“.
8. გამოსვლის კრიტერიუმები: „0 კრიტიკული შეუსაბამობა 48 საათის განმავლობაში“, „შეცდომები არ არის უარესი, ვიდრე scream“, „პერფი ± 5% ფარგლებში“.
9. გადასვლა კანზე: ჩართეთ რეალური პასუხები უსაფრთხო წილით და ავტომატური გარბენის წესებით.

10) კონფიგურაციის მაგალითები

10. 1 Istio (Traffic Mirroring)

yaml apiVersion: networking. istio. io/v1beta1 kind: VirtualService spec:
hosts: ["svc. example"]
http:
- route: [{ destination: { host: svc, subset: v1 } }]
mirror:
host: svc subset: v2 mirrorPercentage:
value: 0. 1 # 10%

10. 2 Kafka Tee (ესკიზი)

text source-topic -> prod-consumer-group
-> shadow-consumer-group (isolated sink/db)

10. 3 შედარების წესები (იამლის პოლიტიკა)

yaml ignoreFields:
- $.traceId
- $.meta. generatedAt floatTolerance:
default: 1e-6 fields:
$.price: 0. 01 invariants:
- name: "nonNegativeTotal"
expr: "$.total >= 0"
- name: "statusMapping"
expr: "map($.status in ['ok','fail'], true)"

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

Shadow წერს გარედან: რეალური გადახდები/შეტყობინებები ჩრდილიდან.
საერთო ქეში/ზოგადი ხაზები: ჯვარედინი გავლენა და დაბინძურება.
ნორმალიზაციის არარსებობა: ბაიტის დიფები „წითელია“ საათების/შეკვეთის გამო.
ძალიან მაღალი პროცენტი სიჩქარით: პერფის დეგრადაცია.
გრძელი „მარადიული ჩრდილი“: მეორე სისტემა ცხოვრობს ცალკე და განსხვავდება რეალობასთან.

12) Shadow რეჟიმის გაშვების ჩეკის სია

• მარიონეტული mirror აქვს წილი და redaction.
• ჩრდილი იზოლირებულია: BD/ქეში/გარე ინტეგრაცია - მხოლოდ readonly/stub.
• Correlation-ID ყველგან; ტრეკები არის ლინზები.
• კომპოზიტორს შეუძლია ignore/normalize და შეამოწმოს ინვარიანტები.
• დაშბორდები და ალერტები განსხვავებებისა და დატვირთვის შესახებ.
• სემპლაცია მარშრუტებზე/ტენანტებზე; შეზღუდვები და უკანდახევა.
• განისაზღვრება მწვანე შუქის დაშვება და კრიტერიუმები.
• გეგმა გადასვლისთვის/ცისფერი-მწვანე და დაბრუნება.

13) FAQ

Q: როგორ განსხვავდება Shadow A/B?
A: A/B ორივე ვერსია მომხმარებლებს პასუხებს უბრუნებს (სპლიტ ექსპერიმენტი), Shadow- ში ახალი ვერსია გავლენას არ ახდენს მომხმარებელზე - მისი პასუხები მხოლოდ ანალიზდება.

Q: შესაძლებელია POST/PUT?
A: დიახ, თუ გარანტირებულია გვერდითი იზოლაცია (stub) და imempotence. ხშირად იწყებენ GET- ს, შემდეგ კი აფართოებენ.

Q: როგორ შევადაროთ პასუხები, თუ ელემენტების რიგი არ არის ფიქსირებული?
ა: შეადარეთ ან შეადარეთ, როგორც კლავიშებს.

Q: რა უნდა გავაკეთოთ BD- ს რეპლიკების შეფერხებებით?
A: შეიყვანეთ „შედარების ფანჯრები“ და საცნობარო წიგნების სლაიდები; დააკავშიროთ შედეგები ვერსიით და არა „სტენოკარდიით“.

14) შედეგები

Shadow ტრაფიკი არის „წარმოების უმტკივნეულო რეპეტიცია“: რეალური დატვირთვა, მომხმარებლებისთვის ნულოვანი რისკი, განსხვავებების დეტალური ანალიტიკა. წარმატება განისაზღვრება იზოლაციით, სწორი ნიმუშით, მაღალი ხარისხის კომპარატორით და დაკვირვებით. შემოთავაზებული გეგმის შემდეგ, თქვენ მიიღებთ რეპროდუქციულ პრაქტიკას, რომელიც დამაჯერებლად ხოცავს გზას/ცისფერ-მწვანე რელიქვიებამდე და აჩქარებს არქიტექტურის ევოლუციას.