Jak zaplanować swoją infrastrukturę w chmurze i jak wyliczyć jej precyzyjny koszt?

Z racji tego, że cloud computing to technologia stosunkowo nowa i wiele firm wciąż spotyka się z nią po raz pierwszy, warto przy takim spotkaniu wykorzystać szansę na przemyślenie i uporządkowanie swojej dotychczasowej filozofii używania infrastruktury IT. W dużym uogólnieniu drogi są dwie:

Zapytajcie swoich administratorów (lub samych siebie) i z pewnością usłyszycie, że dzięki chmurze dostaną oni w swoje ręce zabawki, o których do tej pory mogli tylko pomarzyć. Dlaczego? Otóż jedna instancja OCI o mocy: 64 GB RAM, 16 VCPU x 2,5 Ghz z łatwością może zastąpić nawet kilka wysłużonych już serwerów, a w akompaniamencie ultra szybkich dysków OVS, kontenerów, loadbalancingu i Autoskalera ukaże ona przed każdym wydajność nieosiągalną do tej pory dla większości firm (poza naprawdę dużymi firmami, które było stać na rozwiązania storage'owe za kilka milionów złotych).

Migracja do chmury obliczeniowej jest więc szansą dla firmy, aby przeprowadzić optymalizację obecnej infrastruktury – to fakt, są jednak i takie wdrożenia, gdzie trzeba zacząć od zera. Tym krokiem zerowym często jest odwzorowanie fizycznego sprzętu tak, aby miał on swój odpowiednik w chmurze. Jest to zwykle zadanie, którego podejmuje się administrator, architekt systemów IT czy też dyrektor działu IT.

W Oktawave postanowiliśmy spotkać się z administratorami w połowie drogi. Naszym klientom z jednej strony dajemy całkowitą wolność w zakresie budowy swojej architektury, z drugiej pomagamy w doborze parametrów, a w razie potrzeby i na wyraźne życzenie nawet je korygujemy. Nam zależy na zadowolonych z naszych usług klientach, których zadowolenie wynika nie tylko z wydajności ich maszyn, ale również optymalizacji kosztowej.

Przed dalszą lekturą warto zapoznać się z naszym słowniczkiem najważniejszych pojęć związanych z chmurą obliczeniową.

Chociaż dostawca chmury może pomóc we wstępnej konfiguracji (i często robimy to z wykorzystaniem naszych ninja), to i tak dobrze jest samemu wiedzieć, jak zaprojektować architekturę IT w chmurze. Jak już wstępnie wspomnieliśmy, pewnym minimum może być utrzymanie w chmurze logiki infrastruktury fizycznej. Najłatwiej ugryźć to zagadnienie przy pomocy poniższego schematu.

Do dopełnienia obrazu potrzebny jest jeszcze jeden schemat, który pokazuje ruch.

Powyższe schematy przedstawiają środowiska informatyczne w ujęciu infrastruktury fizycznej i logicznej, jakie można znaleźć w wielu firmach. W przykładzie widać, że taka infrastruktura chroniona jest przez urządzenie zabezpieczające i filtrujące dostęp do serwerów firmowych.

Po drugiej stronie zapory ogniowej administratorzy mogą stworzyć wymaganą liczbę sieci prywatnych, pamiętając o takich aspektach jak np. ustalenie, które z tych sieci znajdą się w DMZ (strefie zdemilitaryzowanej, ograniczonego zaufania), lub do których maszyn będzie przyznany dostęp publiczny, oraz z którymi będą komunikować się pozostałe serwery (bez wymaganego dostępu dla użytkowników).

Na drugim schemacie widać, że serwer pełniący funkcję bramki Exchange'a został udostępniony publicznie, jednak pozostałe sieci nie posiadają już dostępu publicznego.

Jest to bardzo standardowa konfiguracja, którą można traktować jako wyjściową i modyfikować w zależności od konkretnych potrzeb.

Infrastruktura w chmurze to jednak nie tylko aspekt firmowego backendu. Jeśli moc obliczeniowa chmury potrzebna jest do zasilenia aplikacji, która dostępna będzie szerszemu gronu odbiorców, to trudne będzie dokładne oszacowanie, jakiej klasy infrastruktura będzie potrzebna.

Są ku temu dwa powody:

Technologie chmury odpowiadające za rozkładanie ruchu i automatyczne skalowanie infrastruktury (Autoskaler, loadbalancing) są oczywiście odpowiedzią na takie problemy, jednak nie wszyscy chcą i potrafią z nich korzystać. W takim przypadku, jeśli administrator nie zda się na automat, musi wykonać stosowne obliczenia.

Wszystko zależy bowiem od tego, co taki serwer ma robić. Wiedza administratorów ma również bezpośrednie przełożenie na to, z jakiej klasy maszyny będzie korzystać firma - dla przykładu, odpowiednia konfiguracja serwera nginx może obniżyć wymaganą moc firmowej maszyny nawet o jedną klasę, tym samym w prosty sposób prowadząc do wymiernych oszczędności.

Oczywiście sama konfiguracja nie będzie wystarczająca, jeśli skorzystamy z chmury słabych lub przeciętnych osiągach. Tak jak we wszystkich dziedzinach, również w przypadku chmur obliczeniowych, istnieją bowiem rozwiązania lepsze i gorsze. My w Oktawave akurat nie mamy powodów do wstydu i z radością przypominamy o naszych osiągach potwierdzonych przez niezależny test CloudHarmony.

Ten jeden wykres, przedstawiający szybkość dostępu do danych (czyli np. komunikacji między bazą danych a CPU), po prostu musi dawać do myślenia. Mamy ich więcej, sprawdźcie sami.

Ogromne znacznie ma też to, z jakiego kodu zewnętrznego korzysta firma. Znam przypadki, gdzie źle przygotowane wtyczki do WordPressa i nieodpowiednio napisane skrypty obciążały wybrane instancje do granic możliwości - i to przy niewielkim ruchu. Z drugiej strony, po zamianie wtyczek, przy ruchu setki razy większym, możliwe było nawet... obniżenie klasy maszyny.

Jeśli mamy do czynienia z migracją, a nie nowym wdrożeniem, to najczęstszą praktyką jest oparcie się po prostu o dane dotychczasowej maszyny. Dla spokoju ducha, przy wyborze klasy maszyny, administratorzy często zaokrąglali parametry w górę.

Jeśli zatem dotychczasowa infrastruktura to serwer, w którym znajdowało się 4 GB RAM oraz 2 CPU, a w ofercie dostawcy chmury nie ma maszyny o takiej klasie, to zazwyczaj wybierano pozycję wyżej, np. z 4 GB RAM, 4 VCPU (np. nasza instancja klasy Large).

To nie jest złe podejście, można wręcz powiedzieć, że coś w rodzaju pewniaka. Ale klasa maszyny to jednak nie wszystko, nie zapominajmy o storage’u – ten w chmurze, przewyższa to, co do zaoferowania mają serwery dedykowane. Jeśli zapoznaliście się z wspomnianymi wyżej wynikami niezależnego testu CloudHarmony, to spróbujcie zestawić je ze swoimi benchmarkami.

Administratorzy bardzo często mylą ze sobą dwa problemy:

Ten pierwszy problem to niewystarczająca moc procesora do obsługi zapytań, po prostu: CPU nie ma wystarczająco dużo zasobów, by przetworzyć informacje, które do niego napływają. Druga sytuacja jest odmienna, procesor się nudzi, a dysk nie jest w stanie wystarczająco szybko dostarczać do CPU informacji. Rezultat jednak jest podobny (brak zrealizowanego np. zapytania do bazy), dlatego często mylony.

Dlatego tak ważne jest, by uświadomić sobie, że niekoniecznie potrzebujemy więcej procesorów, a bardzo często mniejsza i tańsza architektura w chmurze zrobi dla nas to samo, co fizyczna o wyższych parametrach, ponieważ to chmura właśnie oferuje najbardziej wydajne dyski.

Dowiedz się, jaka jest różnica między serwerem w chmurze, a serwerem dedykowanym i VPS.

Pytanie o koszty serwera jest jednym z najczęściej słyszanych przez dostawców chmury. Wynika to z tego, że cennik chmury obliczeniowej nie jest tak prosty, jak w przypadku innych rozwiązań hostingowych. W dużej mierze wynika to z jednej z najfajniejszych cech chmury: jej elastyczności.

Trzeba pamiętać, że chmura nie przywiązuje klienta wyłącznie do jednej konfiguracji sprzętowej, na której trzeba się opierać. W każdej chwili klient może zmienić klasę swojej maszyny z podstawowego serwera posiadającego np. 0,5 GB RAM-u i jeden procesora VCPU, do prawdziwego monstrum z 64 GB pamięci operacyjnej i szesnastoma procesorami.

Zmiana klasy takiej maszyny może odbywać się automatycznie lub ręcznie, co jest niepowtarzalną zaletą chmury. Trzeba bowiem pamiętać, że korzystając z chmury obliczeniowej klient płaci jedynie za realnie wykorzystane zasoby, więc nie płaci się za moc obliczeniową, która nie jest aktualnie do niczego wykorzystywana. To z kolei oznacza, że podczas wyceny trzeba wziąć pod uwagę wiele parametrów (CPU, RAM, wielkość dysku, wielkość storage, transfer, IOPS), które teraz omówię na podstawie konkretnego przykładu.

Po oszacowaniu, jakiej mniej więcej klasy maszyny potrzeba, nadchodzi kolej na wybranie pasującej do tych wymagań instancji. Trzeba w tym miejscu oczywiście pamiętać, że różni dostawcy chmury w inny sposób nazywają to, co my w Oktawave nazywamy instancją. Dostępne predefiniowane konfiguracje środowisk RAM i VCPU są również różne u poszczególnych dostawców chmury.

Ja naturalnie skupię się na naszej ofercie. Zaznaczę też, że wielu klientów decyduje się początkowo na instancję o małej mocy, a dopiero po testach, jeśli jest taka potrzeba, przesiadają się na lepszej klasy instancję. To oczywiście nie jest problem, a góra minuta roboty. Chmura to nie serwer dedykowany, o czym wspominałem już wielokrotnie.

Za przykład do wykonania obliczeń może posłużyć OCI (Oktawave Cloud Instance) o klasie Mini. OCI w wersji Mini posiada 0,5 GB RAM oraz jeden VCPU taktowany zegarem 2,5 GHz. Taka maszynka wystarczy do prowadzenia niezbyt obleganej firmowej strony internetowej. Sprawdzi się też bardzo dobrze jako maszyna do backupu lub chociażby jako baza dla serwera DNS. W obliczeniach skupię się na tym ostatnim przykładzie.

Oprócz wyboru klasy instancji trzeba wybrać również system operacyjny: Windows albo Linux. Do wyznaczonych wcześniej celów wystarczy ten drugi, za który nie trzeba dodatkowo płacić opłaty licencyjnej. Koszt pracy takiej instancji za godzinę to 6 groszy, który trzeba pomnożyć przez liczbę godzin w miesiącu, a wynikiem jest kwota wynosząca 43,92 złotych - przy założeniu, że jeden miesiąc w skali roku ma średnio 732 godziny.

Sprawdź, czym naprawdę jest dysk w chmurze.

Kolejna rzecz, którą należy wziąć pod uwagę, to transfer wychodzący w rozliczeniu miesięcznym. Jeśli chmura służy za bazę dla serwera DNS, to powinno wystarczyć 1 GB takiego transferu. Do kwoty wyżej należy dodać zatem… 0,02 złotego. Powtórzę, żeby nie było niedomówień, albo domysłów, czy to czasem nie jest jakiś błąd: 1 GB transferu wychodzącego kosztuje w Oktawave dokładnie dwa grosze.

Serwery DNS nie są również wymagające (w kontekście firmowych infrastruktur) jeśli chodzi o przestrzeń dyskową. Można założyć, że 15 GB będzie wystarczającą przestrzenią. Jedna godzina korzystania z dysku o pojemności 1 GB kosztuje 0,0004 zł. Po przemnożeniu tej wartości o przez 24 godziny, a później przez średnią liczbę dni w miesiącu (30,5 dnia) oraz finalnie przez ilość pożądanej przestrzeni - u nas jest to 15 GB - otrzymamy kwotę 4,39 zł.

Po wyliczeniu kosztów pracy instancji, transferu i przestrzeni dyskowej należy podliczyć liczbę operacji na dysku, tzw. IOPS (operacje wejścia/wyjścia na sekundę, ang. Input/Output Operations Per Second). Przy założeniu wykorzystania dysku z pierwszego Tiera, który jest ograniczony do 1000 operacji wejścia/wyjścia na sekundę, prosty rachunek wskazuje 2 635 200 000 IOPS w odniesieniu miesięcznym.

Takie jest maksimum, jednak w omawianym przykładzie nawet nie zbliżymy się do takiej liczby IOPS. Założyć można wykorzystanie pięciu procent tej liczby, czyli dokładnie 131 760 000 IOPS. Po zaokrągleniu liczbę milionów operacji (w tym wypadku 131) mnoży się przez kwotę 4 groszy, co daje wynik 5,24 złotego.

Do kwoty za liczbę operacji dodaje się cenę samej przestrzeń danych (4,39 złotego), co finalnie wynosi 9,63 złotych - dokładnie tyle kosztuje w Oktawave 15 GB przestrzeni miesięcznie. Kwota całkowita za serwer to natomiast suma cen za dysk, instancję oraz transfer. W naszym przykładzie jest to dokładnie 53,57 złotego.

Serwer DNS uruchomiony na Oktawave Cloud Instance o klasie Mini to oczywiście tylko jeden przykład. Po więcej informacji na temat szacunkowych obliczeń dotyczących miesięcznego kosztu chmury mogę odesłać do naszego artykułu w bazie wiedzy pod tytułem “Jak planować budżet na infrastrukturę w chmurze obliczeniowej Oktawave”.

Oczywiście wszystkie podane powyżej ceny pochodzą z naszego cennika, więc możecie mnie sprawdzić.

Po lekturze powyższego artykułu wiecie już, jak odwzorować pożądaną infrastrukturę w chmurze i jak obliczyć jej koszt. Dowiedzieliście się też, że nie musicie się obawiać przeszacowania lub niedoszacowania infrastruktury, bo możecie liczyć na pomoc ze strony dostawcy chmury, a finalnie szybko zmienić jej parametry. Oprócz tego w Oktawave możecie na spokojnie przeprowadzić testy wydajnościowe samodzielnie i to zupełnie za darmo.

Każdy nowy klient otrzymuje od nas 25zł na start. To w zupełności wystarczy, aby przekonać się, która klasa maszyny jest odpowiednia dla waszej firmowej infrastruktury, jeśli chcecie się przekonać na własnym przykładzie, czy migracja faktycznie będzie opłacalna.

-----

Maciej Kuźniar, prezes Oktawave sp. z o.o. oraz główny architekt. Pasjonat technologii związanych z przetwarzaniem i przechowywaniem danych, posiadający 12 lat doświadczenia w pracy dla klientów klasy enterprise (banki, telekomy, FMCG). Autor koncepcji technologicznie wspierających rozwój startupów oraz rozwiązań architektonicznych gwarantujących wysokie HA i SLA dla systemów IT.

Zdjęcia i grafiki pochodzą z serwisu Shutterstock.