Čtyři místa, kde v Cloudu tečou peníze (a jak jsme je našli)
PŘEČÍST ČLÁNEK
Cloud se účtuje podle toho, co máte zapnuté – ne podle toho, co používáte. To je rozdíl, který v prvních měsících provozu nikdo nepozná. Po roce nebo dvou už je z něj položka, na kterou se nikdo neptá, protože „to tak prostě je".
Většina firem přitom nepřeplácí kvůli jedné velké chybě. Obvykle je to čtyři nebo pět malých věcí, které se nasčítaly: prostředí, které někdo nasadil pro test a zapomněl vypnout. Tier, který byl v den návrhu správný a dnes už není. Logy, které se ingestují každý den a nikdo je nečte. Virtuální stroje, které běží i v noci a přes víkend.
Ukazujeme čtyři konkrétní případy z naší praxe: čtyři různé zdroje plýtvání se stejným mechanismem v pozadí. Absolutní částky se pohybují od stokorun po tisíce eur měsíčně, protože velikost úspory závisí na velikosti prostředí. Ten mechanismus je ve všech případech stejný a je velmi pravděpodobné, že alespoň jeden z nich máte i vy.
Někdy přitom platíte za věci, které v Azure portálu nenajdete vůbec: k jednomu takovému případu se dostaneme hned u prvního příkladu.
Typ plýtvání: zdroj, který se fakturuje, ale není vidět.
Klient (e-shop působící na několika evropských trzích) vypnul funkci AI detekce vizuální podobnosti produktů. Očekávání bylo přímočaré: služba neběží, náklady spadnou. Jenže infrastruktura zůstala a náklady také. Vstupní virtuální stroje do prostředí byly navíc výrazně naddimenzované a produkční PostgreSQL databáze, do které se ukládala data pro AI zpracování, běžela nevyužitá odhadem půl roku.
To je běžný nález a odpovídala mu i většina úspory. Zajímavější bylo to, co jsme našli navíc.
Vytáhli jsme granulární data z Azure Cost Management a udělali nad nimi oboustranný full outer join proti tomu, co reálně existovalo v Azure portálu. Vypadla nám z toho jedna testovací PostgreSQL databáze, která se fakturovala, ale v portálu nebyla vidět vůbec.
Šlo o chybu na straně Azure: resource uvízl v mezistavu mezi smazáním a dealokací. Protože PostgreSQL je PaaS služba, na páteřní infrastrukturu Microsoftu nevidíme a vypnout jsme to nemohli sami. Muselo to odstranit až Microsoft na straně své infrastruktury; od nahlášení anomálie to trvalo dva dny.
Výsledek: úspora přibližně 1 000 € měsíčně. Skrytá databáze byla z toho jen menší část: hodnota není v její velikosti, ale v tom, že bez porovnání fakturačních dat s reálným stavem prostředí by se na ni nepřišlo vůbec. Platila by se dál.
Co si z toho vzít: když vypínáte službu, ověřte si výsledek na fakturačních datech, ne v portálu. Nejsou to nutně stejná čísla.
Typ plýtvání: špatně zvolený tier a data, která nikdo nečte.
Tady šlo o rychlou analýzu, včetně úvodního meetingu asi čtyři hodiny práce. Klient (technologická firma s API produktem) měl měsíční náklady v řádu vyšších tisíců korun a chtěl vědět, jestli je to v pořádku. Nebylo.
Identifikovali jsme potenciál snížení celkových nákladů na Azure o 55,8 %, rozložený do tří opatření.
Log Analytics. Denně se ingestovala provozní data, která nikdo nepoužíval. Po vytipování toho, co má smysl si nechat, a odstranění zbytku vycházela úspora na 62 % nákladů této služby, největší jednotlivá položka celé analýzy.
API Management na Consumption tier. Provoz byl malý a nepotřeboval „always on" kapacitu, za kterou se u standardních tierů platí. Na Consumption tieru by se přitom pravděpodobně vešel do měsíčního free tieru, tedy s úsporou blížící se 100 %.
Zombie disky. Několik nepřipojených disků za 28 € měsíčně, existujících přibližně rok. Nulová hodnota, stoprocentní úspora.
Poznámka k výsledku: šlo o analýzu a doporučení. Zpětnou vazbu o implementaci jsme nedostali, takže mluvíme o identifikovaném potenciálu, ne o realizované úspoře.
Co si z toho vzít: Developer a Consumption tiery se často nezvažují ve fázi návrhu, protože v té chvíli není jasné, jaký provoz přijde. Problém je, že přepnutí na ně není descale: resource se musí vytvořit znovu. Čím později to řešíte, tím dražší je migrace. Vyplatí se u toho být od začátku.
Typ plýtvání: platíte čas, kdy nikdo nepracuje.
Klient z finančního sektoru používal Azure Virtual Desktop (Windows stroje, přes které se zaměstnanci dostávali k databázím a souborům v cloudu, protože firemní notebooky neměly přístup do virtuální sítě Azure). Stroje běžely dál i po konci pracovní doby, protože je nikdo nevypínal.
Nejjednodušším řešením je tvrdý rozvrh a ten bývá zároveň nejnepříjemnější. Komukoli, kdo potřebuje pracovat déle, totiž spadne stroj pod rukama. Nastavili jsme to jinak:
Technicky to běží na vestavěné logice VM, která vytváří Logic App; tu jsme si následně rozšířili. Kromě vypínání jsme snížili výkon pracovních stanic, s tím, že pokud někomu přestane vyhovovat rychlost systému, ozve se. Neozval se nikdo. U nově vytvářených instancí jsme rovnou zavedli spotové instance.
Výsledek: úspora přibližně 3 500 € ročně. Implementace včetně schválení trvala dva dny.
Vedlejší efekt: opatření bylo dobře přijato u IT ředitele a vyústilo v zadání na optimalizaci a monitoring celého tenantu. Malá věc, která ukázala, že se tímhle směrem vyplatí jít dál.
Co si z toho vzít: vypínání nemusí být na úkor uživatelů. Rozdíl mezi „stroj ti spadne v šest" a „stroj se ti v šest vypne, pokud si neřekneš jinak" je z hlediska nákladů nulový a z hlediska přijetí ve firmě zásadní.
Typ plýtvání: platforma, která nesedí na to, co s ní děláte.
Poslední případ je z našeho vlastního prostředí. Provozovali jsme datové pipeline v Keboole a přešli jsme s nimi na Azure Data Factory. Náklady spadly na přibližně čtvrtinu původní částky.
Absolutní čísla jsou tu malá: šlo o stokoruny měsíčně. Zajímavý je mechanismus, protože ten škáluje.
Rozdíl je v tom, na čí infrastruktuře běží compute. V Data Factory řídíme výpočet nad vlastní Azure infrastrukturou, musíme se starat o servery, což ale umíme automatizovaně, a platíme řádově méně, u developerského prostředí zvlášť, protože tam jdou použít spotové instance. Druhá věc: v Keboole se nedá zapnout oddělené dev prostředí, takže každá změna se platí v reálných produkčních kreditech.
Cena ale byla spíš trigger než hlavní důvod. Podstatnější bylo, že Data Factory je jádrová technologie Azure a integruje se s Azure Functions, vaulty, databázemi i API. Že jsme dostali lepší datový model postavený na Azure SQL. A hlavně že je nativně napojitelná na Git a Azure DevOps: CI/CD a DevOps zralost jsou u uzavřeného SaaS řešení strop, na který dřív nebo později narazíte.
Funkčně to vychází spíš na poměr 1:1,3, protože jsme při migraci zároveň odstranili několik neduhů původního řešení: generování orphan dat, správu secretů a deduplikaci.
Na co si dát pozor: všechna API mají limity a buď je ošetříte, nebo na ně narazíte v produkci. Proto testování pipeline v Data Factory trvá delší dobu, ideálně klidně 14 dní, aby se odchytaly špičky, přetížení infrastruktury i limity vlastních API. Tenhle benchmarking se pravidelně obětuje ve prospěch „time to market". Žádná datová pipeline se nedá dopředu odhadnout bez telemetrie.
Kombinujeme dvě věci. Zkušenost s Azure, tedy znalost toho, které služby mají jaké tiery, kde se dá platit za spotřebu místo za dostupnost a co se dá vypnout, aniž by to někdo poznal. A vlastní analýzu nad granulárními fakturačními daty, která jde do většího detailu než standardní přehledy v Azure portálu.
Ten druhý bod je důležitější, než se zdá. Fakturační data a to, co vidíte v portálu, nejsou vždy totožné. Analýza samotná je otázka hodin, ne týdnů.
Ve všech čtyřech případech platí totéž: šlo o rozhodnutí, která byla v den svého vzniku správná, ale později správná být přestala. Nikdo je nerevidoval, protože se zdálo, že k tomu není důvod: Azure funguje, faktura přijde, platí se.
Základní analýza je otázka hodin až dnů. Výstupem je konkrétní seznam opatření s vyčíslenou úsporou a odhadem náročnosti.
Podíváme se na vaše Azure prostředí a řekneme vám, kde jsou rezervy. Základní analýza je otázka hodin až dnů, výstupem je konkrétní seznam opatření s vyčíslenou úsporou a odhadem náročnosti. Rozhodnutí, co z toho implementovat a zda pokračovat s dalšími scénáři, zůstává na vás.
.png)
.jpg)
