Tráfico de sombras y comparación

1) Qué es el tráfico de sombras y por qué es necesario

El tráfico de sombras (también conocido como traffic mirroring/dark launch) es una «ejecución» segura de solicitudes/eventos reales a la nueva versión del servicio en paralelo con la versión de producción sin afectar a los usuarios. Los resultados de la nueva versión no se devuelven al cliente ni producen efectos externos, sino que se recogen en un sistema de comparación.

• Verificación de compatibilidad: esquemas, contratos, lógica empresarial.
• Evaluación del rendimiento: latencia, resistencia bajo carga real.
• Detección de la deriva: diferencias en las respuestas, distribuciones, tasa de error.
• Preparación para lanzamientos canarios: reducir el riesgo antes de un cambio real de tráfico.

• Reescribir el núcleo/algoritmos, migrar la DB/caché, cambiar a otro rantime/SDK, cambiar el proveedor de la API externa.

2) Patrones arquitectónicos de tráfico de sombras

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

El proxy acepta la solicitud → da una respuesta de combate de la versión anterior → espejea asíncrónicamente una copia de la solicitud en una «sombra».

Adecuado para API sincrónicas.
Control de la fracción/filtro de espejado: en el camino, header, usuario, 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 de eventos (Kafka/Streams)

• El productor escribe como de costumbre → los consumeres prod leen.
• Paralelamente, la «sombra» (shadow-pipeline) lee el mismo flujo en una caja de arena separada.

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

2. 3 Replayer (grabación/reproducción)

Una instantánea de consultas/tracks reales (PCAP/NGINX access, gRPC taps) → una reproducción en «sombra» con un tempo controlado.

2. 4 «Sombra sintética»

Generación de un perfil de carga a partir de prod-logs + fase de llenado de casos de borde - útil para restricciones de privacidad.

3) Aislamiento de estado y efectos secundarios

Regla dorada: la sombra no altera el mundo exterior.

Acceso al CD/caché o a una caja de arena independiente (snapshot/réplica).
Prohibición de los subproductos salientes: pagos, cartas, pistolas, webhooks → stub/blackhole/record-only.
Idempotencia a nivel de comando/POST: Shadow no debe registrarse como una repetición del original.
Enmascaramiento de PII/secretos, tokens de proveedores de pruebas.

Ejemplo: enmascaramiento en espejo

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

4) Estrategias de muestreo y carga segura

Proporción de tráfico: 1-10% al inicio; aumentar si v2 se ajusta al presupuesto.
Criterios de selección: por ruta, usuario, tamaño de la consulta, tipo de operación (GET más seguros).
Presupuesto de perforación: el espejado no debe aumentar el servicio de combate p95/p99. La sombra siempre es asíncrona.
Back-pressure: Cuando la cadena de sombras se sobrecalienta, golpea la sombra, no las peticiones de combate.
Tiempo: un mínimo de 24-72 horas para cubrir los patrones diarios y máximos.

5) Comparación de resultados: métodos y niveles

5. 1 Niveles de comparación

1. Diff de bytes: cuerpo de respuesta/eventos uno en uno. Simple, pero frágil (timestemps, orden de las llaves).
2. Diff semántico: normalizamos y ordenamos los campos, ignoramos los epeméridos (traceId, timestamps, counters).
3. Invariantes empresariales: si las cantidades, los estados, las cantidades, los límites son los mismos.
4. Análisis estadístico: ¿coinciden las distribuciones métricas? (p50/p95, prueba KS, χ ² a los categóricos).

5. 2 Política de comparación

Máscaras/ignore-listas de campos (por ejemplo, 'updatedAt', 'etag').
Precisión: error absoluto/relativo para los números (por ejemplo, ± 1e-6).
Tolerance Bands: "diferencia de precio ≤ 0. 01», «no hay más errores + 0. 1% relativo a prod'.

Pseudocódigo de comparación

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 Comparación zapros↔otvet

Es obligatorio Correlation-ID (caminar en la sombra).
Linchamiento de los durmientes: la pista de sombras recibe un enlace para la batalla.

6) Observabilidad y artefactos de comparación

• `shadow_requests_total{route,...}`
• `shadow_discrepancies_total{type=byte|semantic|invariant}`
• `shadow_error_ratio` и `shadow_slo_breach_total`
• Perfume: 'shadow _ latencies _ ms {p50, p95, p99}'
• Logs de diffes: JSON delta compacto por llaves.
• Informes: informe diario con las principales N discrepancias, mapas térmicos en rutas/tenantes.
• IU «diff explorer»: filtros por tipo, ruta, campo, exportación a CSV.

7) Ocasiones y sutilezas especiales

7. 1 Secuencia y consistencia

Las solicitudes shadow pueden llegar más tarde/antes; normalice según versiones/horas (Lamport/vector) o las tolerancias de la ventana.
Read-after-write: una sombra con read-replica sin replicación síncrona dará diferentes respuestas - comparar a través de las ventanas de registro.

7. 2 Caché/recomendaciones

No mezcle cachés prod y shadow.
Para ML/recomendadores, compare métricas en línea y métricas offline por separado; vigile las señales de entrada drift.

7. 3 Proveedores externos

Envuelva los clientes con el modo record-only/stub.
Para servicios de liquidación (impuestos, cursos) - capture una instantánea de los manuales para ambas partes.

8) Comparación con canario/azul-verde

Shadow: riesgo cero para los usuarios, pero no hay efectos de lado reales; perfecto para la lógica y la perforación.
Canary: un pequeño porcentaje de respuestas reales de la nueva versión; requiere una estrategia de reversión lista y SLA.
Azul-verde: conmutación instantánea después de la validación; Shadow se utiliza a menudo delante de él.

9) Plan de implementación (estilo GitOps)

1. Objetivos y métricas: qué invariantes y tolerancias verificamos qué SLO para discrepancias.
2. Track: Correlation-ID, líneas de acceso distribuidas.
3. Configuración proxy: política mirror, sampling, redaction.
4. Aislamiento: caja de arena DB/caché, tapones de subproductos, llaves de prueba.
5. Comparador: normalización, ignore-mapas, invariantes, informes.
6. Plan de carga: inicio del 1-5%, crecimiento del 20-50% con métricas verdes.
7. Observabilidad: dashboards «discrepancias/perfume/volumen».
8. Criterios de salida: "0 discrepancias críticas 48 h", "errores no peores prod'," perfume dentro de ± 5% ".
9. Ir al canario: habilita respuestas reales con una cuota de seguridad y reglas de gard automáticas.

10) Ejemplos de configuraciones

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

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

10. 3 Reglas de comparación (yaml-policy)

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

Shadow escribe hacia fuera: pagos/notificaciones reales desde la sombra.
Caché común/colas comunes: impacto cruzado y contaminación.
Falta de normalización: los diffs de bytes se «enrojecen» debido a las horas/orden de las llaves.
Porcentaje demasiado alto con la marcha: degradación de la perforación prod.
Una larga «sombra eterna»: el segundo sistema vive separado y está en desacuerdo con la realidad.

12) Lista de comprobación de inicio del modo Shadow

• El proxy tiene un mirror configurado con acciones y redacciones.
• Sombra aislada: DB/caché/integraciones externas - sólo readonly/stub.
• El ID de corrección se ejecutará en todas partes; los rastros se enlazan.
• El comparador sabe ignore/normalize y comprobar invariantes.
• Dashboards y alertas de discrepancias y carga.
• Sampling a lo largo de rutas/tenantes; límites y back-pressure.
• Se definen las tolerancias y los criterios de «luz verde».
• Plan de transición a canario/azul-verde y retroceso.

13) FAQ

P: ¿En qué se diferencia Shadow de A/B?
R: En A/B, ambas versiones devuelven respuestas a los usuarios (experimento de división), en Shadow, la nueva versión no afecta al usuario - sus respuestas sólo se analizan.

P: ¿Se puede hacer una broma POST/PUT?
R: Sí, si se garantiza el aislamiento de los subproductos (stub) y la idempotencia. A menudo comienzan con GET, luego se expanden.

P: ¿Cómo comparar las respuestas si el orden de los elementos no está fijo?
R: Ordenar por clave sostenible antes de comparar o comparar como múltiples/por clave.

P: ¿Qué hacer con los retrasos de las réplicas de la DB?
R: Introduzca las «ventanas de comparación» y los snapshots de referencia; agregue los resultados por versión, no por «stenochas».

14) Resultados

El tráfico de sombras es un «ensayo de producción sin dolor»: carga real, riesgo cero para los usuarios, análisis detallado de discrepancias. El éxito está determinado por el aislamiento, el muestreo correcto, el comparador de calidad y la observabilidad. Siguiendo el plan propuesto, obtendrá una práctica reproducible que cruza con confianza el camino hacia los lanzamientos canarios/azules-verdes y acelera la evolución de la arquitectura.