Tráfego e comparação Shadow

1) O que é o tráfego shadow e o que é necessário

O tráfego Shadow (ele é traffic mirroring/dark launch) é um «check-up» seguro de solicitações/eventos reais para uma nova versão do serviço, paralelamente à versão de produção sem afetar os usuários. Os resultados da nova versão não são voltados para o cliente e não produzem efeitos de side externos, mas são reunidos em um sistema de comparação.

• Verificação de compatibilidade: esquemas, contratos, lógica de negócios.
• Avaliação de desempenho: latência, sustentabilidade sob carga real.
• Detecção da deriva: diferenças de resposta, distribuição, frequência de erros.
• Preparação para lançamentos canários: redução do risco antes da mudança real de tráfego.

• Reescrever núcleo/algoritmos, migrar BD/dinheiro, ir para outro Rant/SDK, mudar o provedor de API externo.

2) Patrões arquitetônicos Shadow-tráfego

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

O Proxy aceita o pedido → dá uma resposta de combate da versão antiga → espelha assinhosamente uma cópia da solicitação para «sombra».

Adequado para API sincronizada.
Gerenciamento de porção/filtro de espelhamento no caminho, heder, usuário, 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 Pneus de evento (Kafka/Fluxos)

• O produtor escreve como normalmente os consoadores prod leem.
• Paralelamente, «sombra» (shadow-pipeline) lê o mesmo fluxo para um banco de areia separado.

Opções: MirrorMaker/Replicator, dual-write (cuidado), bridge «fonte → prod + shadow».

2. 3 Replayer (gravação/reprodução)

Imagens de pesquisas/trailers reais (PCAP/NGINX access, gRPC taps) → reprodução em «sombra» com ritmo controlado.

2. 4 «Sombra sintética»

A geração de um perfil de carga a partir de prod-logs + fase de finalização de mala de borda é útil para restrições de privacidade.

3) Isolar o estado e os efeitos de side

Regra de ouro, a sombra não altera o mundo exterior.

Reed only acesso a BD/cachê ou uma caixa de areia separada (snapshot/réplica).
Proibição de saques: pagamentos, cartas, pelúcias, webhooks → stub/blackhole/record-only.
Idempotidade no nível de comando/POST: Shadow não deve ser registrado como repetição do original.
Camuflando PII/segredos, tocadores de torneios de teste.

Exemplo: camuflagem em espelho

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

4) Estratégias de semente e carga segura

Proporção de tráfego: 1 a 10% no início; aumentar se v2 estiver no orçamento.
Critérios de seleção: por rota, usuário, tamanho da solicitação, tipo de operação (GET-s mais seguro).
Orçamento perf: espelhamento não deve aumentar p95/p99 serviço de combate. A sombra é sempre asinhrona.
Back-pressure: Quando a cadeia shadow está superaquecida, espreita a sombra e não as solicitações de combate.
Tempo mínimo de 24 a 72 horas para cobrir pateras diárias e de pico.

5) Comparação de resultados: métodos e níveis

5. 1 Níveis de comparação

1. Diff de byte, corpo de resposta/evento um-em-um. Simples, mas frágil (times, ordem das chaves).
2. Diff semântico: normalizamos e ordenamos os campos, ignoramos as epeméridas (traceId, timestams, counters).
3. Os invariantes de negócios são os mesmos valores, estatais, quantidades, limites.
4. Análise estatística, a distribuição de métricas corresponde? (p50/p95, teste KS, c ² para categóricos).

5. 2 Políticas de comparação

Máscaras/ignore-listas de campos (por exemplo, «updatedAt», «etag»).
Exatidão: margem de erro absoluta/relativa para os números (por exemplo, se este for o número 1-6).
Tolerância (tolerance bands): "diferença de preço ≤ 0. 01», «erros no máximo + 0. 1% relativamente prod".

Pseudo-código do comparador

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 Mapeamento de zapros↔otvet

É obrigatório Correlation-ID (colar na sombra).
A pista shadow ganha link para a pista de combate.

6) Observabilidade e artefatos de comparação

• `shadow_requests_total{route,...}`
• `shadow_discrepancies_total{type=byte|semantic|invariant}`
• `shadow_error_ratio` и `shadow_slo_breach_total`
• Perf: 'shadow _ latencies _ ms Se, p50, p95, p99'
• Logs de difs, JSON-delta compactos.
• Relatórios: relatório diário com o top N de divergências, mapas térmicos sobre rotas/tenentes.
• UI «diff explorer»: filtros por tipo, rota, campo, exportação em CSV.

7) Casos especiais e sutilezas

7. 1 Sequência e consistência

As pesquisas shadow podem chegar mais tarde/mais cedo; normalize em versões/relógios (Lamport/vector) ou permissões da janela.
Read-after-write: Uma sombra com uma read-replica sem replicação sincronizada dará respostas diferentes - compare através de janelas duplas.

7. 2 Cash/recomendações

Não misture cachês prod e shadow.
Para ML/recomendadores, compare métricas online e metricas off-line separadamente; acompanhe os sinais de entrada draft.

7. 3 Provedores externos

Vire os clientes record-only/stub-modo.
Para serviços de cálculo (impostos, cursos) - Capture uma imagem dos guias para ambas as partes.

8) Comparação com canários/blue-green

Shadow: risco zero para os usuários, mas sem efeitos de side reais; perfeito para a lógica e a perf.
Canary: pequena porcentagem de respostas reais da nova versão; requer estratégia de reversão pronta e SLA.
Blue-green: mudança instantânea após validação; Shadow é usado frequentemente antes dele.

9) Plano de implementação (estilo GitOps)

1. Alvos e métricas: que invariantes e tolerantes verificamos que tipo de SLO é para divergência.
2. Traçado: Correlation-ID, links de trade distribuídos.
3. Configuração proxy: política mirror, semente, redação.
4. Isolamento: caixa de areia BD/cash, braços colaterais, chaves de teste.
5. Comparador: normalização, ignore-maps, invariantes, relatórios.
6. Plano de carga: início de 1 a 5%, crescimento de 20 a 50% em métricas verdes.
7. Observabilidade: dashboards de variação/perf/volume.
8. Os critérios de saída são «0 discrepância crítica de 48 h», «erro igual ao prod», «perf de R $5%».
9. Ir para canary - incluir respostas reais com uma participação segura e regras automáticas de gard.

10) Exemplos de configuração

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 (esboço)

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

10. 3 Regras de comparação (política 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 escreve para fora: pagamentos reais/notificações da sombra.
As filas compartilhadas e compartilhadas são influências cruzadas e contaminação.
Falta de normalização, os difs de byte são «pintados» por causa do relógio/ordem das chaves.
Porcentagem demasiado alta com o movimento: degradação da perf prod.
A longa «sombra eterna», o segundo sistema vive em separado e separa-se da realidade.

12) Folha de cheque de lançamento do modo Shadow

• O proxy tem mirror configurado com participações e redação.
• Sombra isolada: BD/cachê/integração externa - apenas readonly/stub.
• O Correlation-ID será colocado em todo o lado; os traços estão a ser linchados.
• O comparador é capaz de ignore/normalize e verificar os invariantes.
• Dashboards e alertas sobre divergências e carga.
• Semente em rotas/tenentes; limites e back-pressure.
• As permissões e critérios de luz verde foram definidos.
• Plano de transição para canary/blue-green e reversão.

13) FAQ

Q: Em que o Shadow é diferente do A/B?
A: Em A/B, as duas versões devolvem as respostas aos usuários (experimento split); no Shadow, a nova versão não afeta o usuário - suas respostas são apenas analisadas.

Q: Você pode fazer um POST/PUT?
A: Sim, se for garantido o isolamento e a idempotidade. Muitas vezes começam com GET, depois expandem.

Q: Como comparar as respostas se a ordem dos itens não estiver configurada?
A: Arrume a chave segura antes de comparar ou compare como muitas/por chave.

O que fazer com os atrasos das réplicas do BD?
A: Digite «janelas de comparação» e «guias»; Agregue os resultados em versões, em vez de «paredes».

14) Resultado

O tráfego shadow é um «ensaio de produção indolor»: carga real, risco zero para os usuários, análise detalhada de divergências. O sucesso é determinado pelo isolamento, pela semente correta, pelo comparador de qualidade e pela observabilidade. Seguindo o plano proposto, você terá uma prática reproduzida que traça com segurança o caminho para lançamentos canary/blue-green e acelera a evolução da arquitetura.