Scroll to top
en pl

AWS – optymalizacja kosztów


Piotr Zięba - 16 stycznia 2020 - 0 comments

AWS - optymalizacja kosztówAWS (Amazon Web Services) to niekwestionowany lider na rynku technologii cloudowych. Korzyści z wdrożenia rozwiązań dostarczanych przez AWS są spektakularne, a wachlarz możliwości zadowoli nawet najbardziej wymagających użytkowników i administratorów. W mojej pracy jednak spotykam się z często powtarzanym pytaniem – po co w rozwiązaniach cloudowych ta cała administracja serwerów? Wystarczy przecież postawić aplikację, skonfigurować serwer i tyle. Nie ma tam nic więcej do roboty.

Otóż nie. Osoby zadające to pytanie, zazwyczaj wracają do mnie po pewnym czasie. Słyszę wtedy: “Źle postawiliście tę aplikację! Dlaczego to tyle kosztuje? Czemu z miesiąca na miesiąc płacę coraz więcej? Proszę natychmiast się tym zająć, ta sprawa ma najwyższy priorytet!”. Najbardziej prawdopodobną przyczyną takiego stanu jest brak odpowiedniego administrowania serwerem. Dopiero wtedy przychodzi czas na refleksję – a może jednak warto na poważnie zająć się zarządzaniem tą infrastrukturą? Czy nie należy zacząć monitorować zachodzących w niej procesów, przewidywać potencjalnych kosztów i dostosowywać jej do bieżących potrzeb firmy?

Oprócz oczywistych zalet, jakimi są globalny zasięg i szybkie wdrażanie innowacji, AWS daje duże możliwości w kwestii optymalizacji kosztów. Poniżej przedstawiam kilka wskazówek gdzie szukać przyczyn wysokich kosztów i w jaki sposób skutecznie je wyeliminować.

Bazy danych i aplikacja w jednym stały domku

Duża konkurencja w branży, dynamicznie zmieniające się środowisko i pojawianie się coraz to nowszych technologii to codzienność specjalistów IT. Chęć uwolnienia się od tej presji, minimalizacja kosztów i skrócenie czasu tworzenia produktu często odbijają się negatywnie na jakości kodu. Jest to widoczne w szczególności w startupach, gdzie niedbałość mylona jest często z podejściem Lean Startup. Ma to oczywiście swoje zalety (szybkie generowanie pierwszych przychodów), ale jest też ryzykowne. Mając na względzie dłuższą perspektywę, takie niedoróbki w projekcie mogą w przyszłości stać się źródłem ogromnych kosztów.

Przykładem może być z pozoru niewinnie brzmiący pomysł: “Postawmy bazę danych i aplikację na jednym serwerze bez konteneryzacji.” Wydawać by się mogło, że jest to rozwiązanie idealne. Baza i aplikacja mogą się ze sobą porozumiewać lokalnie (a więc szybko), a konfiguracja nie przysporzy nam trudności. Do tego przechowywanie logów w tej samej bazie danych, z której korzysta aplikacja, ułatwi dostęp do nich. A co z backupami? Róbmy je lokalnie i przechowujmy na tym samym serwerze! Gdy tylko aplikacja zacznie generować większy ruch, koszty automatycznie wzrosną, a oprócz tego taka architektura pociągnie za sobą szereg innych negatywnych konsekwencji. Baza danych będzie coraz obszerniejsza i coraz wolniejsza, pojemność dysku zacznie się wyczerpywać, a aplikacja będzie działać znacznie wolniej. Powiększanie serwera też nie jest dobrym rozwiązaniem, bo jego objętość będzie wykorzystywana w pełni tylko podczas największego natężenia ruchu. 

Zdecydowanie lepszym rozwiązaniem jest oddzielenie bazy danych i kopii zapasowych od serwera aplikacji. Dedykowane usługi AWS są o wiele tańsze niż instancje serwerowe. Tym prostym zabiegiem można zmniejszyć całkowity koszt AWS nawet o 50%.

Czy instancja ma odpowiednią wielkość?

Kolejnym krokiem po rozdzieleniu aplikacji serwerowej od bazy danych i kopii zapasowych, może być przegląd wielkości naszych serwerów. Czasami, w obawie przed zbyt dużym obciążeniem serwera, dodajemy do niego nawet o 50% mocy obliczeniowej więcej, niż jest to faktycznie potrzebne. W takim przypadku, w czasie poza największym obciążeniem, wykorzystywane jest jedynie od 10 do 30% dostępnej mocy obliczeniowej. Płacimy wtedy za moc, która nie jest używana. Warto sprawdzić, co jest przyczyną takiego obciążenia serwera. Może to być  jakiś wątek, który się zapętla podczas tworzenia kopii zapasowej, rosnący ruch na stronie aplikacji, czy wektor ataku na naszą aplikację. W zależności od przyczyny można zrobić odpowiednią poprawkę w kodzie źródłowym aplikacji i na stałe zmniejszyć wielkość instancji. 

Jeżeli przyczyną obciążenia CPU jest rosnący ruch na stronie, można wykorzystać tzw. Scaling Groups. Polega to na skonfigurowaniu grupy tak, aby przynajmniej jedna instancja serwera była zawsze dostępna. Po wykryciu obciążenia CPU na tej instancji w określonych warunkach (np. powyżej 80% przez 3 minuty) dodawana jest kolejna instancja, która odbierze część ruchu. Aby koszty nie były zbyt duże, można ustawić limit liczby instancji, np. maksymalnie 5. 

Kiedy CPU na dodatkowych instancjach spadnie poniżej 20%, Scaling Group automatycznie usunie dodatkową instancję. Tym sposobem, koszty będziemy ponosić tylko wtedy, kiedy zwiększona moc obliczeniowa będzie naprawdę potrzebna. Oszczędności, w zależności od przyczyny i zastosowanej architektury, sięgają nawet do 70% całkowitych kosztów AWS.

Jeśli wielkość instancji jest stała, będzie wykorzystywana przez kolejny rok i nie przewidujemy zmian aplikacji na tej instancji, warto skorzystać z rezerwacji instancji. Jednorazowa opłata za cały rok pozwala zmniejszyć koszty o 15%.

Czy wszystkie dane muszą być szybko dostępne?

W dzisiejszych czasach użytkownicy są bardzo wymagający. Zbyt długo ładująca się strona, wolny przesył danych czy zacinający się pasek postępu, mogą być przyczyną wielu frustracji. Jednak czy duża szybkość dostępu do danych jest niezbędna w każdej sytuacji?

Wolniejsze zasoby są tańsze. Obecnie większość aplikacji gromadzi ogromne ilości logów. W zależności od ich przeznaczenia i częstotliwości wykorzystywania, różnią się one od siebie wielkością, postacią, miejscem i formą przechowywania, strukturą czy sposobem dostępu.

Logi mogą być przetrzymywane w relacyjnej bazie danych, w pliku tekstowym, w Elasticsearch, itd. Warto zastanowić się  czy wszystkie logi muszą być szybko dostępne. Czy nie może być tak, że logi starsze niż 3 tygodnie mogą być dostępne na żądanie np. dopiero po 2 dniach? Jeśli tak, warto stworzyć wolniejszy, ale tańszy zasób do przechowywania starszych logów i przeprowadzić test odzyskiwania z niego logów. Takie rozwiązanie pozwala zmniejszyć koszty nawet o 70%!

Optymalizacja kosztów AWS – jak to zrobić?

Źle dobrana architektura, niewłaściwe zarządzanie infrastrukturą i niedocenianie roli administratora serwerów może być przyczyną wysokich kosztów. Czy chcesz dowiedzieć się, w jaki sposób najlepiej zoptymalizować koszty i zacząć w pełni wykorzystywać potencjał usług AWS? Skontaktuj się z nami – odpowiemy na wszystkie pytania, pomożemy w wyborze i wdrożeniu rozwiązań, które ułatwią pracę i przeniosą Twój biznes na wyższy poziom.