Hlavní navigace

Jak jsme dostali náklady v Amazon Web Services pod kontrolu

26. 7. 2018
Doba čtení: 5 minut

Sdílet

Vývojáři ze služby Zonky.cz prakticky popisují, jak se jim podařilo zkrotit příliš vysoké účty za cloud AWS.

Zonky provozujeme vývojovou, testovací a část produkční infrastruktury v cloudu, konkrétně v Amazon Web Services (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ítit varovná kontrolka ve formě vysokého účtu.

Během 14 měsíců náš účet za AWS narostl o neskutečných tisíc procent. Očekávali jsme, že tato nákladová položka bude růst, ale takhle strmý růst jsme nečekali. 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. Brzy jsme ale zjistili, že nám nestačí vědět, že platíme tisíce dolarů za EC2, stovky za data transfer a podobně. Bez kontextu jsou tato čísla bezcenná.

Rozhodli jsme se proto přidávat jednotlivým resourcům v AWS tagy, podle kterých lze 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říklad Docker či 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 pátrat a dostali jsme se k nástroji CloudChecker na cost management. Nastavili jsme integraci CloudCheckeru s naším AWS účtem a čekali, co z něj vypadne. Bylo toho opravdu hodně. Namátkou:

  • Měli jsme idle instance, což znamená, že nikdo instance fakticky nepoužíval, CPU load byl okolo 0,5 procenta.
  • 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 buil­dě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šší cena, pay as you go.
  • Reserved instance  – rezervovaná instance pro vás, která vychází mnohem levněji než on demand, ale zase si ji musíte předplatit minimálně na rok.
  • Spot Fleet instance  – volné instance, které zrovna nikdo v daném datovém centru nepoužívá, a tak je AWS nabízí se slevou 80 až 90 procent. 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í plug-inu EC2 Fleet, který podporuje škálování, což znamená, že když je ve frontě více buildů, plug-in 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.4×large 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 procent nákladů, které platíte za stroje. Všechny stroje měly 500GB disky. V hlavě jsme měli obvyklou větu lidí z IT: „disky jsou levné“. EBS disky při takovém množství buildovacích strojů stojí majlant. Měřením jsme zjistili, že nevyužijeme 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 AZ. 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 dolarů 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 dolarů za den, dnes okolo 25 dolarů za den.

Dnes už 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 nejbližší době?

UX DAy - tip 2

  • Chtěli bychom se zbavit EBS disků u větší části testovacího prostředí, včetně Jenkinse. AWS propaguje EBS jako spolehlivé úlož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říklad Ephemeral je úložiště, které je několikrát rychlejší 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.4×large, u které máte k dispozici 2 × 300 GB Ephemeral. Pro nás jasná volba. Změnou typu instance a jejího storage jsme schopni ušetřit až 50 procent nákladů pro daný typ clusteru či prostředí.
  • Dalším krokem je vizualizace nákladů pro celý tým. Kdo byl v naší kanceláři, 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 clusterů. 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 vizualizovat. 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 procent v závislosti na dle regionu, nebo že na provozu K8s clusteru můžete ušetřit celkem dost peněz?

Text původně vyšel na blogu vývojářů Zonky.

Byl pro vás článek přínosný?

Autor článku

Autor pracuje jako Software Engineer ve společnosti Zonky, kde má na starost SRE tým. Vývojáři Zonky publikují na svém blogu.

Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).