Schattenverkehr und Vergleich

1) Was ist Shadow-Traffic und warum wird er benötigt?

Shadow-Traffic (auch bekannt als Traffic Mirroring/Dark Launch) ist ein sicherer „Run“ von realen Anfragen/Ereignissen auf eine neue Version des Dienstes parallel zur Produktionsversion ohne Auswirkungen auf die Nutzer. Die Ergebnisse der neuen Version werden nicht an den Client zurückgegeben und erzeugen keine externen Seiteneffekte, sondern werden in einem Vergleichssystem gesammelt.

• Überprüfung der Kompatibilität: Schemata, Verträge, Geschäftslogik.
• Leistungsbeurteilung: Latenz, Belastbarkeit unter Reallast.
• Driftdetektion: Unterschiede in Antworten, Verteilungen, Fehlerraten.
• Vorbereitung auf kanarische Releases: Risikominderung vor einer echten Verkehrsverlagerung.

• Neuschreibung des Kernels/der Algorithmen, DB/Cachemigrationen, Umstellung auf ein anderes Rantime/SDK, Anbieterwechsel der externen API.

2) Architektonische Muster des Schattenverkehrs

2. 1 L7-Proxy/Gateway (HTTP/gRPC)

Der Proxy akzeptiert die Anfrage → gibt eine Kampfantwort von der alten Version → spiegelt asynchron eine Kopie der Anfrage in einen „Schatten“.

Geeignet für synchrone APIs.
Steuerung des Share/Mirroring-Filters: unterwegs, Header, User, 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 Event-Busse (Kafka/Streams)

• Der Produzent schreibt wie gewohnt → die consumers prod lesen.
• Parallel dazu liest der „Schatten“ (Schatten-Pipeline) den gleichen Strom in eine separate Sandbox.

Optionen: MirrorMaker/Replicator, Dual-Write (vorsichtig), „Source → Prod + Shadow“ -Bridges.

2. 3 Replayer (Aufnahme/Wiedergabe)

Momentaufnahme der realen Anfragen/Traces (PCAP/NGINX-Zugang, gRPC-Taps) → Wiedergabe im „Schatten“ mit kontrolliertem Tempo.

2. 4 „Synthetischer Schatten“

Generierung eines Lastprofils aus Prod-Logs + Dosierphasen von Kantenkoffern - sinnvoll bei Datenschutzeinschränkungen.

3) Isolierung von Zustands- und Seiteneffekten

Die goldene Regel: Der Schatten verändert die Außenwelt nicht.

Reed-onli Zugriff auf DB/Cache oder separate Sandbox (Snapshot/Replikat).
Verbot von ausgehenden Spoofs: Zahlungen, Briefe, Puschis, Webhooks → stub/blackhole/record-only.
Idempotenz auf Befehls-/POST-Ebene: Schatten sollte nicht als Wiederholung des Originals aufgezeichnet werden.
Maskierung von PII/Secrets, Token der Testanbieter.

Beispiel: Maskierung im Spiegel

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

4) Sampling-Strategien und sichere Belastung

Verkehrsanteil: 1-10% zum Start; erhöhen, wenn v2 in das Budget passt.
Auswahlkriterien: nach Route, Benutzer, Größe der Anfrage, Art der Operation (GET-s sind sicherer).
Perf-Budget: Die Spiegelung sollte p95/p99 des Kampfdienstes nicht erhöhen. Der Schatten ist immer asynchron.
Back-pressure: Wenn die Schattenkette überhitzt ist, wird der Schatten fallen gelassen, nicht die Kampfanfragen.
Zeit: mindestens 24-72 Stunden, um Tages- und Spitzenmuster abzudecken.

5) Vergleich der Ergebnisse: Methoden und Ebenen

5. 1 Vergleichsstufen

1. Byte-Diff: Der Körper der Eins-zu-Eins-Antwort/des Ereignisses. Einfach, aber zerbrechlich (Zeitstempel, Schlüsselreihenfolge).
2. Semantisches Diff: Wir normalisieren und sortieren die Felder, ignorieren die Epemeriden (traceId, timestamps, counters).
3. Geschäftsinvarianten: ob die gleichen Beträge, Status, Mengen, Grenzen.
4. Statistische Analyse: Stimmen die Verteilungen der Metriken überein? (p50/p95, KS-Test, χ ² kategorisch).

5. 2 Vergleichspolitik

Masken/ignore-Feldlisten (z.B., 'updatedAt', 'etag').
Genauigkeit: absoluter/relativer Fehler für Zahlen (z. B. ± 1e-6).
Toleranzbänder: "Preisdifferenz ≤ 0. 01“, „Fehler nicht mehr als + 0. 1% relativ zu prod".

Pseudocode des Komparators

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 Vergleich der zapros↔otvet

Correlation-ID (in den Schatten werfen) ist erforderlich.
Linking Spans: Die Schattenspur erhält einen Link zum Kampf.

6) Beobachtbarkeit und Vergleichsartefakte

• `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}“
• Diffusionsprotokolle: kompakte JSON-Deltas durch Schlüssel.
• Berichterstattung: Tagesbericht mit Top-N-Diskrepanzen, Heatmaps nach Routen/Tenanten.
• UI „diff explorer“: Filter nach Typ, Route, Feld, Export in CSV.

7) Sonderfälle und Feinheiten

7. 1 Konsistenz und Konsistenz

Shadow-Anfragen können später/früher kommen; Normalisieren nach Versionen/Stunden (Lamport/Vector) oder Fenstertoleranzen.
Read-after-write: Ein Schatten mit Read-Replica ohne synchrone Replikation liefert unterschiedliche Antworten - vergleichen über Lag-Fenster.

7. 2 Cache/Empfehlungen

Mischen Sie die Caches prod und shadow nicht.
Vergleichen Sie für ML/Recommenders Online-Metriken und Offline-Metriken separat; Achten Sie auf drift Eingabemerkmale.

7. 3 Externe Anbieter

Wickeln Sie die Clients im record-only/stub-Modus ein.
Für Abrechnungsdienstleistungen (Steuern, Kurse) - erfassen Sie eine Momentaufnahme der Verzeichnisse für beide Parteien.

8) Vergleich mit Kanarienvögeln/blau-grün

Shadow: Null Risiko für Benutzer, aber keine echten Seiteneffekte; Perfekt für Logik und Perf.
Canary: ein kleiner Prozentsatz der tatsächlichen Antworten aus der neuen Version; erfordert eine vorgefertigte Rollback- und SLA-Strategie.
Blau-grün: sofortiges Umschalten nach Validierung; Schatten wird oft davor verwendet.

9) Implementierungsplan (GitOps-Stil)

1. Ziele und Metriken: Welche Invarianten und Toleranzen, welche SLO auf Abweichungen prüfen.
2. Tracing: Korrelations-IDs, verteilte Trace-Links.
3. Proxy-Einstellung: Spiegelungsrichtlinie, Sampling, Redaktion.
4. Isolierung: Sandbox DB/Cache, Nebenstopfen, Testschlüssel.
5. Komparator: Normalisierung, Ignore-Maps, Invarianten, Berichte.
6. Lastplan: Start von 1-5%, Anstieg auf 20-50% bei grünen Metriken.
7. Beobachtbarkeit: Dashboards „Diskrepanzen/Perf/Volumen“.
8. Ausstiegskriterien: „0 kritische Diskrepanzen von 48 Stunden“, „Fehler sind nicht schlechter als prod“, „perf innerhalb von ± 5%“.
9. Übergang zum Kanarischen: Einbeziehung realer Antworten mit sicherem Anteil und automatischen Gard-Regeln.

10) Beispiele für Konfigurationen

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

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

10. 3 Vergleichsregeln (Yaml-Politik)

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-Muster

Schatten schreibt nach außen: echte Zahlungen/Benachrichtigungen aus dem Schatten.
Geteilter Cache/geteilte Warteschlangen: Quereinfluss und Kontamination.
Fehlende Normalisierung: Byte-Diffs „färben“ aufgrund der Uhr/Schlüsselreihenfolge.
Zu hoher Prozentsatz auf dem Sprung: Abbau von Perf prod.
Der lange „ewige Schatten“: Das zweite System lebt getrennt und steht im Widerspruch zur Realität.

12) Checkliste zum Start des Shadow-Modus

• Der Proxy hat mirror mit share und redaction konfiguriert.
• Schatten isoliert: DB/Caches/externe Integrationen - nur readonly/stub.
• Überall wird die Correlation-ID verworfen; Traces werden verknüpft.
• Der Komparator kann ignore/normalize und die Invarianten überprüfen.
• Dashboards und Warnungen über Abweichungen und Belastungen.
• Sampling nach Routen/Tenanten; Limits und Back-Pressure.
• Toleranzen und Kriterien für „grünes Licht“ sind definiert.
• Plan für den Übergang zu Canary/Blue-Green und Rollback.

13) FAQ

F: Wie unterscheidet sich Shadow von A/B?
A: In A/B geben beide Versionen Antworten an die Benutzer zurück (Split-Experiment), in Shadow hat die neue Version keine Auswirkungen auf den Benutzer - seine Antworten werden nur analysiert.

Q: Ist es möglich, POST/PUT zu beschädigen?
A: Ja, wenn die Isolierung von Seitenteilen (Stub) und Idempotenz garantiert ist. Oft beginnen sie mit GET, dann erweitern sie.

F: Wie vergleiche ich die Antworten, wenn die Reihenfolge der Elemente nicht festgelegt ist?
A: Sortieren Sie nach stabilem Schlüssel vor dem Vergleich oder vergleichen Sie als Menge/nach Schlüssel.

Q: Was tun mit den Verzögerungen der DB-Repliken?
A: Geben Sie „Vergleichsfenster“ und Verzeichnisse ein; Aggregieren Sie die Ergebnisse nach Version, nicht nach „Stenochase“.

14) Ergebnisse

Der Schattenverkehr ist eine „schmerzlose Probe der Produktion“: echte Belastung, null Risiko für die Nutzer, detaillierte Analyse der Diskrepanzen. Erfolg wird durch Isolation, korrektes Sampling, qualitativen Komparator und Beobachtbarkeit bestimmt. Wenn Sie dem vorgeschlagenen Plan folgen, erhalten Sie eine reproduzierbare Praxis, die den Weg zu Canary/Blue-Green-Releases sicher überbrückt und die Entwicklung der Architektur beschleunigt.