optimalizace – OLDŘICH ŠRUBAŘ

Azure Governance díl III. – Cost Management

Dnešní v pořadí třetí disciplína, jak už sám název napovídá, se bude zabývat sledováním nákladů a toho, jak je důležité vnímat za co se v Azure spotřebovávají finanční prostředky. Na mém blogu najdete samozřejmě i dvě předchozí disciplíny – Resource Consistency a Security Baseline. Pokud vás téma Azure Governance zajímá v celkovém pojetí, doporučuji nejprve přečtení předchozích článků, ať vám vše do sebe hezky zapadne.

Správa nákladů je prakticky tou nejdiskutovanější disciplínou. Není se čemu divit, když jde o peníze, a navíc ty firemní, je nutné se zajímat za co se utrácí a jestli je možné někde ušetřit. Nejčastější otázka, která padne na většině prvních schůzek se zákazníkem: „Kolik to v tom Azure bude všechno stát?“ Odpověď většinou přichází vzápětí – záleží co všechno chce firma v Azure provozovat:

Jaké Azure služby se budou využívat? Co chce zákazník, aby v cloudu běželo?
Bude se využívat IaaS, PaaS nebo SaaS?
Může zákazník využít Azure Hybrid licence? – Jde o přenesení licencí pro Windows Server a SQL server z on-premise prostředí v případě aktivního programu Software Assurance.
Má zákazník v plánu být v Azure delší dobu nebo napořád? – V tom případě je rozumné využít možnost rezervovaných instancí služeb.

V disciplíně Cost Management je důležité se zaměřit na náklady z business pohledu společnosti, na odhalení a definici rizik, které jsou s tím spojené. Správa nákladů v tradičním on-premise světě je založena na životním cyklu zařízení v datacentrech, samotných serverů a problémech s údržbou systémů. Tyto náklady jsou předvídatelné, je možné s nimi plánovat a zpřesnit tak, aby odpovídaly ročním výdajovým rozpočtům. U cloudových řešení mnoho společností spoléhá na reaktivní přístup ke správě nákladů. To se může projevit tím, že si předplatí nebo se zavážou k určité spotřebě cloudových služeb. Tento model předpokládá maximální možnou míru slev na základě obchodních plánů a spotřeby kreditu u konkrétního dodavatele cloudu. Díky tomu, může mít společnost pocit, že proaktivně plánuje nákladový cyklus. Není tomu tak, tento pocit se může stát realitou pouze tehdy, pokud bude firma implementovat vyspělou disciplínu řízení nákladů. V podstatě jde o to, že cloudové služby nabízejí samoobslužné portály (Azure portál), které dříve u on-premise řešení neexistovaly. Díky těmto novým možnostem se dokáže společnost lépe adaptovat na nové technologie, být více agilní a méně restriktivní. Na druhou stranu to ale také přináší určitou větší zodpovědnost na straně uživatelů. Pokud si totiž nehlídají, jaké služby a za jakou cenu v cloudu nasazují, může rychle dojít k překročení nastaveného finančního limitu. Podobně tomu může být i při změně firemních plánů, které ovlivní množství nasazování zdrojů a může tak dojít k nenaplnění očekávané cloudové spotřeby, která byla předplacena.

Rizika spojená s se správnou nákladů se budou mezi společnostmi lišit, nicméně nejčastější společná rizika jsou:

Kontrola budgetu – bez kontroly limitu výdajů se může částka za náklady v cloudu dostat k astronomickým hodnotám.

Řešení: Nastavení budget limitů v Azure Cost Management + Billing.

Utilizace – většinou jde o nevyužívání zdrojů dle jejich kapacity nebo předkoupení zbytečného množství zdrojů, které pak nejsou stejně využívány.

Řešení: Sledování využívání zdrojů pomocí Azure Monitor nebo použití auto-scalingu.

Výdajové anomálie – nečekaně objevující se vysoké výdaje mohou být důsledkem špatného nastavení nebo nesprávného využívání služby.

Řešení: Nastavení alertů na Budget limit, které vás informují o překročení limitní částky.

Předimenzované zdroje – při nasazení zdrojů v Azure se může stát, že počáteční konfigurace služby/zdroje převyšuje nároky na běžící aplikaci nebo virtuální stroj. Tyto přebytky mohou tvořit značnou část měsíčních nákladů.

Řešení: Sledování využívání zdrojů v Azure Monitor a v případě nevyužívané kapacity snížení SKU služby.

Jak bylo zvykem v předešlých disciplínách, tak i zde v Cost Management disciplíně je potřeba sledovat metriky, díky kterým jsme schopni identifikovat rizika zmíněná výše. Níže uvedené metriky jsou ty nejdůležitější, které bychom měli sledovat.

Metrika	Popis
Roční výdaje	Celkové roční náklady na služby provozované v cloudu.
Měsíční náklady	Celkové měsíční náklady na služby provozované v cloudu.
Odhad nákladů versus opravdové náklady	Poměr vykazující rozdíl mezi odhadovanými náklady a skutečnou spotřebou.
Míra adopce nákladů	Rozdíl v procentech nákladů, které se liší měsíc od měsíce. Zda lze sledovat nárůst nebo pokles v nákladech.
Akumulované náklady	Celkové nahromaděné denní náklady počínaje začátkem měsíce.
Nákladové trendy	Porovnání nákladových trendů oproti stanovenému limitu. Sledování nákladů v čase, tzv. spending peeks – období kdy jsou náklady nejvyšší.

Pokud se v rámci analýzy podařilo úspěšně identifikovat nákladové metriky, tak je to pouze první krok k úspěchu. Další krokem by mělo být nastavení tolerančních indikátorů. Jde o to, že se musí definovat určitá hranice, která při překročení vyvolá reakci, například:

Metrika – Sledování měsíčních nákladů.

Toleranční indikátor – Limit měsíčních nákladů – Společnost si může dovolit náklady na cloudový provoz ve výši 150 000 kč měsíčně.

Akce při překročení stanoveného limitu – Pokud společnost identifikovala vyšší měsíční náklady, je potřeba udělat jejich analýzu (určitá investice do disciplíny Cost Management). To znamená zjistit za jaké služby se nejvíce utrácí, kontaktovat vlastníky daných zdrojů a analyzovat jejich potřeby. Zdali opravdu nutně potřebují například další virtuální stroj, který stojí 10 000 kč měsíčně.

Tento plán by se měl definovat pro každou metriku, kterou si společnost stanovila. Díky tomu bude zajištěn plynulý proces, který ačkoli se to nezdá bude zvyšovat úroveň této implementované disciplíny ve společnosti.

Důležitou součástí jsou cloudové nástroje nebo služby, které pomáhají při sledování, nastavování nebo analýze stanovených cílů pro každou disciplínu. Jinak tomu není ani v Cost Management disciplíně, kde pomáhají následující nástroje:

Doporučené techniky pro optimalizaci nákladů v Azure najdete v mém článku – Jak optimalizovat Azure infrastrukturu?

Na obrázku níže je praktická ukázka, jak může vypadat nastavení budget limitu s několika limity upozornění na výši spotřebovaného kreditu. Po každém překročení stanoveného upozornění přijde zpráva na nastavenou emailovou adresu. Lze vidět i automatický budoucí výpočet nákladů, pokud by trend spotřeby kreditu pokračoval rychlostí jako ke konci měsíce.

V příštím článku této série se můžete těšit na předposlední disciplínu Azure Governance a tou je Identity Baseline. Zjistíte, jak se chovat k firemním identitám v cloudu, jaká hrozí rizika a opět jaké nástroje mohou pomoci s adaptací této disciplíny.

Zdroj: https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/govern/cost-management/

Published by Oldřich Šrubař on 14/03/2022 | Permalink

Orphaned resources – cleanup your cloud!

Many of you are using Azure every day, have you ever stopped and thought about to make a cleanup of your cloud environment? If not, you should do that because there is many reasons behind why to do this. I like Azure Governance approaches and one of them is cutting off the cost for cloud service – understand that as cost optimization 😊 and make infrastructure and resources well-arranged. When you often deploy and remove resources for testing or development it can happen that some parts of resources will stay in your environment alone – so called orphans. As a nice example is deployment of virtual machine in Azure. Basically virtual machine needs resource group and virtual network where it will be deployed, then as a core parts NIC interface, sometimes public IP, definitely some managed disks and network security group. Quite lot of resources but needed ones!

What happens when you just remove VM from the portal? Mostly virtual machine itself is removed but the rest like NIC interface, public IP, managed disk stays in your subscription:

The fact is that you still pay for some of these resources – managed disks, public IPs and you definitely don’t want to pay for this! The rest of resources is for no cost but you also don’t want to have mess in growing environment, right?

To have a good overview of such “orphaned” resources I am using workbook which I created with few simple Kusto queries. It will tell me which resources are left in environment alone and I can think about their deletion:

Queries which I used in this workbook:

DISKs

Resources
| where type has "microsoft.compute/disks"
| extend diskState = tostring(properties.diskState)
| where managedBy == ""
or diskState == 'Unattached'
| project id, diskState, resourceGroup, location, subscriptionId

NICs

Resources
| where type has "microsoft.network/networkinterfaces"
| where properties !has 'privateLinkConnectionProperties'
| where properties !has 'virtualmachine'
| project id, resourceGroup, location, subscriptionId, properties.macAddress

NSGs

Resources
| where type =~ 'microsoft.network/networksecuritygroups' and isnull(properties.networkInterfaces) and isnull(properties.subnets)
| project Resource=id, resourceGroup, subscriptionId, location

Static PIPs

resources
| where type has "microsoft.network/publicipaddresses"
| where properties.publicIPAllocationMethod == "Static"
| where properties !has "ipConfiguration"
| project id, name, subscriptionId, location, resourceGroup

Dynamic PIPs

resources
| where type has "microsoft.network/publicipaddresses"
| where properties.publicIPAllocationMethod == "Dynamic"
| where properties !has "ipConfiguration"
| project id, name, subscriptionId, location, resourceGroup

You can find template for this workbook on my Github. You can import it or just copy/paste code when creating new Template Specs in Azure:

If you want to extend this workbook with your own Kusto queries for another resources which you would like to monitor if they left alone, then just simply edit workbook in Azure monitor and let me know what to add eventually in comments on my Github so I can add it directly to template.

There are of course other options how to automatically remove these leftovers and one of them is to check the options for auto-delete for disks, NIC, public IP when you are creating VM in Azure portal:

Another option should be adding the parameters into ARM templates if you deploy machines via DevOps or by TerraForm and other automatization tools.

Hopefully this article will help some of you to reduce some costs and make your environment better well-arranged for easy management.

Published by Oldřich Šrubař on 21/02/2022 | Permalink

Jak optimalizovat Azure infrastrukturu?

Představte si, že začínáte s Azure cloudem a nemáte vůbec žádné zkušenosti, nicméně je to pro vás zajímavá výzva a chcete do toho jít. Velmi pravděpodobný scénář bude ten, že si koupíte předplatné Azure, vytvoříte nějakou skupinu zdrojů a do ní začnete umisťovat všechny zdroje, které potřebujete. Pro začátek a otestování funkčnosti řešení je to akceptovatelný postup. Nicméně pokud tento způsob implementace nezměníte a nezačnete systematicky a efektivně plánovat, tak se při rozrůstajícím prostředí začnou objevovat určité problémy. Například se může stát, že ve shluku všech zdrojů budou již některé zbytečné a nepoužívané, jenže vy to nebudete vědět, protože nebudete mít přehled o tom k čemu jsou a pro co jsou využívány. Výsledkem je špatný přehled a vysoká částka na faktuře, kterou dostanete každý měsíc za využívání zdrojů v Azure. Toto byl pouze jeden z mnoha příkladů proč optimalizovat, níže se podíváme na pár tipů, jak optimalizovat a jak nám s tím může pomoci Well-Architected Framework spolu s Azure Governance.

A screenshot of a cell phone Description automatically generated

Jak je z výše uvedeného obrázku patrné, tak se tyto dvě oblasti v některých bodech částečně prolínají. Well-Architected Framework nám v podstatě říká, jak správně budovat infrastrukturu v Azure už od počátku, jak vše správně naplánovat při vytváření architektury a na co si dát pozor. Azure Governance je všeobecně správné řízení Azure cloudu, to znamená, že už pravděpodobně nějaké zdroje máte a nyní je čas je začít správně řídit a bezpečně spravovat včetně jejich nákladů na provoz.

Správa a výběr zdrojů

Jak jsem již na začátku nastínil, sledování zdrojů a jejich správa je extrémně důležitá disciplína. Pokud vám uživatelé nebo administrátoři chrlí hromady zdrojů do subskripce, tak je na místě začít tím nejjednodušším, a to je označování zdrojů pomocí tagů. Tagy mohou obsahovat informace o oddělení, vlastníkovi zdroje, prostředí, do kterého daný zdroj spadá a spoustu dalších parametrů, které jsou jen na vás. Použití tagů je skvělý způsob, jak agregovat a seskupovat prostředky mnoha způsoby, data lze také použít pro zpětné zúčtování. Neméně důležitým faktorem je také správný výběr úrovně služby a velikost virtuálního stroje, který musí odpovídat stanoveným požadavkům. Pokud dobře vyberete velikost virtuálního zdroje bude to mít okamžitý efekt na možnosti, kapacitu a výkon vašich služeb v Azure, především pak na cenu, která je s typem virtuálního stoje úzce spjatá. Velikost a úroveň služby virtuálního stroje nemusí být permanentní stav, v průběhu času a změn požadavků, se může velikost změnit, proto je potřeba se efektivně přizpůsobovat správným výběrům velikostí.

Plánování pro vypnutí systémů

Pokud máte nějaké virtuální stroje, které se používají pouze periodicky – v určitém čase, ale jsou neustále v provozu, tak zbytečně plýtváte penězi. Ideálním řešením je tyto servery vypínat právě v době kdy nejsou potřeba, čas, po který je server vypnutý šetří vaše náklady za výpočetní kapacitu. Hezkým kandidátem je například prostředí pro development, které se většinou využívá pouze během klasické pracovní doby, takže přes noc mohou být servery vypnuté. Existuje několik možností, jak vypínání zdrojů řešit:

Pro běh serverů pouze v čase, kdy to potřebujeme, můžeme využít službu Azure Automation.
Pro jednorázové automatické vypnutí virtuálního stroje můžeme využít nativní funkci auto-shutdown.
Manuální vypnutí serveru, když víme že už jej nebudeme ten den potřebovat. Zde je nutné zmínit, že je potřeba použít nativní Stop VM z ovládacího panelu virtuálního stoje v Azure, jinak nebude VM dealokována a budou stále účtovány náklady.

Spot instance

Jde o zajímavý typ virtuálních strojů, které běží, pokud má Azure nějaké nevyužité kapacity, které potřebuje zaplnit. V případě, že Azure potřebuje kapacitu zpět, tak jsou virtuální stoje vypnuty a dealokovány nebo úplně smazány. Při dealokaci stále platíte za úložiště, které virtuální stoje využívají, při smazání je vše odebráno včetně disků a neplatíte nic. Teď si určitě říkáte: „K čemu je to vlastně dobré?“ Toto řešení je možné používat pro testovací či vývojářské účely, zpracování batch procesů, kterým nevadí přerušení, pro velké výpočetní operace a další. V porovnání s normálními zdroji jsou spot instance za zlomek ceny, což je jejich největší výhoda.

Rezervované instance

Jsou Azure zdroje, které si můžete rezervovat na určitou dobu, konkrétně na jeden nebo tři roky. Díky rezervaci získáte okamžitou slevu až 72% oproti Pay-as-you-Go. V Azure si můžete rezervovat tyto typy zdrojů:

Virtuální stroje Windows a Linux
Azure SQL Database
Azure Cosmos DB
Azure Synapse Analytics
Azure Storage

Využívání „managed“ služeb

Pokud je to možné doporučujeme využívat tzv. „Managed Services“. Výhodou těchto služeb je, že kombinují nižší náklady za zdroje spolu s nižšími operativními náklady za údržbu. Důvodem je to, že se nemusíme starat o nižší vrstvy infrastruktury pod naší aplikací. Neřešíte patchování, instalaci aplikací, správu operačního systému a další komponenty, které jsou nutné pro běh vaší aplikace. Jedním z příkladů je Azure SQL Database – můžete nasadit jednu i více databázových instancí, a přitom neřešíte na jakém operačním systému běží, aktualizace, zálohování, vysokou dostupnout a jiné. Vše je obsaženo automaticky v dané službě. Azure App Service je další spravovanou službou, která je navržena k hostování webových aplikací. Místo nasazení a správy virtuálních počítačů pro vaše webové aplikace můžete své aplikace nasadit přímo do App Service a dramaticky snížit operativní náklady, které jsou vyžadovány pro údržbu infrastruktury.

Optimalizace nákladů na Azure SQL databáze

Když vytváříte Azure SQL databázi, tak musíte vybrat jednu z několika možností, která stanovuje výkon služby. Každá úroveň poskytuje určitý výkon v databázových transakčních jednotkách (DTU) nebo počtu virtuálních jader (vCore). Pokud máte databázi, která má stabilní zatížení v čase, tak je celkem jednoduché vybrat příslušnou úroveň výkonu. Jakou úroveň však vybrat, pokud máte databáze, které mají nekonstantní zatížení v různých časech během dne? V tomto případě může pomoci „elastic pool“.

SQL databázové elastic pooly jsou jednoduchým a nákladově efektivním řešením pro správu a škálování několika databází, které mají různé a nepředvídatelné nároky na zatížení. Databáze v elastic poolu jsou na jednom Azure SQL Database serveru a sdílejí stanovený počet prostředků za stanovenou cenu. Charakteristický model pro toto řešení je větší množství databází s nízkým průměrem zátěže, ale s relativně nepravidelnými zátěžovými špičkami.

K dispozici jsou celkem tři elastic pooly:

Zdroj: Microsoft Docs

Sledování nákladů a tipů Azure Advisor

Využívání služby Azure Cost Management + Billing vám poskytne přehled o tom, za co přesně utrácíte, a také o nevyužitých zdrojích. Jsou sledovány celkové výdaje, náklady podle služeb a náklady v průběhu času. Můžete se proklikávat až do podrobností jednotlivých zdrojů a získat informace o typech prostředků a instancích. Své přehledy nákladů můžete také rozdělit podle organizace nebo nákladového střediska, a to díky již dříve zmíněným tagům.

Výborným pomocníkem je také služba Azure Advisor, která vám automaticky napovídá, co udělat jinak nebo jak danou službu zlepšit za účelem zvýšení výkonu a dostupnosti, zabezpečení či snížením nákladů.

V případě potřeby doporučuje změnu velikosti virtuálního počítače.
Identifikuje nepoužívané linky Azure ExpressRoute a nečinné virtuální brány sítě.
Doporučuje, kdy zvážit nákup rezervovaných instancí, ve chvíli, kdy by to mohlo být nákladově efektivnější než použití instancí typu pay-as-you-go.

Pokud se při sledování a shromažďování nákladů zjistí nějaká výdajová anomálie, měli byste ji nahlásit ihned vlastníkům daných zdrojů nebo zúčastněným stranám. Aktivní zapojení těchto stran může zajistit identifikaci potencionálního překročení nákladů dříve, než se stane problematickým. Transparentnost při komunikaci se zúčastněnými stranami je důležitá, aby mohli plně porozumět veškerým technickým nebo obchodním rozhodnutím, která způsobila neobvyklé náklady.

Věřím, že výše uvedené tipy dokážou ušetřit alespoň nějakou část financí, které byste jinak museli zaplatit. Zkoušejte optimalizovat po malých částech a hlavně tam, kde to opravdu dává smysl. Zaměřte se na služby, za které platíte nejvíce, tam totiž existuje pravděpodobnost, že půjde nějakým způsobem minimalizovat náklady.

Published by Oldřich Šrubař on 14/09/2021 | Permalink

OLDŘICH ŠRUBAŘ

Nejnovější příspěvky

Nejnovější komentáře

Archivy

Rubriky

Základní informace