Dla branży e-commerce okres świąteczny jest bardzo istotny. Wiele organizacji funkcjonujących na tym rynku duży procent przychodów zdobywa właśnie w tym czasie. Oprócz wielu szans czyhają również zagrożenia, związane głównie z dostępnością systemów transakcyjnych. W tym artykule – bazując na rodzimej usłudze chmury obliczeniowej Oktawave – powiemy Ci, co każdy dobry admin powinien zrobić, aby uchronić nadzorowany e-sklep przed klęską urodzaju.

Nawet jeżeli przez większość czasu nasze środowisko jest w stanie w sposób zadowalający obsłużyć standardowy ruch, w okresie przedświątecznym warto wprowadzić dodatkowe usprawnienia. Ich celem będzie przygotowanie architektury na przyjęcie zwiększonego ruchu poprzez umożliwienie łatwego skalowania komponentów infrastruktury. To podejście pozwoli nam na bieżąco dostosowywać parametry oraz liczbę serwerów do zmieniającego się zapotrzebowania. Jednocześnie nie będziemy ponosić kosztów nadmiernie rozbudowanej infrastruktury.

Skalowanie

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ć:

1. skalowanie horyzontalne – zwiększenie liczby serwerów dostarczających treści,
2. 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.

Należy jednak pamiętać, że przy zmniejszaniu parametrów instancji będzie wymagany jej restart, dlatego rekomendowane jest ustawienie przedziału czasowego dla tej czynności 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.

Storage obiektowy

Jak to zrobić? 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:

1. zdejmuje potrzebę synchronizacji dużej liczby plików między serwerami aplikacyjnymi,
2. 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).

Sesje użytkowników

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.

Sama aplikacja

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.

Load balancing

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. 

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 serwerem 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).

Baza 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.

Bezpieczeństwo 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ść.

Rys. 4. Schemat architektury opisywanej w artykule.

Zacznij działać

Działania, które podejmujemy w celu przygotowania naszej aplikacji e-commerce na zwiększoną liczbę odwiedzin, powinniśmy podejmować z wyprzedzeniem. Wcześniejsze przygotowanie środowiska oraz przetestowanie mechanizmów, które będziemy chcieli wykorzystać w trakcie naporu klientów, zapewni na duże poczucie bezpieczeństwa. Kiedy przyjdzie godzina próby, będziemy mogli spokojnie skupić się na realizacji postawionych przed sobą celów biznesowych.

Autor: Grzegorz Falkowski, architekt systemów chmurowych w Oktawave.