Łatwo skalowalny e-commerce. Jaki silnik e-sklepu wybrać, żeby radzić sobie z pikami sprzedażowymi

Zastanawiasz się, czym tak właściwie różnią się systemy sklepów internetowych? W ciągu 20 lat swojej przygody z e-commerce mogłem na bieżąco obserwować gigantyczne zmiany w technologii, jakie wymuszał wzrost popularności e-handlu. Temat, który chcę omówić, jest rzadko poruszany. Mam nadzieję, że po lekturze artykułu będzie Ci łatwiej zrozumieć różnice między rozwiązaniami dla sklepów dostępnymi na rynku.

W październiku 2000 r. – 20 lat temu – w dwa wieczory napisałem pierwszy sklep internetowy dla klienta. Po czym przekazałem mu fakturę i płytę CD do samodzielnej instalacji oprogramowania. Na szczęście usłyszałem, że ten nie ma pojęcia, jak to zrobić. A poza tym na pewno mnóstwa rzeczy nie przewidziałem, więc powinniśmy zostać wspólnikami. Tym sposobem w zamian za 4% przychodów zacząłem rozwijać system e-commerce w modelu SaaS wiele lat przed tym, jak ktoś użył tego terminu. Tak narodziły się firma IAI i platforma sklepowa IAI-Shop (obecnie IdoSell), których obroty dziś sięgają 11 mld zł rocznie.

Klasa 1.0. Bezpośredni odczyt z bazy SQL

Przez kilka lat mój pierwszy kod, podobnie jak pierwotne wersje Amazona, był tak napisany, że sklep stanowił aplikację bazodanową. Mózgiem takiego sklepu jest baza SQL (np. MySQL, PostgreSQL). Skrypt (w PHP czy Pythonie) podczas generowania np. listy towarów wykonuje szereg zapytań do bazy danych, aby wygenerować listę towarów z danej kategorii, posortowanych w określony sposób. To, co zwraca baza danych w odpowiedzi, zamieniane jest w kod strony internetowej sklepu (schemat 1).

Zaletą tak napisanego programu jest jego niski koszt. Każdy programista może go szybko stworzyć. Kolejne funkcje da się w nim wprowadzić bardzo prosto, w zasadzie przez zmianę zapytania do bazy danych. Dlatego mogę dzisiaj rekomendować to rozwiązanie tylko do szybkiego i taniego stworzenia prototypu sklepu, kiedy Twoje potrzeby i wymagania są tak nietypowe, że żaden gotowy system nie pozwala ich spełnić.

      Schemat 1

Plan odczytu z bazy SQL

Nowość!

Prenumerata z pakietem e-szkoleń

Dopasuj „E-commerce w Praktyce” do swoich potrzeb i poszerzaj wiedzę w najdogodniejszy dla siebie sposób. Wybierz prenumeratę z pakietem e-szkoleń wideo. W ramach subskrypcji otrzymasz: 4 wydania w wersji drukowanej, dostęp do 5 e-szkoleń wideo od razu, możliwość udziału w szkoleniach „na żywo”, dostęp do pełnego archiwum (w sumie 16 numerów w PDF) i wiele więcej. Sprawdź szczegóły już teraz.

Dowiedz się więcej

      Schemat 2

Schemat cache‘owania stron WWW

Wadą rozwiązań klasy 1.0 jest szybko rosnący koszt serwerów wraz ze wzrostem skali działalności. Kiedy oglądalność strony jest coraz większa, system przestaje się wyrabiać. Relacyjne bazy danych SQL niezbyt dobrze dają się rozbijać na wiele serwerów. Rozwiązaniem może być konfiguracja z potężnym serwerem (który jest drogi), ale gdy przychodzi pik sprzedażowy – czyli np. oglądalność 5, 10 czy nawet 20 razy większa niż normalnie – sklep pada i nie można obsłużyć w nim nawet minimalnej liczby klientów.

Dodatkowo taki system podczas częstych aktualizacji danych (np. zmiany liczby produktów) blokuje plik z tabelą w bazie, żeby chronić ich integralność. W sklepie oznacza to „zawieszenie się wczytywania strony” w oczekiwaniu na bazę danych. Rozwiązanie stanowią upraszczanie systemu i optymalizacja zapytań. Przykładowo takie systemy nie mają wbudowanej gospodarki magazynowej, a jedynie ogólną informację o dostępności. Dzięki temu nie zachodzi potrzeba aktualizowania liczby produktów. Właściciel sklepu nie dostrzega tego ograniczenia i jest przekonany, że dzięki temu ma prosty w obsłudze system.

Klasa 1.5. System z cache’owaniem informacji

Cache to inaczej bufor. Jak wyjaśniałem wcześniej, podstawowe dane zapisane są w bazie SQL. Aby za każdym razem nie odpytywać jej całej, lepsze systemy buforują wybrane, gotowe partie danych. Może to być np. samo drzewo kategorii, które obecnie są aktywne w sklepie. Informacja o nim będzie używana na każdej stronie. Rezygnacja z odpytywania bazy o to w kółko od nowa i użycie cache’a pozwolą zaoszczędzić dużo mocy obliczeniowej.

Oprogramowanie klasy 1.5 to większość „prostych” SaaS-ów i darmowych rozwiązań open source dostępnych w Polsce i globalnie. Pracuje ono wydajniej niż system klasy 1.0, czyli np. będzie zużywało dwa razy mniej mocy obliczeniowej. Nadal jednak, tak jak system klasy 1.0, skaluje się ono liniowo. Czyli dwukrotny wzrost ruchu w nim wygeneruje podwójne zapotrzebowanie na moc obliczeniową. Pik sprzedażowy przeciąży taki sklep bez problemu.

Ponieważ architektura tego typu jest nieskalowalna, najczęściej nie sensu np. podwajanie mocy, ponieważ w trakcie piku i tak jej nie wystarczy. Dlatego często w wypadku „małych” SaaS-ów różnice w cenniku danego dostawcy nie wynikają z ilości mocy obliczeniowej czy ruchu, tylko z funkcji. A to moc obliczeniowa przecież jest dużym składnikiem kosztu utrzymania klienta i rzutuje na inne czynniki, takie jak koszt wsparcia technicznego, back-upu itp.

Klasa 2.0. System z cache’owaniem stron

W IdoSell optymalizowaliśmy więc zapytania SQL i dodawaliśmy kolejne funkcje. Po wielu latach wiedziałem, że najwięcej ruchu generują karty produktów. W trakcie promocji, wysyłki newsletterów, wprowadzania nowej kolekcji itp. mocno rośnie liczba wywoływanych stron wyszukiwania towaru, a to one generują największe obciążenie bazy danych. Jednocześnie podczas piku większość osób ogląda te same witryny i produkty (schemat 2).

Na podstawie takich obserwacji wprowadziliśmy dekadę temu mechanizm buforowania (cache) nie tylko fragmentów informacji, lecz także całych stron. Działa to tak, że podczas generowania odpowiedzi (strony HTML) do przeglądarki program zapisuje „na boku” całą witrynę i jej indeks.

Jeżeli kolejny klient pyta o dokładnie taką samą stronę, nie jest uruchamiany nawet mechanizm skryptowy, lecz zwracana jest zapisana wcześniej wersja kodu HTML. Dzięki temu kolejny użytkownik dostaje stronę błyskawicznie, prawie bez obliczeń. Można więc powiedzieć, że tysiąc osób, które przyjdą i odpalą ten sam link, wygeneruje obciążenie porównywalne z obciążeniem w systemie klasy 1.5.

Zalety tego rozwiązania to zatem możliwość lepszego skalowania i obsługi pików sprzedażowych oraz nieliniowy wzrost obciążenia serwera względem ruchu. Wadami są natomiast dużo trudniejszy do napisania kod (jego stworzenie może zająć lata) oraz konsumowanie potężnych ilości dodatkowej przestrzeni dyskowej i pamięci operacyjnej.

Ewentualne błędy w takim kodzie objawiają się nieaktualnymi informacjami lub innymi usterkami. Buforowane strony trzeba przechowywać i nimi zarządzać, zwłaszcza że lista towarów może wymagać aktualizacji już po kilku minutach, np. gdy jeden z towarów się skończył i nie powinien się już pojawiać w wynikach wyszukiwania. Dlatego ustawia się czas życia cache’a (np. 10 min) i po tym okresie kolejna osoba generuje odpowiedź już na podstawie bazy danych.

Wyzwaniem jest też obsłużenie cache’a w taki sposób, aby zamienić tylko ceny – tak, żeby klient z rabatem, korzystający z oferty specjalnej lub kodu, widział takie ceny, jakie powinien. Taka strategia z kolei powoduje, że ogranicza się liczbę możliwych kombinacji stron, m.in. przez odejmowanie niepotrzebnych permutacji (np. zmienianie liczby produktów na stronie), i redukuje liczbę elementów filtrowania.

Rozwiązania klasy 2.0 są często dodatkiem dla bardziej zaawansowanych użytkowników. Czasami to osobne, tworzone dla dużych sklepów wersje „pro” lub „plus” programu w rodzaju „małego SaaS”. Gdy oferowana jest taka wersja usługi, prawdopodobnie oznacza to dodanie do niej mechanizmu cache. Jeżeli wybierasz oprogramowanie przeznaczone dla dużych sprzedawców, to jest ono najczęściej rozwiązaniem klasy 2.0 (z dodanym cache’em).

Klasa 2.5. Cache’owanie stron z preloadem

Zabieg z cache’em na poziomie 2.0 sprawdza się świetnie, o ile samo generowanie strony działa szybko. Jeżeli strona bez cache’a ładuje się wolno (np. w Magento), dodaje się do niej specjalnego pajączka, który tak jak klient chodzi po sklepie i dla każdego linku generuje dane do cache’a. Wykonuje tzw. preload lub w żargonie: „wygrzewanie cache’a”, tak żeby potem klient podczas zakupów nie używał stron bez niego.

Taki system składa się więc ze sklepu, systemu cache i pajączka, który wywołuje poszczególne strony, żeby zapisać je w cache’u dla wszystkich kombinacji stron. Czasami takie systemy potrafią być inteligentne, np. tworzyć z większą częstotliwością strony częściej zmieniające się lub odwiedzane przez więcej klientów.

Wadą rozwiązania klasy 2.5 jest ogromne zapotrzebowanie na moc obliczeniową, nawet gdy nie ma ani jednego klienta. Generowanie stron obciąża bowiem serwery, nawet gdy nikt tych stron nie pobiera.

       Schemat 3

Porównanie tradycyjnego CMS z headless CMS

 Klasa 3.0. Headless front-end, mikroserwisy, autoskalowanie itp.

W IdoSell przez wiele lat staraliśmy się dostarczyć klientom rozwiązanie klasy 2.5 automatycznie skalujące się. Niestety, to niełatwe, ponieważ bardzo trudno jest do niego dodawać nowe serwery, zwiększać pamięć dla baz SQL i klasycznej architektury. Niedawno dojrzały do poziomu komercyjnego nowe technologie, które od razu postanowiliśmy wykorzystać. Bazują one na stworzeniu osobno części back-end i osobno – front-end. To oznacza, że front-end w ogóle nie pracuje na bazie SQL sklepu. Nazywa się to w żargonie technologią headless front-end (schemat 3 na następnej stronie).

Działa to w uproszczeniu tak jak napęd hybrydowy w samochodzie. Silnik spalinowy pracuje z równą prędkością i ładuje akumulator, z którego silnik elektryczny pobiera energię.

W rozwiązaniu klasy 3.0 silnik spalinowy odpowiada bazie danych sklepu, jego silnikowi, panelowi administracyjnemu, API itp. Pracuje z równą prędkością i izoluje zapytania mogące blokować i przeciążać bazę ze strony front-endu, w którym może się pojawić pik oglądalności.

Efekt pracy wysyłany jest do osobnej bazy danych, używanej wyłącznie na potrzeby front-endu, czyli tego, co widzi konsument w sklepie internetowym. Baza danych front-endu nie musi być transakcyjną, SQL-ową bazą (może być tzw. NoSQL). Dane w niej nie muszą być superaktualne. Jej struktura jest optymalna do wyszukiwania we front-endzie, żeby uniknąć złączeń tabel w bazie danych.

Zaletami takiej architektury są skalowalność i możliwość stosowania nieograniczonej liczby wariantów stron. Inaczej niż w klasie 2.5 (z tzw. preloadem cache), można tu używać dowolnej liczby filtrów, wyszukiwań, parametrów. Taka strona lepiej się też internacjonalizuje. Jej działanie jest bardzo szybkie. To pozwala też na dodawanie kolejnych komplikacji, np. można sterować kolejnością towarów w zależności od profilu zbudowanego dla danego klienta.

Klient, który woli produkty eko, takie zobaczy jako pierwsze, a jeżeli preferuje artykułu luksusowe, to one pojawią mu się najpierw. Dzięki temu system nie tylko lepiej się skaluje, lecz także zarabia dodatkowe pieniądze dla sklepu.

Dużym przełomem w technologiach webowych było pojawienie się takiej usługi jak Elasticsearch. Można powiedzieć, że dzięki niej da się uruchomić w klastrze serwerów takiego mini-Google’a. To pozwala na rozwój technologii headless superskalujących się, podobnie jak robi to wspomniana wyszukiwarka

Dodatkowo tak napisany system można autoskalować. Stosowanie bazy NoSQL, Elasticsearch i brak wykorzystywania relacyjnych baz danych pozwalają na dynamiczne dodawanie serwerów i ich odejmowanie, gdy pojawia się i kończy pik sprzedażowy. Takie rozwiązanie idealnie nadaje się więc do chmur.

Wadą rozwiązań klasy 3.0 jest trudność i w budowie, i w zbudowaniu front-endu, i w ich utrzymaniu. Niewielu specjalistów potrafi administrować takimi systemami, nie wspominając o tym, że bardzo niewiele platform SaaS oferuje takie możliwości. W obszarze open source bardzo silną pozycję na świecie wywalczył Vue Storefront. Niestety, jego dodanie do platformy Magento czy PrestaShop wymaga sporej wiedzy specjalistów, a co za tym idzie – wysokiego budżetu.

Gdzie to zmierza, co wybrać?

Dzisiejsze marketplace’y, tj. Allegro czy Amazon, są systemami klasy 3.0. Klienci mogą w nich ekspresowo przeszukiwać miliony towarów, a one podczas pików sprzedażowych nawet za bardzo nie zwalniają. Niestety, większość sklepów internetowych nie jest klasy 3.0. Dochodzi do tego, że klienci wybierają marketplace’y z Twoją ofertą tylko dlatego, że w tym czasie Twój sklep działa wolno. Ty płacisz w dodatku prowizję, co też jest ogromnym kosztem, którego przecież nie musisz ponosić.

Rośnie też procent zakupów na smartfonach, czyli nie tylko na małych ekranach, lecz także przy wolnym połączeniu mobilnym. Klienci kupujący w ten sposób chcą zamknąć transakcję w 5 min, np. podczas jazdy tramwajem. Strona musi więc odpowiadać szybko, w przeciwnym razie albo nie sfinalizują oni transakcji wcale, albo zrobią to na platformie marketplace.

Przestoje spowodowane niewydajnością sklepu mogą być ogromne. Statystycznie strona, która wczytuje się nie 0,5 s, ale np. 2,5 s, będzie miała na start 30–40% mniejszą sprzedaż, niż mogłaby mieć. A gdy czas ten urośnie do 5–10 s, sklep straci połowę sprzedaży.

Warto na pewno zrozumieć, co różni dostępne rozwiązania dla sklepów, i nie dać się złapać na hasła. Trzeba zapytać dostawcę o to, jak umożliwia Ci skalowanie wraz ze wzrostem sprzedaży i jak będzie się kształtował tego koszt.

Podsumowanie

Pamiętaj, że można relatywnie szybko poprawić grafikę, nawet UX strony, dodać narzędzia marketingowe, ale architektury rozwiązania sklepowego nie da się modyfikować. Jeżeli decydujesz się na zbudowanie własnego systemu, wybór klasy 1.0 lub 2.0 będzie miał poważne konsekwencje. Poskutkuje niedostępnością sklepu lub jego wolnym działaniem. To podetnie Twoje przychody – przy rosnącej ilości mocy obliczeniowej, czyli coraz wyższych kosztach. Dlatego każdy sklep internetowy myślący o przyszłości powinien wybierać rozwiązanie klasy 3.0 – umożliwiające efektywne prowadzenie biznesu, gdy sprzedaż się rozwinie.

WYKRES

Ruch możliwy do obsłużenia i jego koszty w systemach poszczególnych klas