Support 24/7: +48 61 646 07 77
Z artykułu dowiesz się:
Opisanie specyfiki platformy Magento jest tematem na osobny artykuł.
Planując wybór platformy warto wiedzieć o tym, że Magento zaprojektowano tak, by konieczność skalowania infrastruktury sklepu towarzysząca rozwojowi marki nie była jednoznaczna z koniecznością migracji na inne rozwiązania.
Kolejnym po wyborze platformy zadaniem jest wybór infrastruktury, z której nasz sklep będzie serwowany. Z wyborem każdej z nich wiążą się określone korzyści, ale także ograniczenia. Rozpocznijmy zatem od opisania istniejących dziś możliwości.
Termin „chmura” (ang. cloud) jest dzisiaj bardzo modnym i często wykorzystywanym.
Może wydawać się, że jest to pojęcie abstrakcyjne, najczęściej rozumiane jako zasoby serwerowe (zarówno obliczeniowe, jak i magazynujące dane) dostępne na żądanie, bez konieczności ich wcześniejszego zamawiania.
Obecnie coraz więcej firm, również z branży e‑commerce, decyduje się na delegację przynajmniej części biznesu do chmur ze względu na liczne zalety tego rozwiązania.
Podział chmur najczęściej obejmuje następujące grupy:
W dalszej części artykułu skupimy się dokładnie na chmurze publicznej od Amazona oraz przybliżymy proponowane przez nią mechanizmy, które posłużą nam do optymalizacji naszej instalacji Magento pod kątem:
Zanim rozpoczniemy instalację Magento, trzeba określić kto będzie miał dostęp do naszego konta w AWS.
Tu na pewno pomoże nam usługa o nazwie IAM (Identity and Access Management). Za jej pomocą możemy dodać użytkowników, pogrupować ich i przydzielić grupom ściśle określone uprawnienia.
Wykorzystanie grup to dodatkowa praca na początku, ale taka inwestycja czasu zwróci się tym szybciej, im więcej użytkowników będzie otrzymywać dostęp do konta.
W przypadku dodania nowego użytkownika nie będziemy musieli tworzyć skryptów ani nadawać uprawnień ręcznie – dodanie go do określonych grup przypisze mu automatycznie określone uprawnienia.
Warto także wiedzieć, że w IAM możemy wymusić stosowanie przez każdego z użytkowników mechanizmów 2FA (Two‑Factor Authentication), co przełoży się na poprawę bezpieczeństwa procesu logowania.
Usługę o nazwie KMS możemy wykorzystać do przechowywania kluczy symetrycznych i asymetrycznych, które z kolei mogą zostać wykorzystane m.in. do szyfrowania dysków (EBS), snapshotów czy zabezpieczenia dostępu do maszyn. Jeśli administrujemy dużą liczbą kont, ta usługa może okazać się niezastąpioną.
Jednym z pierwszych etapów wstępnej konfiguracji środowiska jest dostosowanie nowego VPC (Virtual Private Cloud) do architektury wdrażanego rozwiązania. Warto wówczas pamiętać o odpowiedniej konfiguracji dwóch jego usług – Security Groups (SG) oraz Network Access Control List (NACL).
Tabela 1. Lista kluczowych różnic pomiędzy Security Groups (SG), a Network Access Control List (NACL).
Korzystanie wyłącznie z Security Groups może wydawać się wystarczające, jednak aby w pełni zabezpieczyć nowe środowisko, niezbędne są także NACLe. Choćby dlatego, że konfigurując nową instancję istnieje szansa, że zapomnimy ochronić ją konkretnymi regułami SG, a po dodaniu maszyny wirtualnej do konkretnej sieci, przypisane jej reguły NACL obejmą ją swoim działaniem od razu.
Po zakończeniu wstępnej konfiguracji instancji Magento warto zabezpieczyć ją dodatkowo usługami AWS Shield oraz AWS Web Application Firewall (WAF).
Pierwsza z nich jest darmowa w wersji podstawowej (Shield Standard) lub płatna w wersji zaawansowanej (Shield Advanced).
Obie chronią przed atakami typu DDoS na warstwach sieciowej oraz transportowej. Skonfigurowanie usługi Shield uchroni naszą instancję przykładowo przed sytuacją, w której mimo istnienia konfiguracji NACL chroniącej przed niepożądanym ruchem z określonych podsieci, pożądany ruch nie dotrze do aplikacji, ponieważ łącze zostanie wysycone przez prowadzony atak.
AWS WAF wykorzystujemy w celu monitorowania ruchu naszych endpointów (np. Elastic Load Balancerów, instancji CloudFront czy REST API) po protokole HTTP(S).
Możemy skonfigurować w nim ochronę przed ruchem do określonych URL, na podstawie adresów IP czy BasicAuth – w przypadku odmowy dostępu do zasobów możemy także skonfigurować niestandardową stronę błędu 403.
Ze względu na wielość typów instancji EC2 w AWS, to zadanie jest jednym z trudniejszych. Zwłaszcza jeśli tuż po zakończeniu procesu tworzenia i testowania sklepu czeka nas jego produkcyjny start.
Na szczęście tu przychodzi nam z pomocą jedna z największych zalet chmur publicznych – możliwość szybkiego skalowania naszych instancji.
W związku z tym możemy bezpośrednio przed uruchomieniem produkcyjnym wyskalować maszyny wertykalnie, czyli zwiększyć ilość przypisanych im zasobów, a podczas startu produkcyjnego monitorować stopień ich wykorzystania usługą CloudWatch (którą omawiamy dalej) i dostosować ich ilość do potrzeb (warto zadbać o to, by pozostawić zapas na wypadek pojawienia się nieprzewidzianych szczytów ruchu).
Możemy także wyskalować środowisko horyzontalnie, czyli utworzyć zawczasu więcej maszyn (informacje o tym zagadnieniu przedstawiamy przy okazji omawiania redundancji).
Niezależnie od preferowanego podejścia należy wiedzieć, że do naszej dyspozycji oddany został kalkulator kosztów – AWS Calculator.
Narzędzie to jest darmowe i dostępne pod adresem: https://calculator.aws. Pozwala ono weryfikować koszty rozwiązań i całych środowisk, nawet jeszcze przed założeniem konta. Stworzone w nim szkice kosztowe łatwo zapisać oraz udostępnić współpracownikom czy klientowi.
Projektując i testując nowy sklep, warto mieć na uwadze jego potencjalnie wielokrotnie większy rozmiar w przyszłości.
Opisane wcześniej skalowanie wertykalne posiada swoje limity, a jego stosowanie wymaga restartu maszyny wirtualnej – jeśli jest to jedyna maszyna pełniąca daną rolę, oznacza to konieczność organizacji przerwy serwisowej.
Wiedząc o tym, warto zaprojektować środowisko tak, by awaria czy prowadzone przez AWS prace nie oznaczały, że sklep na pewien czas zniknie z sieci. W tym celu:
To rozwiązanie pozwala na automatyczne manewrowanie liczbą istniejących instancji w zależności od warunków, jakie zdefiniujemy.
Najczęściej można się spotkać z warunkami opartymi o obciążenie średnie/maksymalne istniejących workerów – przykładowe reguły:
Poza oczywistymi zaletami w postaci środowiska odpornego na awarie oraz zwiększone obciążenie możemy cieszyć się niższymi kosztami.
Każdą z uruchamianych/likwidowanych instancji możemy dodatkowo oskryptować – dzięki temu pierwszym działaniem wykonywanym na nowych maszynach może być deploy ostatniego stabilnego wydania aplikacji, bez dalszej ingerencji z naszej strony.
Jeśli zdecydujesz się na wykorzystanie więcej niż jednego workera, warto wiedzieć, że do obsługi plików współdzielonych można wykorzystać Elastic File Storage (EFS).
Usługa ta skonstruowana jest tak, by dostęp do plików współdzielonych, (np. mediów) mógł następować bezprzerwowo, bez dalszej ingerencji z naszej strony. Usługa jest z założenia wysokodostępna, wszelkie prace po stronie AWS nie będą więc powodować konieczności organizacji przerw serwisowych.
Bazę danych naszego środowiska możemy oczywiście zainstalować na instancji EC2, ale można również do tego celu wykorzystać Relational Database Service (RDS), czyli usługę relacyjnych baz danych od AWS.
Rozmiar instancji bazy danych wybieramy na podobnej zasadzie, jak maszyny wirtualne EC2. Jeśli chodzi o wydajność, zwłaszcza przy większych sklepach warto zastanowić się nad konfiguracją dodatkowych replik bazodanowych, które będą służyć wyłącznie do odczytu (read replicas).
Innym ważnym elementem wysokodostępnego środowiska (i nie tylko) jest Elastic IP (EIP). Należy wiedzieć, że maszyny wirtualne EC2 po ich zatrzymaniu i uruchomieniu ponownie zmieniają publiczny adres IP.
Dzięki wykorzystaniu EIP możemy mieć pewność, że dostęp po IP np. do instancji, na której skonfigurowana została integracja z systemem magazynowym po FTP, pozostanie taki sam (bez konieczności modyfikacji list dostępowych przy każdej awarii/pracach planowych na tej maszynie).
Konfigurując środowisko, warto pamiętać o konfiguracji backupów. Jeśli tego nie zrobimy, istnieje ryzyko, że przypomnimy sobie o tym zadaniu podczas poszukiwania kopii zapasowych po pierwszej dużej awarii.
Dla instancji EC2 warto skonfigurować mechanizm cyklicznych snapshotów. Usługa jest prosta w konfiguracji i bogata w opcje, które umożliwiają utrzymanie pożądanej przez nas retencji backupów. Najlepiej zaplanować czas na zapoznanie się z nią zaraz po uruchomieniu pierwszej maszyny wirtualnej.
Jedną z najlepszych metod zabezpieczenia bazy danych przed ich utratą i niedostępnością są repliki bazodanowe.
W usługę RDS wkomponowano mechanizmy replikacji natywnie obecne w najpopularniejszych silnikach bazodanowych, (jak np. MySQL czy PostgreSQL). Wzbogacono je jednak m.in. o usługę automatycznego promowania nowego mastera w przypadku awarii/wyłączenia instancji, która do tej pory pełniła tę rolę.
Niezależnie od replikacji bazodanowej możemy skonfigurować tworzenie kopii zapasowych danych w dwóch podstawowych formach – zarówno jako standardowe backupy, jak i jako snapshoty baz danych.
Z tej pierwszej można dokonać odtworzenia stanu bazy do dowolnej chwili od czasu utworzenia ostatniego backupu, ponieważ obejmuje ona również logi transakcyjne bazy.
AWS Backup jest usługą, która umożliwi nam nadzór nad backupowanymi zasobami i politykami z centralnego miejsca. To w niej możemy skonfigurować wykonywanie kopii zapasowych dla danych zgromadzonych w omówionej już wcześniej usłudze EFS.
Dzięki wykorzystaniu usługi AWS Config mamy możliwość śledzenia zmian w konfiguracji zasobów AWS.
Dodatkowo narzędzie to udostępnia podgląd we wszystkie obecne na danym koncie usługi. Jest ono przydatne pod kątem dokonania ich inwentaryzacji.
Możemy tu także określić różnego rodzaju reguły, które powinny być zawsze przestrzegane na naszym koncie, a w przypadku ich przekroczenia skonfigurować powiadomienia o tym (za pomocą usługi SNS omówionej szerzej w kolejnym punkcie). Nie można z tego poziomu dokonywać zmian w usługach.
Usługa CloudTrail gromadzi informacje o działaniach użytkowników na zasobach konta jako odwołania do API AWS.
W zakres gromadzonych w ten sposób danych wchodzi m.in. jakie konto zostało użyte do uwierzytelnienia danego działania, kiedy zostało ono wykonane i z jakiego adresu IP.
CloudTrail może wydawać się podobny do omówionego wyżej AWS Config, i rzeczywiście tak jest. Najczęściej jednak przy analizie incydentu współpracują one ze sobą – przykładowo dowiadujemy się o zaistnieniu oraz typie incydentu z powiadomienia wyzwolonego przez Config, a do dalszej analizy wykorzystujemy już CloudTrail.
Narzędziem służącym do prowadzenia audytów środowiska jest Audit Manager.
Jego konfiguracja polega na wykorzystaniu gotowych testów (bądź utworzeniu własnego) i weryfikacji, czy nasze środowisko spełnia wszystkie założenia wybranych norm (głównie spośród tych przyjętych w Stanach Zjednoczonych) oraz umożliwia przedstawienie zebranych danych w postaci raportu.
Ostatnim, lecz z pewnością nie najmniej istotnym zagadnieniem towarzyszącym prowadzeniu sklepu internetowego w AWS jest monitoring działających usług.
Podstawowym narzędziem do tego celu jest CloudWatch. Dzięki niemu możemy zweryfikować, w jakim stopniu wykupione przez nas usługi AWS są wykorzystywane, i jak często na podstawie jego wskazań je zoptymalizować (np. poprzez zmianę rozmiaru wykorzystywanych instancji na mniejsze).
Na podstawie jego wskazań możemy także automatycznie zwiększać ilość instancji w ruchu produkcyjnym (np. dzięki omówionemu wyżej AutoScalingowi). W usłudze CloudWatch zebrane dane są także przechowywane, co umożliwia analizę wykorzystania zasobów podczas kluczowych akcji promocyjnych.
Usługa Simple Notification Service (SNS) służy do przekazywania powiadomień z innych usług do osób odpowiedzialnych za środowisko, ale również między samymi usługami. Obsługuje m.in. powiadomienia mailowe, powiadomienia push i stanardowe wiadomości SMS.
Wymienione wyżej usługi AWS nie są oczywiście jedynymi, które mogą się okazać przydatne przy konfiguracji nowego środowiska Magento w usługach sieciowych Amazonu.
Niniejszy artykuł nie ma również wyczerpująco opisywać tych, które mogą okazać się przydatne, a jedynie pokazać z lotu ptaka możliwości, jakie daje wykorzystanie AWS.
Tworząc i konfigurując środowisko warto często korzystać z dostarczonej przez dostawcę dokumentacji – jest ona napisana przystępnie i obfituje w przykłady wykorzystania dostarczanych usług.
![Bezpieczeństwo środowisk testowych [krótki poradnik dla DevOps/SysOps]](https://centuria.pl/wp-content/uploads/2022/09/07-12-bezpieczenstwo-srodowisk-424x228.jpg)
