Trafic Shadow et comparaison

1) Qu'est-ce que le trafic Shadow et pourquoi il est nécessaire

Le trafic Shadow (alias traffic mirroring/dark launch) est un « lancement » sécurisé de demandes/événements réels pour une nouvelle version du service en parallèle avec la version de production sans impact sur les utilisateurs. Les résultats de la nouvelle version ne sont pas retournés au client et ne produisent pas d'effets externes, mais sont collectés dans le système de comparaison.

• Vérification de l'interopérabilité : schémas, contrats, logique d'entreprise.
• Évaluation des performances : latence, stabilité sous charge réelle.
• Détection de dérive : différences dans les réponses, les distributions, le taux d'erreur.
• Préparation des sorties canaries : réduire les risques avant un changement de trafic réel.

• Réécrire le noyau/algorithmes, migrer la base de données/cache, passer à un autre rantime/SDK, changer de fournisseur d'API externe.

2) Modèles architecturaux de trafic Shadow

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

Le proxy accepte la demande → donne la réponse de combat de l'ancienne version → met en miroir asynchrone la copie de la demande dans l'ombre.

Convient aux API synchrones.
Contrôle de lobe/filtre miroir : par chemin, header, utilisateur, 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 Bus d'événements (Kafka/Flux)

• Le producteur écrit comme d'habitude → les consumers prod lisent.
• Parallèlement, l'ombre (shadow-pipeline) lit le même flux dans un bac à sable distinct.

Options : MirrorMaker/Replicator, dual-write (attention), bridges « source → prod + shadow ».

2. 3 Replayer (enregistrement/lecture)

Un instantané de requêtes/trajets réels (accès PCAP/NGINX, taps gRPC) → une lecture en « ombre » avec un rythme contrôlé.

2. 4 « Ombre synthétique »

La génération d'un profil de charge à partir des logs prod + phase de remplissage des cas de bord est utile pour les restrictions de confidentialité.

3) Isolation de l'état et des effets side

La règle d'or : l'ombre ne change pas le monde extérieur.

Reed-only accès à la base de données/cache ou un bac à sable séparé (snapshot/réplique).
L'interdiction partant побочек : les paiements, les lettres, пуши, webhooks → stub/blackhole/record-only.
Idempotence au niveau des commandes/POST : Shadow ne doit pas être enregistré comme une répétition de l'original.
Masquage PII/secrets, jetons de fournisseurs de test.

Exemple : masquage dans un miroir

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

4) Stratégies d'échantillonnage et charge sûre

Part du trafic : 1-10 % au départ ; augmenter si le v2 correspond au budget.
Critères de sélection : par itinéraire, utilisateur, taille de la requête, type d'opération (GET-s est plus sûr).
Budget perf : la mise en miroir ne devrait pas augmenter le service de combat p95/p99. L'ombre est toujours asynchrone.
Back-pressure : en cas de surchauffe de la chaîne de shadow, c'est l'ombre qui tape, pas les demandes de combat.
Temps : minimum 24-72 heures pour couvrir les modèles journaliers et de pointe.

5) Comparaison des résultats : méthodes et niveaux

5. 1 Niveaux de comparaison

1. Diff byte : corps de réponse/événements un-en-un. C'est simple, mais fragile (temps, ordre des clés).
2. Diff sémantique : normalisons et trions les champs en ignorant les épémérides (traceId, timestamps, counters).
3. Invariants d'affaires : si les montants, les statuts, les quantités, les limites sont les mêmes.
4. Analyse statistique : les distributions des métriques correspondent-elles ? (p50/p95, test KS, χ ² pour les catégories).

5. 2 Politique de comparaison

Masques/ignore-listes de champs (par exemple, 'updatedAt', 'etag').
Précision : erreur absolue/relative pour les nombres (par exemple, ± 1e-6).
Tolérances (bandes de tolerance) : "différence de prix ≤ 0. 01 », « erreurs au maximum + 0. 1 % par rapport à prod.

Pseudo-code du comparateur

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 Comparaison des zapros↔otvet

Obligatoire pour Correlation-ID.
Linkovka spanov : La piste shadow reçoit un lien pour le combat.

6) Observabilité et artefacts de comparaison

• `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}'
• Logs Diffs : delta JSON compact par clé.
• Reporting : rapport quotidien avec le top N des écarts, cartes thermiques par itinéraire/tenants.
• UI « diff explorer » : filtres par type, itinéraire, champ, export vers CSV.

7) Cas spéciaux et subtilités

7. 1 Cohérence et consistance

Les demandes de shadow peuvent arriver plus tard/plus tôt ; normaliser selon les versions/heures (Lamport/vecteur) ou les tolérances de fenêtre.
Read-after-write : une ombre avec read-replica sans réplication synchrone donnera des réponses différentes - comparer à travers les fenêtres de lag.

7. 2 Cache/recommandations

Ne mélangez pas les caches prod et shadow.
Pour les ML/recommandeurs, comparer les métriques en ligne et les métriques hors ligne séparément ; surveillez le drift des caractéristiques d'entrée.

7. 3 Fournisseurs externes

Enveloppez les clients en mode record/stub.
Pour les services de calcul (taxes, cours) - Capturez un instantané des guides pour les deux parties.

8) Juxtaposition avec canaris/bleu-vert

Shadow : zéro risque pour les utilisateurs, mais il n'y a pas d'effets side réels ; parfait pour la logique et la perf.
Canary : petit pourcentage de réponses réelles de la nouvelle version ; nécessite une stratégie de retrait et une SLA prêtes à l'emploi.
Bleu-vert : commutation instantanée après validation ; Shadow est souvent utilisé devant lui.

9) Plan de mise en œuvre (style GitOps)

1. Objectifs et métriques : quels invariants et tolérances vérifient quel SLO pour les écarts.
2. Trace : Correlation-ID, liens distribués.
3. Configuration proxy : stratégie mirror, échantillonnage, redaction.
4. Isolation : bac à sable OBD/cache, bouchon d'épingle, clés de test.
5. Comparateur : normalisation, ignore-maps, invariants, rapports.
6. Plan de charge : départ de 1-5 %, croissance jusqu'à 20-50 % avec des métriques vertes.
7. Observabilité : dashboards « divergence/perf/volume ».
8. Critères de sortie : « 0 écarts critiques de 48 h », « erreurs pas pire que prod », « perf à ± 5 % ».
9. Aller au canary : inclure des réponses réelles avec des parts sécurisées et des règles de garde automatiques.

10) Exemples de configurations

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

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

10. 3 Règles de comparaison (politique 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-modèles

Shadow écrit à l'extérieur : paiements réels/notifications de l'ombre.
Cache/files d'attente partagées : impact croisé et pollution.
Absence de normalisation : les diffs d'octets sont « colorés » en raison de l'ordre des heures/clés.
Pourcentage trop élevé en marche : dégradation de la perf prod.
Longue « ombre éternelle » : le second système vit séparément et diverge de la réalité.

12) Chèque de démarrage du mode Shadow

• Le mandataire a configuré mirror avec partage et redaction.
• Ombre isolée : Base de données/cache/intégrations externes - uniquement readonly/stub.
• Partout, Correlation-ID est maudite ; les traces sont linkées.
• Le comparateur sait ignore/normalize et vérifier les invariants.
• Dashboards et alertes sur les divergences et la charge.
• Semer sur les itinéraires/tenants ; limites et back-pression.
• Les tolérances et critères du feu vert sont définis.
• Plan de transition vers canary/blue-green et retour en arrière.

13) FAQ

Q : En quoi Shadow diffère-t-il de A/B ?
R : Dans A/B, les deux versions renvoient les réponses aux utilisateurs (expérience de split), dans Shadow, la nouvelle version n'affecte pas l'utilisateur - ses réponses sont seulement analysées.

Q : Est-il possible de shadower POST/PUT ?
R : Oui, si l'isolation des épines (stub) et l'idempotence sont garanties. Ils commencent souvent par GET, puis étendent.

Q : Comment comparer les réponses si l'ordre des éléments n'est pas fixé ?
R : Trier par clé stable avant de comparer ou comparer comme multiple/par clé.

Q : Que faire avec les répliques DB retardées ?
A : Entrez les « fenêtres de comparaison » et les snapshots des manuels ; agrégez les résultats par version plutôt que par « sténochèse ».

14) Résultats

Le trafic shadow est une « répétition indolore de la production » : charge réelle, risque zéro pour les utilisateurs, analyse détaillée des écarts. Le succès est déterminé par l'isolation, l'échantillonnage correct, le comparateur de qualité et l'observation. En suivant le plan proposé, vous obtiendrez une pratique reproductible qui relie avec confiance le chemin vers les versions canary/blue-green et accélère l'évolution de l'architecture.