Kur patiesībā aiziet jūsu RDS rēķins — un kā to samazināt

Pārvaldītās datubāzes ir viena no lielākajām pozīcijām daudzos AWS rēķinos un viena no vismazāk pārskatītajām. Neviens neizlemj tērēt par daudz: instanci palielina incidenta laikā un nekad nesamazina atpakaļ, testa vidi izveido kā produkcijas kopiju, manuālu momentuzņēmumu patur "katram gadījumam". Katrs lēmums atsevišķi ir saprātīgs. Kopā tie summējas.

Lūk, kur skatāmies vispirms, pārskatot Amazon RDS un Aurora izmaksas — un, ne mazāk svarīgi, ko atstājam neskartu.

1. Optimizējiet pirms izmēra maiņas

Efektīvākais izmaksu samazinājums bieži ir veiktspējas labojums. Ja daži neefektīvi vaicājumi tur CPU 70% līmenī, instance izskatās pareiza izmēra — līdz vaicājumi tiek salaboti un tā pati slodze ērti darbojas uz vienu vai divām klasēm mazākas instances. Paskatieties pg_stat_statements (vai Performance Insights), pirms skatāties instanču klases.

2. Pielāgojiet instanču izmēru

Pēc tam aplūkojiet CloudWatch datus vismaz par dažām nedēļām, ieskaitot maksimumus: CPU noslodzi, brīvo atmiņu un lasīšanas un rakstīšanas IOPS. Instances, kas reti pārsniedz 20–30% CPU un kurām ir daudz brīvas atmiņas, ir kandidātes mazākai klasei. Salīdziniet arī instanču saimes: Graviton klases PostgreSQL un MySQL slodzēm parasti piedāvā labāku cenas un veiktspējas attiecību nekā x86 ekvivalenti. Lielākajai daļai datubāzu atmiņa ir svarīgāka par CPU, tāpēc nesamaziniet zem robežas, kur darba datu kopa vairs neietilpst kešatmiņā.

3. Pārbaudiet krātuves tipu un izmēru

• No gp2 uz gp3. Vispārējas nozīmes gp3 krātuvē IOPS un caurlaidspēja nav atkarīgas no apjoma, un tā parasti ir lētāka par GB nekā gp2. Daudzas datubāzes uz gp2 tika padarītas lielākas, nekā vajag, tikai lai iegūtu vairāk IOPS.
• Nodrošinātie IOPS. io1 un io2 sējumi bieži ir nodrošināti maksimumam, kas notiek reti. Salīdziniet nodrošinātos IOPS ar faktisko izmantojumu.
• Krātuve tikai aug. RDS krātuves automātiskā mērogošana palielina piešķirto apjomu, bet nekad to nesamazina, un piešķirto krātuvi nevar samazināt uz vietas. Ja liels datu apjoms ir izdzēsts vai arhivēts, vietas atgūšana nozīmē migrāciju uz jaunu, mazāku instanci.

4. Aurora: sekojiet I/O rindai

Aurora Standard atsevišķi tarificē I/O pieprasījumus, un I/O ietilpīgām slodzēm šī pozīcija var līdzināties instances izmaksām. Aurora I/O-Optimized atceļ maksu par katru I/O pieprasījumu apmaiņā pret augstākām instances un krātuves cenām; paša AWS ieteikums ir, ka tas parasti atmaksājas, ja I/O veido vairāk nekā aptuveni ceturtdaļu no Aurora izmaksām. Pirms izvēles pārbaudiet sadalījumu Cost Explorer.

5. Neprodukcijas vides

Izstrādes, testa un sagatavošanas datubāzēm reti vajag to, ko produkcijai:

• Multi-AZ divkāršo instances izmaksas un ārpus produkcijas gandrīz nekad nav vajadzīgs.
• Izstrādei un testēšanai parasti pietiek ar mazākām instanču klasēm.
• Instances, kas tiek izmantotas tikai darba laikā, ārpus tā var apturēt. Ņemiet vērā, ka RDS apturētu instanci automātiski palaiž pēc septiņām dienām, tāpēc vajag grafiku, nevis vienreizēju darbību.

6. Replikas, momentuzņēmumi un vecas versijas

• Lasīšanas replikas, kas izveidotas projektam vai atskaitei, kas vairs netiek izmantota.
• Manuālie momentuzņēmumi — atšķirībā no automātiskajām rezerves kopijām tie glabājas, līdz kāds tos izdzēš, un kopijas citos reģionos tiek tarificētas katrā reģionā no jauna.
• Vecas galvenās versijas. Dzinēja versijas pēc standarta atbalsta beigām automātiski tiek iekļautas RDS Extended Support, par ko maksā par katru vCPU stundu. Atjaunināšana šo pozīciju novērš pilnībā.

7. Saistības uzņemieties tikai pēc izmēra pielāgošanas

Stabilām slodzēm rezervētās instances dod būtiskas atlaides salīdzinājumā ar pieprasījuma cenām. Pērciet tās pēdējās: uzņemoties saistības uz vienu vai trim gadiem par pārāk lielu instanci, jūs iesaldējat izšķērdību.