Co to takiego, ta skalowalność, i do czego jest potrzebna?

"Skalowalność" to słowo często pojawiające się w różnych dyskusjach na tematy związane z oprogramowaniem, bazami danych, oraz różnymi platformami cloudowymi. Czy jednak wiesz, o co chodzi z tą całą skalowalnością?

Skalowalność ≠ wydajność

Jednym z największych nieporozumień jest to, że wiele osób sądzi, że jeżeli dokonają zakupu wystarczająco szybkiego serwera, i/lub opracują dostatecznie wydajne algorytmy przetwarzania danych, osiągną skalowalność. Tymczasem skalowalność nie może być utożsamiana z prędkością działania aplikacji, to raczej zdolność do zachowania akceptowalnej wydajności w obliczu rosnącego obciążenia. Innymi słowy - naturalne jest, że wraz ze wzrostem liczby odwiedzających serwis/ilości przetwarzanych danych wydajność będzie spadać. Jednak prawidłowo zaprojektowany system pozwoli utrzymać prędkość działania na poziomie akceptowalnym dla Klienta.

Jednym z największych zagrożeń związanych z nieuwzględnieniem zapewnienia skalowalności rozwiązania software'owego na poziomie projektu może być to, że zaczniemy tracić Klientów, jeżeli serwis/usługa stanie się bardziej popularny/a (a przecież właśnie wtedy zależy nam na Klientach najbardziej).

Podam prosty przykład:
wyobraź sobie firmę oponiarską w pierwszych dniach zimy. Gwałtownie rośnie liczba kierowców przyjeżdżających na wymianę opon. Dla każdego właściciela serwisu oczywiste jest, że należy uruchamiać w tym czasie dodatkowe stanowiska obsługi, aby żaden z Klientów nie spędził w kolejce do wymiany dłużej niż, powiedzmy 1,5h. Jeżeli będą czekali dłużej, to pewnie na wiosenną wymianę opon pojadą gdzie indziej. Taka mobilizacja nie jest zaś potrzebna w środku lata, gdy osób przyjeżdżających na wymianę opon będzie zdecydowanie mniej - wtedy wystarczy jedno, może 2 stanowiska, aby zapewnić sprawną obsługę. Na tym przykładzie widać, że sukces wymaga zrównoleglenia obsługi i sprawnego kolejkowania zadań. Nie da się go osiągnąć jedynie wymagając od pracowników szybszego przykręcania kół w zimowym szczycie, jeżeli czynne będzie tylko jedno stanowisko.

Skalowalność pozioma i pionowa

Mamy dwa podstawowe rodzaje skalowalności, umownie nazwane poziomą i pionową. Różnicę między nimi można łatwo wyjaśnić posługując się przedstawionym wyżej przykładem firmy oponiarskiej. Jeżeli osiąga ona wzrost liczby obsługiwanych Klientów wyposażając pracowników w lepsze klucze nasadowe, nowszy podnośnik, oraz motywując ich do szybszej pracy obietnicą premii za każde wymienione koło, to mamy do czynienia ze skalowalnością pionową. W przypadku serwera ten rodzaj skalowalności osiągniemy kupując więcej pamięci, oraz szybsze procesory wielordzeniowe. Skalowalność pionowa obejmuje optymalizację oprogramowania mającą na celu zmniejszenie czasu odpowiedzi serwera, a także mechanizm cacheowania treści. Jest to najprostszy sposób zapewnienia wzrostu prędkości, lecz jego skuteczność jest ograniczona w pewnych granicach.

Natomiast jeżeli wzrost wydajności zostanie osiągnięty poprzez zwiększenie liczby stanowisk obsługujących Klientów jednocześnie, to będziemy mieli do czynienia ze skalowalnością poziomą. W przypadku serwera ten rodzaj skalowalności osiągniemy stosując większą liczbę serwerów z mechanizmem load-balancingu, lub korzystając z baz danych w klastrze, oraz różnego rodzaju technologii przetwarzania danych w chmurze - np. bazy danych noSQL Amazon DynamoDB zapewniających niezrównaną wydajność, czy też serwując pliki bezpośrednio z CDN-a Amazon S3, zamiast z dysku serwera. Możemy także umieścić aplikację na platformie cloudowej udostępnianej w modelu PaaS (platform-as-a-service). Skalowalność poziomą trzeba uwzględnić na etapie planowania infrastruktury aplikacji. Jeżeli nie pomyślimy o tym od razu, zapewnienie większej wydajności aplikacji/systemu który jest niewłaściwie zaprojektowany, bez jego przepisania praktycznie od nowa, może być bardzo trudne, lub nawet niewykonalne.

Testy obciążeniowe

Zwykle kiedy pojawia się temat wydajności rozwiązań IT, pojawia się także temat testów pod obciążeniem. Są dwa podstawowe ich rodzaje, służące nieco innemu celowi:

  1. load testing - które przeprowadza się pod sztucznie wygenerowanym określonym obciążeniem, zwykle o 20-30% powyżej spodziewanego obciążenia produkcyjnego.
  2. stress testing - które polega na stopniowym zwiększaniu obciążenia daleko ponad spodziewane, aby znaleźć granicę powyżej której serwis przestanie działać. Pozwala to także wychwycić ewentualne błędy, które mogą się pojawić w chwilach szczytowego ruchu - np. po restarcie pod obciążeniem, lub tuż po tym, jak popularna strona internetowa wspomni o Tobie w artykule na stronie głównej.

Cierpliwość Klienta

Wszechobecny szybki internet, oraz rozwój technologii informatycznych nauczył nas bycia niecierpliwymi. Dotyczy to niemal wszystkich dziedzin życia. Projektanci wysokich bydynków już od kilkudziesięciu lat mówią, że optymalny czas oczekiwania na windę to około 15 sekund. Badania wykazują, że jeżeli winda nie nadjedzie w czasie 37 sekund statystyczny pasażer zacznie się niecierpliwić, szukając innego sposobu dostania się na pożądane piętro. Szaleństwem byłoby sądzić, że ten sam Klient który nie potrafi wytrzymać nieco ponad pół minuty czekając na windę będzie cierpliwie czekał obserwując "kręciołę" na ekranie swojego komputera w oczekiwaniu na to, aż sklep internetowy pokaże mu opis produktu. Dlatego tak ważne jest planowanie infrastruktury serwisu już na etapie jego budowania. Na szczęście rozwiązania chmurowe pozwalają na wybór systemu naliczania opłat "pay-as-you-go", w którym płacisz tylko za wykorzystywane aktualnie moce serwerów. W połączeniu z możliwością prostego przydzielania dodatkowych mocy obliczeniowych do swojego klastra daje to niezwykłą wręcz elastyczność. Możemy rozpocząć budowanie aplikacji webowej z minimalnymi kosztami, a następnie w miarę wzrostu liczby odwiedzających zwiększać wydajność dobrze zaprojektowanej aplikacji dosłownie kilkoma kliknięciami myszki. System ten pozwala także na przydzielenie dodatkowych mocy np. sklepowi internetowemu w czasie zwiększonych zakupów przedświątecznych.

Jak ważna to rzecz przekonał się każdy, kto w dniach 2-3 stycznia 2015 próbował zakupić ebooki w noworocznej promocji na ebookpoint.pl - serwis praktycznie nie odpowiadał, a "włożenie produktu do koszyka" potrafiło zająć ponad 30 minut.

Witryna ebookpoint.pl była faktycznie mocno obciążona (screen z Google Analytics):

ebookpoint.pl under heavy load

Ja zrezygnowałem z zakupów. Część osób jednak wykazywała się nadludzką wręcz cierpliwością, pisząc później na facebooku gorzkie komentarze typu "3h przed komputerem, ale udało się w końcu".

Zastanów się jednak, czy Twoja strona/serwis/usługa może liczyć na taką determinację Klientów?
Odpowiedź nasuwa się sama.