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.

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.