Nowa wersja przechodzi testy, ale po wdrożeniu na wszystkich użytkowników błędu nie da się już ograniczyć do małej grupy. Canary deployment pozwala najpierw skierować część ruchu do nowej wersji, choć mały udział nie gwarantuje, że wykryjesz problem przed pełnym wdrożeniem.
Canary ogranicza zasięg błędu, jeśli test obejmuje reprezentatywny ruch
- Wdrażasz nową wersję etapami, kierując do niej część ruchu produkcyjnego.
- Promujesz wersję po pomiarach, a nie tylko po poprawnym starcie kontenerów.
- Udział ruchu dobierasz do jego wolumenu i ryzyka, które chcesz wykryć.
- Automatyczny rollback powinien przywracać stabilną wersję po przekroczeniu ustalonych progów.
Canary testuje nową wersję na prawdziwym ruchu
Wyobraź sobie, że wdrażasz zmianę w obsłudze płatności. Testy przechodzą, ale dopiero produkcyjne żądania ujawniają błąd przy nietypowej walucie. W canary część użytkowników trafia do nowej wersji, a reszta nadal korzysta ze stabilnej.
W praktyce utrzymujesz obie wersje równolegle, kierujesz ruch do wybranego podzbioru i obserwujesz wskaźniki. Jeśli nowa wersja zachowuje się prawidłowo, zwiększasz jej udział. Jeśli pogarsza wyniki, zatrzymujesz rollout lub wracasz do poprzedniej wersji. Uważam, że sens tej metody zależy bardziej od jakości pomiarów niż od samego procentu ruchu.
Mały procent może dać zbyt mało danych
Jeden procent brzmi bezpiecznie, ale przy niewielkim ruchu może oznaczać zaledwie kilka żądań. Taka próbka nie pokaże, jak aplikacja zachowa się przy różnych ścieżkach użytkownika, nagłym wzroście obciążenia czy rzadkim błędzie.
Przykład pokazuje ograniczenie: załóżmy, że canary otrzymuje 1000 żądań, a problem występuje średnio w 0,1% żądań nowej wersji. Przy tych założeniach szansa zaobserwowania choć jednego błędu wynosi około 63%. Brak błędu w tej próbce nadal nie daje więc mocnego dowodu, że wersja jest bezpieczna.
W Google SRE Workbook zaleca się dobierać populację i czas canary tak, by próbka odzwierciedlała typowe użycie, a metryki były powiązane ze zdrowiem usługi. Dla API mogą to być odsetek błędów i opóźnienia odpowiedzi; sama zajętość CPU bywa słabym sygnałem, jeśli nie przekłada się na problem użytkownika.
Wybór mechanizmu zależy od tego, jak precyzyjnie kierujesz ruchem
Różnica między narzędziami wychodzi na jaw przy małej liczbie replik. Zwykły Service w Kubernetes rozdziela ruch między pasujące pody, ale bez dodatkowego routingu proporcja canary wynika z liczby replik i może być tylko przybliżona.
W samouczku Kubernetes stabilna wersja ma trzy repliki, a canary jedną. Ruch jest rozdzielany pomiędzy cztery pody, więc nowa wersja obsługuje około jednej czwartej ruchu, a nie precyzyjnie wybrane 5% czy 10%. To dobry przykład, dlaczego liczby replik nie zawsze zastąpią kontrolę na poziomie load balancera.
Argo Rollouts pozwala opisać etapy za pomocą wag ruchu i pauz, a przy integracji z routerem ruchu daje dokładniejszą kontrolę. Bez takiego routingu procenty również są przybliżane przez liczbę podów. Jeśli potrzebujesz precyzyjnego udziału, zwłaszcza przy małej liczbie replik, wybierz routing przez ingress, load balancer lub service mesh.
Automatyczny rollback wymaga progów i czasu na pomiar
Canary bez warunków zatrzymania to w praktyce stopniowe wdrożenie z ręczną obserwacją. Ustal przed startem, które wskaźniki blokują promocję: na przykład wzrost błędów serwera, pogorszenie p95 latency albo spadek skuteczności krytycznej operacji.
Próg powinien porównywać canary ze stabilną wersją w tym samym okresie, a nie wyłącznie z wczorajszą średnią. Ruch zmienia się w ciągu dnia, więc porównanie „przed i po” może przypisać wdrożeniu skok obciążenia, który wystąpił niezależnie od zmiany.
| Sytuacja | Prawdopodobna przyczyna lub skutek | Co zrobić |
|---|---|---|
| Mało żądań trafia do canary | Próbka może nie ujawnić rzadkich błędów | Wydłuż obserwację albo zwiększ ruch, zanim promujesz wersję |
| Rośnie p95 latency tylko w canary | Nowy kod może spowalniać konkretną ścieżkę | Zatrzymaj rollout i sprawdź rozkład opóźnień według endpointu |
| Wskaźniki pogarszają się podobnie w obu wersjach | Przyczyną może być wspólna zależność lub skok ruchu | Wstrzymaj promocję, ale najpierw sprawdź wspólne zależności i metryki infrastruktury |
| Brak alertów, ale nie przetestowano obciążenia szczytowego | Canary mogło działać w niereprezentatywnych warunkach | Poczekaj na typowe obciążenie lub przeprowadź kontrolowany test wydajnościowy |
W dokumentacji Amazon ECS canary jest wdrażane dwuetapowo: najpierw część ruchu przechodzi na nową rewizję, a po okresie obserwacji reszta. System może uruchomić rollback na podstawie alarmów. To użyteczny wzorzec, ale czas obserwacji nadal trzeba dopasować do własnego ruchu i czasu, po którym pojawiają się istotne sygnały.
Dobry rollout kończy się dopiero po sprawdzeniu skutków ubocznych
Udany canary potwierdza, że nowa wersja poradziła sobie z obserwowanym ruchem i metrykami. Nie dowodzi, że każdy wariant zachowania użytkownika został sprawdzony. Po promocji monitoruj usługę dalej, a po rollbacku upewnij się, że stara wersja może współpracować ze zmianami w bazie danych i formacie komunikatów.
Przy zmianach schematu bazy stosuj kompatybilne migracje: najpierw dodaj elementy obsługiwane przez obie wersje, potem wdrażaj kod, a usuwanie starych pól zostaw na później. Dzięki temu cofnięcie aplikacji nie zamieni się w drugi incydent. Canary ogranicza ryzyko wdrożenia, ale nie naprawi nieodwracalnej migracji ani braku obserwowalności.
