Canary deployment: nowa wersja dostaje część ruchu

Minimalny przykład

Mamy dwie wersje aplikacji za dwoma Service.

api-v1
api-v2

Gateway API może rozdzielić ruch wagami w HTTPRoute.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api
spec:
  parentRefs:
    - name: public
  hostnames:
    - api.example.com
  rules:
    - backendRefs:
        - name: api-v1
          port: 80
          weight: 99
        - name: api-v2
          port: 80
          weight: 1

Następny krok może wyglądać tak:

99/1
95/5
75/25
50/50
0/100

To jest mechanika.

Strategia zaczyna się dopiero wtedy, gdy pomiędzy krokami ktoś patrzy na sygnały.

Co mierzyć

Canary bez obserwowalności jest ślepe.

Minimum:

error rate
p95 latency
p99 latency
saturation
restart count
business metric

Metryka biznesowa zależy od systemu.

Może to być:

checkout completed
payment authorized
message sent
document generated

Jeżeli api-v2 ma ten sam error rate, ale psuje płatności, infrastrukturalne metryki nie wystarczą.

Do czego to realnie służy

Canary jest dobre, gdy chcemy sprawdzić nową wersję na prawdziwym ruchu, ale nie chcemy od razu ryzykować całej populacji.

Działa dobrze przy:

stateless API
frontend backend for frontend
zmianach performance
nowych zależnościach
zmianach w integracjach

Canary jest słabsze, jeśli każda wersja musi widzieć globalnie spójny stan albo jeśli błąd ujawnia się dopiero po kilku dniach.

Gdzie nazwa kłamie

Canary brzmi jak automatyczne bezpieczeństwo.

W rzeczywistości to tylko ekspozycja małej części ruchu.

Jeżeli nie ma metryk, alertów i decyzji promocji, canary jest wolniejszym rolling update.

Jeżeli użytkownik raz trafia do v1, raz do v2, a aplikacja wymaga spójności sesji, canary może wygenerować problemy, których nie było w żadnej wersji osobno.

Canary odpowiada na pytanie:

czy nowa wersja psuje system pod prawdziwym ruchem?

Nie odpowiada samo z siebie na pytanie:

czy nowa wersja jest lepsza dla konkretnej grupy użytkowników?

Do tego bliżej targeted rollout i A/B testów.