Stabilna praca sklepu przy nagłych wzrostach ruchu — diagnoza wąskich gardeł i migracja bazy WooCommerce do OVH Cloud Databases

Yutori.pl to warszawskie studio wellness i mindfulness, które organizuje zajęcia jogi, warsztaty, sesje oddechowe i wydarzenia specjalne. Rezerwacje i bilety sprzedaje przez sklep oparty na WordPressie i WooCommerce, działający na hostingu współdzielonym OVH.

W standardowym trybie pracy sklep działał bez zakłóceń. Problem występował podczas okresowych akcji z bezpłatnymi wejściówkami. Pula miejsc była udostępniana o określonej godzinie, co powodowało gwałtowny wzrost liczby jednoczesnych użytkowników w bardzo krótkim czasie.

W takich momentach sklep tracił dostępność. Awaria występowała w chwili największego zainteresowania ofertą, co oznaczało utracone rezerwacje i negatywne doświadczenie klientów.

Diagnoza przed zmianą. Zamiast wprowadzać zmiany na podstawie przypuszczeń, odtworzyłem warunki akcji w testach obciążeniowych w Apache JMeter i sprawdzałem, który element infrastruktury jako pierwszy przestaje działać poprawnie.

Pierwsze wąskie gardło: wydajność serwera. Początkowo żądania kończyły się przekroczeniem czasu odpowiedzi. Przyczyną były zasoby serwera aplikacji, dlatego w tym przypadku zasadne było przejście na wyższy pakiet hostingu. Zmiana usunęła problem z przekroczeniami czasu.

Drugie wąskie gardło: baza danych. Po usunięciu pierwszego ograniczenia kolejne testy ujawniły następne. Aplikacja zaczęła zgłaszać cykliczne błędy połączenia z bazą danych. Standardowa baza w pakiecie współdzielonym obsługuje zbyt małą liczbę jednoczesnych połączeń, a po osiągnięciu limitu kolejne żądania kończyły się błędem.

Dlaczego nie kolejny, wyższy pakiet. Dalsze zwiększanie pakietu nie rozwiązałoby problemu. Limit połączeń wynikał z samej bazy w modelu współdzielonym, a nie z wydajności serwera. Klient poniósłby wyższe koszty, a przy kolejnej akcji błędy wystąpiłyby ponownie.

Migracja wyłącznie bazy danych. Zarekomendowałem przeniesienie samej bazy do usługi zarządzanej OVH Cloud Databases, bez przenoszenia aplikacji. Klient pozostał u dotychczasowego dostawcy i nie zmieniał sposobu pracy. Baza zarządzana zapewnia dedykowane zasoby, kontrolę nad konfiguracją i możliwość zwiększenia wydajności przed większym wydarzeniem, bez konieczności samodzielnej administracji serwerem.

Bez zmian w kodzie i wtyczkach. Przyczyny leżały w infrastrukturze, dlatego nie ingerowałem w logikę sklepu. Ograniczenie zakresu zmian zmniejszyło ryzyko przed kolejną akcją.

1. Przygotowałem scenariusz obciążeniowy w Apache JMeter odwzorowujący przebieg akcji i wykonałem pomiary na dotychczasowej konfiguracji.
2. Po zidentyfikowaniu przekroczeń czasu odpowiedzi sklep został przeniesiony na wyższy pakiet hostingu, a testy powtórzone.
3. Uruchomiłem instancję OVH Cloud Databases i skonfigurowałem ją pod obciążenie generowane przez WordPress i WooCommerce.
4. Przeprowadziłem migrację danych i przełączyłem sklep na nową bazę.
5. Powtórzyłem testy obciążeniowe na docelowej konfiguracji.

• Przy obciążeniu rzędu 100 użytkowników na sekundę sklep działa bez przekroczeń czasu i bez błędów połączenia z bazą danych, a czas odpowiedzi wynosi 1–2 sekundy.
• Oba wąskie gardła zostały zidentyfikowane pomiarami i usunięte w odpowiedniej kolejności.
• Klient otrzymał wyniki testów z każdego etapu, wykonanych tym samym scenariuszem.
• Aplikacja pozostała u dotychczasowego dostawcy, bez zmian w kodzie sklepu.