GH GambleHub

Gölge trafiki və müqayisə

1) Shadow trafiki nədir və niyə lazımdır

Shadow-trafik (eyni zamanda traffic mirroring/dark launch) - istifadəçilərə təsir etmədən istehsal versiyasına paralel olaraq xidmətin yeni versiyasına real sorğuların/hadisələrin təhlükəsiz «qaçışıdır». Yeni versiyanın nəticələri müştəriyə qaytarılmır və xarici side effektləri istehsal etmir, əksinə müqayisə sisteminə toplanır.

Əsas məqsədlər:
  • Uyğunluq testi: sxemlər, müqavilələr, biznes məntiqi.
  • Performans qiymətləndirilməsi: gecikmə, real yük altında sabitlik.
  • Sürüklənmə deteksiyası: cavablarda, paylamalarda, səhv tezliyində fərqlər.
  • Kanarya buraxılışlarına hazırlıq: real trafik keçidindən əvvəl riski azaltmaq.
Nə zaman tətbiq olunur:
  • Nüvənin/alqoritmlərin yenidən yazılması, DB/cache miqrasiyası, başqa bir rantaym/SDK-ya keçid, xarici API provayderinin dəyişdirilməsi.

2) Shadow Trafik Memarlıq Nümunələri

2. 1 L7-proxy/şluz (HTTP/gRPC)

Proxy sorğu qəbul → köhnə versiyası döyüş cavab verir → asinxron «kölgə» sorğu surətini əks etdirir.

Sinxron API üçün uyğundur.
Güzgü payının/filtrinin idarə edilməsi: yol, heder, istifadəçi, tenant.

Nümunə (Envoy):
yaml route:
route:
cluster: prod-v1 request_mirror_policies:
- cluster: shadow-v2 runtime_fraction:
default_value:
numerator: 10 # 10% denominator: HUNDRED trace_sampled: true
Nümunə (Nginx):
nginx location /api/ {
proxy_pass http://prod_v1;
mirror/shadow; # request copy
}
location = /shadow {
internal;
proxy_pass http://shadow_v2; # answer ignored
}

2. 2 Hadisə şinləri (Kafka/Axınlar)

Topik səviyyəsində tee edilir:
  • Prodüser həmişəki kimi yazır → prod konsumerləri oxuyur.
  • Paralel olaraq «kölgə» (shadow-pipeline) ayrıca qum qutusuna eyni axını oxuyur.

Seçimlər: MirrorMaker/Replicator, dual-write (diqqətlə), «source → prod + shadow» brices.

2. 3 Replayer (qeyd/oynatma)

Real sorğuların/treyslərin görüntüsü (PCAP/NGINX access, gRPC taps) → nəzarət olunan templə «kölgə» oynatma.

2. 4 «Sintetik kölgə»

Prod-loqlardan yük profili + kənar halların doldurulması fazası - məxfilik məhdudiyyətlərində faydalıdır.

3) Vəziyyət və side effektlərinin izolyasiyası

Qızıl qayda: kölgə xarici dünyanı dəyişdirmir.

Rid-onli DB/cache və ya ayrı qum qutusu (snapshot/replika).
Çıxan yan təsirlərin qadağan edilməsi: ödənişlər, məktublar, toplar, webhooks → stub/blackhole/record-only.
Komanda səviyyəsində idempotentlik/POST: Shadow orijinalın təkrarı kimi qeydiyyatdan keçməməlidir.
PII/sirlərin maskalanması, test provayderlərinin tokenləri.

Nümunə: güzgüdə maskalanma

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

4) Sample strategiyaları və təhlükəsiz yük

Trafik payı: başlanğıcda 1-10%; v2 büdcəyə uyğun olduqda artırmaq.
Seçim meyarları: marşrut, istifadəçi, sorğu ölçüsü, əməliyyat növü (GET-lər daha təhlükəsizdir).
Perf-büdcə: güzgü p95/p99 döyüş xidmətini artırmamalıdır. Kölgə həmişə asinxronikdir.
Back-pressure: shadow zəncirinin həddindən artıq istiləşməsi zamanı - döyüş istəkləri deyil, kölgə tökün.
Vaxt: gündəlik və pik nümunələri əhatə etmək üçün ən azı 24-72 saat.

5) Nəticələrin müqayisəsi: metodlar və səviyyələr

5. 1 Müqayisə səviyyələri

1. Bayt diff: bir-bir cavab/hadisə bədən. Sadə, lakin kövrək (taymstamplar, açar sırası).
2. Semantik diff: sahələri normallaşdırırıq və sıralayırıq, epemeridlərə məhəl qoymuruq (traceId, timestamps, counters).
3. Biznes invariantları: eyni məbləğlər, statuslar, kəmiyyətlər, sərhədlər.
4. Statistik analiz: metrlərin paylanması üst-üstə düşür? (p50/p95, KS-test, χ ² kateqoriya).

5. 2 Müqayisə siyasəti

Maskalar/ignore-sahə siyahıları (məsələn, 'updatedAt', 'etag').
Dəqiqlik: ədədlər üçün mütləq/nisbi səhv (məsələn, ± 1e-6).
Tolerance bands: "qiymət fərqi ≤ 0. 01», «səhvlər + 0-dan çox deyil. 1% prod".

Komparatorun psevdokodu

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 Sorğu cavab müqayisə

Correlation-ID tələb olunur (kölgəyə atılır).
Span link: shadow-track döyüş link alır.

6) Müşahidə və müqayisə artefaktları

Metriklər:
  • `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 log: kompakt JSON-delta açarları.
  • Hesabat: Top-N fərqləri ilə gündəlik hesabat, marşrutlar/tenantlar üzrə istilik xəritələri.
  • UI «diff explorer»: növü, marşrutu, sahəsi, CSV-də export.

7) Xüsusi hallar və incəliklər

7. 1 Ardıcıllıq və tutarlılıq

Gölge sorğuları daha sonra/əvvəl gələ bilər; versiyaları/saatları (Lamport/vector) və ya pəncərə toleransları ilə normallaşdırın.
Read-after-write: sinxron replikasiyasız read-replica ilə kölgə fərqli cavablar verəcəkdir - lag pəncərələri ilə müqayisə edin.

7. 2 Cache/tövsiyələr

Prod və shadow caches qarışdırmayın.
ML/tövsiyəçilər üçün onlayn metrikləri və oflayn metrikləri ayrıca müqayisə edin; giriş əlamətləri drift edin.

7. 3 Xarici provayderlər

Müştəriləri record-only/stub rejiminə çevirin.
Hesablaşma xidmətləri üçün (vergilər, kurslar) - hər iki tərəf üçün məlumat kitabçalarının şəklini qeyd edin.

8) Kanarya/mavi-yaşıl ilə müqayisə

Shadow: istifadəçilər üçün sıfır risk, lakin real side effektləri yoxdur; məntiq və perf üçün əladır.
Canary: yeni versiyadan real cavabların kiçik faizi; hazır geri dönüş strategiyası və SLA tələb edir.
Mavi-yaşıl: validasiyadan sonra dərhal keçid; Shadow tez-tez onun qarşısında istifadə olunur.

9) Tətbiq planı (GitOps-stil)

1. Məqsədlər və metriklər: uyğunsuzluqlar üçün hansı SLO olduğunu yoxlayırıq.
2. Tracking: Correlation-ID, paylanmış Trace Links.
3. Proxy konfiqurasiya: mirror siyasəti, sempling, redaction.
4. İzolyasiya: qum qutusu DB/cache, yan qapaqlar, test açarları.
5. Komparator: normallaşma, ignore-maps, invariantlar, hesabatlar.
6. Yükləmə planı: yaşıl metrlərlə 1-5% -dən 20-50% -ə qədər artım.
7. Müşahidə: Daşbordlar «uyğunsuzluqlar/perf/həcm».
8. Çıxış meyarları: «0 kritik fərqlər 48 saat», «səhvlər prod daha pis deyil», «perf ± 5%».
9. canary keçid: təhlükəsiz pay və avtomatik gard qaydaları ilə real cavabları daxil edin.

10) Konfiqurasiya nümunələri

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 Müqayisə qaydaları (yaml-siyasət)

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-nümunələr

Shadow yazır: kölgədən real ödənişlər/bildirişlər.
Ümumi cache/ümumi növbələr: çarpaz təsir və çirklənmə.
Normallaşmanın olmaması: saat/açar sırasına görə bayt diffları «qızarır».
gediş ilə çox yüksək faiz: perf prod deqradasiya.
Uzun «əbədi kölgə»: ikinci sistem ayrı yaşayır və reallıqdan fərqlənir.

12) Shadow rejiminin başlanğıc çek siyahısı

  • Proxy pay və redaction ilə mirror konfiqurasiya.
  • Kölgə təcrid olunur: BD/caches/xarici inteqrasiya - yalnız readonly/stub.
  • Correlation-ID hər yerdə atılacaq; tracking linking.
  • Komparator ignore/normalize və invariant yoxlama bilir.
  • Daşbordlar və boşluqlar və yük üçün alertlər.
  • Marşrutlar/tenantlar üzrə sempleme; limitlər və back-pressure.
  • «yaşıl işıq» tolerantları və meyarları müəyyən edilmişdir.
  • canary/blue-green keçid planı və geri.

13) FAQ

Q: Shadow A/B fərqlidir?
A: A/B-də hər iki versiya cavabları istifadəçilərə qaytarır (split-eksperiment), Shadow-da yeni versiya istifadəçiyə təsir etmir - onun cavabları yalnız təhlil olunur.

Q: POST/PUT adaptasiya edilə bilərmi?
A: Bəli, yan təsirlərin izolyasiyası (stub) və idempotentlik təmin edilərsə. Tez-tez GET ilə başlayın, sonra genişləndirin.

Q: Elementlərin qaydası sabit deyilsə, cavabları necə müqayisə etmək olar?
A: Müqayisə etməzdən əvvəl sabit açara görə sıralayın və ya çoxluq/açar ilə müqayisə edin.

Q: BD replikalarının gecikmələri ilə nə etmək lazımdır?
A: «Müqayisə pəncərələri» və məlumat kitablarının snapshotlarını daxil edin; Nəticələri «divar saatı» ilə deyil, versiyalarla yığın.

14) Nəticələr

Gölge trafiki «ağrısız istehsal məşqidir»: real yük, istifadəçilər üçün sıfır risk, uyğunsuzluqların ətraflı analitikası. Uğur izolyasiya, düzgün toxumlama, keyfiyyətli komparator və müşahidə ilə müəyyən edilir. Təklif olunan plana uyğun olaraq, canary/blue-green relizlərinə inamla yol açan və memarlığın təkamülünü sürətləndirən təkrar edilə bilən bir təcrübə əldə edəcəksiniz.

Contact

Bizimlə əlaqə

Hər hansı sualınız və ya dəstək ehtiyacınız varsa — bizimlə əlaqə saxlayın.Həmişə köməyə hazırıq!

Telegram
@Gamble_GC
İnteqrasiyaya başla

Email — məcburidir. Telegram və ya WhatsApp — istəyə bağlıdır.

Adınız istəyə bağlı
Email istəyə bağlı
Mövzu istəyə bağlı
Mesaj istəyə bağlı
Telegram istəyə bağlı
@
Əgər Telegram daxil etsəniz — Email ilə yanaşı orada da cavab verəcəyik.
WhatsApp istəyə bağlı
Format: ölkə kodu + nömrə (məsələn, +994XXXXXXXXX).

Düyməyə basmaqla məlumatların işlənməsinə razılıq vermiş olursunuz.