Skalowalność chmury

Chmura to przede wszystkim skalowalność

Jest wiele powodów, dla których firmy coraz częściej wybierają publiczną chmurę obliczeniową. Szybkość, zwiększone bezpieczeństwo czy też oszczędności na inwestycjach. Kolejnym powodem jest możliwości zapewnienia sobie wysokiej dostępności swoich aplikacji sieciowych przy jednoczesnej możliwość płacenia tylko za te zasoby, które są w danym momencie potrzebne do utrzymania pożądanego poziomu szybkości i niezawodności.

Jak jednak dobrać tę właściwą ilość zasobów? Obciążenia serwisów internetowych czy aplikacji webowych są dość nieprzewidywalne. Możemy się oczywiście przygotować na sezon świąteczny w sklepie internetowym, ale konia z rzędem temu, kto przewidzi najazd użytkowników np. serwisu Wykop.pl na naszą stronę.

Mniejsze serwisy, korzystające ze współdzielonego hostingu, VPS-ów czy nawet pojedynczych serwerów dedykowanych, w zasadzie przygotować się nie miały jak – w razie takiego oblężenia można było co najwyżej zamienić dynamiczną wersję strony głównej na statyczny HTML i czekać, aż ci wszyscy internauci sobie pójdą. Dlatego też serwisy, których operatorzy liczą się z większym ruchem, uruchamiają je zwykle na wielu serwerach, wykorzystując technikę równoważenia obciążenia (load balancingu) pomiędzy podłączonymi w klaster obliczeniowy maszynami.

Hosting tradycyjny zmusza więc najwyraźniej właściciela serwisu, któremu zależy na wysokiej dostępności w Internecie, do sięgnięcia jeśli nawet nie po maksymalną ilość zasobów infrastruktury, to przynajmniej wystarczająco dużą jej ilość, tak by sklep internetowy czy serwis informacyjny nie wyświetliły internaucie „strony 503” (503 to kod błędu oznaczający: usługa niedostępna – przyp. red.) w najmniej oczekiwanym momencie.

Takie zabezpieczenie oczywiście kosztuje. Firma hostingowa nie obniży nam przecież miesięcznego abonamentu za dzierżawę tylko dlatego, że wybrany do hostowania naszej aplikacji szybki serwer dedykowany, z czterema procesorami i szybkimi dyskami SSD, przez niemal cały miesiąc działał na pół gwizdka, zaledwie kilka razy odnotowując poważny skok obciążenia. Właściciel serwisu może mieć wrażenie, że przepłaca (i ma rację) – ale z drugiej strony co miałby zrobić, wybrać słabszą konfigurację i patrzeć jak za każdym razem, gdy wzrośnie zainteresowanie jego stroną, serwer „będzie się mu topił”?

Dobrze byłoby więc mieć jakiś system, pozwalający poradzić sobie z takimi niespodziewanymi skokami. Zastanówmy się, jak wygląda problem, o którym tu mówimy. Przygotowany na różne okoliczności serwis internetowy to trzy warstwy: zwrócony na zewnątrz load balancer, przyjmujący żądania użytkowników i przekierowujący je do serwerów aplikacji, serwery aplikacji, na których uruchamiana jest logika oprogramowania, oraz serwery baz danych. Problem przeciążenia może dotyczyć każdej z tych warstw z osobna (i dlatego duże serwisy mają wiele load balancerów, nie mówiąc już o serwerach aplikacyjnych i bazodanowych), dla uproszczenia jednak skupmy się na warstwie logiki aplikacji.

Aplikacja działa na pewnej puli serwerów, z których każdy możliwy jest do zidentyfikowania po adresie IP. Teraz load balancer otrzymuje rozmaite żądania od użytkowników w ramach otwartych przez nich sesji i przekazuje je do jednego z serwerów aplikacyjnych w puli, wybierając go w ustalony sposób (np. losowo czy według najszybszej odpowiedzi). Im więcej żądań zostaje przekazanych do serwera aplikacyjnego, tym wolniej aplikacja będzie działać.

W sytuacji, gdy żądań robi się zbyt wiele, mamy dwie możliwości, aby utrzymać sensowną wydajność – albo zwiększymy liczbę serwerów w puli, albo dodamy do istniejących serwerów większą ilość pamięci i przyspieszymy działanie ich procesorów. Działania takie muszą być podejmowane automatycznie, przez mechanizm monitorujący rozmaite parametry działających w puli maszyn (np. obciążenie procesora, zużycie pamięci, ruch sieciowy, liczba wątków uruchomionych przez serwer WWW), i w zależności od ich zmian, modyfikujący zbiór zasobów infrastruktury, dodając lub ujmując określone elementy.

Bez względu na rodzaj podjętych działań, cel jest jeden – znaleźć równowagę pomiędzy oczekiwaną niezawodnością działania serwisu, a ilością wykorzystanych zasobów infrastruktury (pamiętając przy tym, że nic nie ma za darmo).

Nie ma automatycznego skalowania bez chmury

Gdy spróbujemy wyobrazić sobie działanie takiego systemu w tradycyjnym hostingu, sytuacja może w przerysowany sposób wyglądać dość komicznie – administratorzy pospiesznie wciskający do szaf kolejne serwery, a do serwerów kolejne kostki RAM w momencie nagłego wzrostu popularności serwisu – to chyba nie najlepszy pomysł. I tutaj właśnie wyraźniej można zauważyć przewagę chmury obliczeniowej.

Zobaczmy, jak to wygląda w wypadku Oktawave. W zwirtualizowanej puli zasobów mechanizm monitorujący stan maszyn wirtualnych i w razie potrzeby modyfikujący ich liczbę czy parametry, nazywa się Autoskalerem. Wyróżnia się dwa rodzaje autoskalerów – horyzontalne, zmieniające liczbę maszyn wirtualnych w puli, oraz wertykalne, które zmieniają parametry maszyn wirtualnych. Ten drugi rodzaj, ze względu na ograniczenia systemów operacyjnych, pod których kontrolą maszyny wirtualne działają, jest znacznie trudniejszy w realizacji, o ile bowiem dodanie do działającej maszyny wirtualnej dodatkowego procesora czy RAM jest możliwe, to ich usunięcie jest bardzo problematyczne.

Dlatego większość dostawców chmur, na czele z Amazonem, oferuje swoim klientom jedynie autoskalery horyzontalne, które w zależności od liczby żądań przechodzących przez load balancer dodają i ujmują repliki zwirtualizowanych serwerów aplikacyjnych czy bazodanowych. W wypadku Oktawave, dzięki wykorzystaniu środowiska wirtualizacyjnego VMware Oktawave bez większych ograniczeń może zmieniać typy serwerowych instancji, aby dopasować je do wymogów sytuacji.