Spot Instance czyli giełda serwerów w chmurze. Jak zredukować koszty o 80%?

Jedną z ciekawszych funkcji, jaką daje chmura AWS, jest tzw. giełda serwerów wirtualnych – czyli tzw. Spot Instances.  Sama koncepcja stojąca za tą funkcją jest w istocie stosunkowo prosta i polega na tym, aby użytkownicy chmury mogli wykorzystywać aktualnie niezagospodarowane serwery infrastruktury AWS na własny użytek za ułamek kwoty (nawet 10-15%), jaką normalnie te serwery kosztują.

Poniższy diagram prezentuje poglądowy schemat działania giełdy. Na pomarańczowo zaznaczono zwykłą cenę serwera OnDemand – która jest stała. Na niebiesko zaznaczono kwotę zdeklarowaną przez użytkownika – tzn. maksymalną cenę, za którą chce nabyć serwery typu Spot. Natomiast na zielono zaznaczono jak zmienia się cena rynkowa serwerów Spot. Jak widać, przez większość czasu, cena rynkowa jest mniejsza, niż cena zdeklarowana przez użytkownika – w  wyniku czego użytkownik ma dostep do serwera – i to za cenę rynkową. W momencie gdy cena rynkowa będzie większa niż cena zadeklarowana przez użytkownika, użytkownik nie będzie miał dostępu do serwera i jednocześnie nie będzie płacił za niego.

AWS posiada olbrzymią infrastrukturę chmurową, każda lokalizacja na świecie (tzw. Region) składa się z kilku stref serwerowni (tzw. Avaibility Zone). Niektóre strefy posiadają nawet do 300 tysięcy serwerów. AWS utrzymuje tak gigantyczną infrastrukturę aby zapewnić jak najlepsze możliwości dla obecnych i nowych użytkowników do uruchamiania dziesiątków (tysięcy) serwerów każdego dnia w każdej serwerowni. Z drugiej strony jednak, jeśli np. tylko połowa serwerów w serwerowni jest aktualnie wykorzystywana przez użytkowników, oznacza to, że druga połowa stoi bezużyteczna– co nie przysparza nikomu korzyści. Właśnie te, aktualnie nieużywane serwery, stanowią serwery, które są udostępniane użytkownikom w ramach tzw. giełdy spot. Giełda ta polega na  tym, że Amazon weryfikuje, ile aktualnie posiada niewykorzystywanych serwerów, które mógłby przekazać na rzecz giełdy i użytkowników. Następnie do gry wchodzą użytkownicy, którzy zgłaszają za ile chcieli by ‘wykupić’ dany serwer – na tej podstawie Amazon decyduje jaka jest aktualnie cena rynkowa serwerów – to właśnie za tę cenę rynkową, serwery ostatecznie trafią do użytkowników.

Powiedzmy, że użytkownik zainteresowany jest pewnym konkretnym typem serwera, którego normalna cena za godzinę (tzw. „OnDemand price”) kosztuje $1. Użytkownik chciałby jednak zapłacić mniej za ten serwer i zgłasza, że jest gotów wypożyczyć ten serwer, ale jedynie za 50 centów za godzinę. Amazon na bieżąco weryfikuje jaka jest cena rynkowa serwerów (i też ile serwerów jest wolnych), jeśli cena rynkowa tego serwera będzie mniejsza od zadeklarowanej przez użytkownika, to użytkownik uzyska ten serwer – i to za cenę rynkową. Czyli np. jeśli aktualna cena rynkowa wynosiła 20 centów, to właśnie tyle użytkownik będzie płacił za godzinę, jeśli wzrośnie ona do 40 centów, to tyle będzie płacił, jeśli jednak skoczy ona powyżej 50 centów, to będzie to oznaczało to, że jest to kwota wyższa niż zdeklarowana przez użytkownika i użytkownik utraci dany serwer (aby nie narażać go na koszty, na które nie był gotowy).

Giełda serwerów w chmurze pozwala osiągnąć niesamowite oszczędności w porównaniu z standardowymi serwerami, jednak serwery Spot nie są idealne pod każdy typ aplikacji/systemu. Dlaczego? Bo serwery Spot charakteryzują się również tym, że jeśli cena rynkowa przekroczy cenę zadeklarowaną przez użytkownika, to serwer zostanie wyłączony  z dwuminutową notyfikacją przed tym faktem, aby użytkownik mógł np. skopiować dane, zakończyć aktualnie procesowane requesty. Możnaby zatem powiedzieć: Po co mi serwer, który mogę stracić w każdej chwili?  Odpowiedź jest jednak prosta, bo może się okazać, że mamy takie rodzaje aplikacji/systemów/komponentów, dla których tego typu cecha nie będzie przeszkadzała. Przyjrzyjmy się poniżej kilku z nich.

W przypadku wykorzystywana technologii z rodziny Hadoop/Spark, użytkownik tworzy klastry serwerów a rozmiar pojedynczego klastra może dochodzić do setek/tysięcy instancji – zazwyczaj im więcej, tym szybciej dane zadanie zostanie przeliczone i użytkownik otrzyma wyniki. Tego rodzaju systemy nadają się idealnie do wykorzystania serwerów typu Spot. Głównym powodem będzie rzecz jasna cena. Ale co z tym ‘traceniem’ serwerów? W przypadku klastra serwerów, nawet jeśli użytkownik po kilku godzinach straci połowę serwerów (bo cena rynkowa wzrosła), to użytkownik ciągle może zachować te dane, które były przeliczone przez klaster w czasie, gdy był on większy. Jednym słowem, to co zostało już przeliczone za ułamek ceny, należy już do użytkownika. Resztę zawsze można przeliczyć za normalną cenę lub poczekać aż cena rynkowa ponownie spadnie poniżej pułapu wskazanego przez użytkownika.

Czasem mamy do czynienia z sytuacją, gdy raz dziennie (lub w innej częstotliwości) musimy coś przeliczyć, skopiować itd. – operacja ta ma być wykonana w nocy,
ale konkretna godzina nie jest zdefiniowana. Ma być po prostu w nocy i …. tanio… .
I ponownie serwery Spot mogą okazać się nieocenione, ponieważ możemy wykorzystać je aby w nocy uruchomić nasze procesy batchowe. Serwer zostanie wówczas uruchomiony, gdy jego cena jest dla nas odpowiednia – czasem po prostu będzie trzeba poczekać trochę dużej, aby cena spadła i serwer został uruchomiony.

Innym ciekawym pomysłem jest wykorzystanie serwerów typu Spot przy skalowaniu horyzontalnym naszej aplikacji. Powiedzmy, że aktualnie nasza aplikacja jest obsługiwana przez 3 zwykłe serwery działające w trybie OnDemand, chcielibyśmy aby np. strona WWW ładowała się dla naszych użytkowników szybciej, jednak nie chcemy dodać kolejnych 2 serwerów typu OnDemand (z uwagi na zwiększenie kosztów). Wówczas możemy ponownie zastosować serwery typu Spot – w takim przypadku nasza warstwa zostanie rozszerzona z 3 do 5 serwów, gdzie dwa z nich będą serwerami Spot – tańszymi. Nawet jeśli cena rynkowa wzrośnie i utracimy serwery, to nasza aplikacja wciąż będzie działała z uwagi na 3 stałe serwery podpięte do LoadBalancera.

Ile bidować, czyli jaką cenę deklarować dla serwerów typu Spot? Przede wszystkim należy pamiętać, że użytkownik i tak zapłaci cenę rynkową serwera, a nie tą maksymalną, którą zdeklarował – co jest wyjątkowo wygodną cechą. Im większa maksymalna cena, którą jesteśmy w stanie zapłacić, tym mniejsze szanse, że utracimy serwer. AWS udostępnia statystyki odnośnie tego, jakie średnio są szanse utracenia konkretnego typu serwera przy deklarowanym typie serwera. Dane te można zweryfikować na tej stronie. Poniżej przykładowy wycinek tejże strony.

Jak widać, są serwery, dla których nawet gdy zadeklarujemy naszą maksymalną cenę na 25% ceny normalnej (OnDemand) – to szanse utracenia serwera są małe. Warto wziąć pod uwagę te statystyki, gdy wybieramy serwery pod nasze aplikacje – im lepiej wybierzemy, tym więcej zaoszczędzimy i tym rzadziej będziemy tracić serwery.

Dodatkowo AWS udostępnia również szczegółowe informacje odnośnie fluktuacji cen rynkowych serwerów na przestrzeni ostatnich miesięcy (dostęp do tych danych użytkownik ma z wizarda do tworzenia serwerów Spot z poziomu konsoli AWS). Przykładowo, diagram poniżej prezentuje cenę, za którą były udostępniane serwery typu c3.large w konkretnej strefie i regionie AWS w ciągu ostatnich 3 miesięcy. Jak widać z diagramu, cena niemal non stop oscylowała w granicach $0.02. Jeśli sprawdzimy natomiast normalną cenę tego serwera (OnDemand) (https://aws.amazon.com/ec2/pricing/) to okazje się, że kosztuje on standardowo $0.12 za godzinę – zatem około 5-6 razy drożej… . Oznacza to (w uproszczeniu), że moglibyśmy wykorzystywać ten typ serwera przez ostatnie 3 miesiące płacąc jedynie 20% normalnej ceny!

Więcej informacji o serwerach typu Spot można znaleźć na tej stronie. Natomiast osoby, które chcą od razu przetestować działanie serwerów Spot w praktyce, odsyłam do konsoli AWS i usługi EC2 gdzie znajduje się link do serwerów Spot.

Kilka dodatkowych informacji:

Istnieje również mniej znana możliwość która gwarantuje, że serwery typu Spot nie zostaną utracone. Użytkownik może bowiem zadeklarować pewien określony czas (od 1 do 6 godzin) – dla którego serwery muszą być non stop uruchomione – wówczas serwery nie zostaną utracone nawet, jeśli cena rynkowa przekroczy cenę zadeklarowaną przez użytkownika. Funkcja ta nazywa się „Spot Blocks”.

Wcześniej wspominałem, że druga strona medalu spotów to to, że spoty mogą zostać ‘zabrane’ przez Amazona. Czy dacie jednak wiarę, że niektórzy chcą aby właśnie tak się stało? Bidują na tyle agresywnie, aby szansa stracenia serwera była jak największa! Z czego to wynika? Standardowo, za serwery (w tym i spoty) płaci się ‘od godziny’. Godziny ‘zaokrągla’ się w górę (tzn. jeśli wyłączymy serwer po 25 minutach, zapłacimy jak za pełną godzinę). Jednak jeśli spot zostanie zabrany przez Amazona, to wówczas ostatnia, niepełna godzina nie jest naliczana! Zatem jeśli serwer stracimy w 58 minucie, to nic nie zapłacimy!

Wreszcie ostatnia ciekawostka, to jeszcze jedna funkcja spotów, mianowicie tzw. „spot fleet” – w skrócie polega to na tym, że użytkownik wybiera sobie jakie serwery go interesują i jaka jest ‘jego’ cena za te poszczególne typy serwerów. Co następnie robi Amazon to analizuje wszystkie typy tych serwerów i uruchamia taką ‘flotę’ aby obsłużyć zapotrzebowanie użytkownika ale jednocześnie zoptymalizować koszty. W ostatnim czasie został udostępnione dedykowane narzędzie ‘Spot Advisor’ – w którym użytkownik podaje jakiej mocy serwerów potrzebuje i jakiej ilości, a następnie dostaje informacje jakie serwery powinien bidować aby uzyskać największe oszczędności!