Håndtering af produktionsbelastninger på hostede databaser

Leveret af Amazon Web Services





AWS tilbyder flere muligheder for at være vært for dine databaser, der betjener OLTP-arbejdsbelastninger - host din egen administrerede database på Amazon EC2 instanser eller brug Amazon RDS administreret af AWS. RDS administrerer høj tilgængelighed, automatiserede sikkerhedskopier, databaseopgraderinger, OS-patches, sikkerhed og læsereplika. RDS tilbyder også den cloud-native mulighed Amazon-Aurora databasemotor, som er kompatibel med MySQL og PostgreSQL. Aurora leverer højere gennemløb sammenlignet med standard MySQL- og PostgreSQL-databaser.

Mens du kører produktionsarbejdsbelastninger på hostede databaser med Amazon RDS eller Amazon EC2, er du muligvis stødt på følgende spørgsmål:



  • Hvad er de bedste muligheder for databaselagringstype?
  • Hvordan løser man problemer med storageydelse?
  • Hvad er RAID-konfigurationsmulighederne for EC2-instans-hostede databaser?
  • Hvad er applikationsændringerne for optimal ydeevne?
  • Sådan fejlfinder du lagerydeevne ved hjælp af Amazon CloudWatch ?
  • Amazon RDS vs. Aurora operationel ydeevne?

I dette indlæg giver jeg bedste opbevaringspraksis til at køre produktionsarbejdsbelastninger på Amazon RDS- eller EC2-instans-hostede databaser.

Sammenlignet med test-, QA- eller iscenesættelsesmiljøer kræver produktionsarbejdsbelastninger hurtig og ensartet I/O-ydeevne. Mens relationelle databaser kan bruges til flere formål, er deres mest almindelige brugssag at være vært for en online transaktionsbehandling (OLTP) arbejdsbyrde. RDS, EC2 hostede databaser og Aurora bruger forskellige typer lagringsteknikker som vist nedenfor:

  • Amazon RDS database instanser bruger Amazon EBS mængder til opbevaring.
  • Aurora-instanser bruger AWS proprietære lagervolumener.
  • EC2-instanser muliggør en række muligheder for opbevaring.

Bedste muligheder for databaselagringstype

Amazon RDS giver tre opbevaringstyper :



  • General Purpose SSD (også kendt som gp2 mængder )
  • Forsynet IOPS SSD (også kendt som io1 )
  • Magnetisk

Forekomstens I/O-kapacitet er baseret på forekomstens lagertype og størrelse. Hvis DB-forekomsten er konfigureret med en gp2-volumen, er baseline IOPS-kapaciteten 3x GiB-lageret. Hvis DB-instansen har allokeret en 100-GiB gp2-volumen, er IOPS-basekapaciteten 300. Jo mere lagerplads du tildeler, jo højere IOPS-kapacitet.

Ud over baseline IOPS-kapacitet leverer gp2-volumener også burst-kapacitet op til 3.000 IOPS i længere perioder. Burst-funktionen er begrænset til volumener lig med eller mindre end 1 TiB lagerplads. DB-instanser til MySQL, MariaDB, Oracle og PostgreSQL kan konfigureres med 20 GiB–32 TiB, men den maksimale basislinje-IOPS er begrænset fra 100 til 16.000 IOPS. Så en gp2-volumen på 5,34 TiB eller mere leverer den samme baseline: 16.000 IOPS.

Hvis din produktionsbelastning kræver høj OLTP og hurtig, konsekvent høj gennemløbsydelse, bør du konfigurere din DB-instans med io1-volumener. Sammenlignet med gp2-volumener, som leverer en maksimal basislinje på 16.000 IOPS, kan io1-volumener levere op til 40.000 IOPS for DB-forekomster til MySQL, MariaDB, Oracle og PostgreSQL og op til 32.000 for SQL Server-forekomster.



Hvis du oplever, at mønsteret for IOPS-brug konsekvent går ud over mere end 16.000, bør du ændre DB instans og skift lagertypen fra gp2 til io1. Amazon RDS tilbyder også magnetisk lagring, men det er ikke egnet til en OLTP-arbejdsbelastning, der kræver ensartet I/O-ydeevne og lav latenstid.

Den magnetiske lagringstype anbefales ikke til I/O-intensive arbejdsbelastninger, fordi den maksimale lagring er mindre end for gp2 eller io1. IOPS-kapaciteten er også begrænset til et maksimum på 1.000 IOPS.

Problemer med lagerydeevne

Brug af gp2-lagring er ideel til en bred vifte af DB-arbejdsbelastninger. For denne lagringstype belaster arkitektdatabasen læse-og-skrive-arbejdsbelastninger på en sådan måde, at summen af LæsIOPS og SkrivIOPS værdier ikke overstiger baseline IOPS-kapacitet på et givet tidspunkt.



Burst-kapacitet kan være tilgængelig i en længere periode. Efter at burstkapacitet er brugt, forringer en konsekvent høj værdi af læse- og skrive-IOPS instansens ydeevne. Denne nedbrydning kan ses ved øget SkrivLatency eller LæsLatency værdier. Ideelt set er gp2-lagring god til encifret millisekunds latency, men overforbrug af IOPS kan forårsage >10 ms latency.

Følgende billeder viser øget SkrivLatency værdier, da WriteIOPS konsekvent bruger baseline 300 IOPS-kapacitet på en Amazon RDS DB-instans. I dette eksempel er Amazon RDS PostgreSQL-instansen hostet på en t2.small-instans med en 100-GiB gp2-volumen.

Ovenstående billede viser, at Write IOPS bruger 300 IOPS konsekvent, hvilket er baseline-ydelsen.

Ovenstående billede viser skriveforsinkelsen steget op til 25 millisekunder på grund af overforbrug af IOPS.

Som en bedste praksis skal du sørge for, at din arbejdsbyrde ikke går ud over instansens IOPS-kapacitet. Nogle af måderne at reducere LæsIOPS værdier er til:

  • Brug en Amazon RDS-replika.
  • Brug højere RAM.

Brug af en Amazon RDS-læse-replika

Amazon RDS DB-instanser til MySQL, MariaDB, Oracle og PostgreSQL tilbyder RDS læse replikaer . Disse forekomster er separate DB-forekomster, der er synkroniseret med DB-kildeforekomsten ved at afspille databasetransaktionslogfiler. Enhver dataændring på kilde-DB-instansen anvendes på læsereplikaen. Med en læsereplika reducerer du belastningen på din kilde-DB-instans ved at dirigere læseforespørgsler fra dine applikationer til læsereplikaen. Du frigør også IOPS-kapacitet til yderligere skriveaktivitet ved kilde-DB-instansen.

Med læsereplikaer er det vigtigt at overvåge replikationsforsinkelse. Generelt er høj replikeringsforsinkelse forårsaget af høj skriveaktivitet ved kilde-DB-instansen.

I Amazon RDS DB-forekomster kan du overvåge replika-forsinkelse ved hjælp af CloudWatch-metrikken ReplicaLag . Hvis du finder høj replika-forsinkelse, bør du også overvåge skriveaktivitet ved kilde-DB-instansen. Dette kan opnås ved at overvåge CloudWatch-metrics SkrivIOPS og WriteThroughput . Hvis kilde-DB-instansen er IOPS-deficient (det vil sige al IOPS-kapacitet bliver brugt af skrive- og læsearbejdsbelastningen), bliver replikaen også ved med at halte.

En af årsagerne til efterslæbende replikaer er, at gendannelse af læst replika i de fleste DB-motorer involverer enkelttrinsprocesser. Det betyder, at jo højere belastningen er ved en masterinstans, desto eksponentielt langsommere genopretning ved læste replikaer. Enhver yderligere høj skriveaktivitet ved kilde-DB-instansen øger eksponentielt læsereplika-forsinkelse. Bortset fra CloudWatch-metrics, med ReplicaLag du kan også overvåge forsinkelse ved SQL-forespørgsler.

I PostgreSQL kan læs replika-forsinkelse beregnes ved hjælp af følgende forespørgsel:

|_+_|

I MySQL kan du kontrollere replikeringsstatussen med følgende kommando:

|_+_|

Med en Amazon RDS-læsereplika skal du konfigurere klienten på en sådan måde, at et vist niveau af latenstid eller replikeringsfejl fundet ved en replika udløser forsøg på et andet replikaslutpunkt for forbindelse.

En god måde at sikre, at din applikation kan finde den sundeste kopi, er at ringe til CloudWatch-metrics for at finde de aktuelle værdier af ReplicaLag og læse-/skriveforsinkelse. Replikeringsforsinkelse kan findes med SQL-kommandoer, som vist i tidligere eksempler. Du kan også finde den aktuelle tilstand af replika ved at ringe til AWS Command Line Interface (AWS CLI) kommando describe-db-instanser. Hvis den aktuelle tilstand af replikaen er en anden end replikering, skal klienten prøve at oprette forbindelse til en anden replika.

Udover fordelen ved at distribuere læste transaktioner, kan læsereplikaer også bruges til at sønderdele dine data. Efter dele-intet-arkitekturen for shards, kan du oprette læsereplikaer, der svarer til hver af dine shards, og promovere dem, når du beslutter dig for at konvertere dem til selvstændige shards.

Bruger højere RAM

Amazon RDS DB-instanser bør have tilstrækkelig RAM, så dit fulde arbejdssæt ligger i hukommelsen. Da læseforespørgslerne kan læse data fra hukommelsen, reducerer det kommunikationen med lagervolumener. Som sådan reducerer det brugen af LæsIOPS kapacitet, der kan bruges til skriveformål.

Der er ingen enkel måde at finde størrelsen på et fungerende datasæt. Se på de læste forespørgsler og find ud af, hvor meget data der bliver ramt. For eksempel, hvis størrelsen af ​​en database er 100 GiB, og arbejdssættet er 20 GiB, bør du bruge en Amazon RDS DB-instans med mindst 20 GiB hukommelse. Det giver dig mulighed for at have det komplette arbejdssæt i hukommelsen.

RAID-konfigurationsmuligheder for EC2-instans-hostede databaser

EBS-volumener er lagervolumener på blokniveau, der giver vedvarende bloklagring. Disse volumener er meget tilgængelige lagervolumener og kan knyttes til en EC2-instans i den samme tilgængelighedszone. EBS-volumener er ideelle til EC2-instans-hostede databaser. Det anbefales ikke at bruge EC2-instans ephemeral storage til en database.

Ved at bruge EBS-lagervolumener med EC2-instanser kan du konfigurere volumener med ethvert RAID-niveau. For at opnå større I/O-ydeevne kan du for eksempel vælge RAID 0, som kan stribe flere enheder sammen. RAID 1 kan bruges til dataredundans, fordi det spejler to diskenheder sammen.

Uanset RAID-konfiguration, replikeres EBS-volumendata på tværs af sekundære servere for at undgå datatab. RAID 5 og RAID 6 anbefales ikke på EC2-instans-hostede databaser, fordi I/O-ydeevnen ikke er så god som RAID 0 eller RAID 1.

Følgende tabel viser fordele og ulemper ved at bruge disse to forskellige RAID-konfigurationer og foreslår mulige anvendelsesmuligheder.

Konfiguration Fordele Ulemper Use case
RAID 0 I/O-ydeevne overlegen sammenlignet med fejltolerance Tab af enkelt volumen forårsager fuldstændigt datatab Hvis databasen kræver højere gennemløb sammenlignet med datatilgængelighed, og data kan reproduceres
RAID 1 Fejltolerance er overlegen sammenlignet med I/O-ydelse Lav skriveydelse Hvis data er kritiske og databasefejltolerance er vigtigere end I/O-ydeevne

Applikationsændringer for optimal ydeevne

Hvis en databaseinstans står over for lagringsproblemer og løber ind i problemer såsom høj commit-tid og høj latens, kan ændringer i applikationen nogle gange afbøde denne nedbrydning. Du kan ændre applikationer for at aktivere eksponentiel backoff eller fejlforsøg.

Eksponentiel backoff tillader applikationer gradvist længere ventetider mellem genforsøg for på hinanden følgende fejlsvar. Mens nogle algoritmer bruger inkrementel forsinkelse, bruger de fleste eksponentielle backoff-algoritmer randomiseret forsinkelse. Her er eksempler på en anden algoritme:

Tilfældig forsinkelse:

  1. Ansøgning igangsætter anmodning.
  2. Hvis anmodningen mislykkes, vent rand(1000,3000) millisekunder og indled anmodningen igen.
  3. Hvis anmodningen mislykkes, vent rand(1000,3000) millisekunder og indled anmodningen igen.
  4. Hvis anmodningen mislykkes, vent rand(1000,3000) millisekunder og indled anmodningen igen.

Inkrementel forsinkelse:

  1. Ansøgning igangsætter anmodning.
  2. Hvis anmodningen mislykkes, skal du vente 1 = 1000 millisekunder og starte anmodningen igen.
  3. Hvis anmodningen mislykkes, vent 2 = vent 1 + 1000 millisekunder og indled anmodningen igen.
  4. Hvis anmodningen mislykkes, vent 3 = vent 2 + 1000 millisekunder og indled anmodningen igen.

Brug visse bedste fremgangsmåder til at opnå hurtigere failover i Amazon RDS Multi-AZ-forekomster og Aurora-klynger. Aktiver TCP Keepalive-parametre, og indstil dem aggressivt for at sikre, at hvis din klient ikke længere er i stand til at oprette forbindelse til DB-instansen, lukkes alle aktive forbindelser hurtigt. Denne modifikation giver også applikationer mulighed for at reagere hurtigere på failover og oprette forbindelse hurtigt til det nye slutpunkt.

Du kan også reducere DNS-cache-timeout hos klienten. Læse- og skriveforbindelser etableres hurtigt til de relevante endepunkter. Nogle af serverens TCP-indstillingsparametre kan også ændres. Disse ændringer hjælper med hurtigere failover. For eksempel, i PostgreSQL kan dette styres af tcp_keepalives_count, tcp_keepalives_idle og tcp_keepalives_interval parametre .

Fejlfinding af lagerydeevne ved hjælp af CloudWatch

Regelmæssig overvågning af instanslagerets tilstand identificerer den tidlige begyndelse af et ydeevneproblem, før det har en alvorlig effekt på databasens ydeevne. Nogle af de lagrings-CloudWatch-relaterede målinger, som du regelmæssigt bør overvåge, er anført her.

Skriv operationer

  • SkrivIOPS: Målt med en hastighed på antal/sekund bestemmer denne CloudWatch-metrik det gennemsnitlige antal diskskrivnings-I/O-operationer pr. sekund. Fokuser på denne metric, hvis din databaseinstans er konfigureret med en Multi-AZ-indstilling.
    Ved hjælp af Multi-AZ oprettes en sekundær forekomst i en anden tilgængelighedszone med samme forekomstkonfiguration som master- og tilknyttet EBS-lagervolumen. Dette lager synkroniseres synkront med masterinstanslageret. For dataredundans kopieres data i hver EBS-volumen som standard til en anden, sekundær EBS-volumen, der er placeret i den samme tilgængelighedszone. Det betyder, at en skrivetransaktion skal foretages fire steder, før en kvittering sendes til klienten. Massiv skriveaktivitet over instansernes IOPS og gennemløbskapacitet forværrer den overordnede ydeevne.
  • WriteThroughput: Denne CloudWatch-metrik repræsenterer det gennemsnitlige antal bytes skrevet til disk pr. sekund. At gå over instansens kapacitet eller lagergennemløbsgrænsen skader instansens ydeevne. Jeg foreslår, at du overvåger skriveaktiviteten og fordeler skrivebelastningen med en passende forsinkelse for at optimere ydeevnen.
  • Skriveforsinkelse: Dette er den gennemsnitlige tid, det tager pr. disk I/O-operation. Det meste af tiden SkrivLatency stigninger skyldes overforbrug af instansressourcerne, såsom CPU, IOPS og gennemløb.

Læs operationer

  • Læs IOPS: Målt med en hastighed på antal/sekund bestemmer denne CloudWatch-metrik det gennemsnitlige antal disklæste I/O-operationer pr. sekund. Den øgede værdi af LæsIOPS antyder, at enten læse arbejdsbyrden er høj, eller at instansen kræver mere ledig hukommelse.
  • ReadThroughput: Denne metrik repræsenterer det gennemsnitlige antal bytes læst fra disken pr. sekund. At gå over forekomsten og EBS-grænserne kan øge latency.
  • Læseforsinkelse: Dette er den gennemsnitlige tid, det tager pr. disk I/O-operation. Hvis du har en høj værdi for denne metric, skal du se på læsearbejdsbyrden og sikre, at den ikke overbruger instansressourcer.

Andre målinger

Sammen med de tidligere nævnte metrics bør du også overvåge følgende CloudWatch-metrics:

  • DiskQueueDepth repræsenterer antallet af udestående I/O'er (læse/skriveanmodninger), der venter på at få adgang til disken. Dette er typisk resultatet af høj arbejdsbyrde.
  • FreeStorageSpace bestemmer mængden af ​​tilgængelig lagerplads. Som en bedste praksis bør du indstille CloudWatch-advarsler så du kan få SNS-meddelelser, så snart instansens gratis lagerplads går under en tærskelværdi, såsom 15 %.

Amazon RDS vs. Aurora operationelle ydeevne

Som tidligere nævnt har Amazon RDS DB-instanser og EC2-instanser IOPS-afhængighed af lagervolumener. Lagringstyperne gp2 og io1 har deres egne IOPS-grænser.

Hvis din arbejdsbyrde kræver højere IOPS-ydeevne og højere gennemløb, planlægger du måske at migrere til Aurora, som er en højtydende, yderst tilgængelig og omkostningseffektiv løsning, der er velegnet til arbejdsbelastninger med høj gennemstrømning. I øjeblikket, daggry tilbyder MySQL- og PostgreSQL-kompatible motorer.

Mens du bruger Aurora, skal du sørge for, at der teknisk set ikke er nogen grænse for IOPS, men gennemløbet kan være begrænset til det underliggende Aurora eksempel begrænse. For bedre gennemløb skal du gå efter en højere Aurora-instansklasse.

Aurora er bedst egnet til applikationer, der kræver lidt eller ingen latenstid for en given IOPS. Den er designet til at håndtere en høj datahastighed, der giver højere gennemløb sammenlignet med traditionelle MySQL- og PostgreSQL-motorer. Da den er en rækkebutiksdatabase, er den ideel til høj volumen, høj samtidig OLTP-arbejdsbelastning.

Et andet anvendelsestilfælde af Aurora er hybrid transaktionsanalytisk behandling (HTAP). Aurora understøtter op til 15 replikaer. Hver af disse replikaer kører inden for 15-20 millisekunder efter skriveforekomsten. Med den nyligt tilføjede Amazon Aurora Parallel Query funktion , forespørgselsbehandling skubbes senere til Aurora-lageret. Forespørgslen bruger potentielt tusindvis af lagernoder i en Aurora-klynge til at behandle, forfine og aggregere data, før de sendes til beregningsknuden.

Konklusion

I dette indlæg lærte du om bedste opbevaringspraksis til at køre en produktionsarbejdsbelastning på Amazon RDS DB-instans og EC2-instans-hostede databaser. Denne praksis involverede følgende:

  • Tildeling af læste arbejdsbelastninger til en læst replika.
  • Forståelse af IOPS-kapacitet og dens afhængighed af lagerstørrelse og -type.
  • Ændring af applikationsarkitektur.
  • Undersøgelse af RAID-muligheder.
  • Overvågning af CloudWatch-metrics.

Du lærte også om Aurora, og hvordan dets proprietære lagring fungerer anderledes end EBS-volumener. Al denne viden hjælper dig med at køre en produktionsarbejdsbelastning problemfrit og uden problemer på AWS-databaser. Du kan også se nærmere på detaljerne om, hvordan Aurora håndterer hastigheden og tilgængeligheden af ​​databasen ved hjælp af lagerlag i dette Database Blog-indlæg: Introduktion til Aurora Storage Engine.

skjule