Mākoņa infrastruktūras izmaksām ir tendence augt klusi. Tas, kas sākas kā saprātīgs mēneša rēķins, gada laikā var dubultoties vai trīskāršoties, jo komandas izveido resursus un tos nenojauc, izvēlas instanču izmērus uz labu laimi un neizmanto cenu modeļus, ko pakalpojumu sniedzēji piedāvā paredzamām slodzēm. Zemāk aprakstītie modeļi visbiežāk dod jūtamu ietaupījumu, nemazinot veiktspēju vai uzticamību.
Pareizs izmērs: vislielākais ieguvums
Visbiežākais mākoņa izšķērdēšanas avots ir pārāk lielas instances. Izstrādes komandas sākotnējā uzstādīšanā parasti paredz jaudu maksimālajai slodzei un šo lēmumu vairs nepārskata. Nereti instances strādā ar 5-15% vidējo CPU noslodzi - tas nozīmē, ka 85% skaitļošanas budžeta tiek izšķiests.
Vispirms mēriet, tad mainiet izmēru
Pirms maināt instanču izmērus, savāciet vismaz divu nedēļu noslodzes datus. Izmantojiet CloudWatch, Grafana vai pakalpojumu sniedzēja uzraudzības rīkus, lai sekotu CPU, atmiņai, tīklam un diska I/O instances līmenī. Skatieties P95 (95. procentiles) vērtības, nevis vidējās - Jums vajag rezervi slodzes kāpumiem.
# AWS CLI - get CPU utilisation statistics for the past 14 days
aws cloudwatch get-metric-statistics \
--namespace AWS/EC2 \
--metric-name CPUUtilization \
--dimensions Name=InstanceId,Value=i-0abc123def456 \
--start-time $(date -d '14 days ago' -u +%Y-%m-%dT%H:%M:%S) \
--end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
--period 3600 \
--statistics Average Maximum p95Ja P95 CPU ir zem 40%, instance ir labs kandidāts samazināšanai. Ja atmiņas noslodze pastāvīgi ir zem 50%, apsveriet pāreju uz skaitļošanai optimizētu instanču saimi, nevis vispārēja lietojuma saimi.
Izvēlieties pareizo instanču saimi
Mākoņa pakalpojumu sniedzēji piedāvā desmitiem instanču saimju, kas optimizētas dažādiem slodzes profiliem. Tīmekļa lietotnes serverim nevajag tādu pašu resursu līdzsvaru kā mašīnmācīšanās apmācības uzdevumam vai datubāzes serverim. Instanču saimes pielāgošana slodzes profilam parasti ietaupa 20-35%, salīdzinot ar vispārēja lietojuma instanču izmantošanu visam.
Rezervētā jauda un ietaupījumu plāni
Cenas pēc pieprasījuma ir dārgākais veids, kā darbināt mākoņa infrastruktūru. Slodzēm, kas darbojas nepārtraukti - datubāzēm, lietotņu serveriem, uzraudzības sistēmām -, rezervētās instances vai ietaupījumu plāni dod 30-60% atlaidi apmaiņā pret viena vai trīs gadu saistībām.
Sāciet ar viena gada saistībām bez priekšapmaksas
Daudzas komandas izvairās no rezervētām instancēm, jo baidās apņemties ar nepareizu konfigurāciju. Drošākais sākums ir viena gada rezervēta instance bez priekšapmaksas visstabilākajām slodzēm. Jūs iegūstat aptuveni 30% ietaupījumu bez kapitālieguldījuma un ar iespēju rezervāciju mainīt, ja vajadzības mainās.
// Cost comparison for a single m6i.xlarge instance (EU West)
const pricing = {
onDemand: { monthly: '$140.16', annual: '$1,681.92' },
reserved1y: { monthly: '$89.79', annual: '$1,077.48', saving: '36%' },
reserved3y: { monthly: '$56.94', annual: '$683.28', saving: '59%' }
};
// For 10 instances, the 1-year reservation saves ~$6,000/yearPārejiet uz trīs gadu saistībām tikai tad, kad Jums ir vismaz sešu mēnešu stabilas lietošanas dati un pārliecība, ka slodze saglabāsies. Lielākā atlaide ir pievilcīga, bet saistību risks ir reāls.
Kešošana tīkla malā: izcelsmes servera slodze mazāka par 80% un vairāk
Cloudflare, CloudFront un līdzīgi CDN pakalpojumi var būtiski samazināt gan datu pārraides izmaksas, gan izcelsmes servera slodzi. Saturam bagātām lietotnēm kešošana tīkla malā bieži ir pati iedarbīgākā izmaksu optimizācija.
Kešojiet agresīvi un pareizi anulējiet
Statiskajiem resursiem (attēliem, CSS, JavaScript, fontiem) kešošanas TTL jābūt vismaz 30 dienām. Lietojiet satura jaucējvērtību failu nosaukumos, lai varētu kešot bez termiņa un neuztraukties par novecojušu saturu.
API atbildēm atrodiet galapunktus, kas atgriež reti mainīgus datus - produktu katalogus, konfigurāciju, publisko saturu -, un kešojiet tos tīkla malā ar īsāku TTL (1-5 minūtes). Pat 60 sekunžu kešs ļoti noslogotam galapunktam var samazināt pieprasījumus izcelsmes serverim par 90%.
Konteineru optimizācija
Konteinerizētām slodzēm ir sava izmaksu dinamika. Biežākie izšķērdēšanas modeļi ir pārspīlēti konteineru resursu pieprasījumi, dīkstāvē esošas replikas un uzpūsti konteineru attēli, kas palēnina izvietošanu un palielina reģistra krātuves izmaksas.
Nosakiet resursu pieprasījumus pēc faktiskā patēriņa
Kubernetes resursu pieprasījumi nosaka, cik daudz jaudas tiek rezervēts katram podam. Ja pieprasāt 1 CPU un 2 GB RAM, bet konteiners parasti izmanto 0,2 CPU un 400 MB, Jūs rezervējat piecas reizes vairāk jaudas, nekā vajag. Reiziniet to ar desmitiem servisu, un izšķērdība strauji uzkrājas.
# Before optimisation - based on guesswork
resources:
requests:
cpu: "1000m"
memory: "2Gi"
limits:
cpu: "2000m"
memory: "4Gi"
# After optimisation - based on P95 usage data
resources:
requests:
cpu: "250m"
memory: "512Mi"
limits:
cpu: "500m"
memory: "1Gi"Uzraudzība un izmaksu brīdinājumi
Izmaksu optimizācija nav vienreizējs projekts. Bez pastāvīgas uzraudzības izmaksas pakāpeniski augs, jo komandas pievieno resursus un mainās lietošanas modeļi. Iestatiet automātiskus brīdinājumus, kas paziņo, kad tēriņi pārsniedz gaidīto slieksni.
Marķējiet visu
Ieviesiet obligātu marķēšanas (tagging) politiku visiem mākoņa resursiem. Kā minimums marķējiet pēc vides (produkcija, testa vide, izstrāde), komandas un projekta. Tas ļauj precīzi attiecināt izmaksas un saprast, kuras komandas vai projekti palielina tēriņus.
Likvidējiet "zombiju" resursus
Nepievienoti EBS sējumi, neizmantotas Elastic IP adreses, pamesti momentuzņēmumi un dīkstāvē esoši slodzes līdzsvarotāji uzkrājas klusi. Reizi mēnesī veiciet auditu, lai atrastu un likvidētu resursus, kam vairs nav nekāda mērķa. "Zombiju" resursi ir bieži sastopams novēršamu tēriņu avots organizācijās, kas tos aktīvi nepārvalda.
Kopsavilkums
Mākoņa izmaksu optimizācijai nav vajadzīgas eksotiskas metodes vai dārgi trešo pušu rīki. Pamati - pareizs instanču izmērs, rezervēta jauda stabilām slodzēm, kešošana tīkla malā un izmaksu redzamība - ir tur, kur parasti atrodama lielākā daļa novēršamo mākoņa tēriņu. Galvenais ir uztvert izmaksas kā inženiertehnisku rādītāju, nevis tikai finanšu problēmu, un iestrādāt optimizāciju ikdienas darbības ritmā.