Shadow-трафик және салыстыру

1) Shadow-трафик дегеніміз не және ол не үшін қажет

Shadow-трафик (сондай-ақ traffic mirroring/dark launch) - бұл пайдаланушыларға әсер етпейтін өндірістік нұсқамен қатар сервистің жаңа нұсқасына нақты сұрауларды/оқиғаларды қауіпсіз «айдап өту». Жаңа нұсқаның нәтижелері клиентке қайтарылмайды және сыртқы сайд-эффектілерді шығармайды, тек салыстыру жүйесіне жиналады.

• Схемалардың, келісімшарттардың, бизнес-логиканың үйлесімділігін тексеру.
• Өнімділікті бағалау: жасырындылық, нақты жүктемедегі тұрақтылық.
• Дрейфтің детекциясы: жауаптардағы, таратулардағы, қателер жиілігіндегі айырмашылықтар.
• Канареялық релиздерге дайындық: трафикті нақты ауыстырып қосу алдында тәуекелді төмендету.

• Ядроны/алгоритмдерді, ДБ/кэштерді көшіру, басқа рантаймға/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 Оқиға шиналары (Kafka/Ағындар)

• Продюсер әдеттегідей жазады → консумерлер prod оқиды.
• Сонымен қатар «көлеңке» (shadow-pipeline) сол ағынды жеке құмсалғышқа оқиды.

Параметрлері: MirrorMaker/Replicator, dual-write (абайлаңыз), «source → prod + shadow» бриджілері.

2. 3 Replayer (жазу/ойнату)

Нақты сұрауларды/трестерді (PCAP/NGINX access, gRPC taps) → бақыланатын қарқынмен «көлеңкеге» ойнату.

2. 4 «Синтетикалық көлеңке»

Сынамалардан жүктеме профилін генерациялау + шеткі жағдайларды қосымша толтыру фазасы - құпиялылықты шектеу кезінде пайдалы.

3) Жай-күйді және сайд-эффектілерді оқшаулау

Алтын ереже: көлеңке сыртқы әлемді өзгертпейді.

Рид-онли ДБ/кэшке немесе жеке құмсалғышқа қол жеткізу (snapshot/реплика).
Шығатын жағымсыз әсерлерге тыйым салу: төлемдер, хаттар, мылтықтар, webhooks → stub/blackhole/record-only.
/ 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. Семантикалық дифф: егістікті қалыпқа келтіріп, сұрыптаймыз, эпемеридті елемейміз (traceId, timestamps, counters).
3. Бизнес-инварианттар: сома, мәртебе, саны, шекарасы.
4. Статистикалық талдау: өлшемдердің бөлінуі сәйкес келе ме? (p50/p95, KS-тест, χ ² санаттарға).

5. 2 Салыстыру саясаты

Маскалар/ignore-өріс тізімдері (мысалы, 'updatedAt', 'etag').
Дәлдігі: сандар үшін абсолютті/салыстырмалы қателік (мысалы, ± 1е-6).
Рұқсаттар (tolerance bands): "бағадағы айырма ≤ 0. 01», «қателер + 0 артық емес. prod қатысты 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 (көлеңкеге лақтыру).
Span linkovka: shadow-трасса жауынгерлік link алады.

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 Кэш/ұсыныстар

prod және shadow кэштерін араластырмаңыз.
ML/ұсынушылар үшін онлайн-метриканы және оффлайн-метриканы бөлек салыстыру; кіріс белгілерінің drift-ін қадағалаңыз.

7. 3 Сыртқы провайдерлер

Клиенттерді record-only/stub режимімен айналдырыңыз.
Есеп айырысу сервистері (салықтар, бағамдар) үшін - екі тарап үшін анықтамалықтардың суретін жазыңыз.

8) Канареялық/blue-green

Shadow: пайдаланушылар үшін нөлдік тәуекел, бірақ нақты сайд әсерлері жоқ; логика мен перф үшін өте жақсы.
Canary: жаңа нұсқадан нақты жауаптардың аз пайызы; дайын қайтару стратегиясын және SLA талап етеді.
Blue-green: валидациядан кейін дереу ауыстырып қосу; Shadow көбінесе оның алдында қолданылады.

9) Енгізу жоспары (GitOps-стиль)

1. Мақсаттар мен өлшемдер: қандай инварианттар мен рұқсаттарды тексереміз, қандай SLO айырмашылықтарға.
2. Трассировка: Correlation-ID, бөлінген трейс-линкалар.
3. Прокси теңшеу: mirror саясаты, семплеу, redaction.
4. Оқшаулау: құмсалғыш ДБ/кэш, жанама тұйықтағыштар, қамыр кілттері.
5. Компаратор: қалыпқа келтіру, ignore-маптар, инварианттар, есептер.
6. Жүктеме жоспары: жасыл метриктер кезінде 1-5% -дан бастау, 20-50% -ға дейін өсу.
7. Байқалуы: «айырмашылықтар/перф/көлем» дашбордтары.
8. Шығу критерийлері: «0 сыни айырмашылықтар 48 сағ», «қателер prod-дан кем емес», «перф ± 5% шегінде».
9. canary ауысу: қауіпсіз үлесімен және автоматты гард ережелерімен нақты жауаптарды қосу.

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-саясат)

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 сыртқа жазады: көлеңкеден нақты төлемдер/хабарламалар.
Жалпы кэш/жалпы кезектер: айқаспалы әсер ету және ластану.
Қалыпқа келтірудің болмауы: сағат/кілттердің тәртібіне байланысты байттық диффуздар «қызарады».
Өте жоғары пайыз: перф prod деградациясы.
Ұзақ «мәңгілік көлеңке»: екінші жүйе бөлек өмір сүреді және шындықпен бөлінеді.

12) Shadow режимін іске қосу

• Прокси үлесімен mirror және redaction орнатылған.
• Көлеңке оқшауланған: ДБ/кэштер/сыртқы интеграциялар - тек readonly/stub.
• Барлық жерде Correlation-ID лақтырылады; трассировкалар сызылады.
• Компаратор ignore/normalize және инварианттарды тексере алады.
• Айырмашылықтар мен жүктемеге арналған дашбордтар мен алерталар.
• Бағыттар/тенанттар бойынша тұқымдастыру; лимиттер және back-pressure.
• «Жасыл жарық» шақтамалары мен өлшемдері анықталды.
• canary/blue-green көшу және қайтару жоспары.

13) FAQ

Q: Shadow A/B айырмашылығы қандай?
A: A/B-де екі нұсқа да пайдаланушыларға жауаптар қайтарады (сплит-эксперимент), Shadow-да жаңа нұсқа пайдаланушыға әсер етпейді - оның жауаптары тек талданады.

Q: POST/PUT қоюға бола ма?
А: Иә, егер зиянды оқшаулау (stub) және демпотенттілік кепілдендірілген болса. Жиі GET бастап, одан кейін кеңейтеді.

Q: Егер элементтердің тәртібі белгіленбесе, жауаптарды қалай салыстыруға болады?
A: Салыстыру алдында тұрақты кілт бойынша сұрыптаңыз немесе көптік ретінде/кілттер бойынша салыстыру.

Q: ДБ репликаларының кідірістерімен не істеу керек?
А: «Салыстыру терезелерін» және анықтамалықтардың снапшоттарын енгізіңіз; нәтижелерді «қабырғамен» емес, нұсқалар бойынша біріктіріңіз.

14) Қорытынды

Shadow-трафик - бұл «өнімнің ауыртпалықсыз дайындығы»: нақты жүктеме, пайдаланушылар үшін нөлдік тәуекел, айырмашылықтарды егжей-тегжейлі талдау. Табыс оқшаулаумен, дұрыс тұқымдастырумен, сапалы компаратормен және бақылаушылықпен анықталады. Ұсынылған жоспарды орындағанда, сіз canary/blue-green релиздеріне сенімді түрде жол ашатын және архитектураның эволюциясын жылдамдататын ойнатылатын тәжірибеге ие боласыз.