Wydajność sklepów podczas Black Friday z punktu widzenia administratorów

Tegoroczny Black Week już za nami. W Unity Group mamy kolejne powody do dumy – w tym roku sklepy naszych klientów ponownie stanęły na wysokości zadania, obsługując łącznie podczas samego Black Friday ponad 67 tysięcy zamówień!

---

Podczas podsumowań akcji promocyjnych i zysków warto też przyjrzeć się temu, jak wygląda perspektywa sprzedawców, którzy musieli zadbać zarówno o konkurencyjną ofertę, umiejętnie przeprowadzone kampanie promocyjne, a także wziąć pod uwagę punkt widzenia administratorów dbających o wydajność sklepu internetowego.

Dla zespołu administratorów Unity Group zarządzających serwerami w wielu platformach e-commerce B2C czas intensywniej pracy rozpoczął się już dużo wcześniej – na kilka tygodni przed Black Friday byliśmy gotowi na wzmożony ruch zakupowy u naszych klientów. Poniżej kilka słów o tym, jak wyglądał proces przygotowania do wyprzedaży.

Wstęp: Warto sprawdzić oczekiwania

Przeanalizowaliśmy ubiegłoroczny ruch w serwisach podczas Black Friday, a następnie podpytaliśmy zespoły i klientów o to, jakie są ich oczekiwania względem ruchu w ich sklepach internetowych w tym roku. Czy zaplanowane są jakieś dodatkowe akcje marketingowe? Czy wśród działań promocyjnych są takie, które mogą skutkować nagłymi peakami w ruchu na stronie (np. reklama w telewizji, rekomendacje influencerskie)? Jak dużego ruchu spodziewają się podczas Black Friday?
Wszystkie odpowiedzi na tego typu pytania pozwoliły nam doprecyzować skalę działań. Z naszego doświadczenia wiemy, że serwisy mogą napotkać ruch kilkukrotnie większy niż ruch w typowy dzień. Aby być pewnym, że jesteśmy w stanie go obsłużyć, konieczne jest przeprowadzenie szeregu działań. Tylko wtedy będziemy w stanie zapobiec problemom.

Przygotowania

We wszystkich serwisach wykonaliśmy intensywne prace rutynowe w kontekście spodziewanej konieczności przetworzenia większej ilości danych, do których należały m.in.:

• weryfikacja wolnej przestrzeni dyskowej i profilaktyczne powiększenie jej tam, gdzie spodziewamy się że może jej zabraknąć.
• weryfikacja wolnych zasobów CPU i pamięciowych oraz przeskalowanie wertykalne, tak aby zachować zapas.
• optymalizacja baz danych, indeksów i zapytań, odzyskanie miejsca zajętego przez usunięte rekordy (tzw. Database Vacuuming).
• w przypadku architektur, które nie posiadają automatycznego skalowania – manualne uruchomienie kolejnych serwerów.
• w przypadku architektur autoskalowalnych – przetestowanie autoskalowania, weryfikacja wskaźników wyzwalających autoskalowanie.
• weryfikacja parametrów niskopoziomowych np. IOPS dla działań dyskowych – czy jest wystarczająca? Czy dyski nie powinny zostać podmienione na szybsze? Sprawdzenie jak wykorzystywane są rdzenie procesora – czy środowiska będą lepiej działać, gdy będą miały mniej szybszych rdzeni, czy więcej wolniejszych?

Optymalizacje

Wstępną optymalizację baz danych wykonaliśmy za pomocą narzędzi logujących zapytania trwające powyżej konkretnej liczby milisekund (np. pgbadger, mysql slow log). W ten sposób wybraliśmy do optymalizacji złożone, najbardziej obciążające serwery zapytania. W drugim kroku, za pomocą narzędzi rejestrujących wszystkie zapytania (np. pg_stat_statements) sprawdziliśmy sumaryczny czas poświęcany przez serwer na obsługę zapytań konkretnego typu. Często można odnaleźć zapytania bazodanowe, których czas wykonania nie przekracza setnych części sekundy, jednak wykonywanie takich zapytań tysiące razy na sekundę powoduje, iż przyspieszenie ich działania nawet o kilka-kilkanaście milisekund pozwala uwolnić cenne cykle procesora. Taka optymalizacja może polegać zarówno na zmianie struktury zapytania, ale także na dodaniu stosownych indeksów. Często korzyść nie jest widoczna w czasie wykonywania zapytania, ale w redukcji ilości operacji dyskowych – zostawiając więcej zasobów dla innych zapytań.
Dodatkowym krokiem przy optymalizacji baz danych była weryfikacja, czy istnieją jakieś nadmiarowe, nieużywane indeksy. W intensywnie rozwijanych aplikacjach czasem takie indeksy są dodawane na wyrost, bywa też, że silnik bazy danych zmienia tzw. query plan wykorzystując inne, dodane na potrzeby nowych zapytań indeksy. Niezależnie od tego, czy indeks jest używany czy nie, wpływa na wydajność wszelkich operacji zapisu, które są nieodłączną częścią każdego procesu składania zamówień.

Testy wydajnościowe

Wybrane serwisy – w szczególności te, które miały przeżyć Czarny Piątek po raz pierwszy – poddaliśmy testom wydajnościowym. Za pomocą odpowiednio skonstruowanego profili w aplikacjach gatling oraz jMeter, symulowaliśmy ruch zwykłego użytkownika przeglądającego serwis, dodającego produkty do koszyka lub realizującego zamówienie. Następnie zwiększaliśmy liczbę symulowanych równocześnie użytkowników do wartości dochodzących do oraz przekraczających założonyruch. Wszystko po to, aby zweryfikować, czy środowisko jest w stanie go obsłużyć oraz by następnie określić, jaka jest granica wydajności i gdzie znajdują się wąskie gardła. Wiedza o ewentualnych wąskich gardłach jest bardzo przydatna, gdyż pozwala na podjęcie optymalizacji, zwiększenie zasobów, przygotowanie skalowania lub zwyczajnie sugeruje, że warto dany element uważnie obserwować. Działania przygotowawcze dały nam pewność, że jesteśmy w stanie zapewnić ciągłość działania serwisów w trakcie Black Friday w stosunku do założonego ruchu, a także wiedzę jak postępować, jeśli te założenia zostaną przekroczone.

Black Friday

Serwisy, oprócz standardowego monitorowania przez administratorów dyżurnych, były dodatkowo doglądane przez administratorów opiekujących się danymi projektami. Analizowaliśmy przede wszystkich ruch na stronach, porównując go z założeniami, ale sprawdzaliśmy także to, jak ruch przekłada się na obciążenie zasobów.

Monitoring prowadzony był wielopłaszczyznowo:

• czujki aktywne regularnie badały fronty serwisów, pobierając np. stronę główną i wybrane podstrony, sprawdzając czas odpowiedzi serwera i otrzymaną treść. Oprócz tego weryfikowane było działanie każdego komponentu, począwszy od serwera WWW, przez bazy danych, warstwy cache a kończąc na działaniu samych komponentów fizycznych w serwerach. Jakiekolwiek odchylenie od normy powodowało natychmiastowe powiadomienie administratorów czekających na możliwość podjęcia reakcji.
• monitoring pasywny na bieżąco pokazywał kluczowe metryki ogólne np. ilość requestów na minutę w serwisach oraz metryki szczegółowe np. obciążenie komponentów, w szczególności tych, które stanowiły wąskie gardła. Informacje przekazywane z tego monitoringu pozwalały na zauważenie sytuacji mogących doprowadzić do awarii oraz podjęcie działań zanim jeszcze tę awarię spowodują.

Działania te przełożyły się na wymierne efekty:

• tylko jeden sklep pracował przez chwilę na obniżonej wydajności, tuż po uruchomieniu reklamy, która wygenerowała ruch znacznie przekraczający spodziewany wolumen, jeszcze zanim środowiska zdążyły się wyskalować. Sytuacja została natychmiastowo rozwiązana, a serwis profilaktycznie przeskalowany z odpowiednio większym zapasem.
• wszystkie pozostałe serwisy pod opieką zespołu administratorów Unity Group przeszły przez Black Friday wzorowo, nie odnotowując żadnych awarii przy rekordowych ilościach odwiedzających i konwersji.
• sklepy naszych klientów obsłużyły w ciągu jednej doby dziesiątki tysięcy zamówień i były przygotowane na rekordowe ilości odwiedzających.

Zespół administratorów Unity bardzo poważnie podchodzi do niezawodności i wydajności systemów naszych klientów. Mamy świadomość, jak ważne jest działanie aplikacji w dniach kluczowych dla sprzedaży, przygotowujemy się do tego z wyprzedzeniem, co przekłada się na zadowolenie klientów.

Potwierdzają to wiadomości wysyłane przez nich pod koniec dnia wieńczącego tygodnie przygotowań: