Przeniesienie sklepu internetowego do chmury

Trudno sobie wyobrazić biznes, który może bardziej ucierpieć w przypadku niedziałania serwisu www niż sklep internetowy (jest to zresztą ryzyko dla całej branży e-commerce). Dlatego przeniesienie sklepu internetowego do chmury rozważa coraz więcej podmiotów e-commerce. Pikanterii dodaje fakt, że 40% internautów porzuca sklep, gdy ten nie załaduje się w czasie poniżej 3 sekund. Jakby tego było mało, aż 79% użytkowników mniej chętnie wraca do sklepu, gdy ten podczas poprzednich zakupów miał problemy z szybkością działania. Jest więc nad czym pracować. 

Przeniesienie sklepu internetowego do chmury – wprowadzenie

Zdecydowana większość ruchu  w sklepach internetowych pochodzi z wyszukiwarek i porównywarek. Skoro już ktoś znalazł i wybrał Twój sklep, nie można dopuścić, aby strona www się nie załadowała. Jak będzie „zamknięte”, klient kliknie kolejny link i prawdopodobnie już nie wróci. Sklepy internetowe działają na różnych platformach, zarówno własnych jak i gotowym oprogramowaniu, jak np. PrestaShop, Magento, Quick.Cart, OpenCart, VirtueMart, osCommerce, WooCommerce i innych. Każde rozwiązanie ma swoje wady i zalety, ale niezależnie od platformy, finalne rozwiązanie musi trafić do sieci.  Nie zawsze wybór tego miejsca dokonywany jest z należytą starannością. Uruchamiamy sklep, działa fajnie. Pytanie, jak zabezpieczony jest hosting? Jaką dostępność gwarantuje usługodawca? Po jakim czasie przywróci dane? Popularne usługi hostingowe zwykle nie zapewniają całodobowego suportu, a do tego SLA (umowny poziom dostępności usługi) liczony jest w długich godzinach, a nawet dniach. Nawet jeśli SLA nie jest dotrzymane, to marnym pocieszeniem będzie 50 zł rekompensaty, jeśli sklep nie działał dwa dni. 4h awarii nie wydaje się długo, prawda? Ok, ale awaria od 17:00 do 21:00 w Black Friday brzmi już znacznie gorzej.

Jeśli poważnie traktujesz swój biznes e-commerce musisz przyjąć, że każdy element infrastruktury może zawieść. Obietnice usługodawcy zawsze będą puste, jeśli nie zabezpieczysz się na poważnie – poczynając od zdublowania każdego elementu sklepu, a kończąc na utrzymaniu kopii serwisu w innej lokalizacji niż pierwotna – gotowej do uruchomienia w razie totalnej awarii u usługodawcy.

Osobną kwestią pozostanie dopasowanie się infrastruktury do obciążenia, które dla każdego sklepu jest zmienne. Niezależnie od tego, czym handlujesz, pojawiają się okresy większego i mniejszego obciążenia, dziennie albo w cyklu rocznym (święta, dzień dziecka/matki/ojca, walentynki itp). Albo w czasie zwykłej promocji.

To właśnie chmura pozwala ograniczyć ryzyko biznesowe, dając jednocześnie atrakcyjne warunki elastycznego dopasowania zasobów do potrzeb. W końcowym rozrachunku zredukujesz koszty prowadzenia biznesu. Ponadto stałe myślenie o tym, czy coś może przestać działać, odciąga Cię od myślenia o biznesie i zajmowania się tym, na czym się najlepiej znasz.

Sprawdźmy, jak może ewoluować Twoja infrastruktura w Amazon AWS w miarę rozwoju biznesu i odpowiedzialnego podejścia do jego utrzymania. Znajdziesz tutaj odpowiedź, jak chmura skaluje swoją „moc” w zależności od potrzeb. Z naszą pomocą przeliczysz także koszty utrzymania sklepu w chmurze Amazon. Możesz zacząć od małych zasobów i tak jak będzie rósł Twój biznes (albo kak będziesz gotowy na kolejne kroki dostosowania Twojego sklepu do chmury) – dokładać kolejne klocki, zyskując coraz większą skalowalność i bezawaryjność platformy.

Każdy kolejny krok, który zrobisz,zwiększy bezawaryjność, elastyczność, skalowalność i dostępność serwisu, a na końcu pozostałe elementy układanki zadbają o najdrobniejsze aspekty infrastruktury.

Pojedyncza instancja w AWS – level 1

Infrastruktura jest odzwierciedleniem jednego serwera lub VPSa. Taką opcję możesz znaleźć w każdej chmurze i poza nią. To pierwszy krok, bo i tak przenosząc hosting sklepu internetowego do chmury, możesz czerpać z tego faktu korzyści – w każdej chwili możesz zwiększyć zasoby instancji, dodać jej więcej procesorów czy rdzeni, pamięci RAM, a także rozszerzyć dysk. Wszystko to sprawi, że sklep będzie niedostępny jedynie kilka minut, a ty nie musisz niczego migrować, przenosić ani kopiować, do nikogo pisać. Oszczędność czasu i kosztów jest niezaprzeczalna, bo zmianę możesz wykonać w każdej chwili w górę i w dół, a zapłacisz tylko za godziny pracy większych zasobów.

Pojedyncza instancja w AWS oraz baza danych w RDS – level 2

To wersja jaka pierwsza zaczyna korzystać z zalet chmury obliczeniowej. Do naszej pojedynczej instancji dołączamy bazę danych zlokalizowaną w Amazonowej usłudze RDS ( Relational Database Service). Nie trzeba instalować Mysqla, Postgresa czy innej bazy (Amazon Aurora, Oracle, MSSQL, MariaDB) – wybieramy ją jako usługę i interesują nas tylko dane, RDS pozwala wybrać odpowiednie zasoby i łatwo je w razie potrzeb zeskalować. Dodatkowo w łatwy sposób możemy tworzyć kopie zapasowe, automatyczne (nawet samodzielnie) i zapisywać je w innym regionie w koszyku S3, do którego tylko my mamy dostęp i otrzymując gwarancję, że nikt nam nagle wszystkich tych danych nie usunie. Instancja zajmuje się serwowaniem strony, pracuje tam aplikacja sklepu czy to Prestashop czy Magento, a do bazy łączy się do usługi RDS. A baza danych to jedno z bardziej obciążonych miejsc w sklepie internetowym, więc nie tylko rozdzielisz obciążenie na  dwie usługi, ale także ułatwisz sobie ew. diagnostykę problemów, obciążenia itp. I tak samo możesz zmieniać zasoby – osobno instancji EC2 z serwisem, albo RDS osobno. Ogromna wygoda i elastyczność – w końcu o to w chmurze chodzi – kiedy będziesz oczekiwał dużego ruchu po prostu na kilka dni czy tygodni. kupisz większe zasoby bez zmartwień i ponoszenia opłat na infrastrukturę, która 90% roku nic nie robi. Zastosowanie RDS daje też inne profity, ale o nich później.

Pojedyncza instancja, RDS oraz pliki statyczne przechowywane w S3 – level 3

Powoli docieramy do sedna chmury. Nasz sklep zyska elastyczność i możliwości zmian w infrastrukturze w momencie, kiedy pozbędzie się zapisu ważnych danych w ramach samej instancji. Możemy to uzyskać, przenosząc pliki sklepu do S3. To kwintesencja Amazon Web Services, historycznie pierwsza usługa w chmurze, miejsce na plik, które jest proste w użyciu, bez limitu ilości czy przestrzeni, skalowalne, posiada niebywałą redundancję i pewność zapisu. Jednocześnie niczego nie musimy rezerwować ani patrzeć na limity, płacimy tylko za ilość danych, transfer,ilość odczytów i zapisów plików. AWS gwarantuje dostępność S3 na poziomie 99,99% (coś może nie działać przez 0,5s miesięcznie). Zapisujesz pliki takie, jak obrazki, zdjęcia czy wgrywane pliki w S3, dane sklepu, klientów i zakupów masz w bazie danych RDS. Na instancji masz tylko pliki kodu sklepu, które w każdej chwili można wgrać na nowo. Jak dojdziesz do tego miejsca, skalowanie serwisu w chmurze stanie przed Tobą otworem.

Pojedyncza instancja, RDS oraz pliki statyczne przechowywane w S3, sesje w Amazon ElastiCache – level 4

Nowe pojęcie to aplikacja bezstanowa. Czyli taka, jak w wersji powyżej: dane w bazie danych, pliki w S3, sesje w… no właśnie sesje. Żaden serwis nie obejdzie się dziś bez sesji, zapisywanie ich w bazie czy w S3 nie jest dobrym pomysłem ze względów wydajnościowych. Idealnie miejsce to Memcache czy Redis. Ale przecież wtedy ich utrata, zmiana instancji czy restart i po sesjach. Dlatego powstała usługa ElastiCache. Taki RDS, ale z Memcache i Redisem do wyboru. Znów AWS martwi się o zasoby, działanie i dostępność, nie ma serwera – po prostu zapisujesz dane pod wskazany adres i tyle.

Doszliśmy do ideału, każdy element działa niezależnie, w ramach instancji, czyli naszego serwera nie mamy żadnych danych, których nie dałoby się łatwo odtworzyć. Każdy składnik możemy skalować i analizować osobno. Sklep nam się rozwija, a w dalszych krokach pozostaje nam skupić się na skalowaniu i zwiększeniu bezawaryjności oraz bezpieczeństwa.

Pojedyncza instancja, RDS oraz pliki statyczne przechowywane w S3 – VPC z VPN, czyli zwiększamy bezpieczeństwo – level 5

Skoro o bezpieczeństwie mowa, to nadszedł czas na jego poprawę. Mając wszystkie dane w usługach AWS-a i dostęp do nich ma tylko nasza instancja, to dobrze byłoby, aby poza nią nic nie było widoczne w Internecie bezpośrednio z publicznym adresem IP. Żeby się dostać do tej bazy najpierw trzeba będzie się dostać na instancję. AWS zapewnia nam fajną usługę VPC (Virtual Private Cloud) – logicznie wyseparowany fragment sieci, w ramach którego pracują nasze usługi z własnym zakresem prywatnych adresów IP (to np. te słynne 192.168.x.x czy 10..x.x.x), podsieciami i routingiem. Wszystkie usługi dostają prywatne adresy IP, a do całości infrastruktury można się dostać tylko poprzez VPN (bezpieczne szyfrowane połączenie). Bez obaw – zestawić połączenie nie jest trudno i Developer się na pewno dostanie do danych, aby rozwijać sklep internetowy.

HA – dwie instancje, baza danych w RDS, pliki w S3 – level 6

Wszystko bezstanowe i zabezpieczone VPC. Serwis działa, czasem trzeba było jakieś zasoby zwiększyć na stałe, czasem tylko w okresie zakupowej nawałnicy. Dotarliśmy do momentu, kiedy doceniamy zalety hostingów sklepu internetowego w chmurze Amazon Web Services, ale nadeszła pora na budowanie środowiska wysokiej dostępności oraz na zwiększanie ilości instancji. To tutaj na froncie najczęściej pojawią się korki. Ale nie ma problemu – aplikacja bezstanowa sprawiła, że każdy element możemy rozbudować bez jakichkolwiek zmian w aplikacji. AWS w każdym regionie posiada co najmniej dwie strefy dostępności – takie osobne data center odległe od siebie z własną infrastrukturą i zasilaniem, ale połączone super szybkim łączem. Wszystkie usługi możemy rozmieścić pomiędzy te strefy (dwie lub trzy). Niektóre ręcznie, a niektóre jak np. S3 czy ELB (Load Balancer) są tak rozmieszczone z założenia. Dokładamy więc drugą instancję dla serwisu, a na froncie ich ELB, który zajmie się rozdzielaniem ruchu. Przy okazji zyskujemy kolejny poziom zabezpieczenia, bo od teraz instancje nie muszą już mieć adresów publicznych, a jedynie ELB musi go mieć. Bez dostępu VPNem nie da się już dostać nawet do instancji www. Nikt postronny się tam nie dostanie.

HA – dwie instancje, baza danych w RDS multi-AZ, pliki w S3 – level 7

W wersji poprzedniej zyskaliśmy nadmiarowość serwerów www, a teraz pora na bazę danych. Usługa RDS także występuje w opcji multi-AZ, czyli może posiadać swoją kopię w drugiej strefie dostępności. Nie tylko uchroni nas to przed awariami, ale dodatkowo pozwoli zmieniać zasoby RDSa bez przerw w działaniu serwisu.

HA – dwie instancje, baza danych w RDS multi-AZ, pliki w S3, sesje w Amazon ElastiCache z HA – level 8

Dochodzimy do ostatniego elementu bez HA. Z naszej bezstanowej architektury ostatnim elementem zostało miejsce na sesje, czyli AWS ElastiCache. Ta usługa tak samo występuje w wersji multi-AZ – zestawiamy klaster Redisa i znowu możemy swobodnie skalować usługę bez wpływu na działanie serwisu. Czyli jak widać redundancja nie tylko chroni Cię przed awariami, ale także pozwala wykonywać aktualizację usług, zmiany konfiguracji i zasobów bez wpływu na działanie sklepu internetowego.  Od teraz możesz już naprawdę spać spokojnie. Twoje źródło dochodów czyli sklep internetowy ma znikome szanse przestać działać z powodów problemów hostingowych. Chmura pozwala Ci także przy okazji stworzyć obok identyczne środowisko testowe, które możesz uruchamiać, gdy jest potrzebne i wygaszać, jeśli już nie jest. Wprowadzasz zmiany i je testujesz, jak są gotowe przenosisz je na platformę produkcyjną. Takich środowisk możesz mieć nawet kilka. To kolejny punkt poprawiający jakość działania sklepu, niezależnie od tego czy działa na platformie PrestaShop, Magento, Quick.Cart, OpenCart, osCommerce,  VirtueMart, WooCommerce, czy innych.

Wykorzystujemy Route 53 oraz CDNa Amazon CloudFront – level 9

Infrastruktura jest bardzo bezpieczna, małe szanse żeby nas coś zaskoczyło. Ale czasem awaria serwisu pojawia się tam, gdzie się tego nikt się nie spodziewał. Do serwisu dostaną się klienci pod warunkiem, że Twój serwer DNS odpowie na zapytania. Niestety wśród lokalnych dostawców domen zdarzają się problemy z DNSami. Dlatego, aby uniezależnić ten element od problemów lokalnych dostawców domen, skorzystaj z AWS-owej usługi DNS Route 53. Nie tylko zyskujemy ogromną pewność działania, ale także skracamy czas odpowiedzi serwera DNS dzięki zlokalizowaniu serwerów bliżej odbiorców. W dzisiejszym konkurencyjnym e-commerce każdy detal ma znaczenie. Drugi element – CloudFront ma już za zadanie lekko odciążyć  infrastrukturę i przyspieszyć ładowanie treści statycznych. Tym bardziej będzie przydatny, im bardziej klienci sklepu rozsiani są po świecie. To CDN CloudFront, czyli taki cache, który przechowuje najczęściej ładowane elementy witryny i serwuje je ze swojej pamięci, pomijając ich pobieranie z serwerów. Szybciej i taniej.

Uruchamiamy autoscaling – level 10

Każdy serwis ma momenty, kiedy jest obciążony bardziej lub mniej. W tradycyjnych usługach kupujemy serwer z rezerwą, który „nudzi się” większość czasu. Mając naszą elastyczną i nadmiarową infrastrukturę możemy o tym zapomnieć. AWS posiada mechanizmy, które pozwalają na podstawie obciążenia instancji podejmować określone działania. Serwer www ma od 5 minut obciążenie ponad 65% – uruchom kolejny i dołącz do load balancera. Za mało? To kolejny. Wiesz, że codziennie od 18.00 do 23.00 jest większy ruch – dostawiaj automatycznie kilka instancji więcej na te godziny. A płacisz tylko za te 5h. Wiesz, że będzie promocja na tydzień – odpal ręcznie kilka dodatkowych instancji. Można zrobić niemal wszystko, jeśli wcześniej zbudowałeś taką fajną, bezstanową aplikację i infrastrukturę opartą o AWS-owe serwisy.

Dodajemy usługi – SES – level 11

Wszyscy cieszyliśmy się, kiedy powstawały takie usługi jak Gmail, czy darmowe skrzynki Onetu, WP, O2. Dziś jednak Ci wielcy dyktują warunki i często bywa tak, że nie wiedzieć czemu Twoje maile nie docierają do odbiorców. Nie mówimy  tutaj o mailingach reklamowych, ale o zwykłych mailach z potwierdzeniem rejestracji, zamówienia, czy wysyłki towaru. To wielki problem, gdy takie maile nie docierają. Z pomocą przychodzi kolejny AWS-owy serwis SES, czyli usługa do wysyłania maili. Ilość adresów IP AWS-a jest tak ogromna, że nikt nam poczty nie zablokuje. Nie musisz się też martwić o rozsyłanie SPAMu, zabezpieczenia i konfigurację serwera pocztowego. Kolejny plus i cegiełka do układanki, z której złożyliśmy bezproblemową usługę utrzymania sklepu internetowego.

Kopia zapasowa – level 12

Na koniec backup. Ufajmy usługom AWS-a, ale posiadanie dobrej kopii bezpieczeństwa i tak jest obowiązkowe. Chmura daje nam tutaj duże możliwości. Od prostych snapshotów całych instancji, do szybkiego przywrócenia gdyby coś poszło nie tak, po backup do S3, czy utrzymanie tzw. hot-site czy cold-site.

Możesz być jeszcze lepiej przygotowany na awarię nawet całego regionu AWS (ktoś odetnie ruch do całej Irlandii), kopiując czy sam snapshot czy dane backupowane do S3 do innego regionu. Jeśli jednak chcesz być gotowy na uruchomienie serwisu w 1 czy 2h w zupełnie innym regionie możesz utrzymywać hot-site, czyli kopię architektury nieco zubożoną (minimalne zasoby), na którą stale kopiowane są dane z głównego serwisu lub też możesz utrzymywać tylko dane i obrazy środowiska pozwalające je uruchomić w maksymalnie kilka godzin. Nic też nie stoi na przeszkodzie, aby kopie trzymać w ogóle poza AWS np. w Hostersach.

Przeniesienie sklepu internetowego do chmury (PrestaShop, Magento, Quick.Cart, OpenCart, VirtueMart, osCommerce, WooCommerce i inne) – podsumowanie

To wszystko nie jest łatwe, dlatego zapraszamy do Hostersów – u nas możesz liczyć na pomoc w wyborze rozwiązań, migracji, a na koniec zlecić nam zarządzanie infrastrukturą i dbanie o jej bezpieczeństwo, monitoring działania i obciążanie, aktualność i ciągły rozwój.

Ile to kosztuje? Cóż zależy od sklepu. Przyjmijmy, że jest niewielki lub średni, bo gigantom łatwiej podejmować takie decyzje. Zakładając (mała infrastruktura), że masz 50GB danych, 10GB bazy, 100GB transferu zobacz, ile kosztuje mniejszy lub większy spokój.  Dla większej infrastruktury przyjmujemy 100GB danych, 25GB bazy, 500GB transferu.

Wycena nie uwzględnia dodatków, których zwykle nie ma porównywana infrastruktura jak zestawienie VPN czy ukrycie zasobów za NAT-GW. Należy wtedy doliczyć do kosztów około 100USD miesięcznie za wersje o wysokim bezpieczeństwie.

To tylko szacunki, komponenty dobiera się tak, aby były idealne, czasem zasoby będą większe, a czasem mniejsze. Dodatkowo jest szereg metod na redukcję tych kosztów w długim okresie (rezerwacja zasobów – płatność za rok, wykorzystanie zewnętrznych usług typu CloudFlare). Ale to już odrębny temat ?

Pytania? Skontaktuj się z nami

Zobacz również:

Chmura AWS na czas sprzedaży biletów na koncert Justina Biebera
Migracja do Amazon Web Services aplikacji Landingi.com
Hosting WordPress w chmurze AWS z pełną redundancją
Skąd się bierze wysoka dostępność (HA) w chmurze?
Infrastruktura serwerowa bez tajemnic. Serwer dedykowany, VPS, czy chmura?