CI/CD pipeline, detailní vhled do nákladů
Nedávno jsem popisoval na našem blogu, jak u nás funguje cost management pro AWSko. Tento článek bude v pokračovat v daném tématu. S Roman Pichlik jsme řešili, jak a zda vůbec jsme schopni stáhnout náklady na AWS. Zadání znělo jasně: chceme snížit náklady a zároveň nechceme trávit týdny či měsíce přepisováním částí systému.
Začli jsme u jedné z větších položek, kterou u nás tvoří pan Jenkins a stroje pro buildění. Rychlým výpočtem jsem zjistil, že se nám náklady na Jenkins pohybují okolo $55 na vývojaře za měsíc. Vývojářů máme aktuálně 30. Takže za buildy na jenkinsu platíme dohromady $1650 měsíčně. Na Twitteru se okolo toho rozjela slušná diskuse a tímto článkem bych chtěl odhalit více detailů, čísel a informací, které vnesou do celé problematiky více světla.
Tak tady je naše konfigurace:
- Jenkins master běží na instanci typu m4.xlarge (4 CPU, 16 GB RAM). Na masteru nic nebuildíme.
- Jenkins slavy běží na instanci typu m5d.4xlarge (16 CPU, 64 GB RAM)
Pro slavy využíváme AWS Spot fleet, kde máme k dispozici stroje s velkou slevou (80–90% oproti ceně za on-demand). Aktuálně vychází hodina provozu našeho slavu na $0.27, přičemž AWS účtuje po vteřinách. Za červen jsme k buildům potřebovali 5000 hodin. Ve špičce nám běží až 30 slavů, mimo špičku obvykle 0.
Jeden build pull requestu trvá okolo 15 minut a potřebujeme k němu dva slavy (paralelizace běhu kvůli rychlosti) — jeden slave pouze pro integrační testy s embedovanou postgres DB. Druhý slave dělá toto:
- build, unit testy
- end2end testy — rozběhneme platformu v dockeru a vůči této platformě provádíme volání RESTového API
- OWASP dependency check — kontrolujeme, zda některé z 3rd party knihoven neobsahuje kritickou zranitelnost
Každý den u nás vznikne zhruba 5–10 nových pull requestů a to pouze na backendu. Aktuálně nám visí ve frontě 30 pull requestů. Proč to říkám? souvisí to s naší pipelinou. Náš PR build funguje takto:
- nejdříve provede git merge source a target branch
- nad výslednou branchi spustí celý build
- tento build se pustí při každé změně jak source, tak target branch.
Jinými slovy, máme-li 30 pull requestů do naší dev větve, tak stačí, aby někdo zamergoval svůj PR a my přebuildíme zbývajících 29 pull requestů. Jedině tak jsme schopni zajistit, že mergovaný kód opravdu nic nerozbije.
Jenkins rozhodně nevyužíváme jen pro buildy, máme spoustu automatizace okolo (např. několikrát týdně připravujeme docker image s daty z produkce, která jsou anonymizovaná — tento image pak následně používáme pro vývoj a testování).
A teď co s těmi náklady 55$ na vývojáře? Vidíte někde prostor pro úsporu se zachováním 15 mintové zpětné vazby? Díky za každý tip.
