Skalowanie aplikacji … jest proste?
Skalowanie aplikacji – w sensie, warstwy serwerów aplikacji – jeśli mamy dobry projekt nie powinno być trudne. Trochę gorzej ma się sprawa skalowania bazy danych (swoją drogą najczęstszego wąskiego gardła aplikacji)- ale o tym problemie opowiem w najbliższych postach.
Dzisiaj ogólnie o technikach skalowania środowiska aplikacji.
Jeśli nasz kod jest już dobrze napisany i zoptymalizowany nie pozostaje nam nic więcej jak rozbudowywać bazę serwerów na których nasza aplikacja pracuje
Generalnie wyróżniamy dwa podejścia do problemu:
- skalowanie pionowe – tutaj sprawa jest prosta. Rozbudowujemy nasze serwery, jak długo się da. Lepszy procesr (więcej procesorów!), więcej ramu, szybsze dyski -czynimy z naszego serwera demona prędkości. Biznesowo patrząc takie rozwiązanie wydaje się być bardzo korzystne. Nasza aplikacja przyspiesza, mamy co prawda koszty związane ze sprzętem – ale są ona bardzo małe w porównaniu do czasu programistów… A czas programistów jest zaoszczędzony ponieważ skalowanie pionowe nie wymaga żadnych zmian w kodzie aplikacji. Przez to zalecane jest jako deska ratunkowa gdy coś zaczyna iść źle lub po prostu w pierwszym etapie rozwoju naszego serwisu.
Niestety skalując pionowo szybko dochodzimy do ściany… Zakupy lepszego sprzętu mogą być po prostu niemożliwe (bariera technologiczna). Szybko może okazać się zakupy nie przynoszą oczekiwanych rezultatów a stosunek ich ceny do odnoszonych korzyści zaczyna rosnąć wykładniczo.
Lepszym rozwiązaniem, stosowanym przez największych jest:
- skalowanie poziome – nie rozbudowujemy naszych wypasionych serwerów w nieskończoność, w zamian za to używamy dużej ilości pospolitych maszyn – i wykorzystujemy siłę przetwarzania rozproszonego. Etap ten jest dla sporych i średnich serwisów nieunikniony, ogromne zyski ze skalowania poziomego odnoszą najwięksi – MySpace, Flickr, Nasza-klasa…
Skalowanie poziome wydaje się być prostym rozwiązaniem – zwłaszcza na poziomie serwerów WWW. Mówiąc w skrócie, skalowanie poziome polega na:
- połączeniu kilku, kilkunastu, klikuset serwerów w sieć,
- równoważeniu ruchu między wszystkie maszyny za pomocą load-balancera (sprzętowego, czy też programowaego – np. Perlball lub LVM),
- pliki aplikacji, danych znajdują się w jednym miejscu – na wydzielonym serwerze dyskowym – podłączone przez NFS. Tak jest najprościej, ale nie najlepiej.
Wykorzystując skalowanie poziome tak naprawdę dużo oszczędzamy. Poniższy rysunek pokazuje stosunek ceny od jakości (ilości CPU) przy obu wspomnianych wyżej technikach:

Hmm … zatem -czy to wszystko? I gdzie jest haczyk?
Skalowanie poziome wiąże się z pewnymi trudnościami na poziomie aplikacji. Najczęściej wymaga pewnych zmian w kodzie.
Wiążą się z nim dwa główne problemy (można się doszukać wielu więcej – np. związanych z systemem plików, połączeniami do bazy danych ,,,)z którymi musi się zmierzyć projektant:
- Co zrobić ze stanem sesji użytkowników (odwiedzający raz korzysta z serwera 1 ale po odświeżeniu strony już z serwera 2 – a stan sesji domyślnie pamiętany jest na serwerze
)? - Jak zarządzać rozproszonym środowiskiem (powyżej 1000 serwerów nie ma dnia, aby jeden z nich się nie zepsuł)?
Na szczęście istnieją pewne rozwiązania:
- do zarządzania stanem sesji najlepiej wykorzystać brak sesji … lub memcache jeśli sesje są wymagane,
- do zarządzania środowiskiem można korzystać z rozwiązań typu Capistrano
Jeśli nasza aplikacja będzie przystosowana do skalowania poziomego możemy sięgnąć po EC2 amazona, rightscale.com …
Liznęliśmy temat
Komentarze (0)