Kilka sposobów na oszczędności w Azure

Chmura Azure daje niezwykłe możliwości implementacji wszelkiego rodzaju rozwiązań przy stosunkowo mniejszych nakładach finansowych. Wszystko oczywiście zależy od konkretnego projektu jendakże w większości przypadków wykorzystanie swoich własnych środowisk on-premise bardzo często wiąże się z zakupem sprzętu, licencji oraz zatrudnieniem szeregu ludzi, którzy będą się tym opiekowali co zdecydowanie mnoży koszty CapEx. W chmurze natomiast mamy do czynienia z modelem OpEx gdzie płacimy kwoty zależne od użycia i nie potrzebujemy ogromnych środków aby rozpocząć projekt i z niego korzystać przez co próg wejścia w określoną technologię jest zdecydowanie niższy niż w analogicznym podejściu on-premise. Mimo elastyczności chmury istnieje wiele dróg do tego aby zapłacić zdecydowanie więcej niż powinniśmy. Czy jest jakiś sposób na tego typu problemy? Oczywiście, że tak! W ramach artykułu przedstawię kilka kluczowych moim zdaniem punktów związanych z oszczędnościami w Azure.

Pricing calculator

Pierwszą rzeczą na którą powinniśmy zwrócić uwagę jeśli chodzi o koszty w Azure jest Pricing calculator. Mnogość narzędzi i serwisów dostępnych w chmurze może być przytłaczająca dlatego też aby osiągnąć orientacyjny koszt najlepiej sięgnąć po kalkulator właśnie.

Jak możecie zauważyć kalkulator ma przyjazny interfejs w którym możemy wybrać interesujące nas narzędzia, ich lokalizację oraz konfigurację aby poznać ich koszt. To o czym wiele osób zapomina jest fakt, iż kalkulator posiada kilka wbudowanych architektur referencyjnych na których możemy się wzorować i wyestymować koszty co czasami bywa pomocne:

Całą estymatę możemy oczywiście zapisać czy też wyeksportować w zależności od potrzeb:

Jak dla mnie jest to jedno z tych narzędzi, które każdy powinien znać.

Monitorowanie kosztów

Monitoring aktualnych kosztów plus ewentualne notyfikacje przy przekroczeniu określonego progu to niezwykle istotne kwestie. W przypadku chmury Azure czynności te są dosyć proste i intuicyjne ponieważ mamy do dyspozycji dedykowany serwis poświęcony właśnie kosztom, serwis ten nazywa się Cost Management and Billing. To właśnie w tym miejscu powinniśmy rozpocząć inwestygację co w jakim czasie pochłonęło najwięcej funduszy. W rzeczywistości omawiany serwis jest zestawem narzędzi, który pomaga nie tylko śledzić konsumpcję środków, ale również nią zarządzać oraz optymalizować.

Jak możecie zobaczyć na powyższym obrazku koszty mogą być analizowane w przejrzysty sposób w przeróżnych przekrojach.Warto wspomnieć o takich funkcjonalnościach jak budżety oraz notyfikacje tzn. jesteśmy w utworzyć zakładany budżet np. 1000$ i ustawić notyfikację wtedy gdy nasze zasoby osiągnąć 80% realizacji budżetu. Dodatkowo logi związane z kosztami możemy przesłać np. do Log Analytics i tam w reakcji na przekroczenie limitu wykonać pewne operacje jak np. zeskalowanie w dół bazy danych lub wyłączenie maszyn wirtualnych. Opcji jest bardzo wiele i są one stosunkowo proste do ustawienia.

Chciałbym również wspomnieć, że na samą optymalizację kosztów mają wpływ również rekomendacje pochodzące z Azure Advisor również widoczne z poziomu opisywanego narzędzia:

Ogólnie rzecz biorąc zawsze polecam zapoznać się z tym co chce nam przekazać Azure Advisor ponieważ większość z rzeczy które tam znajdziemy naprawdę pomaga nam zoptymalizować nie tylko koszty ale również cały workload.

Azure Hybrid Benefit

W przypadku gdy mamy już wykupione licencje na określone oprogramowanie takie jak np. Windows Server czy SQL Server mamy możliwość wykorzystać te licencje również w Azure. Innymi słowy Hybrid Benefit jest Azureową implementacją konceptu BYOL (Bring Your Own License). Jest to niezwykle korzystna opcja, która pozwala zaoszczędzić sporą część funduszy. Część osób nie zdaje sobie sprawy, że tworząc maszynę wirtualną ze wspomnianym Windows Server w koszcie za tą maszynę wliczone są nie tylko zasoby potrzebne do jej działania ale również koszt licencji. Dlatego też w przypadku posiadania odpowiednich licencji on-premise warto zastosować wspomniany benefit. Na stronie poświęconej tej właśnie ofercie można przeliczyć ile jesteśmy w stanie zaoszczędzić:

Na powyższym przykładzie można zobaczyć, że przy licencji na SQL Server z Software Assurance na 8 core w przybliżeniu możemy zaoszczędzić blisko dwa tysiące dolarów miesięcznie co daje naprawdę niebagatelną sumę w skali roku (około 74% oszczędności). Co ciekawe jeśli posiadamy również licencję na Windows Server to wtedy oszczędności będą jeszcze bardziej pokaźne:

87% oszczędności i tylko 350Euro za 8 core’ową maszynę z dyskami SSD i 28GB RAM to naprawdę niezwykle atraktycjna cena. Oczywiście warto zwrócić uwagę na fakt, iż jak każdy kalkulator w Azure tak również ten ma charakter poglądowy i rzeczywiste wyliczenia mogą się nieco różnić ale nie jakoś znacząco.

Podsumowjąc hybrid benefit może dotyczyć następujących usług:

• IaaS (Azure VM):
  • Windows Server
  • Red Hat
  • SUSE Linux
  • SQL Server
• PaaS:
  • Azure SQL Database
  • Azure SQL Managed Instance
  • Data Factory with Integration Services

Azure Reservations

W przypadku gdy nasze rozwiązania będą używane długofalowo możemy pomyśleć o tym aby zarezerwować określone zasoby na czas jednego roku lub trzech lat. Rezerwując je w taki sposób mamy możliwość otrzymania zniżki, która może wynosić aż do 72%! Na czym to polega? Możemy sobie wyobrazić sytuację gdzie mamy stabilny workload i nie chcemy skalować w górę/dół naszej usługi (np. Azure SQL) i cena w cenniku Pay-As-You-Go wynosi określoną kwotę. Mając na uwadzę stabilność i trwałość użycia tej usługi możemy zobligować się, że będziemy jej używać w takiej konfiguracji przez następny rok lub trzy i przez to, że się zobligowaliśmy otrzymujemy pokaźną zniżkę.

Jeśli będziemy potrzebowali większej mocy to istnieje możliwość zwiększenia rezerwacji  (niestety zmniejszenie nie jest możliwe na moment pisania tego artykułu). Możliwa jest również rezygnacja z rezerwacji przez co będziemy musieli zapłacić 12% pozostałej kwoty do zapłaty (warto prześledzić dokumentację żeby wiedzieć dokładnie jak taka procedura wygląda). Według mnie jest to jeden z najbardziej efektywnych sposobów na oszczędzenie środków i jednocześnie nie wpływa na założony przez nas poziom wydajności oraz zestaw funkcjonalności.

Automatyczne wyłączanie VM

O tym, że w przypadku maszyn wirtualnych płacimy za Compute, Storage oraz licencje nie trzeba nikomu mówić. Co natomiast jeśli moc obliczeniowa takiej maszyny jest nam potrzebna tylko w określonych porach dnia, w wybrane dni tygodnia? Nic nie stoi na przeszkodzie aby ją wyłączyć! Oczywiście taki proces może być wykonany zarówno ręcznie jak i automatycznie. Maszyny wirtualne w swoim głównym menu zarządczym na portalu posiadają opcję automatycznego wyłączania:

Po co nam taka opcja? Powiedzmy, że mamy maszynę wirtualną na potrzeby deweloperskie i wiemy, że po 17 nikt nie powinien jej już używać i z tego też powodu o tej konkretnej godzinie maszyna się wyłączy. Następnego dnia jeśli będzie taka potrzeba deweloperzy ją włączą. Możemy wyłączeniem i włączaniem sterować również z poziomu innych narzędzi wykorzystując np. Azure Automation, Logic Apps czy wywołania przez REST API i inne.

Do wystartowania maszyny możemy również wykorzystać tzw. Automation Task:

Dzięki temu podejściu gdzie nasza maszyna działa jedynie przez np. 8 godzin w ciągu doby z góry oszczędzamy 2/3 kosztów związanych z mocą obliczeniową.

 

Enterprise DEV/TEST

Dla klientów z Enterprise Agreement Microsoft przygotował specjalny rodzaj subskrypcji o nazwie Enterprise DEV/TEST. Co to takiego? Jak sama nazwa wskazuje jest to usługa dla klientów Enterprise w skład której wchodzi cała gama różnych benefitów. Nie będę jej szczegółowo opisywał ponieważ wszystko znajduje się w dokumentacji ale z punktu widzenia oszczędności mamy zdecydowanie niższe stawki dla usług takich jak:

• Windows Virtual Machines,
• Cloud Services,
• SQL Database,
• SQL Managed Instance,
• HDInsight,
• App Service (Basic, Standard, Premium v2, Premium v3)
• Logic Apps

Ponad to powyższy bonus możemy również łączyć ze wspomnianymi rezerwacjami dzięki czemu tworzone przez nas środowiska DEV/TEST mogą być super tanie.

Visual Studio Subscriber benefit

Jeśli wy lub wasza organizacja macie subskrypcje Visual Studio to po pierwszy każdy subskrybujący dostaje swoją pule zasobów w Azure, które mogą być wykorzystywane do nieprodukcyjnych zastosowań. Z mojego punktu widzenia tego typu benefit pozwala testować różnego rodzaju funkcjonalności bez konieczności obciążania klienckich subskrypcji co z całą pewnością może być formą oszczędności. Dodatkowo subskrybenci mają możliwość dostępu do Pay-As-You-Go Dev/Test, która pod wieloma względami przypomina wspomniane wyżej Enterprise DEV/TEST – z całą pewnością warto się zapoznać bo być może macie taki benefit i nawet o nim nie wiecie.

Spot Virtual Machines

Czy macie taką sytuację, że wasz workload na maszynie wirtualnej może być przerwany i nie wpływa to negatywnie na postawione przed nim zadanie? Jeśli odpowiedź brzmi twierdząco to Spot Virtual Machines to coś czym powinniście się zainteresować. Ale jak to możliwe? Jak zapewne wiecie klienci chmury Azure wykorzystują zasoby dostępne w określonych regionach, w danych data center. Czy to oznacza, że takie data center jest w całości wykorzystywane? Oczywiście, że nie! Microsoft musi zadbać o odpowiednią “przestrzeń” ponieważ mogą pojawić się nowe potrzeby klientów, istniejące elementy będą się skalować w górę itp. ta “zapasowa” przestrzeń nie jest na dany moment wykorzystywana, ale w każdym momencie może się to zmienić. To właśnie tą dodatkową przestrzeń możemy wykorzystać tworząc tzw. Spot Virtual Machines.

Tworząc tego typu maszynę możemy uzyskać bardzo atrakcyjną cenę – pytanie brzmi tylko jaką. Odpowiedź nie jest jednoznaczna i zależy przede wszystkim od regionu, ale również od tego ile tej nieużywanej przestrzeni jest. Jeżeli jest jej dużo możemy liczyć na większy rabat. Cena zatem jest różna w zależności od sytuacji, a my tworząc maszynę tego typu możemy wyznaczyć górny limit jaki jesteśmy zdolni za taką maszynę zapłacić – przykład takiego ustawienia możecie zobacyzć na poniższym zrzucie:

 

Brzmi to bardzo dobrze natomiast może pojawić się pytanie po co mi maszyna, której “moc” w każdej chwili może zostać mi odebrana? Chociażby dla potrzeb deweloperskich czy też testowych. Innym zastosowaniem będzie batchowe przetwarzanie danych, które może być zatrzymane i wznowione w dowolnej chwili. Warto wspomnieć, że serwisy takie jak Databricks, które pod spodem powołują maszyny wirtualne na własne potrzeby w ramach swojej własnej Managed Resource Group również posiadają możliwość powoływania Spot VMs.

Skalowanie

O skalowaniu powiedziano już wiele rzeczy i bardzo często to ta funkcjonalność jest przedstawiana jako jedna z zalet chmury w ogóle. Skalowanie w odniesieniu do oszczędności sprawdza się do tego aby podnieść poziom wydajności wtedy kiedy jest to konieczne i go zmniejszyć lub całkowicie wyłączyć po godzinach szczytu.  Dobrym przykładem będzie tu baza Azure SQL czy Synapse SQL Dedicated Pool gdzie w zależności od potrzeb możemy skalować w górę i w dół manipulując w ten sposób pomiędzy wydajnością, a ceną. O tym jak to zrobić miałem już okazję pisać w ramach artykułu “Skalowanie Azure SQL Database przy pomocy TSQL i REST API” dlatego też warto o tej opcji pamiętać. Jest jeszcze oczywiście możliwość użycia Azure SQL Serverless czyli instancji, która może się skalować tylko w momencie gdy jest używana. Jeśli następuje określony moment braku aktywności (np. 1h czy 30m – jest to konfigurowalne) to wtedy usługa jest wyłączana i na okres braku aktywności nie ponosimy kosztów związanych z Compute. Kiedy taka maszyna się wybudzi? Po wysłaniu do niej pierwszego żądania.

Warto wspomnieć również o fakcie, że wiele różnych usług posiada swoje własne metody skalowania i tak np. Azure Data Factory ma swoje jednostki wydajności (Data Integration Unit), którymi możemy sterować i w zależności np. od ilości przetwarzanych danych zwiększać lub zmniejszać ich ilość. Dlatego też zawsze warto przyjrzeć się bliżej każdej usłudze bo zapewne posiada ona jakieś możliwości optymalizacyjne.

Oszczędność miejsca na storage

Storage w Azure jest tani – tego typu zdania słyszymy bardzo często. Jednakże przy pewnej skali to właśnie storage może być dosyć istotnym punktem na naszym rachunku. Dlatego też warto się zastanowić jak wygląda cykl życia danych przechowywanych. Wiemy, że BLOB posiada tiery dostępowe takie jak Hot, Cold, Archive więc dlatego warto przechowywać dane zgodnie z ich przeznaczeniem tzn:

• jeśli dane są często używane i potrzebujemy mieć do nich szybki dostęp do domyślnym wyborem będzie HOT – opcja najdroższa,
• jeśli dane są odczytywane sporadycznie ale jeżeli już pojawi się potrzeba ich odpytannia to mamy mieć do nich stosunkowo szybki dostęp do wyborem będzie COLD – opcja średnia cenowo,
• jeśli dane mają być archiwizowane np. na potrzeby zgodności z określonym standardem, a dostęp do nich nie musi być natychmiastowy to wybów pada na ARCHIVE – opcja najtańsza.

Poszczególne dane mogą oszczywiście zmieniać tier, a pomóc nam w tym może mechanizm Data Lifecycle Policy dostępny w określonym Storage Account. Ponadto same dane możemy przechowywać w różny sposób, mamy formaty skompresowane jak chociażby parquet oraz nieskompresowane jak CSV (bez kompresji) więc w miarę możliwości warto rozważyć użycie tych z kompresją co przy większych projektach może mieć znaczący wpływ na koszt.

Istnieją również formaty takie jak Delta szeroko wykorzystywany przez Databricks. Format ten przechowywany jest oczywiście na Azure Storage w postaci zestawu plików parquet i opisujących ich JSONów. Format ten charakteryzuje się m.in. tym, że posiada coś na wzór loga transakcyjnego i dane ( a raczej każda ich zmiana) są historyzowane przez co z czasem danych historycznych może nam narosnąć ogromna ilość. Z tego też powodu należy zastanowić się czy dane historyczne są nam potrzebne, a jeśli nie to je usunąć przy pomocy dostępnych komend wewnątrz Databricks jak chociazby VACUUM.

Storage to oczywiście nie tylko BLOB dlatego warto również przyjrzeć się np. snapshotom dysków bo czasem zdarza się tak, że zalegają na chmurze, a tak naprawdę nie są nam do niczego potrzebne.

Wybór odpowiedniego narzędzia do odpowiednich celów

W moim odczuciu temat często pomijany w odniesieniu do kosztów. Zdarza się widzieć implementacje, które niekoniecznie są zrobione zgodnie ze zdrowym rozsądkiem. Bardzo często architektura jest przeszarżowana i zbyt wielkie zasoby są angażowane do za małych prac. O dziwo z moich obserwacji zdecydowanie częściej pojawia się przeszacowanie potrzebnej mocy niż niedoszacowanie 🙂 Z czego to wynika? Być może ludzie chcą się zabezpieczyć przed wolnodziałającymi procesami, bądź mają swoje preferencje narzędziowe.

Przykład? Jeżeli mamy do przetworzenia w trybie batchowym raz na tydzień 10 plików CSV o łącznej wielkości 100MB to czy warto angażować wielki klaster Databricks? Jeśli mamy do wykonania prostą operację w języku Python na podstawie zadanych parametrów przez REST API to czy stawianie pełnoskalowej aplikacji i szeregu API ma sens? Tworząc hurtownię danych, której przewidywany rozmiar nigdy nie przekroczy 50GB powinniśmy porywać się na Azure Synapse Dedicated Pool?

Odpowiedzi na powyższe pytania zazwyczaj powinny brzmieć NIE. To właśnie dopasowanie narzędzi do potrzeb, a nie potrzeb do narzędzi powinno być priorytetem dla każdego projektu chmurowego, a budżet i koszty z całą pewnością na takim podejściu nie ucierpią.

Porównuj ceny między regionami

Nie jest to rada dla każdego i może być wykorzystana tylko w niektórych scenariuszach jednakże możliwa jest drobna oszczędność pieniędzy. Ceny poszczególnych usług potrafią dosyć znacząco różnić się pomniędzy regionami. Dlatego też jeżeli nie jesteście związani z żadnym regionem i właściwie odległość geograficzna nie ma dla was aż takiego znaczenia warto porównać ceny.

Poniżej możecie zobaczyć cenę z trzech różnych regionów:

Jak widać ceny mogą być zdecydowanie różne w zależności od lokalizacji danego data center i może to być przyczyna do wyboru danej usługi w tej konkretnej lokalizacji. Należy jednak pamiętać, że nie wszystkie usługi są dostępne we wszystkich regionach.

Bandwith cost

To, że płacimy za przesył danych powinno dla każdego być jasne. W zależności od tego skąd dokąd trafiają nasze dane możemy za ten transfer zapłacić lub nie. Poniżej kilka przykładów:

• transfer DO chmury – za darmo
• transfer w ramach pojedynczej Availability Zone – za darmo
• transfer pomiędzy regionami w Europie – 0.018 Euro za GB
• transfer pomiędzy Europą, a innymi regionami – 0.045 Euro za GB

Oczywiście to tylko niewielki wycinek wszystkich możliwych kombinacji (całość oczywiście w dokumentacji). Warto zatem z góry zaplanować architekturę oraz zamodelować przepływ danych co według moich obserwacji często bywa pomijane.

To by było na tyle jeśli chodzi o to co przygotowałem na temat oszczędzania w Azure. Oczywiście artykuł nie wyczerpuje tematu i istnieje więcej czynników na które warto zwrócić uwagę. Polecam każdemu przy okazji planowania wdrożenia przyjrzeć się kosztom i odpowiednio rozplanować poszczególne kroki, pozwoli to uniknąć problemów w przyszłości. Pozdrawiam!