Shadow trafigi va taqqoslash

1) Shadow-trafik nima va nima uchun kerak

Shadow-trafik (ya’ni traffic mirroring/dark launch) - bu foydalanuvchilarga ta’sir qilmasdan ishlab chiqarish versiyasi bilan parallel ravishda xizmatning yangi versiyasiga real so’rovlar/hodisalarning xavfsiz «progonkasi». Yangi versiya natijalari mijozga qaytarilmaydi va tashqi sayd effektlarini yaratmaydi, balki taqqoslash tizimiga yig’iladi.

• Sxemalar, kontraktlar, biznes-mantiqning muvofiqligini tekshirish.
• Unumdorlikni baholash: yashirin, real yuk ostida barqarorlik.
• Drift deteksiyasi: javoblar, taqsimotlar, xatolar chastotasidagi farqlar.
• Kanareya relizlariga tayyorgarlik: trafikni haqiqiy almashtirishdan oldin xavfni kamaytirish.

• Yadro/algoritmlarni qayta yozish, DB/kesh koʻchirish, boshqa rantaym/SDK ga oʻtish, tashqi API provayderini almashtirish.

2) Shadow-trafikning arxitektura patternlari

2. 1 L7-proksi/shlyuz (HTTP/gRPC)

Proxy so’rovni qabul qiladi → eski versiyadan jangovar javob beradi → so’rovning nusxasini «soyada» aks ettiradi.

Sinxron API uchun mos keladi.
Oynaning ulushini/filtrini boshqarish: yo’l bo’yicha, xeder, foydalanuvchi, tenant.

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 Voqea shinalari (Kafka/Oqimlar)

• Prodyuser odatdagidek yozadi → konsumerlar prod o’qiydilar.
• Shu bilan birga, «soya» (shadow-pipeline) alohida qum qutisiga xuddi shu oqimni o’qiydi.

Moslamalar: MirrorMaker/Replicator, dual-write (ehtiyotkorlik bilan), «source → prod + shadow» brijlari.

2. 3 Replayer (yozish/takrorlash)

Haqiqiy so’rovlar/treyslarni (PCAP/NGINX access, gRPC taps) → nazorat qilinadigan sur’atda «soyaga» o’ynash.

2. 4 «Sintetik soya»

Prod-loglardan yuklash profilini yaratish + cheklangan holatlarni to’ldirish fazasi - maxfiylikni cheklashda foydalidir.

3) Holat va sayd-effektlarni izolyatsiya qilish

Oltin qoida: soyalar tashqi dunyoni oʻzgartirmaydi.

Rid-onli kirish/kesh yoki alohida qum qutisi (snapshot/replika).
Chiqadigan nojo’ya ta’sirlarni taqiqlash: to’lovlar, xatlar, pushlar, webhooks → stub/blackhole/record-only.
Buyruqlar darajasidagi/POST: Shadow original takrorlash sifatida roʻyxatdan oʻtmasligi kerak.
Test provayderlarining PII/sirlarini, tokenlarini yashirish.

Misol: oynada niqoblash

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

4) Semplash strategiyasi va xavfsiz yuk

Trafikning ulushi: startda 1-10%; agar v2 budjetga to’g "ri kelsa, ko’tarilsin.
Tanlash mezonlari: yo’nalish, foydalanuvchi, so’rov hajmi, operatsiya turi (GETlar xavfsizroq) bo’yicha.
Perf-budjet: oynalash jangovar xizmatni p95/p99 ga oshirmasligi kerak. Soyalar doimo asinxron.
Back-pressure: shadow-zanjir haddan tashqari qizib ketganda - jangovar so’rovlarni emas, balki soyani purkash.
Vaqt: kunlik va eng yuqori namunalarni qoplash uchun kamida 24-72 soat.

5) Natijalarni solishtirish: usullar va darajalar

5. 1 Qiyoslash darajalari

1. Bayt diff: javob/hodisa tanasi. Oddiy, ammo mo’rt (taymstemplar, kalitlar tartibi).
2. Semantik diff: maydonlarni normallashtirish va saralash, epemeridlarni (traceId, timestamps, counters) e’tiborsiz qoldirish.
3. Biznes-invariantlar: bir xil summalar, maqomlar, miqdorlar, chegaralar.
4. Statistik tahlil: metriklarning taqsimlanishi mos keladimi? (p50/p95, KS-test, χ ² toifaga).

5. 2 Taqqoslash siyosati

Maskalar/ignore-maydonlarning ro’yxatlari (masalan,’updatedAt’,’etag’).
Aniqlik: sonlar uchun mutlaq/nisbiy xatolik (masalan, 1e-6 ±).
Ruxsatnomalar (tolerance bands): "narxdagi farq ≤ 0. 01», «xatolar + 0 dan oshmaydi. prod’ga nisbatan 1%.

Komparatorning psevdokodi

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 So’rovni taqqoslash javob

Majburiy Correlation-ID (soyaga tashlash).
Span linkovkasi: shadow-trassaga jangovar link beriladi.

6) Kuzatish va taqqoslash artefaktlari

• `shadow_requests_total{route,...}`
• `shadow_discrepancies_total{type=byte|semantic|invariant}`
• `shadow_error_ratio` и `shadow_slo_breach_total`
• Perf:’shadow _ latencies _ ms {p50, p95, p99} ’
• Diff loglari: ixcham JSON-delta kalitlari.
• Hisobot: top-N tafovutlardan kundalik hisobot, yo’nalishlar/tenantlar bo’yicha issiqlik xaritalari.
• UI «diff explorer»: turi, yo’nalishi, maydoni, export bo’yicha CSV.

7) Alohida holatlar va noziklik

7. 1 Izchillik va konsistentlik

Shadow-so’rovlar keyinroq/oldinroq kelishi mumkin; (Lamport/vector) versiyalari yoki oynaning chegaralari boʻyicha normallashtiring.
Read-after-write: sinxron replikatsiyasiz read-replica bilan soya turli xil javoblarni beradi - lag-derazalar orqali solishtiring.

7. 2 Kesh/tavsiyalar

Prod va shadow keshlarini aralashtirmang.
ML/tavsiyanomalar uchun onlayn va oflayn metrikalarni alohida solishtiring; kirish belgilari driftini kuzatib boring.

7. 3 Tashqi provayderlar

Mijozlarni record-only/stub-rejimiga aylantiring.
Hisob-kitob xizmatlari (soliqlar, kurslar) uchun - har ikki tomon uchun ma’lumotnoma rasmini yozib oling.

8) Kanareya/blue-green bilan taqqoslash

Shadow: foydalanuvchilar uchun nol xavf, lekin haqiqiy side effektlari mavjud emas; mantiq va perf uchun juda yaxshi.
Canary: yangi versiyadan haqiqiy javoblarning kichik foizi; tayyor qaytish strategiyasi va SLA talab qiladi.
Blue-green: validatsiyadan so’ng darhol o’zgartirish; Shadow koʻpincha uning oldida ishlatiladi.

9) Joriy etish rejasi (GitOps-uslub)

1. Maqsad va ko’rsatkichlar: qanday invariantlar va qo’llanmalarni tekshiramiz, qaysi SLO farqlarga ega.
2. Trastirovka: Correlation-ID, taqsimlangan treys-linkalar.
3. Proksi moslamalari: mirror siyosati, semplash, redaction.
4. Izolyatsiya: DB/kesh qum qutisi, nojo’ya ta’sirlar, sinov kalitlari.
5. Komparator: normallashtirish, ignore-maplar, invariantlar, hisobotlar.
6. Ish rejasi: 1-5% dan boshlash, yashil metriklarda 20-50% gacha o’sish.
7. Kuzatilishi: «tafovut/perf/hajm» dashbordlari.
8. Chiqish mezonlari: «0 tanqidiy tafovutlar 48 soat», «xatolar proddan yomon emas», «perf ± 5% doirasida».
9. Canariga oʻtish: haqiqiy javoblarni xavfsiz ulushlar va avtomatik gard qoidalar bilan kiritish.

10) Konfiguratsiya namunalari

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 (eskiz)

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

10. 3 Qiyoslash qoidalari (yaml-siyosat)

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) Anti-patternlar

Shadow tashqariga chiqadi: haqiqiy to’lovlar/bildirishnomalar.
Umumiy kesh/umumiy navbatlar: oʻzaro taʼsir va ifloslanish.
Normallashuv yo’qligi: bayt difflari soat/kalitlar tartibi tufayli «qizaradi».
Juda yuqori foiz: perf prod degradatsiyasi.
Uzoq «abadiy soya»: ikkinchi tizim alohida yashaydi va haqiqatdan farq qiladi.

12) Shadow rejimini ishga tushirish chek-varaqasi

• Proksida mirror va redaction moslamalari mavjud.
• Soyasi izolyatsiya qilingan: DB/keshlar/tashqi integratsiyalar - faqat readonly/stub.
• Correlation-ID hamma joyda tashlanadi; trastirmalar linklanadi.
• Komparator ignore/normalize va invariantlarni tekshirishni biladi.
• Farqlar va yuk uchun dashbordlar va alertlar.
• Yo’nalishlar/tenantlar bo’yicha semplash; limitlar va back-pressure.
• «Yashil yorug’lik» ning yo’l qo’yilishi va mezonlari belgilandi.
• canary/blue-green ga o’tish va qaytish rejasi.

13) FAQ

Q: Shadow A/B dan qanday farq qiladi?
A: A/B da ikkala versiya ham foydalanuvchilarga javoblarni qaytaradi (split-eksperiment), Shadowda yangi versiya foydalanuvchiga ta’sir qilmaydi - uning javoblari faqat tahlil qilinadi.

Q: POST/PUT yozish mumkinmi?
A: Ha, agar nojo’ya ta’sirlarni izolyatsiya qilish va idempotentlik kafolatlangan bo’lsa. Ko’pincha GET bilan boshlanadi, keyin kengaytiriladi.

Q: Agar elementlar tartibi o’rnatilmagan bo’lsa, javoblarni qanday solishtirish mumkin?
A: Solishtirishdan oldin turg’un kalit bilan saralang yoki ko’p/kalit bilan solishtiring.

Q: DB replikalarining kechikishi bilan nima qilish kerak?
A: «Taqqoslash oynalari» va ma’lumotnoma snapshotlarini kiriting; natijalarni «devor soati» bo’yicha emas, balki versiyalar bo’yicha birlashtiring.

14) Yakunlar

Shadow-trafik - bu «ishlab chiqarishning og’riqsiz mashqlari»: haqiqiy yuk, foydalanuvchilar uchun nol xavf, tafovutlarni batafsil tahlil qilish. Muvaffaqiyat izolyatsiya, toʻgʻri semplash, sifatli komparator va kuzatish bilan belgilanadi. Taklif qilingan rejaga amal qilib, siz canary/blue-green relizlariga ishonch bilan yo’l ochadigan va arxitektura evolyutsiyasini tezlashtiradigan takrorlanadigan amaliyotga ega bo’lasiz.