Smanjenje troškova clouda bez narusavanja produkcije

Smanjivanje troskova clouda bez ugrozavanja produkcije nije finansijski zadatak. To je zadatak produkcionog inzenjerstva.

Cilj nije da racun bude manji jednu nedelju. Cilj je da se smanje troskovi uz kontrolu latencije, stope gresaka, margine za oporavak i operativne preglednosti. To zahteva metodian pristup. Slepe korekcije su nacin na koji timovi stvaraju skupe incidente, bucne rollback-ove i skrivene regresije performansi.

U stvarnim projektima, najbezbedniji redosled je obicno isti:

1. Dobijte detaljizaciju troskova.
2. Identifikujte opsege nad kojima vredi raditi.
3. Auditirajte izabrane resurse i workload-ove.
4. Prvo uradite ciscenje niskog rizika.
5. Izmerite efekat.
6. Tek onda pređite na dublju optimizaciju.

Taj redosled je vazan.

Zasto su slepe korekcije troskova opasne

Racuni za cloud su tesno povezani sa ponasanjem sistema. Slepo smanjivanje troskova cesto samo premesta trosak negde drugde.

Manja instanca baze podataka moze smanjiti stavku za racunarske resurse, ali povecati cekanje na I/O, vreme upita, retries, lock contention i CPU potrosnju u aplikacionim worker-ima.

Smanjeni Kubernetes requests mogu umanjiti prividni visak kapaciteta, ali ako se to uradi bez analize workload-a, mogu povecati scheduling pritisak, evictions, throttling i tail latency. Pod-ovi koji se trajno ponovo kreiraju na CGroup-OOM zbog nedovoljnih requests ce trositi mnogo vise resursa.

Agresivno smanjivanje logova i trace-ova moze ustedeti novac ovog meseca, ali moze i ukloniti dokaze koji su vam potrebni tokom sledeceg incidenta.

Problem je jednostavan: cloud resursi su deo runtime ponasanja sistema. Oni nisu odvojeni od produkcije. Posmatranje smanjenja troskova kao skupa izolovanih billing akcija je cesta greska.

Pocnite sa detaljizacijom troskova, ne sa smanjivanjem resursa

Pre nego sto promenite bilo sta, razlozite racun na nesto o cemu inzenjeri zaista mogu da razmisljaju.

Najmanje treba detalizovati troskove po:

• okruzenju: produkcija, staging, development
• servisu ili oblasti proizvoda
• compute, storage, network, managed services, observability
• kriticnim naspram nekriticnih workload-ova
• stabilnom opterecenju naspram opterecenja vođenog skokovima
• direktnim naspram indirektnim troskovima

Tacka je vazna. Neki troskovi su ocigledni, kao sto su sati instanci, prostor na disku, snapshot-ovi, unos logova ili network egress. Drugi su indirektni i cesto veci tokom vremena.

Baza podataka puna zastarelih sesija, zastarelih indeksa, log tabela, starih notifikacija, istorije popup-ova ili isteklih message podataka ne kosta samo prostor na disku. Ona povecava i velicinu tablespace-a, vreme backup-a, vreme restore-a, trosak upita, cache churn, overhead kompakcije ili vacuum-a, i CPU vreme potrebno da se opsluzi normalan saobracaj. Greske u garbage collection-u su cesto istovremeno i problem higijene podataka i problem troskova clouda.

Ne optimizujte “cloud racun” kao jednu brojku. Optimizujte oblasti troskova koje odgovaraju stvarnim sistemskim granicama i aplikacijama koje rade u tom cloudu. Upravljanje troskovima clouda je zajednicka odgovornost - app developer, devops, ili web designer - optimizaciju troskova treba razmatrati na svakom nivou. I to nije jednokratno resenje vec kontinuiran proces koji zahteva jasnu vizualizaciju (uz Grafanu, to bi trebalo da bude jednostavno), redovne revizije, automatizaciju i strateško usklađivanje.

Pet grafova koje treba imati otvorene dok smanjujete troskove

Prilikom promene troskova, pet signala treba da bude vidljivo sve vreme:

1. Zapremina saobracaja, kako bi se promene troskova mogle uporediti sa stvarnom traznjom.
2. Latencija, posebno p95 i p99, a ne samo proseci.
3. Stopa gresaka i retry-ova, ukljucujuci timeout-ove i upstream neuspehe.
4. Signali zasicenja, kao sto su CPU throttling, memory pressure, disk I/O wait, queue backlog i pritisak na connection pool.
5. Troskovi po servisu ili workload-u, kako bi ustedjeni iznos mogao da se poveze sa konkretnom promenom.

Bez ovih grafova, timovi cesto prerano proglase uspeh. Racun se smanjuje, ali latencija polako raste, retry-ovi se povecavaju, ili se queue pocinje nagomilavati sve dok sledeci skok saobracaja ne pretvori to u incident.

Prvo ciscenje niskog rizika

Prve ustede treba da poticu od uklanjanja viska, a ne od agresivnog smanjivanja resursa.

Ova faza je obicno najbezbednija jer uklanja stvari koje uopste ne bi trebalo da postoje, ili smanjuje retention tamo gde je poslovna vrednost jasno niska.

Tipicno ciscenje niskog rizika ukljucuje:

• brisanje neiskoriscenih volume-ova, snapshot-ova, IP adresa, load balancer-a i starih machine image-ova
• ciscenje zastarelih podataka, zastarelih sesija, privremenih zapisa, starih notifikacija, message tabela i napustenih indeksa
• primenu retention i rotation politika za logove, evente i operativne tabele
• smanjenje nepotrebnog logovanja i volumena trace-ova
• prvo prilagodjavanje resursa nekriticnih servisa
• zaustavljanje ili smanjivanje staging i development workload-ova kojima nije potreban kapacitet kao u produkciji tokom celog dana

Ova faza cesto donosi trenutne ustede uz ogranicen operativni rizik.

Tu takodje mnogi timovi otkrivaju da je racun za cloud naduvan zbog zanemarivanja, a ne zbog stvarne traznje. Podaci koje niko ne cita, indeksi koji nikome ne trebaju i logovi koje niko ne koristi vrlo su skupe navike.

Preemptible i spot instanci

Jos jedna prakticna poluga za smanjenje troskova je preemptible ili spot kapacitet.

Spot instance (takodje zvane preemptible VM-ovi na nekim platformama) mogu znacajno smanjiti troskove u odnosu na on-demand instance. U praksi, to je obicno prvo mesto gde treba gledati kada je workload po dizajnu prekidiv.

Bezbedno pravilo je jednostavno: spot kapacitet koristite samo tamo gde je prekid ocekivan, tolerisan i operativno cist.

Dobri pocetni kandidati ukljucuju:

• batch jobs
• CI/CD runner-e i build agente
• data pipeline-ove
• background worker-e sa podrskom za retry
• stateless queue consumer-e koji mogu cisto da se restartuju

Ove workload-ove je obicno lakse prve premestiti zato sto ne zahtevaju strogu kontinuitet na odredjenom nod-u. Ako instanca nestane, posao moze da se ponovi, rescheduluje ili preuzme drugi worker.

Ovde mnogi timovi ostvaruju rane ustede bez diranja produkcionih putanja koje gledaju korisnici.

Ipak, spot koriscenje nije “besplatan novac”. Dobro funkcionise samo kada je workload projektovan za prekid. Pre nego sto bilo sta premestite na spot kapacitet, proverite:

• da su poslovi idempotentni ili bar bezbedni za ponovni pokusaj
• da prekid ne kvari stanje niti proizvodi duple side effect-e
• da queue-ovi, checkpoint-ovi ili medjurezultati mogu da prezive gubitak workera
• da je startup vreme prihvatljivo
• da su autoscaling i rescheduling ponasanja dobro razumljivi

U Kubernetes okruzenjima, spot node-ovi mogu biti veoma efikasni za tolerantne workload-ove, ali zahtevaju pravilno odvajanje od kriticnih servisa. Koristite taints, tolerations, node affinity i priority classes kako customer-facing workload-ovi ne bi slucajno zavrsili na nestabilnom kapacitetu.

Praktican put uvodjenja je:

1. pocnite sa CI/CD agentima, batch obradom i nekriticnim asinhronim worker-ima
2. merite ucestalost prekida i ponasanje oporavka
3. proverite da li su ustede stvarne nakon retry-ova, duzeg vremena izvrsavanja i operativnog overhead-a
4. tek onda prosirite upotrebu na sire klase prekidivih workload-ova

Spot kapacitet je jedan od najboljih alata za optimizaciju troskova, ali samo kada je pouzdanost projektovana oko cinjenice da instanca moze nestati u bilo kom trenutku.

Brza iskljucivanja su prihvatljiva, ali samo kao privremena mera

Ponekad racun treba brzo smanjiti. To moze opravdati privremena iskljucivanja, ali ona moraju biti tretirana kao privremena.

Primeri:

• kraci retention za logove male vrednosti
• manje uzorkovanje trace-ova
• manji node pool-ovi za nekriticne servise
• smanjeni kapacitet za interne alate
• pauziranje retko koriscenih non-production workload-ova van radnog vremena ili tokom vikenda ili dugih praznika

Ove akcije su korisne za trenutno olaksanje, ali nisu potpuna strategija optimizacije. Moraju biti pracene merenjem i pregledom.

Ako privremeno iskljucivanje opstane samo zato sto niko nije kasnije proverio grafikone, ono prestaje da bude optimizacija i postaje tiho akumuliranje rizika.

Auditirajte stvarni oblik workload-a pre nego sto smanjite nesto vazno

Posle ciscenja, sledeci korak je audit workload-a.

Glavno pitanje nije “sta je provisioned?”, vec “kako se workload zapravo ponasa?”

Tri obrasca su veoma vazna:

Nepravilan load sa skokovima

Neki sistemi su uglavnom tihi i povremeno naglo skoce. Tu cloud elasticnost moze biti dragocena, pod uslovom da je scaling put stvaran a ne teoretski.

Ako baza podataka, message broker, cache ili upstream zavisnosti ne mogu da skaluju zajedno sa aplikacionim slojem, onda samo autoscaling racunanja ne resava problem. Mozda samo premesta usko grlo.

Minimalno opterecenje

Neki workload-ovi su jednostavno premali da opravdaju svoj cloud otisak. Mali stabilni servis moze postati skup kada se dodaju managed networking, observability, backup-ovi i overhead skladistenja. U takvim slucajevima, najjeftinija arhitektura moze biti mnogo jednostavnija.

Predvidljivo stabilno opterecenje

Kada je traznja poznata, ravna i tehnicki dosadna, unapred provisionovan hardware cesto moze da obavi posao jeftinije i predvidljivije od pay-as-you-go infrastrukture. Ovo je posebno tacno kada workload dominantno cine baze podataka, search, queue-ovi ili pozadinska obrada sa velikim oslanjanjem na storage.

Kubernetes: gde se cesto krije troskovni visak

U Kubernetes okruzenjima, probleme sa troskovima cesto manje pravi cloud provider, a vise navike klastera.

Prvo mesto za proveru su resource requests i limits.

Preterani requests povecavaju broj nod-ova i rasipaju kapacitet. Preniski requests stvaraju contention, throttling, evictions i nestabilnu latenciju. Oba su skupa, ali na razlicite nacine.

Praktican audit treba da pogleda:

• stvarnu raspodelu CPU i memory koriscenja, a ne samo proseke
• workload-ove sa velikim razlikama izmedju request-a i stvarne upotrebe
• noisy neighbor-e na deljenim node-ovima
• da li HPA reaguje na koristan signal ili samo na CPU
• da li Cluster Autoscaler dodaje node-ove zbog stvarne traznje ili losih request-ova
• DaemonSet-ove i sidecar-ove koji tiho trose kapacitet na svakom nod-u
• observability agente koji prikupljaju vise nego sto iko pregleda

Klaster moze izgledati zdravo, a da i dalje bude neefikasan po pitanju troskova. Cesto se istovremeno vide previse node-ova, previse replica, prevelik volumen logova i preveliki requests.

Za Kubernetes konkretno, optimizaciju troskova treba tretirati kao problem schedulinga i ponasanja workload-a, a ne samo kao infrastrukturni problem.

Managed servisi nisu uvek skupi, niti su uvek jeftini

Cesta greska je pretpostavka da su managed servisi ili uvek isplativi ili uvek preskupi.

Oba stava su previse jednostavna.

Managed servisi mogu biti veoma efikasni kada zamenjuju veliku kolicinu operativnog rada, dobro apsorbuju saobracaj u skokovima ili pruzaju mogucnosti koje bi inace zahtevale mnogo inzenjerskog vremena. To je cesto tacno za funkcije, workere, queue-ove, CDN, ili neke operativno zrele managed baze podataka.

Ali kada je workload stabilan, predvidljiv i jako koriscen, premija moze postati teska za opravdanje. U tim slucajevima, placanje pogodnosti zauvek moze biti skuplje od rada na jednostavnijem dedicated setup-u.

Pravo pitanje nije “managed ili self-hosted?” Pravo pitanje je “za sta placamo i da li i dalje koristimo tu prednost?”

Ponekad je najbolja optimizacija troskova clouda napustanje clouda

Treba reci direktno: ponekad je najbolji nacin da se smanje troskovi clouda da se napusti cloud, ili bar trenutni cloud.

To nije ideologija. To je inzenjerska ekonomija.

Odlazak moze imati smisla kada:

• je load predvidljiv
• je hardware profil dobro poznat
• je performansa za isti trosak dosledno bolja na dedicated resursima
• storage i network troskovi dominiraju racunom
• workload je heavy na bazama podataka, search-u ili inace u stabilnom stanju

Odlazak nema smisla kada:

• je workload uglavnom nizak, ali mora da apsorbuje nagle skokove
• je ukupni otisak toliko mali da bi on-prem bio preteran
• managed servisi vec rade mnogo vrednog posla
• operativna jednostavnost je vaznija od sirove infrastrukturalne efikasnosti

U praksi, pravi odgovor cesto nije “cloud” naspram “on-prem”. To moze biti drugi region, drugi provider, manje managed slojeva, ili mesoviti model u kome se prebacuju samo predvidljive teske komponente.

Cilj nije da se brani izbor platforme. Cilj je da se dobije predvidljiviji racun i bolja performansa za isti trosak.

Praktican redosled rada

Bezbedan projekat smanjenja troskova clouda obicno izgleda ovako:

1. Detalizujte racun

Raspodelite troskove na stvarne tehnicke domene. Prvo pronadjite najveca mesta troska.

2. Identifikujte opsege

Izaberite servise, klastere, baze podataka ili storage domene koji zaista imaju znacaja.

3. Auditirajte izabrane opsege

Pogledajte oblik traznje, iskoriscenost, retention, ponasanje pri skaliranju i operativnu neophodnost.

4. Uradite ciscenje niskog rizika

Uklonite visak pre nego sto podesavate stvarni produkcioni kapacitet.

5. Izmerite efekat

Uporedite sa saobracajem, latencijom, greskama i signalima zasicenja.

6. Idite dublje samo tamo gde podaci to podrzavaju

Prilagodite resurse, redizajnirajte, premestite workload-ove ili promenite platformu tek nakon sto je lako uklonjiv visak nestao.

Ovaj redosled izbegava jedan od najcescih nacina neuspeha: optimizovanje bucnog, prljavog sistema i pogresno tumacenje smeca kao traznje.

Sta obicno najbolje radi

U stvarnim projektima, najpouzdanije ustede obicno dolaze iz kombinacije:

• ciscenja retention-a
• uklanjanja neiskoriscenih resursa
• ciscenja zastarelih operativnih podataka
• prvog prilagodjavanja nekriticnih servisa
• smanjenja preteranog logovanja i trace-ova
• popravljanja rotacije za logove i tabele nalik message-ovima
• audita Kubernetes requests, limits i strategije node pool-a
• ponovnog razmatranja da li odredjeni workload i dalje pripada svom trenutnom cloud setup-u

Ove promene nisu glamurozne, ali su obicno izvor prakticnih usteda.

Zavrsna poenta

Bezbedno smanjenje troskova clouda nije stvar jacih rezova. Stvar je u rezanju pravim redosledom.

Prvo uklonite visak. Onda proverite oblik workload-a. Zatim optimizujte ono sto je stvarno. Tek potom ponovo razmotrite gde platforma treba da bude, kada ekonomija to jasno podrzava.

Tako dobijate manji racun bez placanja toga kasnije kroz incidente, degradiranu latenciju ili operativnu krhkost.