Ražošanas darba slodzes pārvaldīšana mitinātajās datu bāzēs

Nodrošina Amazon tīmekļa pakalpojumi





AWS piedāvā vairākas iespējas, kā mitināt jūsu datu bāzes, kas apkalpo OLTP darba slodzes — mitiniet savu pārvaldīto datu bāzi Amazon EC2 gadījumus vai izmantošanu Amazon RDS pārvalda AWS. RDS pārvalda augstu pieejamību, automatizētas dublējumkopijas, datu bāzes jauninājumus, OS ielāpus, drošību un lasīšanas reprodukciju. RDS piedāvā arī mākoņdatošanas iespēju Amazone-Aurora datu bāzes dzinējs, kas ir saderīgs ar MySQL un PostgreSQL. Aurora nodrošina lielāku caurlaidspēju, salīdzinot ar standarta MySQL un PostgreSQL datu bāzēm.

Veicot ražošanas darba slodzi mitinātās datu bāzēs ar Amazon RDS vai Amazon EC2, iespējams, esat saskāries ar šādiem jautājumiem:



  • Kādas ir labākās datu bāzes krātuves veida iespējas?
  • Kā atrisināt krātuves veiktspējas problēmas?
  • Kādas ir RAID konfigurācijas opcijas EC2 instanču viesotajām datu bāzēm?
  • Kādas ir lietojumprogrammas modifikācijas optimālai veiktspējai?
  • Kā novērst krātuves veiktspējas problēmas, izmantojot Amazon CloudWatch ?
  • Amazon RDS vs Aurora darbības veiktspēja?

Šajā ziņojumā es piedāvāju labāko uzglabāšanas praksi, lai palaistu ražošanas darba slodzi Amazon RDS vai EC2 instanču viesotās datubāzēs.

Salīdzinot ar testēšanas, kvalitātes nodrošināšanas vai inscenēšanas vidēm, ražošanas darba slodzei ir nepieciešama ātra un konsekventa I/O veiktspēja. Lai gan relāciju datu bāzes var izmantot vairākiem mērķiem, to visizplatītākais lietošanas gadījums ir tiešsaistes darījumu apstrādes (OLTP) darba slodzes mitināšana. RDS, EC2 mitinātās datu bāzes un Aurora izmanto dažāda veida uzglabāšanas metodes, kā parādīts tālāk:

  • Amazon RDS datu bāzes gadījumu izmantošana Amazon EBS tilpumi uzglabāšanai.
  • Aurora gadījumi izmanto AWS patentētus krātuves apjomus.
  • EC2 gadījumi nodrošina dažādas uzglabāšanas iespējas.

Labākās datu bāzes krātuves veida iespējas

Amazon RDS nodrošina trīs uzglabāšanas veidi :



  • Vispārēja pielietojuma SSD (pazīstams arī kā gp2 apjomi )
  • Nodrošināts IOPS SSD (pazīstams arī kā io1 )
  • Magnētiskais

Eksemplāra I/O kapacitāte ir atkarīga no gadījuma krātuves veida un lieluma. Ja DB gadījums ir konfigurēts ar gp2 sējumu, IOPS bāzes ietilpība ir 3 reizes lielāka par GiB krātuvi. Ja DB instance ir piešķīrusi 100 GiB gp2 sējumu, IOPS bāzes ietilpība ir 300. Jo vairāk krātuves nodrošināsit, jo lielāka IOPS jauda.

Papildus pamata IOPS kapacitātei gp2 sējumi nodrošina arī sērijveida jaudu līdz 3000 IOPS ilgāku laika periodu. Sērijveida sērija ir ierobežota ar tilpumiem, kas vienādi vai mazāki par 1 TiB krātuves. DB gadījumus MySQL, MariaDB, Oracle un PostgreSQL var konfigurēt ar 20 GiB–32 TiB, taču maksimālā bāzes līnijas IOPS ir ierobežota no 100 līdz 16 000 IOPS. Tātad gp2 apjoms 5,34 TiB vai vairāk nodrošina to pašu bāzes līniju: 16 000 IOPS.

Ja jūsu ražošanas darba slodzei ir nepieciešams augsts OLTP un ātra, nemainīgi augsta caurlaidspēja, jums ir jākonfigurē DB instance ar io1 sējumiem. Salīdzinājumā ar gp2 sējumiem, kas nodrošina maksimālo bāzlīniju 16 000 IOPS, io1 sējumi var nodrošināt līdz 40 000 IOPS DB gadījumiem MySQL, MariaDB, Oracle un PostgreSQL un līdz 32 000 IOPS SQL Server gadījumiem.



Ja konstatējat, ka IOPS lietošanas modelis pastāvīgi pārsniedz 16 000, jums vajadzētu mainīt DB instance un mainiet krātuves veidu no gp2 uz io1. Amazon RDS piedāvā arī magnētisko krātuvi, taču tā nav piemērota OLTP darba slodzei, kurai nepieciešama konsekventa I/O veiktspēja un zems latentums.

Magnētiskās krātuves veids nav ieteicams I/O intensīvām darba slodzēm, jo ​​maksimālā krātuve ir mazāka nekā gp2 vai io1. IOPS jauda arī ir ierobežota līdz 1000 IOPS.

Krātuves veiktspējas problēmas

Gp2 krātuves izmantošana ir ideāli piemērota dažādām DB darba slodzēm. Šim krātuves veidam arhitektu datu bāzes lasīšanas un rakstīšanas darba slodzes tā, lai summa Lasīt IOPS un WriteIOPS vērtības nevienā brīdī nepārsniedz IOPS bāzes jaudu.



Sērijveida sērija var būt pieejama ilgāku laiku. Tomēr pēc sērijveida jaudas izmantošanas nemainīgi augsta lasīšanas un rakstīšanas IOPS vērtība pasliktina instances veiktspēju. Šo degradāciju var redzēt, palielinoties Rakstīšanas latentums vai Lasīšanas latentums vērtības. Ideālā gadījumā gp2 krātuve ir piemērota viencipara milisekundes latentumam, taču pārmērīga IOPS izmantošana var izraisīt vairāk nekā 10 ms latentumu.

Nākamajos attēlos redzams palielināts Rakstīšanas latentums vērtības, jo WriteIOPS konsekventi patērē sākotnējo 300 IOPS jaudu Amazon RDS DB instancē. Šajā piemērā Amazon RDS PostgreSQL instance tiek mitināta t2.small instancē ar 100 gigabaitu gp2 sējumu.

Iepriekš redzamajā attēlā redzams, ka Write IOPS konsekventi patērē 300 IOPS, kas ir sākotnējā veiktspēja.

Iepriekš redzamajā attēlā redzams, ka IOPS pārmērīgas izmantošanas dēļ rakstīšanas latentums ir palielinājies līdz 25 milisekundēm.

Labākā prakse ir nodrošināt, lai jūsu darba slodze nepārsniegtu gadījuma IOPS jaudu. Daži no veidiem, kā samazināt Lasīt IOPS vērtības ir šādas:

  • Izmantojiet Amazon RDS lasīšanas kopiju.
  • Izmantojiet lielāku RAM.

Izmantojot Amazon RDS lasīšanas kopiju

Amazon RDS DB gadījumi MySQL, MariaDB, Oracle un PostgreSQL piedāvājumā RDS lasīšanas kopijas . Šie gadījumi ir atsevišķi DB gadījumi, kas sinhronizēti ar avota DB gadījumu, atkārtoti atskaņojot datu bāzes darījumu žurnālus. Visas datu modifikācijas avota DB instancē tiek lietotas lasīšanas replikā. Izmantojot lasīšanas reprodukciju, tiek samazināta avota DB instances slodze, maršrutējot lasīšanas vaicājumus no lietojumprogrammām uz lasīšanas repliku. Jūs arī atbrīvojat IOPS jaudu papildu rakstīšanas darbībām avota DB instancē.

Izmantojot lasīšanas replikas, ir svarīgi uzraudzīt replikācijas aizkavi. Parasti lielu replikācijas aizkavi izraisa augsta rakstīšanas aktivitāte avota DB instancē.

Amazon RDS DB gadījumos varat pārraudzīt replikas aizkavēšanos, izmantojot CloudWatch metriku ReplicaLag . Ja konstatējat lielu replikas aizkavi, jums arī jāuzrauga rakstīšanas darbība avota DB instancē. To var paveikt, pārraugot CloudWatch metriku WriteIOPS un Rakstīšanas caurlaidspēja . Ja avota DB instancē ir IOPS deficīts (tas ir, visa IOPS jauda tiek izmantota rakstīšanas un lasīšanas darba slodzei), arī replika atpaliek.

Viens no iemesliem, kāpēc replikas ir atpalikušas, ir tas, ka lielākajā daļā DB programmu nolasītās kopijas atkopšana ietver procesus ar vienu protektoru. Tas nozīmē, ka jo lielāka ir galvenā instances slodze, jo eksponenciāli lēnāka atkopšana lasīšanas reprodukcijās. Jebkura papildu augsta rakstīšanas aktivitāte avota DB instancē eksponenciāli palielina lasīšanas replikas aizkavi. Izņemot CloudWatch metriku, ar ReplicaLag jūs varat arī uzraudzīt kavēšanos ar SQL vaicājumiem.

Programmā PostgreSQL lasīšanas replikas aizkavi var aprēķināt, izmantojot šādu vaicājumu:

|_+_|

Programmā MySQL varat pārbaudīt replikācijas statusu, izmantojot šādu komandu:

|_+_|

Izmantojot Amazon RDS lasīšanas reprodukciju, konfigurējiet klientu tā, lai noteikta līmeņa latentuma vai replikācijas kļūda, kas atrasta replikā, izraisītu mēģinājumu izveidot savienojumu ar citu replikas galapunktu.

Labs veids, kā nodrošināt, ka jūsu lietojumprogramma var atrast veselīgāko kopiju, ir izsaukt CloudWatch metriku, lai atrastu pašreizējās ReplicaLag un lasīšanas/rakstīšanas latentums. Replikācijas kavēšanos var atrast ar SQL komandām, kā parādīts iepriekšējos piemēros. Pašreizējo kopijas stāvokli varat uzzināt arī, zvanot uz AWS komandrindas interfeiss (AWS CLI) komanda description-db-instances. Ja pašreizējais replikas stāvoklis nav replicēšana, klientam jāmēģina izveidot savienojumu ar citu reprodukciju.

Papildus priekšrocībām, ko sniedz lasīšanas darījumu izplatīšana, lasīšanas kopijas var izmantot arī datu sadalīšanai. Ievērojot shard-nothing arhitektūru, varat izveidot lasīšanas kopijas, kas atbilst katrai savai shardai, un reklamēt tās, kad nolemjat tās pārveidot par atsevišķām lauskas.

Izmantojot lielāku RAM

Amazon RDS DB gadījumiem ir jābūt pietiekami daudz RAM, lai viss darba komplekts atrastos atmiņā. Tā kā lasīšanas vaicājumi var nolasīt datus no atmiņas, tas samazina saziņu ar krātuves apjomiem. Tādējādi tas samazina izmantošanu Lasīt IOPS jauda, ​​ko var izmantot rakstīšanai.

Nav vienkārša veida, kā noteikt darba datu kopas lielumu. Apskatiet lasīšanas vaicājumus un uzziniet, cik daudz datu tiek sasniegts. Piemēram, ja datu bāzes izmērs ir 100 GiB un darba kopa ir 20 GiB, jums vajadzētu izmantot Amazon RDS DB gadījums ar vismaz 20 GiB atmiņu. Tas ļauj jums saglabāt visu darba komplektu atmiņā.

RAID konfigurācijas opcijas EC2 instanču viesotajām datu bāzēm

EBS sējumi ir bloka līmeņa krātuves sējumi, kas nodrošina pastāvīgu bloku krātuvi. Šie sējumi ir ļoti pieejami krātuves sējumi, un tos var pievienot EC2 instancei tajā pašā pieejamības zonā. EBS sējumi ir ideāli piemēroti EC2 instanču viesotām datu bāzēm. Nav ieteicams datu bāzei izmantot EC2 gadījumu īslaicīgu krātuvi.

Izmantojot EBS krātuves apjomus ar EC2 gadījumiem, varat konfigurēt apjomus ar jebkuru RAID līmeni. Piemēram, lai iegūtu lielāku I/O veiktspēju, varat izvēlēties RAID 0, kas var apvienot vairākus sējumus. RAID 1 var izmantot datu dublēšanai, jo tas atspoguļo divus sējumus kopā.

Neatkarīgi no RAID konfigurācijas EBS apjoma dati tiek replicēti sekundārajos serveros, lai izvairītos no datu zuduma. RAID 5 un RAID 6 nav ieteicami EC2 instanču viesotās datu bāzēs, jo I/O veiktspēja nav tik laba kā RAID 0 vai RAID 1.

Nākamajā tabulā parādītas priekšrocības un trūkumi starp šo divu dažādo RAID konfigurāciju izmantošanu, kā arī ieteikti iespējamie lietošanas gadījumi.

Konfigurācija Priekšrocības Trūkumi Izmantot gadījumu
RAID 0 I/O veiktspēja ir labāka salīdzinājumā ar kļūdu toleranci Viena apjoma zaudēšana izraisa pilnīgu datu zudumu Ja datu bāzei ir nepieciešama lielāka caurlaidspēja, salīdzinot ar datu pieejamību, un dati ir reproducējami
RAID 1 Kļūdu tolerance ir labāka salīdzinājumā ar I/O veiktspēju Zema rakstīšanas veiktspēja Ja dati ir kritiski un datu bāzes kļūdu tolerance ir svarīgāka par I/O veiktspēju

Lietojumprogrammu modifikācijas optimālai veiktspējai

Ja datu bāzes instancē ir radušās krātuves problēmas un rodas tādas problēmas kā ilgs izpildes laiks un liels latentums, dažkārt izmaiņas lietojumprogrammā var mazināt šo pasliktināšanos. Varat modificēt lietojumprogrammas, lai iespējotu eksponenciālu atkāpšanos vai kļūdu atkārtošanas mēģinājumus.

Eksponenciālā atkāpšanās ļauj lietojumprogrammām pakāpeniski ilgāk gaidīt starp atkārtojumiem, lai saņemtu secīgas kļūdas. Lai gan daži algoritmi izmanto pakāpenisku aizkavi, lielākā daļa eksponenciālo atkāpšanās algoritmu izmanto nejaušinātu aizkavi. Šeit ir piemēri citam algoritmam:

Nejauša aizkave:

  1. Lietojumprogramma ierosina pieprasījumu.
  2. Ja pieprasījums neizdodas, pagaidiet randu (1000,3000) milisekundes un sāciet pieprasījumu vēlreiz.
  3. Ja pieprasījums neizdodas, pagaidiet randu (1000,3000) milisekundes un sāciet pieprasījumu vēlreiz.
  4. Ja pieprasījums neizdodas, pagaidiet randu (1000,3000) milisekundes un sāciet pieprasījumu vēlreiz.

Pakāpeniska aizkave:

  1. Lietojumprogramma ierosina pieprasījumu.
  2. Ja pieprasījums neizdodas, uzgaidiet 1 = 1000 milisekundes un sāciet pieprasījumu vēlreiz.
  3. Ja pieprasījums neizdodas, pagaidiet 2 = pagaidiet 1 + 1000 milisekundes un sāciet pieprasījumu vēlreiz.
  4. Ja pieprasījums neizdodas, pagaidiet 3 = pagaidiet 2 + 1000 milisekundes un sāciet pieprasījumu vēlreiz.

Izmantojiet noteiktu paraugpraksi, lai panāktu ātrāku kļūmjpārlēci Amazon RDS Multi-AZ gadījumos un Aurora klasteros. Iespējojiet TCP saglabāšanas parametrus un iestatiet tos agresīvi, lai nodrošinātu, ka gadījumā, ja klients vairs nevar izveidot savienojumu ar DB gadījumu, visi aktīvie savienojumi tiek ātri aizvērti. Šī modifikācija arī ļauj lietojumprogrammām ātrāk reaģēt uz kļūmjpārlēci un ātri izveidot savienojumu ar jauno galapunktu.

Varat arī samazināt klienta DNS kešatmiņas taimautu. Lasīšanas un rakstīšanas savienojumi tiek ātri izveidoti ar attiecīgajiem galapunktiem. Dažus servera TCP iestatījumu parametrus var arī mainīt. Šīs izmaiņas palīdz ātrāk pārvarēt kļūmju. Piemēram, programmā PostgreSQL to var kontrolēt ar tcp_keepalives_count, tcp_keepalives_idle un tcp_keepalives_interval. parametrus .

Krātuves veiktspējas problēmu novēršana, izmantojot CloudWatch

Regulāri pārraugot gadījumu krātuves stāvokli, tiek konstatēta veiktspējas problēmas agrīna parādīšanās, pirms tā nopietni ietekmē datu bāzes veiktspēju. Šeit ir norādīti daži ar CloudWatch krātuves rādītāji, kas jums regulāri jāpārrauga.

Rakstīt operācijas

  • WriteIOPS: Mērot ar ātrumu skaitu sekundē, šī CloudWatch metrika nosaka vidējo diska ierakstīšanas I/O darbību skaitu sekundē. Koncentrējieties uz šo metriku, ja jūsu datu bāzes gadījums ir konfigurēts ar Multi-AZ iestatījumu.
    Izmantojot Multi-AZ, sekundārā instance tiek izveidota citā pieejamības zonā ar tādu pašu instances konfigurāciju kā galvenajam un pievienotajam EBS krātuves apjomam. Šī krātuve tiek sinhroni sinhronizēta ar galvenās instances krātuvi. Datu dublēšanai pēc noklusējuma dati katrā EBS sējumā tiek kopēti citā, sekundārajā EBS sējumā, kas atrodas tajā pašā pieejamības zonā. Tas nozīmē, ka pirms apstiprinājuma nosūtīšanas klientam rakstīšanas transakcija ir jāapņemas četrās vietās. Liela rakstīšanas darbība virs instanču IOPS un caurlaidspējas pasliktina kopējo veiktspēju.
  • Rakstīšanas caurlaidspēja: Šī CloudWatch metrika atspoguļo vidējo diskā ierakstīto baitu skaitu sekundē. Pārsniedzot instances caurlaidspēju vai krātuves caurlaidspējas ierobežojumu, tiek pasliktināta instances veiktspēja. Es iesaku pārraudzīt rakstīšanas darbību un sadalīt rakstīšanas slodzi ar atbilstošu aizkavi, lai optimizētu veiktspēju.
  • Rakstīšanas latentums: Šis ir vidējais laiks, kas nepieciešams vienai diska I/O darbībai. Lielāko daļu laika Rakstīšanas latentums pieaugums ir saistīts ar gadījumu resursu pārmērīgu izmantošanu, piemēram, CPU, IOPS un caurlaidspēju.

Lasīt operācijas

  • Lasīt IOPS: Mērot ar ātrumu skaitu sekundē, šī CloudWatch metrika nosaka vidējo diska nolasīšanas I/O darbību skaitu sekundē. Palielināta vērtība Lasīt IOPS liecina, ka vai nu lasīšanas slodze ir liela, vai arī gadījumam ir nepieciešams vairāk brīvas atmiņas.
  • Lasīšanas caurlaidspēja: Šī metrika atspoguļo vidējo no diska nolasīto baitu skaitu sekundē. Pārsniedzot gadījumu un EBS ierobežojumus, var palielināties latentums.
  • Lasīšanas latentums: Šis ir vidējais laiks, kas nepieciešams vienai diska I/O darbībai. Ja jums ir augsta šī rādītāja vērtība, apskatiet lasīšanas darba slodzi un pārliecinieties, vai tā neizmanto pārmērīgu gadījumu resursus.

Citi rādītāji

Papildus iepriekš minētajiem rādītājiem jums vajadzētu pārraudzīt arī šādus CloudWatch rādītājus:

  • DiskQueueDepth apzīmē atlikušo I/O (lasīšanas/rakstīšanas pieprasījumu) skaitu, kas gaida, lai piekļūtu diskam. Parasti tas ir lielas darba slodzes rezultāts.
  • FreeStorageSpace nosaka pieejamās krātuves vietas apjomu. Labākajā praksē jums vajadzētu iestatīt CloudWatch brīdinājumi lai jūs varētu saņemt SNS paziņojumus, tiklīdz instances bezmaksas krātuve ir zemāka par sliekšņa vērtību, piemēram, 15%.

Amazon RDS vs Aurora darbības veiktspēja

Kā minēts iepriekš, Amazon RDS DB gadījumiem un EC2 gadījumiem ir IOPS atkarība no krātuves apjomiem. gp2 un io1 krātuves veidiem ir savi IOPS ierobežojumi.

Ja jūsu darba slodzei ir nepieciešama lielāka IOPS veiktspēja un lielāka caurlaidspēja, iespējams, plānojat migrēt uz Aurora, kas ir augstas veiktspējas, ļoti pieejams un izmaksu ziņā efektīvs risinājums, kas piemērots lielas caurlaidspējas darba slodzēm. Pašlaik rītausma piedāvā ar MySQL un PostgreSQL saderīgus dzinējus.

Lietojot Aurora, pārliecinieties, ka IOPS nav tehniski ierobežojumu, taču caurlaidspēja var būt ierobežota ar pamatā esošo. Aurora piemērs ierobežojums. Lai iegūtu labāku caurlaidspēju, izvēlieties augstāku Aurora instances klasi.

Aurora ir vispiemērotākā lietojumprogrammām, kurām jebkurai noteiktai IOPS ir nepieciešams neliels latentums vai tā nav. Tas ir izstrādāts, lai apstrādātu lielu datu ātrumu, nodrošinot lielāku caurlaidspēju salīdzinājumā ar tradicionālajiem MySQL un PostgreSQL dzinējiem. Tā kā datu bāze ir rindu veikala, tā ir ideāli piemērota liela apjoma, lielai vienlaicīgai OLTP darba slodzei.

Vēl viens Aurora lietošanas gadījums ir hibrīda darījumu analītiskā apstrāde (HTAP). Aurora atbalsta līdz 15 replikām. Katra no šīm replikām darbojas 15–20 milisekundēs pēc rakstīšanas gadījuma. Ar nesen pievienoto Amazon Aurora Parallel Query funkcija , vaicājumu apstrāde vēlāk tiek pārsūtīta uz Aurora krātuvi. Vaicājumā tiek izmantoti potenciāli tūkstošiem krātuves mezglu Aurora klasterī, lai apstrādātu, precizētu un apkopotu datus pirms to nosūtīšanas uz aprēķina mezglu.

Secinājums

Šajā ziņā jūs uzzinājāt par labāko krātuves praksi, lai palaistu ražošanas darba slodzi Amazon RDS DB instancē un EC2 instanču viesotās datubāzēs. Šīs prakses bija šādas:

  • Lasīšanas darba slodzes piešķiršana lasīšanas replikai.
  • Izpratne par IOPS ietilpību un tās atkarību no krātuves lieluma un veida.
  • Lietojumprogrammu arhitektūras maiņa.
  • RAID iespēju pārbaude.
  • CloudWatch metrikas pārraudzība.

Jūs arī uzzinājāt par Aurora un to, kā tās patentētās krātuves darbība atšķiras no EBS apjomiem. Visas šīs zināšanas palīdz netraucēti un bez problēmām vadīt ražošanas slodzi AWS datu bāzēs. Šajā datu bāzes emuāra ziņojumā varat arī izpētīt informāciju par to, kā Aurora apstrādā datu bāzes ātrumu un pieejamību, izmantojot krātuves slāni: Iepazīstinām ar Aurora Storage Engine.

paslēpties