Jak zapobiec problemom e-sklepu spowodowanym obciążeniem serwerów?
Platformy e-commerce, zwłaszcza systemy B2C, często cechuje sezonowość sprzedaży. Przeróżne święta czy akcje promocyjne to okresy wytężonej pracy całego przedsiębiorstwa, a często także stresu i niepewności wynikających z obaw o sprawność działania systemu IT. Im bardziej złożone są systemy i im większa jest przestrzeń pomiędzy światem biznesu i technologii, tym bardziej ta niepewność rośnie. Ten artykuł pomoże Ci zrozumieć, w jaki sposób możesz zadbać o to, aby uniknąć problemów z niewydolną technologią, a tym samym – z ograniczeniem sprzedaży.
Rozmowę o szybkości działania sklepu najlepiej rozpocząć od zrozumienia, co składa się na czas, który upływa pomiędzy wykonaniem akcji przez użytkownika (np. wejście na stronę, uruchomienie wyszukiwania produktu), a pojawieniem się oczekiwanego przez użytkownika wyniku. Nie wchodząc w szczegóły można podzielić ten czas m.in. na:
- Czas transmisji sieciowej
- Czas przetwarzania żądania przez serwery
- Czas wyświetlania wyników przez urządzenie użytkownika.
W zależności od budowy i umieszczenia systemu, rozproszenia geograficznego klientów sklepu czy używanych urządzeń, każdy z tych elementów w różnym stopniu będzie wpływał na Customer Experience. I chociaż mogłoby się wydawać, że obecnie szybkość działania sieci nie jest już problemem, to nietrudno znaleźć sklepy, w których niezoptymalizowane grafiki niepotrzebnie wydłużają czas wyświetlania karty produktu. Jednocześnie coraz częściej stosowane chmury publiczne z bardzo detalicznie skonstruowanymi cennikami natychmiast przenoszą koszty transmisji na właściciela systemu. Zatem warto przyjrzeć się, czy zespół przygotowujący materiały graficzne stosuje dobre praktyki, czy jakość obrazów prezentowanych w dużych ilościach jest wystarczająca (a nie najlepsza możliwa) i wreszcie czy stosowane są mechanizmy skracające drogę od serwerów do ekranu takie jak Content Delivery Network (CDN).
Czy wiesz jak wydajny jest Twój system?
Właściciele sklepów działających na wystandaryzowanych platformach SaaS mają tu nieco ułatwione zadanie – mogą oczekiwać odpowiedzi na tak postawione pytanie od dostawcy platformy. Jeśli jednak opierają swoją strategię na wyróżnieniu się na tle konkurencji (np. budując unikalne doświadczenia zakupowe w oparciu o platformy takie jak WooCommerce czy Magento), to o określenie wydajności platformy należy zadbać samodzielnie. Doświadczenie partnera wdrożeniowego pozwala do pewnego stopnia oszacować teoretyczną wydajność systemu, ale gdy pada pytanie o gwarancję szybkiego działania, okazuje się, że nieco inna platforma sprzętowa, unikalne funkcje, integracje czy nawet nietypowy katalog produktów uniemożliwiają udzielenie rzetelnej odpowiedzi. Jak sobie z tym poradzić? Nasuwająca się odpowiedź „zróbmy testy wydajności” nie zawsze będzie najlepszym rozwiązaniem. Dlaczego? Z prostego powodu: weryfikacja każdej hipotetycznej sytuacji jest nieefektywna kosztowo.
Jak dobrze zdefiniować problem?
Przed zleceniem wykonania testów wydajności trzeba przede wszystkim wiedzieć, na jakie pytanie chcemy uzyskać odpowiedź, gdyż różne problemy będą wymagały różnego podejścia. Pamiętajmy, że „na koniec dnia” system jako całość będzie tak wydajny, jak jego najwolniejszy element. Oto przykładowe zagadnienia, które powinny być zweryfikowane:
- Ilu użytkowników sklep jest w stanie obsługiwać jednocześnie?
- Ile transakcji może być wykonanych w jednostce czasu?
- Jakie maksymalne chwilowe obciążenie (oglądalność, liczba transakcji) wytrzyma system? Czy jest gotowy na zdarzenia typu Black Friday?
- Od czego zależy szybkość działania sklepu u użytkownika końcowego?
- Czy sklep ma nietypowe dla danej technologii cechy – np. bardzo rozbudowaną strukturę katalogu produktów, silną segmentację klientów i personalizację (rekomendacji, cen), dużą liczbę produktów?
- Czy systemy zintegrowane ze sklepem będą w stanie obsłużyć oczekiwaną liczbę klientów, zamówień, zmienność stanów magazynowych itp.?
W praktyce tylko niektóre z takich pytań weryfikuje się testami wydajności, głównie ze względu na koszty przygotowania odrębnych testów, które będą sprawdzały każdą z tez z osobna. Najważniejsze jest, aby tego typu pytania zostały postawione i aby zespół wdrażający e-commerce pochylił się nad każdym z nich i zaproponował metodę pozyskania odpowiedzi na dane pytanie. Czasem wystarczy analiza historii i porównanie do podobnego wdrożenia u innego klienta, czasem przegląd statystyk czasów wykonania zapytań do bazy danych i optymalizacja najcięższych i najczęściej wykonywanych zapytań. Innym razem nie obejdzie się bez czasochłonnego zbudowania zaawansowanego profilu testowego przy pomocy aplikacji takiej jak np. JMeter i sprawdzenia na środowisku testowym wydajności procesu zakupowego. Jedno jest pewne: im bardziej ogólne zadasz pytanie, oczekując jak najprostszej odpowiedzi (np. „czy sklep da radę?”), tym bardziej ryzykujesz, że spotka Cię niemiła niespodzianka. Istotne jest to, by wymagania wydajnościowe były rozbite na czynniki pierwsze i przeanalizowane jedno po drugim. Warto dopilnować, aby to się wydarzyło.
Jak przewidzieć przyszłość?
Wbrew pozorom nie potrzeba tu szklanej kuli. Większość biznesów detalicznych nie powstaje nagle, rzadko budowane są w wielkiej tajemnicy, w izolacji od Internetu po to, by w odpowiednim momencie z impetem wejść na internetową scenę i błyskawicznie przejąć połowę rynku. Przeważnie organiczny rozwój umożliwia systematyczne zbieranie danych:
- o zachowaniach użytkowników (np. użycie Google Analytics),
- o poszczególnych komponentach systemu (serwery aplikacyjne, baz danych, wyszukiwarki, cache itp.)
- o zmianach w aplikacji (nowe funkcje, integracje, przebudowy funkcjonalne itp.).
Budowanie historii takiego monitoringu najlepiej rozpocząć jak najwcześniej, najlepiej jeszcze przed uruchomieniem produkcyjnym sklepu. Już na etapie testów wewnętrznych okaże się, czy monitoring jest kompletny i czy w aplikacji nie ma elementów, które nawet przy niewielkim ruchu budzą wątpliwości co do szybkości działania. Bezwzględne wartości wskaźników takich jak procentowe obciążenie procesorów, liczba uruchomionych procesów czy operacji dyskowych w czasie pozwolą doświadczonemu inżynierowi ocenić stan zdrowia systemu. Znacznie trafniejsze diagnozy będą wystawiane wtedy, kiedy będziemy dysponować materiałem porównawczym. Dlatego tak ważna jest dostępność dłuższej historii monitorowanych parametrów. Często nawet z samej charakterystyki wykresów można wyciągnąć wniosek, czy system będzie się zachowywał stabilnie przy większym obciążeniu.
Przy dobrze monitorowanym systemie włączenie w proces budowy e-commerce testowania niewielkimi kampaniami promocyjnymi daje zespołowi dodatkową możliwość obserwacji zależności pomiędzy tym, co i jak jest promowane, a statystykami oglądalności i obciążeniem serwerów.
Warto rozmawiać!
Jest tu jednak jeden warunek: dobra komunikacja pomiędzy zespołami przeprowadzającymi promocję i odpowiedzialnymi za rozwój i utrzymanie sklepu. Zespoły te muszą wymieniać się wiedzą o datach i skali planowanych promocji, ich efektach, widocznych wąskich gardłach czy spodziewanych ograniczeniach systemu. Podobnie wdrożenia nowych funkcji, pojawienie się skokowo większej złożoności w systemie czy większej ilości danych nie mogą być tajemnicą dla żadnej z osób współodpowiedzialnych za działanie sklepu. Przy braku dobrego przepływu wiedzy można doprowadzić do sytuacji, w której nie da się uniknąć spowolnionego działania sklepu (a co za tym idzie – ograniczenia przychodów). Co więcej, dostrzeżony problem będzie niepotrzebnie długo diagnozowany, podczas gdy wystarczyłoby skojarzenie faktu, że dana platforma korzysta z nowej integracji, co może korelować z jej spowolnieniem. Zatem widać tu ewidentnie istotne znaczenie dobrego prowadzenia projektu rozwoju sklepu.
Masz system w chmurze, więc Black Friday Cię nie zaskoczy?
Otóż właśnie niekoniecznie. Kluczowa kwestia to to, w jaki sposób ten system został zbudowany. Proste przeniesienie zwykłej, „kanapkowej” instalacji, np. Magento, z własnych serwerów na systemy wirtualne w chmurze publicznej może pozwolić na przygotowanie się na zwiększone obciążenie, przynajmniej do pewnej skali. Zmiana systemu wirtualnego na dysponujący 96-cioma procesorami? Czemu nie, tylko czy na pewno płacąc kilka dolarów za każdą godzinę działania taka „zabawa” ciągle będzie opłacalna? A co, jeśli pojedynczy serwer ulegnie awarii, co może się zdarzyć nawet u najlepszych dostawców chmurowych? Żaden z nich nie daje 100% SLA na działanie pojedynczego systemu wirtualnego.
Decydując się na zbudowanie sklepu na bazie jednej z trzech czołowych chmur publicznych (Amazon Web Services, Microsoft Azure, Google Cloud Platform) masz zdecydowanie większe pole manewru niż w przypadku tradycyjnych data center. Jednak aby system był gotowy na duży ruch nie rujnując budżetu projektu, musi być zoptymalizowany pod działanie w chmurze. Jeśli pełna i automatyczna skalowalność zastosowana dla Twojej aplikacji czy bazy jest trudna do realizacji bez wprowadzenia znaczących zmian w kodzie, to prawie na pewno jest możliwe rozbicie poszczególnych komponentów na systemy wirtualne o dobrze dopasowanych parametrach, zastosowanie Content Delivery Network, ustawienie polityk cache’owania czy odpowiednie przygotowanie przestrzeni do serwowania obiektów statycznych. W ten sposób nawet sklep zbudowany w oparciu o platformę, która nie była natywnie zaprojektowana do działania w środowisku autoskalowalnym i opartym o wysokodostępne usługi chmurowe, można znacznie „podrasować” i przygotować na spodziewane obciążenie.
Przygotowanie sklepu na święta to nie jest rocket science. A z pewnością nie wymaga od jego właściciela czy szefa e-commerce gruntownej znajomości technologii i wszelkich czyhających niespodzianek. Czytając ten artykuł zapoznałeś się z najważniejszymi zagadnieniami, o których powinieneś wiedzieć, układając współpracę zespołów pracujących nad rozwojem Twojego sklepu. Uwzględniając i pogłębiając tę wiedzę od początku procesu budowania sklepu i kultywując w zespołach kulturę otwartości i współpracy masz dużą szansę na sukces.
