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

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.

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.

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.

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.

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.

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.

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.

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ść.

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.