Zalando testuje obciążenie na produkcji. Oto dlaczego.

Z 4200 do 7200 w rok

Zalando to jedna z największych platform modowych w Europie, a Cyber Week to moment, który definiuje jej rok inżynierski. W październiku 2020 roku executive principal engineer Bartosz Ocytko opisał na Zalando Engineering Blog, jak Zalando przygotowuje się do sezonu. Najważniejsza liczba z 2019 roku: zmierzona liczba zamówień na minutę w szczycie osiągnęła 7200, wobec 4200 w 2018 roku. To wzrost o 71% rok do roku w najostrzejszym momencie obciążenia. Liczba klientów rosła o 20–25% rocznie, z 840 000 nowych klientów w samym tym roku.

Przy takiej dynamice pytanie o planowanie przepustowości się zmienia. Nie chodzi już o to, czy wasz serwis checkoutu udźwignie ruch. Chodzi o to, czy udźwignie go nadal, gdy wszystkie inne serwisy, które wywołuje, są jednocześnie w szczycie, z interakcjami, których nikt nie zamodelował, bo nigdy wcześniej nie wystąpiły w tym samym czasie.

Granica stagingu

Standardowa odpowiedź to środowisko stagingowe: postawić kopię produkcji, puścić na nią syntetyczny ruch i patrzeć, co się psuje. Problem w tym, że środowisko stagingowe jest modelem systemu produkcyjnego, a nie jego kopią. W skali Zalando interakcji między tysiącem serwisów pod jednoczesnym szczytowym obciążeniem nie da się odtworzyć poza prawdziwą platformą. Zależności, profile opóźnień, rozmiary buforów, współdzielone kolejki: nic z tego nie jest wiernie odwzorowane na stagingu, a przy odpowiedniej skali to właśnie rozbieżność staje się całą historią.

Zespół Ocytki doszedł do wniosku, który jest cytowany częściej niż jakiekolwiek inne zdanie w dziedzinie testów obciążeniowych:

„Jedynym sposobem, który okazał się skuteczny w przypadku tak dużego systemu jak nasz, są testy obciążeniowe na żywo na produkcji”.

To nie jest preferencja ani wygoda. To ograniczenie wynikające z architektury, powiedziane wprost po latach stosowania obu podejść i porównywania wyników.

Czego naprawdę wymaga testowanie na produkcji

Decyzja o testowaniu na produkcji to łatwa część. Program Zalando ma trzy niepodlegające negocjacji wymagania i każde jest trudniejsze, niż się wydaje.

Pierwsze to syntetyczne zamówienia, które da się oddzielić od prawdziwych na etapie realizacji. Zalando składa zamówienia na produkty testowe w prawdziwym systemie produkcyjnym i oddziela je od zamówień prawdziwych klientów dalej w pipelinie, zanim cokolwiek zostanie wysłane. To oznaczenie musi przetrwać każde przekazanie. Test jest prawdziwy; realizacja nie. Ta modyfikacja pipeline’u realizacji to praca infrastrukturalna, którą trzeba wykonać, zanim test w ogóle będzie mógł ruszyć.

Drugie to koordynacja około 100 zespołów dyżurnych, które wszystkie wiedzą, że test trwa. Większość programów planowania przepustowości nie uwzględnia tego w budżecie. Jeśli serwis inżyniera zacznie alarmować podczas testu na żywo, a nikt go nie uprzedził, program nie testuje platformy. Generuje fałszywe incydenty i zużywa dobrą wolę, która będzie potrzebna, gdy przyjdą prawdziwe.

Trzecie to liczba, która zasługuje na najwięcej uwagi. Zalando przetestowało w swoim programie 1122 aplikacje z ponad 4000 na platformie. Większość planowania przepustowości testuje trzy serwisy, co do których wszyscy i tak podejrzewają, że mogą paść. Ciekawe rodzaje awarii kryją się w serwisach, których nikt nie pomyślał sprawdzić, bo nic w ich normalnym zachowaniu nie sugerowało ryzyka. Testowanie 1122 aplikacji to nie pedanteria dla samej pedanterii. To jedyny sposób, by znaleźć serwis, którego nigdy nie było w niczyim rejestrze ryzyk, a który pada pod obciążeniem, jakiego nigdy wcześniej nie widział.

Wybór narzędzia: łatwość utrzymania ponad surową wydajność

W drugim wpisie, opublikowanym w marcu 2021 roku, inżynierowie Zalando Amila Kumaranayaka i Carsten Timpert opisali przejście od ręcznie uruchamianych testów obciążeniowych do w pełni zautomatyzowanego systemu działającego na Kubernetesie. W ocenie narzędzi znalazły się JMeter, Vegeta i Locust. Wybrali Locusta.

Powód warto zacytować dosłownie: Locust był „popularniejszy w naszych zespołach programistycznych, więc zestaw testów byłby łatwiejszy w utrzymaniu”. Nie najwydajniejsza opcja. Nie najbogatsza w funkcje. Ta, z którą zespoły rzeczywiście potrafiły pracować, którą rozumiały i mogły aktualizować z czasem.

To niedoceniana zasada w każdym obszarze testowania. Narzędzie technicznie lepsze, którego nikt w zespole nie potrafi edytować bez dwóch godzin odtwarzania kontekstu, nie jest w praktyce lepsze. Wcześniejsze podejście, czyli ręcznie uruchamiane testy, zespół określił jako „uciążliwe i drogie”. Automatyzacja włączyła je w normalny tok pracy inżynierskiej. W testach obciążeniowych płatności używali Hoverfly do symulowania zewnętrznych zależności płatniczych, a każdy przebieg trwał około dwóch godzin. To wybór Locusta sprawił, że po początkowej budowie dało się to utrzymać.

Zależności zewnętrzne: Spotify Wrapped 2022

Lekcja Zalando dotyczy tego, co dzieje się wewnątrz dużej platformy. Doświadczenie Spotify z Wrapped 2022, opisane we wpisie z marca 2023 roku na Spotify Engineering Blog, dodaje inny wymiar: co się dzieje, gdy wąskim gardłem nie jest serwis, który należy do was.

Wrapped to jedno z corocznych wydarzeń Spotify o największym ruchu. Edycja 2022 miała ponad 150 milionów aktywnych użytkowników na 111 rynkach, a dziesiątki milionów przyszły w ciągu pierwszych trzech–czterech godzin po starcie. Zespół spodziewał się dziesiątek tysięcy żądań na sekundę jednocześnie w regionach USA, UE i Azji.

Własne serwisy Spotify przeszły testy obciążeniowe. Ale Wrapped opiera się na wielu serwisach, których zespół Wrapped nie obsługuje. Przygotowania polegały na zidentyfikowaniu każdej zależności zewnętrznej, skoordynowaniu się z każdym z tych zespołów, potwierdzeniu, że każdy przygotował zasoby na przewidywane obciążenie, i sprawdzeniu, że przygotowania były kompletne przed dniem premiery. Premiera obyła się bez poważnych problemów technicznych.

Serwis, który przechodzi własny test obciążeniowy, podczas gdy serwisy, od których zależy, nie zostały przygotowane na wydarzenie, w rzeczywistości nie został przetestowany od początku do końca. Zmapowanie drzewa zależności przed wydarzeniem o dużym obciążeniu, łącznie z zespołami, których nie kontrolujecie, przestaje być opcjonalne od pewnego poziomu integracji.

Czego Ticketmaster nie opublikował

Ticketmaster nie opublikował technicznego postmortemu żadnego z dwóch swoich najczęściej przywoływanych incydentów. To, co poniżej, opiera się wyłącznie na publicznych oświadczeniach Ticketmastera, jego zeznaniach przed Senatem USA i doniesieniach stron trzecich i tak należy to czytać.

W przedsprzedaży trasy Taylor Swift Eras Tour w listopadzie 2022 roku publiczne oświadczenia Ticketmastera i jego zeznania przed Senatem USA określiły skalę na 3,5 miliarda żądań do systemu w ciągu jednego dnia, czterokrotnie więcej niż poprzedni zarejestrowany szczyt, przy 14 milionach jednoczesnych użytkowników i botów na platformie. Dane podane przez firmę mówią o 2,4 miliona sprzedanych biletów; sprzedaż ogólną później odwołano. Awaria widoczna dla użytkowników to licznik kolejki, który cofał się do tyłu.

Cockroach Labs opublikował wpis analizujący incydent. Ta analiza to komentarz dostawcy, firmy od rozproszonych baz danych, która ma bezpośredni interes handlowy we wnioskach, do jakich dochodzi. Może być trafna; nie da się jej niezależnie zweryfikować i tak należy ją traktować.

W przypadku sprzedaży biletów na Oasis w sierpniu 2024 roku The Stack, serwis technologiczny, informował o powszechnych błędach 503 i 500 oraz o systemie antybotowym, który oznaczał prawdziwych kupujących jako podejrzany ruch automatyczny. Po tych doniesieniach nie pojawił się żaden techniczny postmortem.

Trwalsza obserwacja nie jest techniczna. Nikt poza Ticketmasterem nie zna prawdziwej przyczyny żadnej z tych awarii, bo Ticketmaster nie opublikował niczego, z czego branża mogłaby się uczyć. Kolejka, która cofała się do tyłu, kody błędów, oznaczeni prawdziwi użytkownicy: to widoczne objawy. Przyczyna techniczna pozostaje nieudokumentowana. To, że firma tej skali po tak widocznych awariach decyduje się nie publikować postmortemu, samo w sobie jest informacją. Oprzyjcie się pokusie diagnozowania przyczyny z zewnątrz. Można powiedzieć tyle, że w obu przypadkach system nie odrzucał łagodnie nowych żądań po przekroczeniu przepustowości i że wszystkie krążące wyjaśnienia techniczne pochodzą od stron, których nie było przy tym.