Jak jsme snížili cloudové náklady o 41 % pro fintech klienta bez výpadku
Účet za AWS tiše narostl z 5 000 na 14 000 EUR měsíčně, aniž by odpovídajícím způsobem narostl provoz. Tady je, kam peníze odcházely a co jsme s tím udělali.
Jeden z našich fintech klientů za námi přišel s problémem: jejich účet za AWS tiše narostl z 5 000 EUR na 14 000 EUR měsíčně za 18 měsíců, bez odpovídajícího nárůstu provozu. Systém nebyl pomalý — ale byl drahý. Požádali nás o nalezení úspor bez dopadu na dostupnost.
Strávili jsme dva týdny profilováním, optimalizací a restrukturalizací jejich infrastruktury. Výsledek: 41% snížení nákladů s měřitelně lepšími odezvovými časy. Zde je popis toho, co jsme zjistili a opravili.
Proč účty rostou samy od sebe
Žádná z položek na faktuře nevznikla omylem. Každou někdo kdysi zapnul s dobrým důvodem: replikaci kvůli havarijnímu plánu, větší databázi před očekávanou kampaní, další kontejner kvůli jednorázové dávce. Důvody mezitím zmizely, nastavení zůstalo.
Cloud je v tomhle zrádnější než vlastní server. Server je vidět, stojí v racku a někdo za něj zodpovídá. Instance zapnutá na pět minut vypadá jako nic — jenže běží dál, osmnáct měsíců, a na faktuře se schová mezi dvaceti dalšími položkami. Proto se růst skoro nikdy nevysvětlí jedním velkým viníkem: jde o deset drobností, které se sečetly.
Audit: Kam odcházely peníze
Prvním krokem bylo namapování každého eura na konkrétní službu. Použili jsme AWS Cost Explorer s tagováním na úrovni zdrojů a identifikovali tři hlavní nákladové položky:
- RDS (PostgreSQL): 4 200 EUR/měsíc — instance db.r6g.2xlarge běžící 24/7
- EC2/ECS: 5 100 EUR/měsíc — 12 permanentně běžících kontejnerů ve 3 službách
- Datové přenosy + S3: 2 800 EUR/měsíc — cross-region replikace, kterou už nepotřebovali
- Ostatní (CloudWatch, Lambda atd.): 1 900 EUR/měsíc
Samotná databáze tvořila 30% účtu — a byla dramaticky předimenzovaná.
Měření trvalo pět pracovních dnů a bylo to nejdůležitějších pět dnů celé práce. Dokud nevíte, která služba kolik stojí, každá úprava je sázka. Část zdrojů navíc neměla žádné tagy, takže jsme je dohledávali podle času vzniku a podle toho, kdo je v týmu zakládal — proto doporučení tagovat všechno stojí na prvním místě v závěru článku.
Oprava 1: Správné dimenzování databáze
RDS instance měla 64 GB RAM, ale špičkové využití paměti nikdy nepřekročilo 18 GB. CPU mělo průměr 12% se špičkami na 35% během dávkových úloh.
Migrovali jsme na db.r6g.large (16 GB RAM) a přesunuli dávkové zpracování do hodin mimo špičku pomocí naplánovaných ECS tasků. Také jsme zapnuli RDS Proxy pro connection pooling — což ve skutečnosti zlepšilo latenci dotazů díky snížení režie spojení.
Zmenšení databáze je přitom změna, které se týmy bojí nejvíc — a zbytečně. Instanci jsme měnili v neděli ráno, restart trval čtyři minuty a návrat k původní velikosti by byl stejně rychlý. Riziko tu není ve výkonu, ale v tom, že nikdo neví, kolik paměti systém opravdu potřebuje. Proto měření předchází zásahu.
Úspora: 2 800 EUR/měsíc
Oprava 2: Auto-scaling místo trvalého běhu
Všech 12 kontejnerů běželo 24/7, ale analýza provozu ukázala jasné vzorce: 80% požadavků přicházelo mezi 7:00 a 22:00 CET, s prudkým poklesem přes noc. Víkendový provoz byl na 40% objemu pracovních dnů.
Nakonfigurovali jsme ECS auto-scaling na základě metrik CPU a počtu požadavků: minimum 3 kontejnery mimo špičku, škálování až na 12 v pracovních hodinách. Také jsme sloučili dvě mikroslužby, které vždy škálovaly společně, do jedné služby — čímž se výchozí počet kontejnerů snížil z 12 na 8.
Sloučení dvou služeb do jedné je proti běžnému instinktu „čím víc mikroslužeb, tím lépe“. Jenže služby, které se vždy spouštějí i vypínají společně, nejsou dvě nezávislé části systému — jsou to dvě poloviny jedné, které platíte dvakrát a mezi nimiž navíc tečou data po síti. Po sloučení zmizela nejen jedna sada kontejnerů, ale i část latence.
Úspora: 1 900 EUR/měsíc
Oprava 3: Eliminace zbytečných datových přenosů
Systém replikoval veškerá data v S3 do druhého regionu — disaster recovery nastavení z doby prvotního spuštění. Klient ale mezitím přešel na multi-AZ architekturu v rámci eu-central-1, čímž se cross-region replikace stala zbytečnou. Nikdo ji nevypnul.
Odstranili jsme replikaci, vyčistili 2,3 TB duplicitních dat a přepnuli zbývající S3 přístupy na VPC endpointy, abychom se vyhnuli poplatkům za datové přenosy.
Datové přenosy jsou nejčastější slepá skvrna. Za uložená data platíte viditelně a za výpočetní výkon taky, ale přenos mezi zónami, regiony a ven do internetu se objevuje v položkách, které nikdo nečte. U tohoto klienta šlo o pětinu účtu — a ani jeden gigabajt z ní neplnil žádnou funkci.
Úspora: 1 100 EUR/měsíc
Výsledky
Před: 14 000 EUR/měsíc
Po: 8 200 EUR/měsíc
Úspora: 5 800 EUR/měsíc (41%)
Ale čísla vypovídají jen o části příběhu. Odezvové časy se ve skutečnosti zlepšily o 15% — částečně díky connection poolingu přes RDS Proxy, částečně díky sloučeným službám s menší síťovou režií.
Stojí za to si to pojmenovat: optimalizace nákladů a optimalizace výkonu nejdou proti sobě tak často, jak se čeká. Předimenzovaná infrastruktura bývá i špatně nastavená, protože výkon „nějak stačí“ a nikdo se nedívá dál. Jakmile začnete měřit kvůli penězům, najdete i úzká hrdla.
Poučení pro jakékoli cloudové prostředí
1. Tagujte vše
Nemůžete optimalizovat to, co nemůžete měřit. Každý zdroj by měl být otagován projektem, prostředím a týmem. Bez tagů je přiřazování nákladů pouhým odhadováním.
2. Revidujte Reserved Instances čtvrtletně
Náš klient platil on-demand ceny za instance, které běžely 24/7. Stabilní workloady jsme převedli na 1leté Reserved Instances bez zálohy — což přineslo dalších 25% úspor na těchto zdrojích.
3. Nastavte cenové alerty dříve, než je budete potřebovat
AWS Budgets s alertem na 80% a 100% cílových výdajů by zachytily tento růst o měsíce dříve. V rámci optimalizace jsme nakonfigurovali alerty pro každé nákladové středisko.
4. Plánujte nekritické workloady
Vývojová a staging prostředí nemusí běžet o víkendech. Naplánované spouštění a zastavování neprodukčních prostředí ušetřilo dalších 400 EUR/měsíc, které nejsou ani zahrnuty ve výše uvedených číslech.
5. Přiřaďte účet konkrétnímu člověku
Dokud je faktura „nákladem IT“, nikdo ji nečte. Jakmile má každé nákladové středisko svého vlastníka, který dostává měsíční přehled, růst se zastaví sám. Tohle je jediné opatření ze seznamu, které nestojí ani hodinu práce.
Co dělat, aby se to nevrátilo
Jednorázový audit uspoří peníze na čtvrt roku. Pak se vrátí stejný mechanismus: dočasné nastavení, které zůstane. Proto má smysl udělat z revize rutinu — čtvrtletní kontrola tagů, nevyužitých zdrojů a rezervací zabere půl dne a udrží výsledek.
U klientů to většinou řešíme jedním z dvou způsobů. Buď převezmeme provoz a nasazování i s hlídáním nákladů, nebo doplníme váš tým o DevOps inženýra, který to dělá zevnitř. Když si nejste jistí, co z toho dává u vás větší smysl, začněte auditem — výstupem je seznam, který se dá ocenit.
Závěr
Optimalizace cloudových nákladů není o škrtání — je o eliminaci plýtvání. Většina firem má předimenzovanou infrastrukturu, protože ji nastavily pro špičkovou zátěž a nikdy ji nerevidovaly. Cílený dvoutýdenní audit typicky odhalí 30–50% úspor. Otázkou není, zda utrácíte víc, než musíte — ale kolik.
Časté otázky
Jak dlouho takový audit trvá?
U prostředí velikosti našeho klienta dva týdny: první týden měření a tagování, druhý úpravy a ověření. U větších nebo roztříštěných prostředí počítejte se třemi až čtyřmi týdny — nejvíc času sežere zjišťování, kdo co vlastně používá.
Hrozí při optimalizaci výpadek?
Riziko existuje a dá se ohlídat. Změny jsme pouštěli po jedné, mimo špičku a s možností okamžitého návratu: změna velikosti instance RDS je restart v řádu minut, auto-scaling se zapíná postupně s vysokým minimem. U tohoto klienta výpadek nenastal, odezvy se naopak zlepšily o 15 %.
Kolik se dá reálně ušetřit?
Z naší zkušenosti 30–50 % u prostředí, které nikdo systematicky nerevidoval. Pokud už máte tagování, rezervované instance a škálování, bude úspora menší — zato se najde spíš v architektuře než v nastavení.
Má smysl optimalizovat, když plánujeme přepis systému?
Ano, pokud je přepis vzdálený víc než půl roku. Vypnutí nepotřebné replikace nebo zmenšení databáze je práce na dny a ušetřené peníze přepis částečně zaplatí. Nemá smysl investovat do hluboké přestavby infrastruktury, kterou za tři měsíce zahodíte.
Pracujete i s Azure a Google Cloud?
Ano. Principy jsou stejné — měřit, zmenšit, naplánovat, hlídat — liší se jen nástroje a názvy služeb. Největší rozdíl bývá v cenách za datové přenosy, kterých si všimne málokdo.