Konfiguracja Twojej aplikacji: Jak wybrać najlepszą konfigurację serwera?

Wprowadzenie

Technologia i internet stały się kluczowymi elementami naszego codziennego, akademickiego i zawodowego życia. Dlatego też ogromna liczba witryn i aplikacji istniejących jednocześnie nie powinna być zaskoczeniem. Jeśli prowadzisz firmę, z pewnością chcesz posiadać powiązaną z nią platformę internetową. Aplikacja umożliwia łatwe promowanie i dostarczanie usług docelowym klientom.

Niezależnie od powodu, dla którego tworzysz aplikację internetową, musisz określić, jak ją zbudować. Masz do dyspozycji wiele opcji, jeśli chodzi o wybór najlepszej konfiguracji serwera. Wybrana architektura serwera określi sposób uruchamiania i zarządzania wszystkim w Twoim środowisku. Dlatego decyzja ta musi zostać podjęta po dokładnym przemyśleniu.

Jak wybrać odpowiednią konfigurację serwera

Jak więc zdecydować, która architektura jest „odpowiednia” dla Twojej aplikacji? Aby to zrobić, musisz najpierw pomyśleć o wymaganiach dotyczących aplikacji internetowej. Musi ona posiadać pewne funkcje, które należy wdrożyć, aby działała wydajnie w Twoim konkretnym przypadku użycia. Na przykład, być może dążysz do stworzenia aplikacji, którą łatwo skalować. Albo potrzebujesz, aby Twoja aplikacja działała płynnie zarówno w przeglądarkach, jak i na urządzeniach mobilnych. Jednocześnie głównym czynnikiem może być również Twój budżet.

Niezależnie od tego, jakie są Twoje wymagania, powinieneś wiedzieć, że możesz stworzyć niestandardowe rozwiązanie dla swojej aplikacji. W tym samouczku przyjrzymy się różnym typom serwerów, które są powszechnie używane w aplikacjach internetowych. Omówimy różne przypadki użycia oraz sytuacje, w których dana konfiguracja sprawdza się najlepiej. Aby pomóc Ci zdecydować, czy jest ona odpowiednia dla Ciebie, przedstawimy również wady i zalety każdej architektury serwera.

1. Wszystko na jednym serwerze

Jak sugeruje nazwa, całe środowisko jest ładowane na jednym, pojedynczym serwerze. Środowisko to obejmuje serwer WWW, serwer aplikacji, a także serwer bazy danych. Na przykład działa to w konfiguracji stosu Linux, Apache, MySQL, oraz PHP (LAMP). Możesz skorzystać z naszych samouczków dotyczących tego, jak zainstalować stos LAMP na serwerze Ubuntu oraz jak zainstalować stos LAMP na CentOS.

Kiedy stosować:

Ten typ konfiguracji sprawdza się najlepiej, gdy masz mało czasu. Jest prosty i szybki w konfiguracji. Dlatego dobrze nadaje się do prostych aplikacji internetowych.

Zalety:

• Prosty i łatwy do zrozumienia oraz wdrożenia.
• Konfiguracja całości zajmuje niewiele czasu.

Wady:

• Nie pozwala na skalowanie poziome.
• Oferuje bardzo niewiele w kwestii izolacji komponentów.
• Aplikacja i baza danych zasadniczo konkurują o te same zasoby, ponieważ znajdują się na jednym serwerze.
• W rezultacie możesz doświadczyć niskiej wydajności.

2. Oddzielny serwer bazy danych

Głównym problemem przy korzystaniu z jednego serwera jest rywalizacja o ograniczone zasoby. Ta konfiguracja ma na celu rozwiązanie tego problemu. W tym przypadku system zarządzania bazą danych, czyli DBMS, jest oddzielony od serwera aplikacji. Serwer bazy danych znajduje się w sieci prywatnej i posiada własne zasoby. Przekłada się to na lepszą wydajność i większe bezpieczeństwo.

Kiedy stosować:

Ponownie, jeśli chcesz szybko wdrożyć środowisko, ta konfiguracja jest dość prosta. To idealne rozwiązanie, jeśli obawiasz się, że baza danych i aplikacja będą rywalizować o te same zasoby.

Zalety:

• Oddzielne, dedykowane zasoby systemowe dla aplikacji i bazy danych, w tym procesor, pamięć, wejście/wyjście (I/O) itp.
• Większy potencjał skalowalności zarówno w warstwie aplikacji, jak i bazy danych.
• Możesz dodawać i usuwać zasoby w zależności od potrzeb.
• Usunięcie bazy danych z publicznego internetu pozwala również na znaczne zwiększenie bezpieczeństwa.

Wady:

• Nieco bardziej skomplikowane niż konfiguracja z jednym serwerem.
• Niska przepustowość lub wysokie opóźnienia w połączeniu sieciowym między dwoma serwerami mogą powodować problemy z wydajnością.

3. Odwrotne proxy lub load balancer

To tutaj systemy równoważenia obciążenia wkraczają do gry. Moduły równoważenia obciążenia są zazwyczaj stosowane w środowiskach serwerowych w celu poprawy wydajności i niezawodności. Robią to poprzez „równoważenie obciążenia”, tj. rozdzielanie obciążenia roboczego na zestaw serwerów.

Kiedy stosować:

Moduły równoważenia obciążenia są niezwykle przydatne, gdy zachodzi potrzeba wykonania skalowania poziomego. Skalowanie poziome zasadniczo oznacza dodawanie kolejnych serwerów do środowiska. Można również użyć odwrotnego serwera proxy warstwy aplikacji, aby obsługiwać kilka aplikacji jednocześnie przy użyciu jednej domeny i portu. HAProxy, Nginx, oraz Varnish to przykłady oprogramowania, które umożliwia równoważenie obciążenia typu reverse proxy.

Zalety:

• W przypadku awarii jednego z serwerów, pozostałe serwery kompensują jego brak, równoważąc obciążenie robocze.
• Umożliwia wykonywanie skalowania poziomego w celu zwiększenia lub zmniejszenia wydajności środowiska.
• Ogranicza również połączenia klienckie, co zapewnia ochronę przed atakami DDoS.

Wady:

• W przypadku niewystarczających zasobów systemowych, moduł równoważenia obciążenia może ograniczyć wydajność aplikacji.
• Wymagana jest odpowiednia konfiguracja, aby zapewnić należytą wydajność.
• Znacznie bardziej skomplikowane niż konfiguracje z jednym serwerem lub oddzielnymi serwerami.
• Należy wziąć pod uwagę czynniki takie jak terminacja SSL oraz aplikacje wymagające sesji typu sticky sessions.
• Głównym powodem do niepokoju przy stosowaniu modułów równoważenia obciążenia jest to, że stanowią one pojedynczy punkt awarii. Oznacza to, że jeśli moduł równoważenia obciążenia ulegnie awarii, cała usługa przestanie działać.

4. Akcelerator HTTP lub buforujący odwrotny serwer proxy

Jest to konfiguracja, którą można wykorzystać do zwiększenia szybkości dostarczania treści użytkownikowi aplikacji. Wykorzystuje ona różne techniki w celu skrócenia tego czasu. Najważniejszą z nich jest buforowanie odpowiedzi z serwera aplikacji. Akcelerator zapisuje treść w swojej pamięci, gdy użytkownik żąda jej po raz pierwszy. Dzięki temu, gdy pojawią się kolejne podobne żądania, szybko dostarcza treść bez interakcji z serwerem aplikacji. Zarówno Nginx, Varnish, jak i Squid są w stanie zapewnić akcelerację HTTP.

Kiedy stosować:

Co zrozumiałe, ta konfiguracja jest najbardziej odpowiednia dla plików i treści, o które użytkownicy pytają bardzo często. Sprawdza się również bardzo dobrze w przypadku dynamicznych aplikacji internetowych o dużej zawartości treści.

Zalety:

• Buforowanie i kompresja znacznie zwiększają szybkość działania aplikacji i przetwarzania żądań.
• Zmniejszenie obciążenia procesora również poprawia wydajność witryny.
• Można go również używać jako modułu równoważenia obciążenia typu reverse proxy.

Wady:

• Należy go dobrze dostroić, aby uzyskać najlepszą wydajność.
• Można doświadczyć słabej wydajności w przypadku niskiego współczynnika trafień pamięci podręcznej.

5. Replikacja bazy danych typu Primary-Replica

Konfiguracja replikacji bazy danych typu primary-replica jest zazwyczaj bardzo przydatna w systemach, które wykonują więcej odczytów niż zapisów. Na przykład systemy zarządzania treścią mogą naprawdę skorzystać z takiej architektury. Do replikacji potrzebny jest jeden węzeł główny i jeden lub więcej węzłów replikacji. Rozdziela ona odczyty na wszystkie węzły. Aktualizacje trafiają wyłącznie do węzła głównego.

Kiedy stosować:

Jak wspomniano, konfiguracja bazy danych oparta na replikacji pomaga poprawić wydajność odczytu systemu. Można ją stosować w aplikacjach takich jak CMS.

Zalety:

• Poprawia wydajność odczytu bazy danych, ponieważ rozdziela go na repliki.
• Jeśli węzeł główny będzie używany wyłącznie do aktualizacji, można również poprawić wydajność zapisu.

Wady:

• Każda aplikacja próbująca uzyskać dostęp do bazy danych musi być w stanie zdecydować, do którego węzła wysyłać aktualizacje, a do którego żądania odczytu.
• W przypadku awarii węzła głównego, aktualizacje zostają wstrzymane. Należy rozwiązać problem, aby umożliwić kontynuację aktualizacji.
• Brak mechanizmu automatycznego przełączania na wypadek potencjalnej awarii węzła głównego.

Łączenie konfiguracji serwerowych

Na szczęście możliwe jest również połączenie różnych technik w celu uzyskania pożądanego rezultatu. Oznacza to, że można równoważyć obciążenie serwerów aplikacji z serwerami buforującymi w jednym środowisku i replikować bazę danych. Takie rozwiązanie pozwala wykorzystać funkcjonalność obu serwerów. Nie sprawia to jednak, że konfiguracja staje się bardziej skomplikowana lub kłopotliwa.

Przykład:

Spróbujemy zrozumieć takie środowisko na przykładzie:

W takim środowisku moduł równoważenia obciążenia będzie wysyłał statyczne żądania do serwerów buforujących. Zawartość statyczna obejmuje między innymi pliki CSS, obrazy i Javascript. Zamiast tego będzie kierować wszelkie inne rodzaje żądań o zawartość do serwerów aplikacji.

Załóżmy, że użytkownik żąda pewnej statycznej zawartości ze środowiska. Oto co się wydarzy:

• Moduł równoważenia obciążenia najpierw ustali, czy zawartość to cache-hit czy cache-miss. Zawartość cache-hit znajduje się w pamięci podręcznej, podczas gdy zawartości cache-miss tam nie ma. Robi to poprzez sprawdzenie z backendem pamięci podręcznej (cache-backend).
• W przypadku cache-hit, moduł równoważenia obciążenia wysyła zawartość do użytkownika.
• W przypadku cache-miss, serwer pamięci podręcznej przekazuje żądanie do backendu aplikacji.
• Backend aplikacji (app-backend) znajdzie i wyśle zawartość z bazy danych.
• Backend pamięci podręcznej (cache-backend) odbiera zawartość z modułu równoważenia obciążenia. Zapisuje również tę zawartość w pamięci podręcznej przed zwróceniem jej do modułu równoważenia obciążenia.
• Ten ostatni przekazuje następnie odpowiedź do użytkownika.

Z drugiej strony, oto co się stanie, jeśli użytkownik zażąda zawartości dynamicznej:

• Żądanie trafi od użytkownika do modułu równoważenia obciążenia.
• To żądanie trafia do backendu aplikacji.
• Backend aplikacji lokalizuje żądaną zawartość i zwraca ją do modułu równoważenia obciążenia.
• Użytkownik otrzymuje zawartość.

Jedną z głównych zalet takiego połączonego środowiska jest to, że jest ono bardziej niezawodne. Co więcej, charakteryzuje się ono również wyższą wydajnością. Istnieją jednak nadal dwa pojedyncze punkty awarii – moduł równoważenia obciążenia i główny serwer bazy danych.

Podsumowanie

Możesz używać każdej konfiguracji serwera samodzielnie w swoim środowisku. Z drugiej strony, możesz również połączyć kilka z nich, aby stworzyć spersonalizowane rozwiązanie. Nie ma jednej „prawidłowej” odpowiedzi. Wszystko zależy od funkcjonalności, jaką chcesz uzyskać z danej architektury.

Posiadanie podstawowej wiedzy na temat działania poszczególnych konfiguracji serwerów pomoże Ci podjąć decyzję dotyczącą własnej aplikacji. Najlepiej zacząć od czegoś małego i prostego. W miarę zdobywania doświadczenia możesz stopniowo zwiększać złożoność swojej konfiguracji.

Powodzenia!