Jak droższe usługi zmniejszają koszty?

Czy zdarzyło wam się kiedykolwiek zapłacić za usługę chmurową zdecydowanie więcej niż oczekiwaliście? Czy nie do końca wiecie skąd biorą się liczby przy estymowanych kosztach usług chmury publicznej i jaki mają faktyczny wpływ na wasz ostateczny rachunek? Może przenieśliście do chmury swoją stronę i po pierwszej fakturze w panice poważnie rozważaliście wzięcie chwilówki?

Bez paniki! To normalne, a problemy tego typu są do rozwiązania przy odpowiednim zrozumieniu tego, jak działa chmura i za co w niej się płaci.

Jeśli interesuje cię poznanie kilku prostych metod na zoptymalizowanie kosztów chmury publicznych dla swojej aplikacji, ten artykuł jest dla ciebie. Dowiesz się z niego podstaw tego, na jakie aspekty zwracać uwagę przy używaniu chmury publicznej dla swojej aplikacji internetowej, aby nie musieć z tego powodu brać wyżej wspomnianej chwilówki.

Kiedy twój produkt znajdzie się na rozdrożu

Tym razem nie jest to tytuł polskiej komedii romantycznej, a realna sytuacja która przydarza się w pewnym momencie wielu produktom na rynku. Przydarzyła się również mojemu.

Każdy zdrowo rozwijający się produkt w końcu urośnie na tyle, aby nie być już małym produktem (np. małym blogiem), ale nie jest jeszcze wystarczająco duży, aby korzystać z infrastruktury i usług dedykowanych dużym produktom (np. onet). Jest gdzieś pomiędzy tymi dwoma rozmiarami, nie pasując w pełni do żadnej z kategorii.

Wraz ze wspólnikiem prowadzimy ŚREDNIEJ wielkości portal popularno-naukowy Historykon.pl z ruchem około 100 – 150 tys. unikalnych użytkowników miesięcznie. W ciągu lat wypróbowaliśmy różne rodzaje infrastruktury: od hostingów, poprzez serwery dedykowane, aż po własny, fizyczny serwer.

Wydawało się nam, że nareszcie osiągnęliśmy stan stabilny – nic tylko dokładać kolejne serwery. Dzisiaj mamy jedno pudło w biurze, jutro całą farmę na Arktyce!

Własny serwer to w końcu wolność, pełna kontrola i wydajność taka jaką sobie zafundujemy. Jasne! Oprócz tego to również pełna odpowiedzialność i konieczność posiadania 24-godzinnego wsparcia technicznego, które z twarzy łudząco przypomina mnie samego.

Nie będę szczegółowo wspominać ilości obowiązków związanych z bezpieczeństwem, infrastrukturą sieci, podnoszeniem wywalonego serwera w środku nocy i ciągłym poczuciem zagrożenia.

Historykon stanął na wyżej wspomnianym rozdrożu, kiedy nasze urocze pudło przestało radzić sobie przy ciągle rosnącym poziomie ruchu.

To jest sytuacja, której się już nie da przeczekać, bo brak reakcji to również konkretna reakcja z konkretnymi konsekwencjami. Jeśli chcemy to robić dalej, to akceptujemy coraz większy ruch i adaptujemy do niego. Jeśli nie, to czas kończyć zabawę w portal, bo jedyną drogą zmniejszenia ruchu na portalu jest zamknięcie go.

Wybór był prosty, robimy coś albo patrzymy, jak pudło płonie.

Źródło: https://giphy.com/gifs/richard-ayoade-it-crowd-maurice-moss-dbtDDSvWErdf2

Wybierz coś albo zgiń

- To co, budujemy tę farmę serwerów na Arktyce?

- No pewnie, czekaj wyciągnę milion dolarów z konta naszego ŚREDNIEGO rozmiarem portalu

- No co Ty, nie mamy tyle.

- Aha, spoko to ja ogarnę te serwery jakoś. Po co mi życie prywatne?

Dobra, już całkiem poważnie – to jest ten wybór. To jest ten moment, kiedy produkt jest w rozkroku. Jeśli rozbudowujemy własną infrastrukturę, to musi już za tym iść zatrudnienie ludzi obsługujących ją.

Nie ma kasy? Cóż, no to możemy wrócić do hostingu.

Jest to tanie rozwiązanie, ale wracamy do punktu wyjścia. Od tego zaczęliśmy i z jakiegoś powodu uciekliśmy od hostingu. Ograniczał rozwój portalu i kiepsko się skalował. Ale uczciwie rozważyliśmy w naszej sytuacji również i tę opcję.

Historykon swoją liczbą unikalnych użytkowników i intensywnym ruchem albo nie mieści się w żadnym z planów hostingowych, albo łapie się na najwyższy za $300, który przekracza nasze potrzeby. Nie jest to optymalne rozwiązanie.

W swojej pracy jako inżynier oprogramowania często mierzyłem się z problemami związanymi z infrastrukturą, kosztami i efektywną pracą rozwiązań, które rozwijałem.

Skonfrontowałem moje doświadczenie z daną sytuacja – jakie rozwiązanie pozwoli nam płacić jedynie za zużyte zasoby i da dobrą wydajność, dzięki skalowaniu usług w zależności od ruchu?

Odpowiedź brzmi chmura publiczna. Pierwsze zetknięcie z nią miałem już w 2013 z Google Cloud Platform, dzisiaj na co dzień używam Microsoft Azure. W tym temacie od dawna czuje się pewnie i uznałem, że jest to dodatkowy atut przemawiający za wykorzystaniem chmury.

Podjąłem zatem decyzję – idziemy do chmury! Zobaczymy co będzie.

No i po miesiącu przychodzi pierwsza faktura.

[caption id=“attachment_126” align=“aligncenter” width=“706”] Pierwsza faktura za chmurę[/caption]

Opuścić okręt – toniemy!

Wyobraźcie sobie:

• Wasza strona praktycznie nie zarabia – jest projektem hobbystycznym
• Co miesiąc płacicie 400 euro
• Czy jesteście w stanie kontynuować takie hobby?

Może. Zależy od waszej sytuacji życiowej. Ale i tak zaboli, prawda?

Czy to musi być takie drogie?

Niekoniecznie.

To nie jest tak, że w pierwszym miesiącu, gdy faktura wyszła na prawie 400 euro, poleciałem w najdroższe plany i nie patrzyłem na co wydaje pieniądze.

Usługi, które złożyły się na taką kwotę to:

• App Service dla strony internetowej
• Baza danych
• CDN
• SSL
• Storage dla multimediów

Plan dla każdej z usług i politykę skalowania (lista reguł wg których chmura dobiera odpowiednią liczbę instancji do ruchu na stronie) opracowałem na podstawie długich testów na sztucznym środowisku imitującym realia działania Historykona.

Wybrałem usługę w konkretnym planie za konkretną kwotę za zużycie zasobów i ustawiłem dla niej skalowanie. Korzystając z wbudowanych w Azure’a możliwości imitowania danego ruchu na stronie zacząłem bombardować biednego Historykona hordą użytkowników-zombie.

Następnie prosta obserwacja – jak się usługa zeskalowała, ile zasobów pożarła i czy działała wydajnie? Zapisać wynik i próbować w innej konfiguracji.

Powtórz do wyczerpania możliwości.

Najlepsze wyniki dla danej kombinacji wydają się oczywistym wyborem dla migracji, prawda?

Otóż nie w tym przypadku. Za chwilę wyjaśnię, dlaczego.

Oto plany, które wyszły mi z mojej analizy wraz z polityką skalowania dla App Service’u.

• App Service Plan: S1 (koszt około 40 euro za instancję)
• Azure Database for MySql: 1 vCore Gen 4 ( koszt około 30 euro za miesiąc)
• CDN: Standard Verizon (koszt 0.073 euro za 1 GB)

[caption id=“attachment_127” align=“aligncenter” width=“903”] Polityka skalowania Historykona przed fakturą[/caption]

Dlaczego się nie udało?

To co zrobiłem było poprawne i logiczne. Zrobiłem wszystko zgodnie z zasadami. Niestety z jednym małym wyjątkiem.

Moją winą było kiepskie oddanie realiów ruchu na portalu. Podstawowe błędy symulacji, które popełniłem to np. zbyt krótkie symulowane obciążenia w stosunku do prawdziwego ruchu i zupełnie inny poziom natężenia ruchu (ruch rośnie inaczej, ma zupełnie inną długość i rośnie z inną częstotliwości oraz prędkością).

Tylko czy dobra symulacja jest faktycznie realna do wykonania?

Najlepszą i wyłączną prawdziwą metryką jest prawdziwy ruch i prawdziwe zachowania użytkowników. Pierwsza faktura jest tego dowodem.

Rzeczywistość zatem zweryfikowała wyniki mojej analizy. Gdy ruch zwiększał się tak intensywnie, skalowanie App Service Planu nie nadążało za nim. W wyniku tego dana instancja App Service Planu była zadeptywana przez hordy użytkowników – powodując brak dostępności strony dla części z nich. Nieżywa instancja nadal jednak kasowała mnie za swoje wątpliwe istnienie.

Natomiast wybranie zbyt niskiego planu i bardzo skokowe i niestabilne natężenie ruchu ze zbyt wolnym skalowaniem doprowadziło do sytuacji, gdy parę razy dziennie App Service Plan skalował się do 7 – 8, a czasem nawet do 10 instancji, a następnie bardzo długo wracał do poziomu początkowego. Wówczas przez sporą część dnia byłem obciążany kosztami działania nawet 10 instancji (o koszcie 40 euro/1 instancja /miesiąc).

Ale czy trzeba koniecznie zabulić 400 euro za pierwszą fakturę, żeby dobrze dopasować chmurę do naszych potrzeb? W moim przypadku jak widać niestety tak, ale dzięki temu, że to przeżyłem - to mogę wam oszczędzić tego bólu i powiedzieć co zrobić zamiast tego co ja na początku.

Najważniejsze w oszczędzaniu na chmurze to…

Rysunek: Arleta Rynk

Nie ma złotego środka, ale powiedziałbym, że najważniejsze to dobra obserwacja i wyciąganie wniosków z zachowania naszego produktu i jego użytkowników.

Optymalizacja jest procesem, który trwa ciągle. Optymalizacja nie jest pojedynczym działaniem. Każda nowa metryka i nowy log z aplikacji mogą dać wskazówkę do zmiany sposobu korzystania z usług chmury.

Dlatego przyjrzałem się kilku podstawowym metrykom – średnia liczba instancji aplikacji, transfer danych i odwiedziny na stronie w czasie – aby zweryfikować swoje aktualne podejście.

Zbyt tanio, czasem znaczy drożej

W moim przypadku rozwiązanie było jak na dłoni. Jeśli App Service Plan S1 był na tyle mało wydajny, że potrzebował skalować się do prawie 10 instancji, z których każda wychodzi 40 euro za miesiąc użytkowania to wydajniejszy App Service Plan powinien mieć mniejszą amplitudę skalowania. To znaczy, że potencjalnie powinien być tańszy.

Po szybkim przeliczeniu kilku możliwości zdecydowałem, że wybiorę plan ponad 4 razy DROŻSZY od obecnego.

Tak. Zmieniłem plan na taki, który kosztuje 150 euro miesięcznie. I to w sytuacji, gdy poprzednia faktura spadła na mnie jak fortepian z nieba.

Dlaczego? Znacznie większa wydajność sprawia, że App Service Plan rzadziej będzie potrzebować skalowania. W moim przypadku podnosi się on do maksymalnie 2 – 3 instancji tylko w czasie totalnego oblężenia, kiedy ruch jest spokojny zostaje na jednej instancji.

Wydajnościowo również jest zadowalający.

[caption id=“attachment_128” align=“aligncenter” width=“362”] Wydajność App Service Planu S3[/caption]

Transfer to spora część kosztów chmury – zmniejsz go!

Kolejnym krokiem było całkowita rezygnacja z CDN dostarczanego przez Azure.

W zamian przerzuciłem się całkowicie na darmowe rozwiązania Cloudflare. Jako, że portal serwuje głównie statyczne treści, które raz dodane rzadko się zmieniają, ustawiłem dość agresywną politykę cachowania ruchu po stronie Cloudflare.

Dlaczego?

Sporą część kosztów w Azure stanowią koszty transferu danych z datacenter do reszty świata. W ten sposób omijałem przesyłanie ciągle tych samych danych, by oszczędzić na transferze. To realna oszczędność pieniędzy.

1 GB przy moim transferze kosztuje 0.074 euro. Realnie Cloudflare oszczędził mi w tym miesiącu naprawdę dużo pieniędzy.

Dzięki temu rozwiązaniu można oszczędzić ogromne ilości danych wchodzących i wychodzących z Azure na twój koszt. Tak to wygląda u mnie.

[caption id=“attachment_129” align=“aligncenter” width=“960”] Cloudflare oszczędza mi 4TB miesięcznie[/caption]

Poznaj swój ruch – zaadaptuj do niego

To temat godny swojego własnego artykułu. Jest bardzo obszerny i trudny. Opiszę Wam zatem jedną prostą zasadę, którą zastosowałem. W następnych artykułach poświęcę więcej uwagi analizie ruchu i wyciągania z niej wniosków, by oszczędzić pieniądze na infrastrukturze.

Jednym ze sposobów poradzenia sobie z wolnym skalowaniem, gdy ruch na stronie zwiększa i zmniejsza się bardzo dynamicznie i szybko, jest analiza danych historycznych na podstawie np. Google Analytics i Application Insights. Odnalezienie wzorców zachowań, z których można wywnioskować kiedy i z jakiego powodu strona może doświadczyć tzw. peaku to trudne zadanie.

Przeszukałem dane wiele lat wstecz analizując godziny aktywności, godziny dodawania artykułów i ich promocję. Znalazłem prawdopodobne obszary czasowe w ciągu dnia szczególnie narażone na peak i spadek wydajności.

Te obszary ustawiłem na sztywno w polityce skalowania, aby kiedy zacznie się peak, aplikacja już była gotowa, a nie dopiero zaczynała się przystosowywać do intensywnego ruchu. Zaraz po zakończeniu tego okresu liczba instancji wracała natychmiast do jednej.

[caption id=“attachment_130” align=“aligncenter” width=“740”] Polityka skalowania po fakturze[/caption]

Sam taki ruch już zwiększy komfort użytkowania strony podczas oblężenia, a Tobie oszczędzić pieniądze wydane na powolne i stopniowe deskalowanie strony po peaku.

Efekty reakcji na prawdziwe metryki aplikacji

[caption id=“attachment_131” align=“aligncenter” width=“719”] Druga faktura Historykona[/caption]

Oto następna faktura, którą dostałem.

Koszty od razu spadły prawie dwukrotnie. Zaoszczędzona różnica to koszty księgowości mojej firmy. Pamiętacie kwotę jedynego planu hostingowego, który pasował do Historykona? To była kwota $300. Różnica pomiędzy $300 a 200 euro to prawie tyle ile co miesiąc wydaję na prawnika. Wolę mieć tę różnicę w kieszeni niż nie mieć.

Dodatkowo ten plan hostingowy nie będzie na tyle wydajny i elastyczny, by dopasować się do ruchu Historykona. Co jeśli ruch jeszcze wzrośnie? Dostawcy hostingów, których sprawdzałem nie posiadają wyższych planów – mogę zawsze prosić mailowo o plan dedykowany. Ale po co, gdy mogę to na chmurze zrobić jednym kliknięciem?

W porządku, koszty spadły, ale coś innego wzrosło. Co wzrosło?

Uptime Historykona po migracji do chmury

Tak jest. Uptime wzrósł.

A wraz z nim ilość mojego czasu wolnego, który poświęciłem na dalsze optymalizacje i rozwój.

Czy nie łatwiejszy byłby hosting?

Prawda, estymacja i optymalizacja kosztów w chmurze diametralnie się różni od własnego serwera, czy hostingu. Jest trudniej.

Cała idea chmury polega na tym, że płaci się za zużycie zasobów, a nie jedną ustaloną kwotę.

Oczywiście, dla osób/organizacji z ograniczonym budżetem jest to z jednej strony korzystne, bo daje większą kontrolę nad kosztami, ale z drugiej sprawia, że można się bać jej używać, gdyż jedna pomyłka może poskutkować wydrenowaniem kieszeni właściciela.

Jeśli jesteś zadowolony z wydajności i kosztów swojej infrastruktury – możliwe, że jeszcze nie czas na decyzję migracji do chmury. Nie ma to sensu, gdy chmura ma pełnić rolę zwykłego hostingu. Bez wątpienia byłby to porównywalnie znacznie droższa opcja. Koszty korzystania z chmury są ściśle powiązane z tym jak z niej korzystamy.

Natomiast jeśli to elastyczność infrastruktury i jej wysoka wydajność przy płatności jedynie za faktycznie użyte zasoby jest dla ciebie ważna, tak jak dla Historykona, wtedy przyda ci się chmura, a wraz z nią wiedza jak z niej optymalnie korzystać.

Co możesz zrobić, aby zacząć oszczędzać już dziś?

Podane przy usługach kwoty to tylko wskazówka, która może w niektórych kontekstach wprowadzić w błąd. Najlepszą metodą optymalizacji jest próbowanie i ciągła ewaluacja.

Nawet ludzie pracujący z chmurą na co dzień popełniają błędy, ale istotne jest szybkie reagowanie i obserwacja konsekwencji. Dzięki temu można czerpać garściami z korzyści chmury.

Aby zacząć optymalizację już teraz i od razu zobaczyć tego efekty:

• Zweryfikuj warstwę cenową jakiej używasz. Jeśli masz ruch na podobnym poziomie jak Historykon to zapomnij o wszystkich planach Basic, jeśli używasz S1 lub S2 i skalujesz je – spójrz czy przez większość czasu nie lecisz na 7 instancjach planu. Jeśli tak, nie bój się podwyższać planów na droższe. Koszty spadną drastycznie.
• Cloudfare ma darmowy plan – załóż konto jeszcze dziś i podepnij tam swoją witrynę. Poza wieloma benefitami niezwiązanymi z dzisiejszym tematem, po ustawieniu dobrego cachowania statycznego contentu oszczędzisz na transferze nawet kilkadziesiąt euro miesięcznie przy poziomie ruchu jak na Historykonie
• Zacznij korzystać z agregatora metryk jak Google Analytics, czy Application Insights i użyj ich do rozpoznania kiedy występują potencjalne oblężenia. Na ten czas ustaw większą liczbę instancji aplikacji, a jak upłynie natychmiast wróć do 1 instancji. Zarówno utrzymasz wysoką wydajność strony i komfort dla użytkowników, jak i oszczędzisz kolejne kilkadziesiąt euro przy dobrych wiatrach

Powyższe kroki pozwolą ci już teraz oszczędzić pieniądze, ale nie zatrzymuj się na tym. Po co wydawać więcej, jak można mniej?

Dzięki ciągłemu praktykowaniu optymalizacji zyskasz:

• większą ilość zaoszczędzonych pieniędzy
• mniejszą ilość czasu poświęconego na żmudne zarządzanie infrastrukturą
• większe zrozumienie chmury publicznej, które pozwoli tworzyć coraz lepsze i optymalne kosztowo i wydajnościowo rozwiązania