Support 24/7: +48 61 646 07 77
Z artykułu dowiesz się:
Platforma Magento nie bez powodu uchodzi za niekwestionowanego lidera wśród dostępnych na rynku platform e‑commerce, z których korzystają zarówno marki B2B, jak i B2C.
Jeżeli zastanawiasz się nad wdrożeniem tej platformy w Twoim biznesie, koniecznie przeczytaj tę publikację. Dzięki niej lepiej zrozumiesz i poznasz najważniejsze komponenty infrastruktury Magento dla e‑commerce.
W celu przybliżenia rozwiązań, poniżej opisujemy przykładowy układ infrastruktury komponentów e‑commerce. Przedstawiamy podejście dające w praktyce dużą elastyczność oraz wysoką dostępność usługi.
W naszej codziennej pracy w Centurii wykorzystywaliśmy wielokrotnie ten stos aplikacyjny zarówno dla małych, jak i dużych projektów opartych o Magento.
Na warstwie pierwszej znajdują się elementy infrastruktury Magento, dzięki którym mamy wysoką dostępność front‑endu, (czyli sprawnie działającą zawartość strony internetowej widzianej przez każdego użytkownika, m.in. menu strony www, zamieszczonych na niej grafiki, animacji, czy układu tekstów).
W pierwszej warstwie umieszczone są także odpowiedzialne za obsługę poszczególnych zadań cache (mechanizmy odpowiedzialne za pamięć podręczną wyszukiwarki).
Rozwiązaniem, które pomaga cache zapewnić prawidłowe działanie strony internetowej, jest Keepalived. To ono zapobiega zerwaniu połączenia.
Jeżeli dojdzie do awarii jednego serwera, Keepalived przekazuje dane na adres IP innego, sprawnie działającego serwera. Taki sposób działania umożliwia protokół VRRP, który z każdego serwera wysyła cykliczne powiadomienia.
Zawierają one informacje o tym, że dany serwer prawidłowo działa. W przypadku, gdy jeden z serwerów ulega awarii, Keepalived przestaje wysyłać powiadomienia VRRP. Bazując na algorytmie, podejmuje dalej decyzje o tym, który z serwerów przejmie niedostępny w danej chwili adres IP.
Narzędzie Keepalived pozwala również na weryfikację, czy inne komponenty (np. Nginx – serwer www) działają poprawnie. W przypadku awarii Keepalived uznaje samego siebie za uszkodzonego i wyłącza się z klastra („udaje” własną awarię). W ten sposób otrzymujemy zabezpieczenie dostępności pamięci podręcznej (cache) między serwerami.
Spoglądając na zamieszczony wyżej rysunek, dostrzeżesz, że użytkownik odwiedzający stronę sklepu internetowego opartego o infrastrukturę platformy Magento, w pierwszej chwili trafia na cache1.
Następnie pamięć podręczna (cache1) wysyła zapytanie do Nginx1 (serwera www), który sprawdza czy Varnish1 (akcelerator HTTP optymalizujący czas dostępu do otwieranych stron internetowych) jest dostępny i działa prawidłowo. Jeśli nie działa on prawidłowo, to Nginx1 pobiera zawartość z Varnish2.
Kiedy użytkownik zadaje konkretne zapytanie dotyczące Varnish, to akcelerator HTTP przeprowadza procedurę weryfikacji posiadanych cache. Ma ona sprawdzić, czy wśród nich znajduje się zawartość, o jaką pyta dany użytkownik.
Jeżeli okaże się, że Varnish posiada tę zawartość w cache, to dostarcza on użytkownikowi wskazaną treść prosto z pamięci podręcznej (RAM). Odbywa się to z bardzo dużą prędkością i wydajnością.
Natomiast jeżeli okaże się, że Varnish nie posiada takich cache, to przesyła żądanie o przesyłanie zawartości do jednego z serwerów APP (inaczej to serwer aplikacyjny – obsługuje żądania kierowane do konkretnej aplikacji, do jakiej zapewnia dostęp). Po otrzymaniu odpowiedzi zapisuje on w pamięci podręcznej te treści, które zgodnie z ustawieniami mogą zostać zapisane.
Warto w tym miejscu podkreślić, że precyzyjna i szczelna konfiguracja Varnish jest tutaj kluczowym elementem. Zapisane w cache dane, (takie jak np. numer karty kredytowej) dzięki niej nie będą udostępniane niewłaściwemu użytkownikowi, co mogłoby być poważnym zagrożeniem.
Algorytmów odpowiedzialnych za podejmowanie decyzji, do którego z serwerów APP zostanie przekazane dane zapytanie, istnieje kilka. Proces ten może odbyć się w ramach random lub na podstawie ustalonych wcześniej wag (jest to szczególnie przydatne w przypadku serwerów APP o różnych zasobach obliczeniowych).
Varnish posiada również mechanizm odpowiedzialny za odłączanie z ruchu działających serwerów aplikacyjnych. W ten sposób zapewnia wysoką dostępność na poziomie serwerów APP.
Głównym celem warstwy drugiej jest obsługa żądań wysyłanych przez użytkowników poprzez generowanie strony WWW. W warstwie tej znajduje się wcześniej wspomniany serwer aplikacyjny (APP).
Na serwerach aplikacyjnych umieszczony jest NGINX (serwer www) z PHP‑FPM (to technologia, która pozwala na zapisanie w pamięci serwera elementów i instrukcji, do których odnosi się zapytanie użytkownika.
Elementy te mogą zostać ponownie wykorzystane po pojawieniu się tego samego zapytania). Ich zadanie to odebranie żądania, którym jest wyszukanie konkretnego HTTP oraz wygenerowanie danej strony www z wykorzystaniem kodu PHP.
Dodatkowo na serwerach aplikacyjnych znajduje się również usługa Redis, która odpowiada za przechowanie konfiguracji Magento (tzn. zapisuje w pamięci podręcznej widoki kategorii produktów czy np. CMS).
Gluster działa jako współdzielony storage (dodatkowa przestrzeń przeznaczona do przechowywania danych) między serwerami aplikacyjnymi.
Magento wymaga, żeby te dane były jednolite dla wszystkich serwerów aplikacyjnych. Nawet kilkusekundowa różnica może spowodować nieprawidłowe działanie, które będzie powodowało awarię trudną w naprawie i samej diagnostyce.
Zazwyczaj gluster wykorzystywany jest do przetrzymywania plików statycznych (media) i plików konfiguracyjnych. W dużym uproszczeniu: NGINX (serwer www), odczytując plik z gluster‑client, wysyła żądanie do warstwy III, którą tworzy serwera gluster. W ten sposób serwery gluster zawsze mogą zapewnić dostęp do jednolitej zawartości przechowywanych plików.
Kluczowym elementem poprawnego działania platformy e‑commerce jest obsługa zapytań serwera aplikacyjnego, kierowanych do baz danych.
Sama aplikacja powinna mieć możliwość komunikacji ze wszystkimi serwerami znajdującymi się w danym klastrze. Najprostszym sposobem do load‑balancowania tych zapytań jest Proxy SQL lub haproxy.
Zalecamy wykorzystanie pierwszego narzędzia, ponieważ w odróżnieniu od haproxy, Proxy SQL działa na warstwie 7 TCP/IP (a nie jak haproxy na 4). Rozwiązanie to umożliwia podjęcie decyzji na podstawie typu zapytania (np. SELECT czy INSERT). W ten sposób proces ten pozwala trafić do bazy danych, znajdujących się na konkretnym serwerze w odpowiednim klastrze.
W takiej konfiguracji możemy przyjąć przykładowe rozwiązanie, w którym cały klaster jest klastrem służącym do zapisu/odczytu danych lub jeden z nodów (komputer wyposażony w kartę sieciową) służy tylko do zapisu. Tymczasem pozostałe są wykorzystywane jedynie do odczytu (np. wykonywania samych selectów).
Oba wyżej opisane narzędzia oferują funkcjonalność wysokiej dostępności, (tj. potrafią odłączyć z klastra niedziałającego lub z przeciążonego serweru bazodanowego).
Zadaniem, które w infrastrukturze Magento spełnia warstwa trzecia jest przechowywanie danych. Warto wiedzieć, że Magento, jak i wiele popularnych frakmeworków opartych o PHP napisane jest dla narzędzia MySQL lub jego forków – Percona i MariaDB (ostatnia z wersji jest najbardziej popularna i rekomendowana).
Baza danych przechowuje wszystkie kluczowe informacje biznesowe o e‑commerce, tzn. konta klientów, zamówienia, magazyn, opisy produktów itd. Dostępność i pełna spójność bazy jest najważniejszym celem każdej infrastruktury.
Do zapewnienia wysokiej dostępności i spójności MySQL można wybrać najbardziej popularne rozwiązanie – Galera Cluster. Jest to rozwiązanie multi‑master, (tzn. wszystkie serwery w klastrze obsługują zarówno zapytania read i write, jednocześnie wysyłając aktualizację danych do jednego serwera). Galera upewnia się, że dane te zostały zaktualizowane na wszystkich uczestnikach klastra.
Zaletą tego rozwiązania jest jego prostota. W przypadku awarii jednego z node’ów, na który skierowaliśmy zapytania typu write, dochodzi do szybkiego przełączenia zapytań na inny serwer. Dzięki temu dany serwis internetowy działa stabilnie i pozostaje odporny na awarie pojedynczych elementów.
Główną wadą tego rozwiązania jest jednak prędkość działania całego klastra multi‑master. Pozostaje on ograniczony przez prędkość działania najwolniejszego node’a.
W warstwie III znajduje się Redis. Przechowuje on informacje operacyjne związane z bieżącym działaniem systemu. Jego rolą jest znaczące przyspieszenie dostępu do danych potrzebnych w pracy framework’u (mechanizmu działania danej aplikacji).
Są to przede wszystkim informacje o sesji użytkowników (tj. tokeny związane z zalogowaniem w systemie, które utracone mogą doprowadzić do resetu koszyka).
Redis dodatkowo oferuje funkcjonalność klastra active‑active lub active‑passive. Jest to stosunkowo stabilne rozwiązanie, które umożliwia obsługę bardzo dużej liczby zapytań przy minimalnych zasobach sprzętowych.
Zazwyczaj w przypadku Redis rekomendujemy usługę w formie active‑passive. Podyktowane jest to naszym doświadczeniem z wieloma problemami, na które natrafiliśmy ustawiając active‑active w połączeniu z dużymi instancjami Magento (głównie związanych ze spójnością danych).
Warto wiedzieć, że Redis najlepiej pracuje w połączeniu z dodatkiem sentinel. To on zapewnia wysoką dostępność klastra w przypadku awarii jednego węzła.
W warstwie III znajduje się jeszcze element określany jako Common Storage. Pozwala on na współdzielenie danych, takich jak media, dokumenty (np. reklamacyjne etykiety wysyłkowe), czy konfiguracje pomiędzy serwerami aplikacyjnymi.
W jego przypadku należy zwrócić szczególną uwagę na wydajność. W ciągu kilku lat na platformie e‑commerce mogą pojawić się olbrzymie ilości plików (nawet kilka milionów).
W takim przypadku rozwiązanie Gluster może sprawiać kłopoty ze stabilnością i wydajnością. Zdarza się to szczególnie w przypadku, gdy wszystkie pliki są w jednym katalogu.
Warto wiedzieć, że Gluster oferuje mechanizmy wysokiej dostępności na poziomie klienta, który wybiera z dostępnych węzłów klastra, do jakiego serwera się podłączy. Z tego powodu nie jest konieczne zapewnienie tego rozwiązanie po stronie samego serwera.
To ostatnia warstwa w infrastrukturze komponentów, która pozostaje z tyłu i może obsługiwać niezależne zapytania. Wśród jej przykładowych funkcji znajdują się:
W artykule omówiliśmy wszystkie niezbędne elementy wchodzące w skład infrastruktury komponentów Magento.
Warto jednak podkreślić, że ten układ danych nie jest typowy tylko dla Magento. Ma on również zastosowanie m.in. w przypadku Shopware, co oznacza, że może on występować również w innych infrastrukturach platform e‑commerce.
Układ ten pozostaje niezależny bez względu na to, czy przygotowujemy kontenery z poszczególnych warstw. Pozostaną one podobne, jedynie może zmienić się sposób realizacji działań, które mają prowadzić do uzyskania np. wysokiej dostępności.
![Bezpieczeństwo środowisk testowych [krótki poradnik dla DevOps/SysOps]](https://centuria.pl/wp-content/uploads/2022/09/07-12-bezpieczenstwo-srodowisk-424x228.jpg)
