Skalowanie hostingu aplikacji internetowej

Jeżeli stworzyliśmy aplikację internetową, portal WWW, usługę internetową, z której korzysta coraz więcej osób, prędzej czy później trzeba się zmierzyć z ograniczonych możliwości platformy sprzętowej, w którą wyposażona jest nasza aplikacja.

Pewnie powiesz, „co za problem kupić hosting o wyższych parametrach?” Mało kto zdaje sobie sprawę, że koszt coraz wydajniejszego hostingu rośnie wykładniczo a jeżeli nasza aplikacja osiągnie naprawdę duży sukces to w końcu wyczerpiemy ofertę dostawcy i serwer dedykowany z ośmioma rdzeniami na pokładzie, który ma 128GB RAMu i dysk z zaledwie 4TB też okaże się za słaby by rozwijać nasz projekt. Tak na marginesie koszt rocznej dzierżawy takiej maszyny to ok 7 500,00 zł netto.

Przedwczesna, nieprzemyślana optymalizacja jest źródłem całego zła (lub przynajmniej jego większości) w świecie programowania.

Cal Henderson

Skalowalność (ang. Scalability)

Skalowalność to zdolność systemu (w tym przypadku aplikacji internetowej) do sprawnego działania i możliwości utrzymania w przypadku stale zwiększającej się liczby użytkowników lub rozmiaru przetwarzanych danych.

Co ciekawe, w przypadku aplikacji internetowych lub portali zwykle te okoliczności występują niemal równocześnie. Dlaczego? Otóż załóżmy, że rozwijamy aplikację typu Instagram. Więcej użytkowników wysyła coraz więcej treści w postaci zdjęć. Te treści coraz silniej angażują nowych użytkowników i tak w kółko aplikacja się rozwija i rośnie jak kula śnieżna.

Skalowanie zasobów w pionie (Vertical Scaling)

Skalowanie zasobów w pionie to nic innego jak właśnie takie dokupowanie coraz lepszej maszyny. W przypadku strony internetowej lub aplikacji działającej w przeglądarce będzie to stopniowe zastępowanie słabszej platformy coraz silniejszą. Ogromną zaletą skalowania w pionie jest to, że nie wymaga dodatkowego wysiłku od deweloperów. Programiści poza ewentualnym przeniesieniem aplikacji nie muszą robić niczego dodatkowego z wyjściową aplikacją.

Żeby nie było tak kolorowo, skalowanie w pionie ma kilka zasadniczych wad. Po pierwsze zabawa w dokupowanie coraz mocniejszej maszyny jest coraz bardziej nieopłacalna. Koszt kolejnych konfiguracji jest coraz droższy. Tempo wzrostu kosztów jest wyższe od wzrostu możliwości jaką dana maszyna jest w stanie zagwarantować:

Po drugie, w końcu dobijamy do „ściany”, o której wspomniałem we wstępie. Nawet jak będziemy mieli dużo budżetu spotkamy się z ograniczeniami technologicznymi i nie znajdziemy dostawcy, który bez końca jest w stanie zagwarantować coraz lepszą konfigurację w ramach pojedynczej maszyny.

Po trzecie, serwer zapasowy, który powinien być w pogotowiu na wypadek awarii też kosztuje tyle ile aktywny, działający serwer. Niech nikogo nie dziwi, że mówimy o serwerze zapasowym. W tego typu przedsięwzięciach trzeba zapewnić nadmiarowość, czyli redundancję zasobów. W końcu jedynym rozsądnym rozwiązaniem jest…

Skalowanie w poziomie (Horizontal Scaling)

Skalowanie w poziomie to dokupywanie po prostu kolejnych serwerów. W wyniku czego zapewniamy skalowanie aplikacji pozbywając się wady poprzedniego rozwiązania.

Zaletą skalowania poziomego jest liniowość kosztów jakie ponosimy. Dokupując kolejny serwer, którego relacja ceny do wydajności jest najbardziej opłacalna nie narażamy się dopłacanie, z którym mieliśmy do czynienia wyżej. Zakup kolejnego seryjnie produkowanego serwera będzie zawsze możliwy, mamy zatem nieograniczone możliwości wzrostu. Po trzecie zapasowy serwer, który miałby zastąpić jednostkę w przypadku awarii też będzie relatywnie tańszy do rozwiązania w którym kupujemy „potwora” tylko po to by bezczynnie czekał w pogotowiu jako tzw. zimny sprzęt.

W przypadku skalowania horyzontalnego mamy do rozwiązania jeden kluczowy problem. Otóż… nasza aplikacja nie będzie działać – od tak – na kilku komputerach jednocześnie. Aby aplikacja funkcjonowała na kilku maszynach jednocześnie musi być poprawnie zaprojektowana. Dotyczy to jej architektury, technologii, oraz poszczególnych rozwiązań jakich użyto w trakcie budowy.

Co ze skalowaniem z wykorzystaniem chmury i hostingu Cloud?

Problem z automatycznym skalowaniem na hostingu chmurowym polega na tym, że płacimy za to co wykorzystujemy. Większość osób uzna to za zaletę. Tak to dobry model (paradoksalnie) dla… małych aplikacji. W przypadku aplikacji dużej skali wykorzystujemy dużo i – no właśnie – płacimy dużo. Na hosting chmurowy może sobie pozwolić duża korporacje i aplikacje które na siebie już zarabiają. Jeżeli chcesz stworzyć własny startup „na chmurze” koszty zjedzą twój projekt zanim się on rozwinie.

Przykład:

Koszt samej bazy danych Amazon RDS to 94 zł netto miesięcznie. Koszt VPSa na którym można postawić cały serwis to 110 zł netto rocznie. To samo jest z serwerem, dyskiem itd… Amazon Elasti Cloud to koszt zaczynający się od 1000 zł netto miesięcznie wzwyż. to wszystko mogę mieć za 110 złotych rocznie tylko dlatego że potrafię zainstalować, uruchomić i wykorzystać memcached na VPSie.

Jeżeli przeniósłbym przykładowo cały serwis QQMODELS ze standardowego hostingu WWW do AWS to obecny roczny koszt klient płaciłby co miesiąc i to w dodatku dwukrotnie.

Chmura jest dobra bo nie trzeba martwić się problemem skalowania i aplikację mogą rozwijać „agencje” bez odpowiedniego know-how. W zamian płacimy wyższy koszt tylko dlatego, że nie przejmujemy się problemem skalowania i nie potrafimy zainwestować we własną infrastrukturę, która spełni nasze potrzeby na kilka dobrych lat.

Czego zaczyna brakować na początku?

W małych aplikacjach utrzymywanych najczęściej na najtańszym hostingu współdzielonym najbardziej zasobożerna okazuje się baza danych, która potrzebuje coraz więcej RAMu wraz ze zwiększającą się liczbą rekordów w poszczególnych tabelach. Pisałem o tym we wstępie do optymalizacji MySQL.

Jak już dokupimy RAM do serwera MySQL, którego koszt kilkakrotnie przewyższa resztę hostingu (tak na marginesie, jest to celowy zabieg dostawców hostingu aby „uciekać” z najtańszych opcji) w zależności od charakteru serwisu kolejna będzie konieczność rozszerzenia pamięci masowej albo jednostki obliczeniowej, której po prostu zacznie brakować przy dużym ruchu. Taki procesor raz obsługuje żądanie raz przetwarza dane i nie było by w tym nic złego gdyby nie fakt, że właśnie to przełączanie kontekstu obciąża go najbardziej. Dlatego już w początkowych fazach warto odseparować bazę danych od logiki aplikacji a także przenieść dane na osobny serwer plików.

Replikacja baz danych

Replikacja bazy danych to temat na osobny wpis ale z grubsza chodzi o to aby wykorzystać fakt, że aplikacja raczej częściej odczytuje niż zapisuje dane do bazy danych. Jak wiadomo, zapis zawsze bardziej angażuje zasoby niż odczyt. Dlatego jedną z technik skalowania baz danych jest replikacja czyli niejako klonowanie ją w czasie rzeczywistym z mastera (mistrza), który obsługuje zapis, aktualizację i usuwanie danych na slave’a (niewolnika), który obsługuje odczytywanie. Jeżeli ruch będzie bardzo duży wystarczy potem poziomo je skalować, czyli kopiować bazy służące do odczytu i przy zapytaniach odczytu przekierowywać użytkownika losowo do poszczególnych klonów.

Pamięć masowa i sieć czyli serwer plików i CDN

Jeżeli zabraknie pamięci na duże pliki przechowywane w aplikacji należy skorzystać z serwera plików lub modnej ostatnio chmury do przechowywania statycznych plików. Jeżeli okaże się, że wąskim gardłem jest sieć – wystarczy skorzystać z usługi CDN, która odciąży serwer z zapytań dotyczących plików statycznych i przyspieszy działanie aplikacji na całym globie ziemskim.

Co dalej?

Jeżeli po wykonaniu tych działań nadal aplikacja będzie domagała się więcej zasobów należy skorzystać z techniki pamięci podręcznej na poziomie aplikacji webowej i równoważenia obciążeń (Load Balancing). Skalujemy wówczas w poziomie serwery front-endowe i te odpowiedzialne za logikę i przetwarzanie danych aplikacji.

Podsumowanie

Samo przeniesienie poszczególnych elementów aplikacji na osobne maszyny nawet tanie opcje VPS da sporą oszczędność i „przestrzeń do rozwoju”. Specjalizacja takich serwerów pozwoli na skalowanie w poziomie i uzyskaniu możliwie największej wydajności (ponieważ, procesor nie przełącza się pomiędzy kontekstami). Zadbaj o to aby projektem oraz wykonaniem aplikacji internetowej zajął się profesjonalista z odpowiednią wiedzą i doświadczeniem, który będzie wstanie zoptymalizować koszty utrzymania już na samym początku ewolucji. Drożej kupić taniej sprzedać i… przepłacić za hosting rozwijającej się aplikacji to nie sztuka 😉

Źródła:

Henderson C. Building Scalable Web Sites. Building, Scaling, and Optimizing the Next Generation of Web Applications, Helion 2006.

https://mansfeld.pl/books/Pawe%c5%82%20Mansfeld%20-%20Skalowanie%20Aplikacji%20Webowych.pdf