Cloud finance aneb jak (u)řídit náklady v cloudu
Cloud může být dobrý sluha, ale zároveň i zlý pán. V oblasti financí a nákladů to přitom platí dvojnásob. Jedním z důvodů vzniku tohoto článku byly množící se dotazy od klientů, kteří zjišťují, že řídit cloud finance není jen tak. Zároveň jsme je začali řešit interně, neboť peněženka není nikdy bezedná, že.
Martin Gavanda
Má doporučení v oblasti cloud finance jsou dvojího typu: procesní, která jsou aplikovatelná na jakékoliv prostředí, a technická, která se zaměřují zejména na Amazon Web Services (přece jenom jsem AWS Principal Cloud Architekt); ale mnohá se dají přizpůsobit libovolnému cloud prostředí.
Cloud finance stojí na budgetu
Čemu byste se tedy měli věnovat, pokud vás začíná trápit útrata v cloudu? Určitě začněte u procesů.
Následující diagram vytvořili Lukáš Klášterský, Zdeněk Mach a jejich kolegové z Governance týmu (kteří vám rádi pomohou nejen v oblasti cloud strategií). Jeho stěžejní myšlenkou je budget, tedy odhad nákladů na provoz infrastruktury za dané období.
Budget jako klíčová proměnná ovlivňující vaše cloudu finance
Ve většině případů je budget tvořený na rok, ale vychází z předpokládané měsíční útraty. Vzniká při návrhu aplikace, ať už s využitím AWS Pricing Calculator nebo Azure Pricing Calculator.
Příklad kalkulace ročních nákladů určité aplikace
Ve většině případů zákazníkům doporučujeme, aby v této fázi počítali primárně „hlavní“ komponenty aplikace, respektive ty, které budou mít zásadní dopad na celkovou cenu. Vypočítanou cenu je poté vhodné navýšit asi o 10 %, což pokryje náklady na různé dílčí služby, jejichž přesná kalkulace není možná (nebo by zabrala příliš mnoho času).
V našem příkladu výše tedy máme roční budget $60 000 a předpokládanou útratu $5 000 měsíčně. To je dobrý začátek, protože se máme od čeho odrazit.
Využití budgetu (konzumace)
Pokud víte, kolik plánujete měsíčně utratit, měli byste výši útraty pravidelně sledovat. Pokud utrácíte více, než jste plánovali, potřebujete budget navýšit (a naopak – pokud utrácíte méně, můžete ho snížit).
Vyšší konzumace budgetu
Pravděpodobně jste při analýze a návrhu aplikace s něčím nepočítali nebo došlo ke změně na úrovni infrastruktury, přibyl další server, potřebovali jste vyšší výkon atp. To je samozřejmě možné a legitimní, ale je důležité o tom vědět.
Hezkým příkladem může být aplikace, která se při prvotním návrhu „stěží zaplatila“, ale byla nakonec realizována. Během jejího života se do ní implementovaly nové funkce (dopad na náklady), ale výnos (či jiný přínos) aplikace se nezměnil.
Můžete se tedy ocitnout v situaci, kdy aplikace již není rentabilní, a je čas ji „přecenit“, nebo dokonce zrušit. Pokud však nekontrolujete budget, na kterém stojí celý business case aplikace, tak to nejste schopni zjistit.
Nižší konzumace budgetu
Tato situace je samozřejmě výhodnější. Business case aplikace je „lepší než plánovaný“, což můžete využít k realokaci budgetu jiným směrem – k jiným aplikacím, k vývoji nových funkcí či k čemukoliv jinému, kde naopak budget přečerpáváte.
Ale opět – musíte mít nástroje, jak s touto informací pracovat a vyhodnocovat ji. Jinak vždy půjde jen o nepřesné odhady s větší či menší mírou nepřesnosti.
Jakým způsobem tedy budget hlídat?
Nástroje hlídající cloud finance
AWS Budgets
V prostředí AWS je nejjednodušší využít AWS Budgets, se kterým snadno definujete, co a jakým způsobem chcete hlídat.
Pokud dojde k přečerpání budgetu (ať už aktuálních nákladů či těch předpokládaných na konci měsíce), dostanete o této situaci okamžitě notifikaci.
Ukázka realizace budgetu pomocí nástroje AWS Budgets
Ukázka upozornění na překročení budgetu
Nevýhodou AWS Budgets je fakt, že reportuje pouze přečerpání předpokládaného budgetu, nikoliv situaci, kdy budget zásadním způsobem nevyužíváte. V ten moment nastupuje na scénu nástroj druhý.
AWS Costs Explorer
AWS Costs Explorer vám zpracuje detailní analýzu útraty v cloudovém prostředí.
Zde se dostáváme zpět k finančním procesům v cloudu, kde byste měli mít jasně definováno, kdo a jak často AWS Costs Explorer požívá. Obvykle zákazníkům doporučuji, aby si určili odpovědnou osobu, která bude s tímto nástrojem pracovat alespoň na kvartální bázi (ideálně na měsíční).
AWS Costs Explorer je mocný nástroj, v němž můžete různým způsobem filtrovat a zobrazovat požadovaná data. Zajímá vás pohled přes konkrétní aplikaci? Můžete si ji vyfiltrovat na základě konkrétního tagu. Zajímá vás pohled přes jednotlivé používané zdroje? Nebo například přes prostředí? Toho všeho docílíte relativně jednoduchým způsobem.
Výstup z AWS Costs Explorer, na kterém je hezky vidět, že v prosinci 2023 došlo ke značnému navýšení konzumace služeb Relational Database Service (tedy platformní databáze) a Certificate Manager.
Takže, máme budget a umíme ho sledovat. Teď nastupuje druhá část, a to optimalizační neboli více technická.
Jak optimalizovat cloud finance
Ukažme si pět oblastí, které vám mohou pomoci s optimalizací cloudového prostředí. Nejedná se o seznam, který je vhodný pro každého. Ale některé z bodů budou aplikovatelné skoro v každém prostředí.
1) Pricing modely
První z oblastí je aplikace různých pricing modelů. V AWS máme v principu dvě varianty: Pay as you Go a Rezervace. V principu platí, že s nižší flexibilitou přichází nižší cena. Nechci zacházet do velkých detailů (oblast rezervace zdrojů je docela komplikovaná věc), ale základní rozdělení je na:
-
- Rezervované Instance (ať už standardní, nebo konvertibilní),
- EC2 Instance Savings Plan,
- Compute Saving Plan.
Základní srovnání jednotlivých pricing modelů v AWS
Rozebírat, který způsob je vhodnější, by vydalo na samostatný článek. Za důležité považuji dokázat rozlišit, co je vhodné provozovat v režimu PAYG a kde dává smysl zdroje rezervovat (kterýmkoliv typem rezervace).
Určitě ve svém prostředí najdete příklady zdrojů, o kterých víte, že je budete provozovat minimálně další rok – ty jsou vhodné pro rezervaci.
2) Domnělé vs. reálné potřeby
Druhou oblastí, na kterou doporučuji se zaměřit, je otázka, co reálně potřebujete vs. co si myslíte, že potřebujete.
Potřebujete 4 CPU a 16 GB RAM. Proč? „Protože to tak vždycky děláme,“ je typická špatná odpověď.
V cloudu máte provozovat to, co reálně potřebujete. Váš disk nemá mít 500 GB, protože „se tím nechcete zabývat“. Váš disk má mít takovou velikost (s rozumnou rezervou), jakou potřebujete. I váš server má být tak velký, jak potřebujete.
S tím se samozřejmě pojí nutnost monitoringu, protože když neznáte reálné využití existujících zdrojů, nemůžete ani vědět, zda je potřebujete, nebo ne.
Své zdroje tedy monitorujte a adekvátně tomu je upravujte. Nepsané pravidlo říká: „Když nevíte kolik, tak radši méně.“ Navýšit zdroje je jednoduché, snížit (v některých případech) zdroje je o něco složitější.
3) Provoz neprodukčních prostředí
Troufám si tvrdit, že část neprodukčních prostředí nemusí běžet vůbec, případně bohatě stačí, když jsou dostupná v pracovní době.
Hezkou ilustrací je Pay as you Go model. Pokud provozujete prostředí 24×7, jde průměrně o 720 hodin měsíčně. Pokud budete stejné prostředí provozovat jen v pracovním týdnu od 7 do 19 h, tak je to průměrně pouze 240 hodin měsíčně. Tedy krásný příklad úspory 66 %.
Realita je taková, že většina prostředí nemusí být dostupná ani přes den, ale jen v případě potřeby.
Jakým způsobem tedy automatizovat ono „zapínání“ a „vypínání“ prostředí? Rychlým řešením může být využití AWS Step Functions, kde si rychlým drag & drop způsobem připravíte workflow, které se postará o zapnutí či vypnutí prostředí.
Může to vypadat třeba takto:
-
- Vždy v 19:00 Amazon EventBridge pošle signál, že se má workflow spustit.
- Upravíme Amazon Managed Streaming for Apache Kafka na 0 běžících brokerů (čímž ji efektivně vypneme).
- Nastavíme jednotlivé služby běžící v Amazon Elastic Conatiner Service na 0 replik, tedy že žádný kontejner neběží.
- Vypneme Amazon EC2 servery.
- Pozastavíme jednotlivé databáze provozované v Amazon Relational Database Service.
Využití AWS Step Functions k regulaci provozu neprodukčního prostředí
4) Technické review služeb a infrastruktury
Review služeb a infrastruktury doporučuji provádět alespoň jednou za rok nebo v případě větší změny aplikace. Smyslem review je zhodnocení stavu použitých komponent, případně jejich nahrazení za jiné (které v době implementace aplikace nebyly k dispozici nebo je nebylo možné použít).
Jednou z věcí, kterou doporučujeme s tímto procesem spojit, je i komplexnější AWS Well-Architected review, které vám odhalí slabá místa vaší aplikace.
Příklad 1: Aplikace ve své prvotní verzi podporovala ukládání dat pouze lokálně do Amazon Elastic Block Store. Nová verze však již podporuje ukládání do Amazon S3 bucketu. EBS je přitom mnohem dražší než S3.
Příklad 2: Aplikace na začátku nepodporovala škálování a kontinuálně vám běžely dvě velké EC2 instance. Dnes je ale možné dynamicky škálovat počet EC2 instancí dle reálné zátěže.
Příklad 3: AWS přišlo s novou službou či s aktualizovanou verzí stávající služby. Krásným příkladem jsou T2 vs. T3a instance. Pokud vytváříte novou EC2, T2 instance jsou stále „defaultní“. Jenže nové T3a instance mají vyšší výkon a nižší cenu, a možná tak dává smysl všechny T2 instance změnit na T3a. Úspora 20 % není úplně k zahození. (Toto samozřejmě platí u všech typů instancí. AWS kontinuálně představuje nové řady a je vhodné toto sledovat.)
Příklad úspory při změně T2 instancí na T3a
Úplně stejné je to v případě použití Elastic Block Store (EBS). Defaultní je stále varianta gp2, ale gp3 (obě varianty generické SSD disky) přináší vyšší výkon a nižší cenu. Výsledkem je opět úspora 20 %.
Příklad úspory při přechodu z gp2 na gp3 SSD disky
5) Na každém rozhodnutí záleží
V AWS platíte vždy a za všechno. A některá vaše rozhodnutí mohou značně ovlivnit vaše cloud finance.
Je tedy nanejvýš vhodné si tyto věci uvědomovat. Nebo se poradit s námi. Rádi vám s čímkoliv pomůžeme, ať už půjde o modernizaci infrastruktury, optimalizace či migrace aplikací.
A pokud vás zajímají detaily k Azure, kontaktujte kolegu Jakuba Procházku, jehož tým vám dohlédne na cloud finance v Azure prostředí. Případně se můžete zatím začíst do jeho článků na podobné téma:
