Przygotowujemy serwer sklepu internetowego na świąteczną gorączkę

Przygotowujemy serwer sklepu internetowego na świąteczną gorączkę

Przygotowujemy serwer sklepu internetowego na świąteczną gorączkę
30.11.2017 12:00, aktualizacja: 21.06.2019 16:57

Dla właścicieli sklepów internetowych ostatni piątek był okazją do przetestowania sprawności swojej infrastruktury, dla wielu próba w postaci masowego zainteresowania internautów promocjami okazała się zbyt trudna, przez co w niektórych sklepach internetowych zamiast korzystnych ofert, wyświetlane były jedynie komunikaty o niedostępności serwisu. Czarny PIątek to jednak w Polsce jedynie przedsmak przed prawdziwym zakupowym szałem – ten zbliża się wraz ze świętami. Jak każdy administrator powinien zadbać o swój e-sklep przed okresem przedświątecznych promocji, wyjaśnił Grzegorz Falkowski, architekt systemów chmurowych w Oktawave.

Co powinno być pierwszym krokiem do zapewnienia sklepowi infrastruktury, która przyjmie zwiększony ruch?

W pierwszym kroku powinniśmy się zastanowić, w jaki sposób chcemy nasze środowisko skalować. Do dyspozycji mamy dwa mechanizmy, z których możemy skorzystać:

  • skalowanie horyzontalne – zwiększenie liczby serwerów dostarczających treści,
  • skalowanie wertykalne – zwiększenie zasobów (CPU, RAM) instancji serwerowych.

Chmura obliczeniowa Oktawave dostarcza usługę Autoskalera, którego przeznaczeniem jest automatyczne skalowanie infrastruktury z wykorzystaniem obydwu wymienionych powyżej mechanizmów. Niezależnie, który z wymienionych mechanizmów będziemy chcieli zastosować, podstawowym założeniem architektury powinno być umieszczenie usługi bazodanowej oraz aplikacyjnej na oddzielnych instancjach serwerowych. Jest to dobra praktyka, która ułatwia dalszą optymalizację.

W pierwszym kroku zajmiemy się usługą serwera aplikacyjnego. W wypadku, kiedy chcemy zastosować skalowanie wertykalne, nie musimy wykonywać zbyt wielu zmian w konfiguracji usług. Możemy uruchomić w panelu na interesującej nas instancji usługę Autoskalera, zdefiniować jego parametry oraz zatwierdzić jej aktywowanie. Od tej chwili - jeżeli Autoskaler wykryje przekroczenie progów utylizacji zasobów serwera – zostaną one dodane.

Rys.1 Konfiguracja Autoskalera wertykalnego na instancji. Informuj/Zmień typ - tryb pracy Autoskalera. Tylko powiadamianie lub automatyczna zmiana zasobów instancji. Maksymalna/Minimalna ilość pamięci RAM - zakres, w jakim Autoskaler może zmieniać ilość dostępnej pamięci RAM dla instancji. Maksymalna/Minimalna ilość CPU - zakres, w jakim Autoskaler może zmieniać ilość dostępnego CPU dla instancji. Zgoda na zmniejszenie/zwiększenie typu instancji - wydanie zgody na automatyczną zmianę parametrów instancji w danym kierunku. Zgoda na wykonanie restartu w godzinach - deklaracja wskazująca godziny, w których instancja może zostać restartowana, jeżeli zajdzie taka potrzeba.
Rys.1 Konfiguracja Autoskalera wertykalnego na instancji. Informuj/Zmień typ - tryb pracy Autoskalera. Tylko powiadamianie lub automatyczna zmiana zasobów instancji. Maksymalna/Minimalna ilość pamięci RAM - zakres, w jakim Autoskaler może zmieniać ilość dostępnej pamięci RAM dla instancji. Maksymalna/Minimalna ilość CPU - zakres, w jakim Autoskaler może zmieniać ilość dostępnego CPU dla instancji. Zgoda na zmniejszenie/zwiększenie typu instancji - wydanie zgody na automatyczną zmianę parametrów instancji w danym kierunku. Zgoda na wykonanie restartu w godzinach - deklaracja wskazująca godziny, w których instancja może zostać restartowana, jeżeli zajdzie taka potrzeba.

Należy jednak pamiętać, że przy zmniejszaniu parametrów instancji będzie wymagany jej restart, dlatego rekomendowane jest ustawienie przedziału czasowego tę czynność w najbardziej dogodnym okresie, np. w godzinach nocnych.

Rekomendowanym rozwiązaniem jest również posiadanie co najmniej dwóch serwerów aplikacyjnych podlegający mechanizmowi Autoskalowania i mających w różnych godzinach ustawione okna restartów. W takim wypadku unikamy potencjalnych niedostępności serwisu.

W wypadku, kiedy zdecydujemy się na skalowanie horyzontalne, powinniśmy dążyć do uzyskania maksymalnej bezstanowości instancji aplikacyjnych. Rozumiemy przez to zminimalizowanie ilości danych, które są na nich przechowywane oraz jednocześnie przetwarzane przez aplikację.

Jednym z przykładów tego typu plików są zdjęcia produktów. Jak wiadomo - jeżeli mamy więcej niż jeden serwer aplikacyjny - w wypadku dodania produktu musimy zadbać, aby wszystkie instancje posiadały ten sam zestaw danych potrzebnych do jego wyświetlenia.

Jak zapewnić wszystkim instancjom dostęp do tych samych plików statycznych?

Jeśli chodzi o informacje o produkcie, łatwo jest je przechować w bazie danych. W wypadku plików z pomocą przychodzi zaś Oktawave Cloud Storage (OCS). OCS to storage obiektowy (przestrzeń przechowywania danych), służący głównie do przechowywania statycznych plików, zapewniający bardzo wysoką dostępność poprzez wielokrotną replikację oraz łatwy dostęp do danych. Nadaje się idealnie do przechowywania statycznych zasobów wideo, grafik czy dowolnych plików, które muszą zostać dostarczone do przeglądarki klienta w szybkim czasie z wykorzystaniem HTTP/HTTPS.

Możemy wykorzystać OCS do przechowywania oraz dostarczania całości treści statycznych (arkuszy CSS, grafik czy zdjęć). Takie rozwiązanie ma dwie bardzo ważne zalety:

  • zdejmuje potrzebę synchronizacji dużej liczby plików między serwerami aplikacyjnymi,
  • zmniejsza liczbę zapytań, które są przez nie obsługiwane.

Już tylko ta zmiana zwiększa pojemność naszego środowiska. Integracja aplikacji z usługą OCS możemy zrealizować w bardzo łatwy i szybki sposób poprzez API HTTP Restful lub dedykowane gotowe biblioteki (np. PHP). Opis metody która umożliwia listowanie adresów IP serwerów znajdujących się w grupie znajduje się w dokumentacji API Oktawave.

Rys. 2. Przykład tworzenia nowego kontenera OCS dla aplikacji WWW. Włącz listowanie - umożliwienie przeglądania całej zawartości kontenera. Włącz publiczny dostęp - dostęp do obiektów w kontenerze bez uwierzytelniania. Włącz obsługę stron statycznych - umożliwia wykorzystanie OCS-a do serwowania całych stron statycznych (proste strony HTML).
Rys. 2. Przykład tworzenia nowego kontenera OCS dla aplikacji WWW. Włącz listowanie - umożliwienie przeglądania całej zawartości kontenera. Włącz publiczny dostęp - dostęp do obiektów w kontenerze bez uwierzytelniania. Włącz obsługę stron statycznych - umożliwia wykorzystanie OCS-a do serwowania całych stron statycznych (proste strony HTML).

Drugim elementem, który należy dostosować, jest zarządzanie sesjami użytkowników. Najlepsze rozwiązanie polega na przekazaniu przechowywania sesji do zewnętrznej usługi. W tym celu możemy przykładowo zastosować rozwiązania Memcached lub Redis.

Nie będziemy musieli stosować tego typu rozwiązań, jeżeli zastosowany przez nas serwer aplikacyjny ma możliwość bezpośredniej synchronizacji informacji o sesji pomiędzy instancjami. Taką funkcjonalność posiadają serwery aplikacyjne JAVA, takie jak Tomcat czy WildFly.

Pozostaje jeszcze kwestia dostępu do plików aplikacji. Jak go zapewnić?

Ponieważ obsłużyliśmy już kwestie plików statycznych oraz sesji, pozostało nam zapewnienie dostępu do plików aplikacji. W tym wypadku mamy o tyle komfortową sytuację, że mamy kontrolę nad procesem wdrażania zmian, które zostały wprowadzone w kodzie. Stąd też możemy nie wdrażać żadnych zewnętrznych mechanizmów, a jedynie w trakcie wgrywania zmian uwzględnić kopiowanie ich na wszystkie serwery aplikacyjne.

Kiedy korzystamy z usługi Autoskalera, jesteśmy w stanie zautomatyzować pobieranie adresów docelowych, na których przeprowadzimy wdrożenie aplikacji. W tym celu możemy wykorzystać Oktawave API, które pozwala na pobranie danych z wykorzystaniem skryptu informacji o instancjach, które w określonym momencie zajmują się dostarczaniem aplikacji.

Alternatywą jest zapewnienie sieciowego zasobu dyskowego, do którego będą się łączyły serwery aplikacyjne. Przykładem takiego rozwiązanie może być GlusterFS. Innym podejściem jest zapewnienie synchronizacji plików między serwerami aplikacyjnymi. W tym wypadku możemy zastosować narzędzie Syncthing.

Mamy już przygotowane instancje. Jak kierować na nie użytkowników?

Na tak przygotowane instancje musimy teraz skierować ruch użytkowników. Najłatwiej zrobimy to z wykorzystaniem Load Balancera Oktawave, który dodatkowo wspiera działanie mechanizmu Autoskalera. Oznacza to, że jeżeli zostanie uruchomiona dodatkowa instancja, Load Balancer automatycznie będzie kierował na nią żądania z przeglądarek użytkowników. Tak samo w wypadku zmniejszenia liczby instancji pula serwerów, na które kierowany jest ruch, zostanie zmniejszona.

Sama konfiguracja Autoskalera polega na zdefiniowaniu takich parametrów jak maksymalna oraz minimalna liczba instancji, a także czy skalowanie ma się odbywać poprzez klonowanie lub dodanie już istniejących instancji do Load Balancera na grupie serwerów. Po zatwierdzeniu całość pracy przejmuje logika mechanizmu autoskalowania.

Rys. 3. Konfiguracja Load Balancera Oktawave oraz Autoskalera horyzontalnego. Usługa - wskazanie, która usługa ma podlegać load balancingowi (HTTP/HTTPS, SMTP lub dowolny port wpisany ręcznie). Włącz SSL - włączenie jednoczesnego load balancingu dla HTTPS oraz HTTP. Wspólna persystencja HTTP i HTTPS - deklaracja czy wybrany mechanizm obsługi sesji ma dotyczyć obu protokołów. Algorytm - wybór, na podstawie jakiego mechanizmu Load Balancer będzie kierował ruch. Obsługa sesji - wybór mechanizmu utrzymywania sesji z konkretny sewerem docelowym. IPv4/Ipv6 Address - wybór wersji protokołu IP, dla którego jest wykonywany load balancing ruchu. Sprawdzenie dostępności - deklaracja, czy Load Balancer lub serwer docelowy są dostępne. Maksymalna/Minimalna ilość OCI w kontenerze - określenie liczby instancji, które mogą znajdować się w kontenerze. Rodzaj - sposób, w jaki ma być zwiększana liczba OCI (poprzez klonowanie bieżącej instancji lub dodawanie wskazanych OCI, które już istnieją i nie są dołączone do innego Load Balancera).
Rys. 3. Konfiguracja Load Balancera Oktawave oraz Autoskalera horyzontalnego. Usługa - wskazanie, która usługa ma podlegać load balancingowi (HTTP/HTTPS, SMTP lub dowolny port wpisany ręcznie). Włącz SSL - włączenie jednoczesnego load balancingu dla HTTPS oraz HTTP. Wspólna persystencja HTTP i HTTPS - deklaracja czy wybrany mechanizm obsługi sesji ma dotyczyć obu protokołów. Algorytm - wybór, na podstawie jakiego mechanizmu Load Balancer będzie kierował ruch. Obsługa sesji - wybór mechanizmu utrzymywania sesji z konkretny sewerem docelowym. IPv4/Ipv6 Address - wybór wersji protokołu IP, dla którego jest wykonywany load balancing ruchu. Sprawdzenie dostępności - deklaracja, czy Load Balancer lub serwer docelowy są dostępne. Maksymalna/Minimalna ilość OCI w kontenerze - określenie liczby instancji, które mogą znajdować się w kontenerze. Rodzaj - sposób, w jaki ma być zwiększana liczba OCI (poprzez klonowanie bieżącej instancji lub dodawanie wskazanych OCI, które już istnieją i nie są dołączone do innego Load Balancera).

Co z bazami danych?

Jeżeli natomiast mówimy o usłudze bazodanowej, to w tym wypadku najlepszym podejściem jest uruchomienie jej w formie klastra. Podstawową zaletą tego typu rozwiązania jest to, że już na starcie jesteśmy przygotowani na zwiększoną ilość odwiedzin.

Dodatkowo, ograniczamy lub wręcz likwidujemy niedostępności usługi bazodanowej w przypadku potrzeby zmiany parametrów instancji lub samego silnika wynikających z ich optymalizacji. Mamy możliwość skorzystania z wielu rozwiązań, które pracują w różnych trybach. Jednym z nich jest master-slave, gdzie slave jest w stanie obsługiwać zapytania, odciążając mastera z realizacji części pracy.

To rozwiązanie bardzo dobrze sprawdza się w sytuacji, kiedy aplikacja generuje przede wszystkim dużą liczbę odczytów z bazy danych i stosunkowo niewielką liczbę zapisów. Jesteśmy w stanie skalować taką bazę zarówno wertykalnie, jak i horyzontalnie.

W wypadku, kiedy jednak nasza aplikacja generuje dużą liczbę zapisów do bazy danych, lepiej sprawdzi się klaster pracujący w trybie multi-master. Przykładem takiego rozwiązania dla MySQL jest Percona XtrDB Cluster, które dodatkowo powinno zostać wsparte przez ProxySQL. To ostatnie narzędzie daje możliwość dynamicznego zarządzania ruchem kierowanym do węzłów klastra bazodanowego. Również i w tym wypadku rozwiązanie to jesteśmy w stanie skalować zarówno wertykalnie, jak i horyzontalnie.

Jak zapewnić redundację usług?

O ile chmura obliczeniowa Oktawave gwarantuje dla swoich usług najwyższe na rynku SLA na poziomie 99,96%, to powinniśmy jednak dodatkowo pomyśleć zabezpieczeniu na wypadek problemów z usługami, które bezpośrednio dostarczają naszą aplikację (serwer aplikacyjny, baza danych).

W niniejszym artykule kilkukrotnie wspominałem, że uruchomienie poszczególnych usług na więcej niż jednym serwerze umożliwia wprowadzanie zmian konfiguracyjnych, minimalizując ryzyko przestoju aplikacji. Dodatkowym pozytywnym aspektem stosowania takiego rozwiązania jest podniesienie odporności naszego środowiska na awarie.

Zawsze może bowiem dojść do sytuacji, kiedy któraś z usług nieoczekiwanie zatrzyma się. W takim wypadku - jeżeli zadbaliśmy o redundancję naszych usług - całość pracy przejmuje druga instancja realizująca te same zadania. Jak widać, działania podjęte u podstaw w celu podniesienia elastyczności naszej infrastruktury przekładają się również na podniesienie współczynnika SLA dla aplikacji.

Musimy zadbać o to, aby wszystkie komponenty biorące udział w dostarczaniu aplikacji zostały zdublowane - tak aby zostały wyeliminowane wszystkie pojedyncze punkty awarii oraz żeby komunikacja pomiędzy nimi uwzględniała duplikacje usług. W niektórych wypadkach, aby to uzyskać, wystarczy zmodyfikować pliki konfiguracyjne. Tak jest na przykład w przypadku, kiedy mamy do czynienia z aplikacją napisaną w PHP i do przechowywania sesji wykorzystujemy Memcached. Część rozwiązań wymaga jednak, aby dodać kolejny element. Tak jest w przypadku silnika bazy danych.

Bardzo dobrze w zakresie klastra wysokiej dostępności sprawdza się wymieniona wcześniej Percona XtrDB wraz z ProxySQL. Jednakże, jeżeli z duplikujemy usługę proxy, musimy zapewnić pojedynczy adres IP, z którym będą mogły komunikować się serwery aplikacyjne. W tym celu możemy skonfigurować usługę Keepalived, która zapewni nam opisaną powyżej funkcjonalność.

Obraz

Efekt końcowy takiej konfiguracji obrazuje powyższy schemat. Widać na nim rozdział instancji aplikacyjnych (z mechanizmem synchronizacji danych o sesjach użytkowników) od bazodanowych (klastrowa relacja multi-master z wykorzystaniem Percona XtrDB Cluster) z dostępem do przechowywanych w Oktawave Cloud Storage plików statycznych. Wszystko to spięte Load Balancerem, który automatycznie dostosuje dystrybucję ruchu do skalowanych instancji. Administrator może spać spokojnie – świąteczna gorączka zakupów jego infrastrukturze nie straszna.

Uwaga, podwajamy Twoją pierwszą wpłatę! Mamy dla Ciebie specjalną ofertę. Załóż konto w Oktawave, dokonaj wpłaty zasilającej Twoje konto prepaidowe, a my ją podwoimy! Co trzeba zrobić? 1. Załóż konto. 2. Wejdź do zakładki Konto | Doładuj konto. 3. Dokonaj płatności, a w trakcie tego procesu podaj kod: hHkAVqy4. 4. Ciesz się podwójnym doładowaniem! Szczegóły akcji na stronie Bądźcie czujni.

Programy

Zobacz więcej
Źródło artykułu:www.dobreprogramy.pl
Oceń jakość naszego artykułuTwoja opinia pozwala nam tworzyć lepsze treści.
Wybrane dla Ciebie
Komentarze (22)