Shadow traffic: sprawdzenie bez odpowiedzi dla użytkownika

Minimalny model

Logika wygląda tak:

client
  |
  v
stable version -> response to client
  |
  +-- copy request -> shadow version

Użytkownik nie widzi odpowiedzi shadow.

My patrzymy na:

logs
metrics
traces
różnice odpowiedzi
czas wykonania
błędy

Najprostszy przykład w kodzie testowego gatewaya:

const stableResponse = await fetch("http://api-v1/orders", request);

fetch("http://api-v2/orders", request.clone()).catch((error) => {
  logger.warn({ error }, "shadow request failed");
});

return stableResponse;

To nie jest gotowy wzorzec produkcyjny.

To pokazuje mechanizm: odpowiedź z nowej wersji nie wraca do klienta.

Do czego to realnie służy

Shadow traffic jest dobre, kiedy chcemy zobaczyć, jak nowa wersja zachowuje się pod prawdziwym kształtem ruchu.

Nadaje się do:

odczytów
nowych silników wyszukiwania
nowych algorytmów scoringu
porównania odpowiedzi
testów performance
walidacji zależności

Jest szczególnie przydatne, gdy ruch syntetyczny nie oddaje produkcji.

Prawdziwy ruch ma dziwne nagłówki, stare klienty, nietypowe payloady i kolejność zdarzeń, której testy zwykle nie mają.

Największy problem: skutki uboczne

Nie każdy request wolno skopiować.

Jeżeli request robi write:

tworzy zamówienie
wysyła mail
ściąga pieniądze
publikuje event
zmienia stan magazynu

to kopia może zrobić szkodę.

Shadow traffic wymaga kontroli skutków ubocznych.

Możliwe podejścia:

mirror tylko dla GET
blokowanie write'ów w shadow
osobna baza testowa
mock zewnętrznych integracji
idempotency keys
oznaczanie requestów jako shadow

Czego shadow traffic nie sprawdza

Shadow traffic pozwala pokazać nowej wersji prawdziwe requesty, ale nie sprawdza pełnego zachowania produkcyjnego.

Użytkownik nadal dostaje odpowiedź ze starej wersji, więc nie widzimy skutków, które pojawiłyby się dopiero po prawdziwym przejęciu ruchu: reakcji klienta, ponowień, zmian w sesji, cache po stronie przeglądarki albo kolejnych requestów zależnych od odpowiedzi.

Druga granica to koszt. Kopia ruchu też zużywa CPU, pamięć, sieć i zależności. Jeżeli shadow wersja jest wolniejsza, użytkownik tego nie czuje, ale infrastruktura może już dostać dodatkowe obciążenie.

Dlatego shadow traffic służy głównie do porównania zachowania pod prawdziwym ruchem.

Nie zastępuje canary, bo canary sprawdza moment, w którym nowa wersja naprawdę odpowiada użytkownikowi.