Duże aplikacje i load balancing, Czyli co i jak zrobic jak maszyna nie daje rady Opcje

[kwiateusz]

Temat założony na prośbę SHIPa oraz normanosa traktujący o rozkładaniu obciążenia na wiele maszyn

[rashid]

Pozwole sie wtracic, bo Panowie proboja rozwiazac problemy, ktore stosunkowo dobrze sa opisane w literaturze zagranicznej, ktora chyba nie wszystkim jest znana.

Po pierwsze zalozenie, ze ruch jest wysylany jest do najmniej obciazonego serwera jest niezbyt wydajne, bo do load balancingu dochodzi wtedy potrzeba monitorowania wydajnosci. Znacznie prosciej jest zastosowac load balancing metoda round-robin (czyli po kolei kazdy serwer) lub przyklejac uzytkownikow do poszczegolnych maszyn i zakladac, ze statystycznie rozlozy sie to ladnie.

Pomysly oparte o wspoldzielone dyski sprawdzaja sie tylko w ograniczonym zakresie. Ze szczegolna rezerwa nalezy podchodzic do propozycji oferujacych liniowa skalowalnosc na architekturach SAN - wg. naszej opinii nie nadaja one sie operacji charakterystycznych dla srodowiska webowego - czyli malych plikow o duzej liczbie dostepow. Skalowalnosc odczytu mozesz miec liniowa tylko przy zalozeniu, ze tworzysz za kazdym razem kopie obiektu na nowym dysku.

Sesje najprosciej jest przechowywac lokalnie, na pojedynczej maszynie. Wszelkie pomysly z trzymaniem sesji w bazie, czy wykorzystaniem memcached, beda juz powodowac komplikacje. Wiekszosc serwerow proxy dzialajacych jako akceleratory WWW pozwala "przykleic" sesje uzytkownika do pojedynczej maszyny.

Powaznym problemem jest synchronizacja plikow miedzy serwerami, szczegolnie takich, ktore uploaduja uzytkownicy systemu.

Zanim zacznie sie analizowac mozliwosci load balancingu powinno sie wykonac pewna prace u podstaw - skonfigurowanie aplikacji i serwerow WWW w taki sposob, by pliki statyczne wykorzystywaly efektywnie cache przegladarek internetowych. Robi to gigantyczna roznice i przydaje sie bardzo przy nastepnym kroku - dodaniu akceleratora WWW przed pozostalym srodowiskiem webowych do przezroczystego serwowania plikow statycznych. Taka konstrukcja ma ta zalete, ze kolejne akceleratory mozna dodawac rownolegle i skorzystac z DNS round-robin do load balancingu ruchu statycznego.

Zastanowcie sie w jakim stopniu mozecie wyjac statyczny kontent poza wasza infrastrukture. Z pomoca Amazon S3 i Cloud Front mozna osiagnac niskim kosztem swietne rezultaty. Czasami tez latwo osiagnac znaczaca poprawe wykonujac zwykle profilowanie aplikacji i wylapujac waskie gardla.

Nie skaluj, dopoki to nie jest potrzebne. Jesli masz mozliwosc, to sprawdz czy nie oplaca sie bardziej zwiekszyc mocy maszyny.

@normanos - jesli wydajnosc pojedynczej maszyny bazodanowej nie jest wystarczajaca do uciagniecia ruchu, to nalezy przyjrzec sie strukturze bazy danych i rozwazyc wydobycie czesci tabel do osobnej bazy. Oczywiscie jest to znacznie utrudnione w przypadku gestej sieci powiazan miedzy tabelami i wlasnie przez to mozna zaryzykowac twierdzenie, ze JOINy sie nie skaluja. Czesciowo mozna tez zaryzykowac wybranie jednej maszyny na zapisy (master) i kilku wylacznie do odczytow (slave). Zwroc tez uwage, ze istnieja alternatywy do relacyjnych baz danych, ktore znacznie lepiej sie skaluja. Byc moze trzeba przyjrzec sie modelowi w aplikacji i go przebudowac pod katem skalowalnosci.