AWS račun s 24.000 $ na 2.000 $ mjesečno: tri uzroka koja sam našao

• Pogrešno dimenzionisanovidi se u iskorištenosti
• Pokvarenovidi se u trošku naspram saobraćaja
• Pogrešno napravljenovidi se samo u kodu

Na projektu državnog sistema za lične karte i pasoše prije svega ostalog pročitao sam AWS račun. Iznosio je 24.000 $ mjesečno. Šest mjeseci kasnije isti sistem koštao je 2.000 $ mjesečno.

Nijedan dio sistema nije bio ugašen, a proizvod je radio isti posao za iste korisnike. Razliku su činila tri odvojena problema, svaki druge vrste. Ta podjela važnija je od samih iznosa, jer se svaka vrsta pronalazi na drugi način.

Istraživanje kompanije Flexera iz 2026. godine, provedeno među 753 organizacije, procjenjuje da se 29% potrošnje na cloud baci, a 85% tih organizacija upravljanje tom potrošnjom navodi kao jedan od najvećih izazova. Račun koji sam čitao bio je oko osam puta veći od onoga što je posao stvarno tražio, dakle prevelik za mnogo više od 29%. Na kraju je pao i ispod te procjene: s 24.000 $ na 2.000 $, dvanaest puta manje.

Sve je bilo predimenzionisano, od instanci do baze.

Ovo je dosadan uzrok i onaj koji svi očekuju. Rijetko je riječ o nemaru. Neko dimenzioniše okruženje pri lansiranju, kad se opterećenje još ne zna, i odabere velikodušno, što je u tom trenutku ispravna odluka. Kad opterećenje postane poznato, dimenzionisanju se niko ne vraća: ništa nije pokvareno, a uvijek ima nešto hitnije.

Predimenzionisanje ćete pronaći ako dodijeljeni kapacitet uporedite sa stvarnom iskorištenošću tokom jednog mjeseca. Ako baza stalno radi na 8% CPU-a i nikad ne pređe 25%, ta rezerva je posljedica dimenzionisanja koje niko nije preispitao.

Predimenzionisan sistem prolazi neprimijećeno jer radi savršeno. Nijedan alarm se ne oglasi i nijedan korisnik se ne žali. Jedini signal je faktura, a nju obično niko ne čita.

U sistemu su se vrtjele beskonačne petlje i neprestano trošile procesorsko vrijeme. Nije bila riječ o hot pathu ni o neefikasnom upitu, nego o petljama koje se nikad ne završe, a neko ih je mjesecima plaćao ne znajući da postoje.

Ovo je kvar i traži se na drugi način. Kod predimenzionisanja grafovi iskorištenosti pokazuju nisku potrošnju. Proces koji se otrgao kontroli na njima se vidi kao visoka potrošnja, koju je nemoguće povezati s bilo čim što korisnici rade.

Ovakav kvar pronaći ćete ako provjerite prati li trošak saobraćaj. Ako potrošnja procesora preko noći ostaje ista, a broj zahtjeva padne skoro na nulu, nešto radi, a nikome ne služi.

Petlje su opstale jer je sistem radio: korisnici su dobijali ono što traže, zahtjevi su prolazili i greške nije bilo. Petlja koja u pozadini troši CPU ne vidi se ni u jednom signalu koji tim inače prati. Primijetit ćete je tek kad se zapitate zašto je kriva troška ravna dok kriva saobraćaja pada.

Uploadi su išli preko backenda, iako su mogli ići direktno od klijenta u object storage.

Svaka fotografija lica ili dokumenta stizala je na server, čekala u njegovoj memoriji i tek onda išla dalje u skladište. U ovom sistemu svaki zahtjev za ličnu kartu ili pasoš bio je upload, pa je tom putanjom prolazila većina saobraćaja.

To košta na tri načina. Svaki fajl drži memoriju instance dok se njegov zahtjev ne završi, pa se instance dimenzionišu prema broju istovremenih uploada umjesto prema poslu koji aplikacija radi. Svaki bajt dvaput prelazi mrežu, a jedna od te dvije dionice nije trebala postojati. I koliko uploada sistem može primiti odjednom određuje instanca, iako object storage može primiti daleko više. Kako upload poslati direktno u skladište, opisao sam u posebnom tekstu.

Ovaj uzrok ne vidi se ni u iskorištenosti ni na krivi troška. Pronalazi se čitanjem koda, kad se zapitate šta server radi sa svakim zahtjevom. Pošto ga pokazuje samo kod, od sva tri uzroka pronalazi se posljednji, a obično je i najveći.

Opstaje zato što je tako po defaultu: tako radi tutorijal, to pokazuje dokumentacija middlewarea i to savršeno radi na deset uploada dnevno.

Tri uzroka pronađena su na tri različita načina i nijedan nije izbacio grešku. Korisnici se žale na spor endpoint, a kad job padne, oglasi se alarm. Predimenzionisane instance, petlje i putanja uploada u ovom sistemu mjesecima su radile ispravno, a plaćale su se na svakom mjesečnom računu.

Trošak se neće primijetiti usput. Neko ga mora redovno provjeravati.

Postavite alarm za budžet prije nego što vam zatreba. Ne košta ništa, a beskonačne petlje mogu se mjesecima vrtjeti samo kad niko ne prati brojku. Alarm bi ih otkrio u prvoj sedmici, a ovako su se vrtjele do pedesete.

Račun čitajte servis po servis, pa stavku po stavku. Ukupan iznos kaže da je previsok, a raspodjela po servisima pokazuje koju od tri vrste gledate. Onda provjerite prati li trošak saobraćaj, jer ako ne prati, nešto radi uzalud.

Nakon toga pročitajte kod. Arhitektonski uzroci ne vide se ni na jednom dashboardu, a upravo su oni skupi.