Náklady za AWS pod kontrolu

V Zonky provozujeme vývojovou, testovací a část produkční infrastruktury v cloudu, konkrétně v AWS. Pomáhá nám to být flexibilní a plynule růst. Nicméně, zatímco jsme rostli, měnili architekturu, spouštěli nové testovací prostředí a dělali další psí kusy, začínala nám nenápadně svítít varovná kontrolka ve formě vysokého účtu za AWS. Během 14 měsíců náš účet za AWS narostl o neskutečných 1 000%. Očekávali jsme, že tato nákladová položka bude růst, ale takhle strmý růst nikoliv. Museli jsme proto dostat náklady za cloud pod kontrolu. V tomto článku se s vámi podělím o to jak se nám to povedlo.

Prvním krokem byl průzkum nákladů a jejich rozklíčování v Bill Details v AWS — chtěli jsme vědět, za co přesně platíme takovou dardu. Brzo jsme ale zjistili, že nám nestačí vědět, že platíme tisíce dolarů za EC2, stovky za data transfer apod. Bez kontextu jsou tahle čísla bezcenná. Rozhodli jsme se proto přidávát jednotlivým resourcům v AWS Tagy, podle kterých jde analyzovat konkrétněji. Vše, co souviselo s testovacím prostředím, dostalo tag costUnit: test, produkce zase costUnit: production. Nakonec jsme šli ještě hlouběji až na úroveň toho k čemu daný resource slouží např. Docker, vývojářský use case. Díky tomu jsme mohli začít vytvářet reporty v Cost Exploreru. To je přímo nástroj na analýzu nákladů od AWS.

No jo, reporty s čísly by byly, ale co s nimi? Dívat se, jak čísla každý měsíc rostou? Cost Explorer není úplně ideální nástroj pro deep dive analýzu. Začali jsme patrát a dostali jsme se k nástroji CloudCheckr na cost management. Nastavili jsme integraci CloudCheckeru s naším AWS accountem a čekali, co z něj vypadne. Vypadlo toho fakt hodně. Tak namátkou:

• Měli jsme idle instance, tzn. nikdo je fakticky nepoužíval, CPU load byl okolo 0.5%.
• Některé instance byly zbytečně naddimenzované
• Doporučili nám přejít na novější typy instancí, které jsou výkonnější a o trošičku levnější (rovnou nám ukázali částku, kterou bychom tímto přechodem ušetřili).
• Vypočítali možné úspory při nákupu několika instanci na rok dopředu (reserved instance).

Tímhle krokem jsme konečně složili naši skládanku a mohli začít efektivně pracovat na cost managementu.

CloudCheckr nás neustále zásobuje doporučeními

A jaké kroky jsme uskutečnili? Začali jsme u buildů. Používáme Jenkins pro buildění zdrojáků, ale jelikož počet vývojářů rostl, rostl i počet pull requestů, které bylo potřeba zbuildit. Ale kde sehnat velký výpočetní výkon za málo peněz? My ho našli v AWS Spot Fleetu. Co je Spot fleet? Amazon nabízí EC2 stroje v několika cenových kategoriích:

• On demand — nejvyšší cenam, pay as you go
• Reserved instance — rezervovaná instance pro vás, která vychází mnohem levněji než on demand, ale zase si jí musíte předplatit minimálně na rok.
• Spot fleet instance — volné instance, které zrovna nikdo v daném datové centru nepoužívá a tak je AWS nabízí se slevou 80–90%. Stroj pak máte k dispozici do doby, než jej AWS bude potřebovat — a neptá se, jestli vám tam zrovna něco běží, prostě si ho vezme, což nám u buildů až tak moc nevadí — když se to stane, tak prostě spustíme build znova na jiném stroji

Ale jak přinutit Jenkins, aby používal AWS Spot fleety jako build slavy? pomocí pluginu https://plugins.jenkins.io/ec2-fleet, který podporuje škálování, tzn. když je ve frontě více buildů, plugin rozjede nové stroje pro buildění a naopak, když špička opadne, stroje opět zahodí. Dnes nám ve špičce běží až 25 strojů typu m4.4xlarge pro Jenkins, mimo špičku to číslo klesá k nule. Zároveň jsme se zaměřili na velikost disků pro tyto buildovací stroje. Storage dělá až 40% nákladů, které platíte za stroje. Všechny stroje měli 500 GB disky. V hlavě jsme měli obvyklou větu lidí z IT: “disky jsou levné”. EBS disky při takovém množství buildovací strojů stojí majlant! Měřením jsme zjistili, že nevyužijem více než 150 GB a hned byl prostor k úspoře.

Od buildů jsme se přesunuli k testovacím prostředím. Někde jsme nakoupili instance na rok dopředu, jinde zase přešli na spot fleety. Když nám docházela inspirace pro další akci typu “cutting cost”, mrknul kolega Marek Sirový do AWS Billu a začal vrtat do vysoké částky u položky Data Transfer. Po chvíli jsme objevili příčinu — Jenkins. Zjistili jsme, že naše Jenkins Slavy sice běží ve stejném regionu jako Jenkins Master. Bohužel ale v jiné AZ (Availability Zone). Každý region má několik availability zones. A my netušili, že se krom přenosu mezi Regiony platí i za data transfer v rámci jednoho regionu mezi AZ. Tahle neznalost nás stála asi $200 měsíčně.

Graf nákladů za naše “personální instance” v AWS. Na počátku dubna jsme změnili typ instance z m3 na t2 s funkcí burst. Před změnou jsme platili $50 / den, dnes okolo $25 / den.

Dnes už máme máme přehled o tom, kolik nás stojí testovací prostředí, kolik nás stojí buildovací infrastruktura. Zároveň máme nastavené alerty, které nás upozorní na neobvyklý cenový nárůst. Každých 14 dnů máme pravidelné review AWS nákladů, pro které jsou insighty z CloudCheckeru nezbytností.

A jaké kroky nás čekají v nejblížší době?

• Chtěli bychom se zbavit EBS disků u větší části testovacího prostředí, včetně jenkinse. AWS propaguje EBS jako spolehlivé uložiště, na kterém vám zůstanou data i v případě, že instance terminuje. Například u Jenkins slaves nebo testovacích prostředí nám na této vlastnosti až tak moc nezáleží. O alternativách k EBS se až tak moc nemluví. Přitom např. ephemeral je uložiště, které je několikrát rychleší než EBS. Vtip je v tom, že instancí, které podporují ephemeral storage je málo a není možné si navolit velikost disku dle svého uvážení. Nedávno se objevila nová instance podporující tento storage m5d.4xlarge, u které máte k dispozici 2 x 300 GB ephemeral. Pro nás jasná volba. Změnou typu instance a jejího storage jsme schopni ušetřit až 50% nákladů pro daný typ clusteru či prostředí.
• Dalším krokem je visualizace nákladů pro celý tým. Kdo byl v našem kanclu, ví, že máme na stěně televize s různými grafy a reporty. V nejbližších dnech tam přidáme informace jako: aktuální účet za AWS, forecast na tento měsíc či celkový účet za minulý měsíc.
• Díky pokročilé automatizaci uvažujeme o dynamickém zapínaní a vypínání či downsize testovacích clusteru. Další dimenze může být K8s, díky kterému poskládáme na větší stroje více malých instancí pro vývojové a testovací účely, které mají typicky minimální CPU footprint.

Cloud cost management je disciplína, která se neustále vyvíjí. Vyplatí se číst, ptát se, studovat, experimentovat a hlavně měřit a visualizovat. Věděli jste například, že můžete ušetřit i tím, že se v AWS přesunete do jiného regionu, ceny se liší i o 50% v závislosti na dle regionu nebo, že na provozu K8s clusteru můžete ušetřit celkem dost peněz?

Jak řešíte náklady na cloud vy? Mimochodem v Zonky mám na starosti SRE tým a rád se s vámi potkám a pokecám nejenom o AWS.