Traffico e confronto Shadow

1) Cos'è il traffico Shadow e perché è necessario

Il traffico Shadow (traffic mirroring/dark launch) è un «controllo» sicuro delle richieste/eventi reali per una nuova versione del servizio parallela alla versione di produzione senza influire sugli utenti. I risultati della nuova versione non vengono restituiti al cliente e non producono effetti side esterni, ma vengono raccolti nel sistema di confronto.

• Verifica di compatibilità: schemi, contratti, logiche aziendali.
• Valutazione delle prestazioni: latitanza, resistenza a carico reale.
• Rilevamento della deriva: differenze di risposta, distribuzione, frequenza di errori.
• Preparazione per i rilasci canari: riduzione dei rischi prima del cambio di traffico reale.

• Riscrivere kernel/algoritmi, migrare database/cache, passare a un altro rent/SDK, cambiare il provider API esterno.

2) Cartelli di Shadow architettonic

2. 1 proxy/gateway L7 (HTTP/gRPC)

Proxy accetta la richiesta e dà una risposta di guerra dalla vecchia versione del specchia asincrona la copia della richiesta in ombra.

Adatto per API sincrona.
Controllo della quota/filtro di mirroring lungo il percorso, l'heder, l'utente, il tenante.

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 Pneumatici eventi (Kafka/Flussi)

• Il produttore scrive le consolle prod come al solito.
• Parallelamente, shadow-pipeline legge lo stesso flusso in una singola cassetta di sabbia.

Opzioni: , dual-write (attenzione), bridge «source-prod + shadow».

2. 3 Replayer (scrittura/riproduzione)

Un'istantanea di query/trailer reali (PCAP/NGINX access, gRPC taps) → la riproduzione in un'ombra a ritmo controllato.

2. 4 «Ombra sintetica»

La generazione di un profilo di carico da prod-logs + fase di completamento delle valigette di bordo è utile per le restrizioni di privacy.

3) Isolamento dello stato e effetti side

Regola d'oro, l'ombra non cambia il mondo esterno.

Reed onley accesso a database/cache o arenaria separata (snapshot/replica).
I pagamenti, le e-mail, i pass, i webhooks → stub/blackhole/record-only sono vietati.
Idampotenza a livello di comando/POST: Shadow non deve essere registrato come ripetizione originale.
Maschera PII/segreti, token provider.

Esempio di maschera nel mirror

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

4) Strategie di semilibertà e carico sicuro

Quota di traffico: 1-10% alla partenza; aumentare se v2 è in bilico.
Criteri di selezione: percorso, utente, dimensione della query, tipo di operazione (GET-E più sicuro).
Budget perf: il mirroring non deve aumentare il p95/p99 del servizio di combattimento. L'ombra è sempre asincrona.
Back-pressure - Quando si surriscalda una catena shadow, si sprigiona l'ombra, non le richieste di combattimento.
Tempo minimo di 24-72 ore per coprire i pattern giornalieri e i picchi.

5) Confronto dei risultati: metodi e livelli

5. 1 Livelli di confronto

1. Diff byte - corpo risposta/evento uno-in-uno. Semplice, ma fragile (minutaggio, ordine delle chiavi).
2. Diffide semantico: normalizziamo e ordiniamo i campi, ignoriamo gli epemeridi (traceId, timestamps, counters).
3. Invarianti aziendali: gli stessi importi, gli stessi stati, le stesse quantità, i stessi limiti.
4. Analisi statistiche: la distribuzione delle metriche corrisponde? (p50/p95, KS test, mq per categorico).

5. 2 Criteri di confronto

Maschere/ignore-elenchi di campi (ad esempio, «updatedAt», «etag»).
Precisione: margine di errore assoluto/relativo per i numeri (ad esempio, © 1e-6).
Tolleranze (tolerance bands) - «Differenza di prezzo». 01», «errori non più di + 0. 1% rispetto a prod".

Pseudo-codice del comparatore

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 Mappatura zapros↔otvet

È obbligatorio Correlation-ID.
La pista shadow riceve link sulla pista di combattimento.

6) Osservabilità e manufatti di confronto

• `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}'
• I fogli dei diffusi sono compatti JSON delta in chiave.
• Report: report giornaliero con la top N delle variazioni, mappe termiche su percorsi/tenanti.
• UI «diff explorer» - Filtri per tipo, percorso, campo, esport in CSV.

7) Casi speciali e sottilità

7. 1 Sequenza e consistenza

Le richieste Shadow possono arrivare dopo/prima; Regolate le versioni/orologi (Lamport/vector) o le tolleranze della finestra.
Read-after-write - L'ombra read-replica senza replica sincrona fornisce risposte diverse: confrontare attraverso le finestre di doppio.

7. 2 Cache/raccomandazioni

Non mescolare la cache prod e shadow.
Per ML/consulenti confrontare le metriche online e le metriche off-line separatamente; tieni d'occhio i segni di ingresso draft.

7. 3 Provider esterni

Avvolgere i client record-only/stub-modalità.
Per i servizi di calcolo (tasse, corsi) - Registra un'istantanea delle guide per entrambe le parti.

8) Mappatura con canarie/blue-green

Shadow: rischio zero per gli utenti, ma nessun effetto side reale; Perfetto per logica e perfido.
Canary: una piccola percentuale delle risposte reali dalla nuova versione; richiede una strategia di recupero pronta e SLA.
Blue-green: cambio istantaneo dopo la convalida Shadow è spesso utilizzato prima di esso.

9) Piano di implementazione (GitOps)

1. Obiettivi e metriche: quali invarianti e tolleranze verificare quale SLO per le discrepanze.
2. Traccia: Correlation-ID, trace distribuite.
3. Configurazione proxy: criteri mirror, semilibertà, redaction.
4. Isolamento: cassetta di sabbia/cache, stub collaterale, chiavi di prova.
5. Comparatore: normalizzazione, ignore-maps, invarianti, report.
6. Piano di carico: partenza da 1-5%, crescita fino al 20-50% con metriche verdi.
7. Osservabilità: dashboard «variazioni, perf/volume».
8. I criteri di output sono «0 discrepanze critiche 48 ore», «errori uguali a prod», «perf entro il + 5%».
9. Passare al canary: includere risposte reali con una quota sicura e regole di controllo automatiche.

10) Esempi di configurazione

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

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

10. 3 Regole di confronto (criteri 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) Anti-pattern

Shadow scrive all'esterno: pagamenti/notifiche reali dall'ombra.
La cache/le code condivise includono impatto incrociato e inquinamento.
Nessuna normalizzazione: i diffusi di byte sono «colorati» a causa di ore/ordine delle chiavi.
Percentuale troppo alta in movimento: degrado della perpa prod.
Una lunga ombra eterna: il secondo sistema vive separato e si separa dalla realtà.

12) Assegno foglio di avvio modalità Shadow

• Il proxy è configurato con mirror con quota e redaction.
• Ombra isolata: database/cache/integrazioni esterne - solo readonly/stub.
• Correlation-ID ovunque; I tratti vengono linciati.
• Il comparatore sa ignore/normalize e controllare gli invarianti.
• Dashboard e alert su discrepanze e carico di lavoro.
• Sempilamento su percorsi/tenanti; limiti e back-pressure.
• Sono stati definiti i criteri di tolleranza e luce verde.
• Piano di transizione canary/blue-green e ripristino.

13) FAQ

Q: In cosa Shadow è diverso da A/B?
A: In A/B entrambe le versioni restituiscono le risposte agli utenti (esperimento split), in Shadow la nuova versione non influisce sull'utente - le risposte vengono solo analizzate.

Q: Puoi usare POST/PUT?
A: Sì, se è garantito l'isolamento degli avvisi (stub) e l'idepotenza. Spesso iniziano con GET, poi espandono.

Q: Come si confrontano le risposte se l'ordine degli elementi è nefisso?
A: Ordinare per chiave sostenibile prima di confrontare o confrontare come più o più chiavi.

Cosa fare con i ritardi delle repliche del database?
A: Immettere le finestre di confronto e le finestre di riferimento. aggregare i risultati in base alle versioni, non in base alla parete.

14) Riepilogo

Il traffico Shadow è «prova di produzione indolore»: carico reale, rischio zero per gli utenti, analisi dettagliata delle divergenze. Il successo è determinato dall'isolamento, dalla corretta semilibertà, da un comparatore di qualità e dall'osservabilità. Seguendo il piano proposto, si otterrà una pratica riproduttiva che guiderà con sicurezza la strada verso le release canary/blue-green e accelererà l'evoluzione dell'architettura.