Administrere produksjonsarbeidsbelastninger på vertsbaserte databaser

Levert av Amazon Web Services





AWS tilbyr flere alternativer for å være vert for databasene dine som betjener OLTP-arbeidsbelastninger – vert for din egen administrerte database Amazon EC2 forekomster eller bruk Amazon RDS administrert av AWS. RDS administrerer høy tilgjengelighet, automatiserte sikkerhetskopier, databaseoppgraderinger, OS-oppdateringer, sikkerhet og lesereplika. RDS tilbyr også det skybaserte alternativet Amazon-Aurora databasemotor, som er kompatibel med MySQL og PostgreSQL. Aurora leverer høyere gjennomstrømming sammenlignet med standard MySQL- og PostgreSQL-databaser.

Mens du kjører produksjonsarbeid på vertsbaserte databaser med Amazon RDS eller Amazon EC2, kan det hende du har møtt følgende spørsmål:



  • Hva er de beste alternativene for databaselagring?
  • Hvordan løser jeg problemer med lagringsytelse?
  • Hva er RAID-konfigurasjonsalternativene for EC2-forekomst-vertsbaserte databaser?
  • Hva er applikasjonsendringene for optimal ytelse?
  • Slik feilsøker du lagringsytelse ved hjelp av Amazon CloudWatch ?
  • Amazon RDS vs. Aurora operasjonell ytelse?

I dette innlegget gir jeg beste lagringspraksis for å kjøre produksjonsarbeidsbelastninger på Amazon RDS- eller EC2-forekomstbaserte databaser.

Sammenlignet med test-, QA- eller iscenesettelsesmiljøer krever produksjonsarbeidsbelastninger rask og konsistent I/O-ytelse. Mens relasjonsdatabaser kan brukes til flere formål, er deres vanligste bruksområde å være vert for en online transaksjonsbehandling (OLTP) arbeidsbelastning. RDS, EC2-vertsbaserte databaser og Aurora bruker forskjellige typer lagringsteknikker som vist nedenfor:

  • Amazon RDS-databaseforekomster bruker Amazon EBS volumer for lagring.
  • Aurora-forekomster bruker AWS proprietære lagringsvolumer.
  • EC2-forekomster muliggjør en rekke alternativer for lagring.

Beste alternativer for databaselagringstype

Amazon RDS gir tre typer oppbevaring :



  • General Purpose SSD (også kjent som gp2 volumer )
  • Provisioned IOPS SSD (også kjent som io1 )
  • Magnetisk

I/O-kapasiteten til forekomsten er basert på forekomstens lagringstype og størrelse. Hvis DB-forekomsten er konfigurert med et gp2-volum, er baseline IOPS-kapasiteten 3 ganger GiB-lagringen. Hvis DB-forekomsten har tildelt et 100-GiB gp2-volum, er grunnlinje-IOPS-kapasiteten 300. Jo mer lagringsplass du klargjør, jo høyere IOPS-kapasitet.

I tillegg til baseline IOPS-kapasitet, leverer gp2-volumer også burst-kapasitet på opptil 3000 IOPS i lengre perioder. Burst-funksjonen er begrenset til volumer lik eller mindre enn 1 TiB lagring. DB-forekomster for MySQL, MariaDB, Oracle og PostgreSQL kan konfigureres med 20 GiB–32 TiB, men den maksimale baseline IOPS er begrenset fra 100 til 16 000 IOPS. Så et gp2-volum på 5,34 TiB eller mer gir samme grunnlinje: 16 000 IOPS.

Hvis produksjonsarbeidsmengden krever høy OLTP og rask, konsekvent høy gjennomstrømningsytelse, bør du konfigurere DB-forekomsten med io1-volumer. Sammenlignet med gp2-volumer, som leverer en maksimal baseline på 16 000 IOPS, kan io1-volumer levere opptil 40 000 IOPS for DB-forekomster for MySQL, MariaDB, Oracle og PostgreSQL og opptil 32 000 for SQL Server-forekomster.



Hvis du finner at mønsteret for IOPS-bruk konsekvent går utover mer enn 16 000, bør du endre DB instans og endre lagringstypen fra gp2 til io1. Amazon RDS tilbyr også magnetisk lagring, men den er ikke egnet for en OLTP-arbeidsbelastning som krever konsistent I/O-ytelse og lav ventetid.

Magnetisk lagringstype anbefales ikke for I/O-intensive arbeidsbelastninger fordi maksimal lagringsplass er mindre enn for gp2 eller io1. IOPS-kapasiteten er også begrenset til maksimalt 1000 IOPS.

Problemer med lagringsytelse

Å bruke gp2-lagring er ideell for et bredt utvalg av DB-arbeidsbelastninger. For denne lagringstypen belaster arkitektdatabasen lese-og-skrive arbeidsbelastninger på en slik måte at summen av ReadIOPS og SkrivIOPS verdier ikke overskrider baseline IOPS-kapasitet til enhver tid.



Burst-kapasitet kan være tilgjengelig i en lengre periode. Etter at seriekapasiteten er brukt, forringer imidlertid en konsistent høy verdi av lese- og skrive-IOPS instansytelsen. Denne nedbrytningen kan sees ved økt Skriveforsinkelse eller ReadLatency verdier. Ideelt sett er gp2-lagring bra for ensifret millisekunds latens, men overbruk av IOPS kan forårsake >10 ms latens.

Følgende bilder viser økt Skriveforsinkelse verdier som WriteIOPS konsekvent bruker baseline 300 IOPS-kapasitet på en Amazon RDS DB-forekomst. I dette eksemplet er Amazon RDS PostgreSQL-forekomsten vert på en t2.small-forekomst med et 100-GiB gp2-volum.

Bildet ovenfor viser at Write IOPS bruker 300 IOPS konsekvent, som er baseline-ytelsen.

Bildet ovenfor viser skriveforsinkelsen økt med opptil 25 millisekunder på grunn av overbruk av IOPS.

Som en beste praksis, sørg for at arbeidsmengden din ikke går utover IOPS-kapasiteten til forekomsten. Noen av måtene å redusere ReadIOPS verdier er til:

  • Bruk en Amazon RDS read replika.
  • Bruk høyere RAM.

Ved å bruke en Amazon RDS-lesekopi

Amazon RDS DB-forekomster for MySQL, MariaDB, Oracle og PostgreSQL tilbyr RDS lese kopier . Disse forekomstene er separate DB-forekomster synkronisert med kilde-DB-forekomsten ved å spille av databasetransaksjonslogger. Eventuelle datamodifikasjoner på kilde-DB-forekomsten blir brukt på lesereplikaen. Med en lesereplika reduserer du belastningen på kilde-DB-forekomsten ved å rute lesespørringer fra applikasjonene dine til lesereplikaen. Du frigjør også IOPS-kapasitet for ytterligere skriveaktivitet ved kilde-DB-forekomsten.

Med lesereplikaer er det viktig å overvåke replikeringsforsinkelse. Generelt er høy replikeringsforsinkelse forårsaket av høy skriveaktivitet ved kilde-DB-forekomsten.

I Amazon RDS DB-forekomster kan du overvåke replikaforsinkelse ved hjelp av CloudWatch-beregningen ReplicaLag . Hvis du finner høy replikaforsinkelse, bør du også overvåke skriveaktiviteten ved kilde-DB-forekomsten. Dette kan oppnås ved å overvåke CloudWatch-beregninger SkrivIOPS og WriteThroughput . Hvis kilde-DB-forekomsten er IOPS-mangelfull (det vil si at all IOPS-kapasitet brukes av skrive- og lesearbeidsbelastningen), fortsetter replikaen også å henge.

En av årsakene til etterslepende replikaer er at i de fleste DB-motorer involverer gjenoppretting av gjenoppretting av lesekopier enkelttrådede prosesser. Det betyr at jo høyere belastning ved en masterforekomst, desto eksponentielt langsommere gjenoppretting ved lesereplikaer. Enhver ekstra høy skriveaktivitet ved kilde-DB-forekomsten øker eksponentielt lesereplika-forsinkelsen. Bortsett fra CloudWatch-beregninger, med ReplicaLag du kan også overvåke etterslep etter SQL-spørringer.

I PostgreSQL kan lesereplika-forsinkelse beregnes ved å bruke følgende spørring:

|_+_|

I MySQL kan du sjekke replikeringsstatusen med følgende kommando:

|_+_|

Med en Amazon RDS-lesereplika, konfigurer klienten på en slik måte at et visst nivå av latenstid eller replikeringsfeil funnet ved en replika utløser forsøk på et annet replikaendepunkt for tilkobling.

En god måte å sikre at applikasjonen din kan finne den sunneste kopien er å ringe CloudWatch-målinger for å finne gjeldende verdier for ReplicaLag og lese-/skriveforsinkelse. Replikeringsforsinkelse kan bli funnet med SQL-kommandoer, som vist i tidligere eksempler. Du kan også finne gjeldende tilstand for replika ved å ringe AWS Command Line Interface (AWS CLI) kommando describe-db-instanser. Hvis gjeldende tilstand for replikaen er en annen enn replikering, bør klienten prøve å koble til en annen replika.

Bortsett fra fordelen med å distribuere leste transaksjoner, kan lesekopier også brukes til å dele dataene dine. Ved å følge del-ingenting-arkitekturen til shards, kan du lage lesereplikaer som tilsvarer hver av shards og markedsføre dem når du bestemmer deg for å konvertere dem til frittstående shards.

Bruker høyere RAM

Amazon RDS DB-forekomster bør ha tilstrekkelig RAM slik at hele arbeidssettet ditt ligger i minnet. Ettersom lesespørringene kan lese data fra minnet, reduserer det kommunikasjonen med lagringsvolumer. Som sådan reduserer det bruken av ReadIOPS kapasitet som kan brukes til skriveformål.

Det er ingen enkel måte å finne størrelsen på et fungerende datasett. Se på lesespørringene og finn ut hvor mye data som blir truffet. Hvis for eksempel størrelsen på en database er 100 GiB, og arbeidssettet er 20 GiB, bør du bruke en Amazon RDS DB-forekomst med minst 20 GiB minne. Det lar deg ha hele arbeidssettet i minnet.

RAID-konfigurasjonsalternativer for EC2-forekomst-vertsbaserte databaser

EBS-volumer er lagringsvolumer på blokknivå som gir vedvarende blokklagring. Disse volumene er svært tilgjengelige lagringsvolumer og kan kobles til en EC2-instans i samme tilgjengelighetssone. EBS-volumer er ideelle for EC2-forekomstbaserte databaser. Det anbefales ikke å bruke kortvarig lagring av EC2-forekomster for en database.

Ved å bruke EBS-lagringsvolumer med EC2-forekomster, kan du konfigurere volumer med alle RAID-nivåer. For eksempel, for bedre I/O-ytelse, kan du velge RAID 0, som kan stripe flere volumer sammen. RAID 1 kan brukes for dataredundans fordi den speiler to volumer sammen.

Uavhengig av RAID-konfigurasjon, replikeres EBS-volumdata på tvers av sekundære servere for å unngå tap av data. RAID 5 og RAID 6 anbefales ikke på EC2-forekomst-vertsbaserte databaser fordi I/O-ytelsen ikke er like god som RAID 0 eller RAID 1.

Tabellen nedenfor viser fordelene og ulempene ved å bruke disse to forskjellige RAID-konfigurasjonene, og foreslår mulige brukstilfeller.

Konfigurasjon Fordeler Ulemper Bruk case
RAID 0 I/O-ytelse overlegen sammenlignet med feiltoleranse Tap av enkeltvolum forårsaker fullstendig datatap Hvis databasen krever høyere gjennomstrømming sammenlignet med datatilgjengelighet og data kan reproduseres
RAID 1 Feiltoleransen er overlegen sammenlignet med I/O-ytelsen Lav skriveytelse Hvis data er kritiske og databasefeiltoleranse er viktigere enn I/O-ytelse

Applikasjonsmodifikasjoner for optimal ytelse

Hvis en databaseforekomst står overfor lagringsproblemer og får problemer som høy innføringstid og høye ventetider, kan noen ganger endringer i applikasjonen redusere denne forringelsen. Du kan endre applikasjoner for å aktivere eksponentiell backoff eller feilforsøk.

Eksponentiell backoff tillater applikasjoner gradvis lengre ventetid mellom gjenforsøk for påfølgende feilsvar. Mens noen algoritmer bruker inkrementell forsinkelse, bruker de fleste eksponentielle backoff-algoritmer randomisert forsinkelse. Her er eksempler på en annen algoritme:

Tilfeldig forsinkelse:

  1. Søknad starter forespørsel.
  2. Hvis forespørselen mislykkes, vent rand(1000,3000) millisekunder og start forespørselen på nytt.
  3. Hvis forespørselen mislykkes, vent rand(1000,3000) millisekunder og start forespørselen på nytt.
  4. Hvis forespørselen mislykkes, vent rand(1000,3000) millisekunder og start forespørselen på nytt.

Inkrementell forsinkelse:

  1. Søknad starter forespørsel.
  2. Hvis forespørselen mislykkes, vent 1 = 1000 millisekunder og start forespørselen på nytt.
  3. Hvis forespørselen mislykkes, vent 2 = vent 1 + 1000 millisekunder og start forespørselen på nytt.
  4. Hvis forespørselen mislykkes, vent 3 = vent 2 + 1000 millisekunder og start forespørselen på nytt.

Bruk visse beste fremgangsmåter for å oppnå raskere failover i Amazon RDS Multi-AZ-forekomster og Aurora-klynger. Aktiver TCP keepalive-parametere og sett dem aggressivt for å sikre at hvis klienten din ikke lenger er i stand til å koble til DB-forekomsten, lukkes alle aktive tilkoblinger raskt. Denne modifikasjonen lar også applikasjoner reagere på failover raskere og koble seg raskt til det nye endepunktet.

Du kan også redusere tidsavbrudd for DNS-bufring hos klienten. Lese- og skriveforbindelser etableres raskt til de aktuelle endepunktene. Noen av serverens TCP-innstillingsparametere kan også endres. Disse endringene bidrar til raskere failover. For eksempel, i PostgreSQL, kan dette kontrolleres av tcp_keepalives_count, tcp_keepalives_idle og tcp_keepalives_interval parametere .

Feilsøking av lagringsytelse ved hjelp av CloudWatch

Regelmessig overvåking av tilstanden til forekomstlagring identifiserer tidlig utbruddet av et ytelsesproblem før det har en alvorlig effekt på databaseytelsen. Noen av lagrings-CloudWatch-relaterte beregninger som du bør overvåke regelmessig, er oppført her.

Skriv operasjoner

  • SkrivIOPS: Målt med en hastighet på tellinger/sekund, bestemmer denne CloudWatch-beregningen gjennomsnittlig antall diskskrive I/O-operasjoner per sekund. Fokuser på denne beregningen hvis databaseforekomsten din er konfigurert med en Multi-AZ-innstilling.
    Ved å bruke Multi-AZ opprettes en sekundær forekomst i en annen tilgjengelighetssone med samme forekomstkonfigurasjon som hoved- og tilkoblet EBS-lagringsvolum. Denne lagringen synkroniseres med hovedforekomstlagringen. For dataredundans blir data i hvert EBS-volum som standard kopiert til et annet sekundært EBS-volum som ligger i samme tilgjengelighetssone. Dette betyr at en skrivetransaksjon må foretas fire steder før en bekreftelse sendes til klienten. Massiv skriveaktivitet over forekomstenes IOPS og gjennomstrømningskapasitet forverrer den generelle ytelsen.
  • WriteThroughput: Denne CloudWatch-beregningen representerer gjennomsnittlig antall byte skrevet til disk per sekund. Å gå over forekomstgjennomstrømmingen eller lagringsgjennomstrømningsgrensen skader forekomstytelsen. Jeg foreslår at du overvåker skriveaktiviteten og distribuerer skrivearbeidsmengden med en passende forsinkelse for å optimalisere ytelsen.
  • Skriveforsinkelse: Dette er den gjennomsnittlige tiden det tar per disk I/O-operasjon. Meste parten av tiden Skriveforsinkelse økninger skyldes overforbruk av instansressursene, slik som CPU, IOPS og gjennomstrømning.

Les operasjoner

  • Les IOPS: Målt med en hastighet på tellinger/sekund, bestemmer denne CloudWatch-beregningen gjennomsnittlig antall diskavleste I/O-operasjoner per sekund. Den økte verdien av ReadIOPS antyder at enten lesearbeidsmengden er høy eller at forekomsten krever mer ledig minne.
  • ReadThroughput: Denne beregningen representerer gjennomsnittlig antall byte lest fra disken per sekund. Å gå over forekomsten og EBS-grensene kan øke ventetiden.
  • Leseforsinkelse: Dette er den gjennomsnittlige tiden det tar per disk I/O-operasjon. Hvis du har en høy verdi for denne beregningen, se på lesearbeidsmengden og sørg for at den ikke overbruker forekomstressurser.

Andre beregninger

Sammen med de tidligere nevnte beregningene, bør du også overvåke følgende CloudWatch-beregninger:

  • DiskQueueDepth representerer antall utestående I/O-er (lese-/skriveforespørsler) som venter på å få tilgang til disken. Vanligvis er dette et resultat av høy arbeidsbelastning.
  • FreeStorageSpace bestemmer mengden tilgjengelig lagringsplass. Som en beste praksis bør du angi CloudWatch-varsler slik at du kan få SNS-varsler så snart forekomstens gratis lagring går under en terskelverdi, for eksempel 15 %.

Amazon RDS vs. Aurora operasjonell ytelse

Som nevnt tidligere har Amazon RDS DB-forekomster og EC2-forekomster IOPS-avhengighet av lagringsvolumer. Lagringstypene gp2 og io1 har sine egne IOPS-grenser.

Hvis arbeidsbelastningen din krever høyere IOPS-ytelse og høyere gjennomstrømning, kan du planlegge å migrere til Aurora, som er en høyytelses, svært tilgjengelig og kostnadseffektiv løsning som passer for arbeidsbelastninger med høy gjennomstrømming. For tiden, soloppgang tilbyr MySQL- og PostgreSQL-kompatible motorer.

Mens du bruker Aurora, sørg for at det teknisk sett ikke er noen grense for IOPS, men gjennomstrømmingen kan være begrenset til det underliggende Aurora eksempel grense. For bedre gjennomstrømning, gå for en høyere Aurora-forekomstklasse.

Aurora er best egnet for applikasjoner som krever liten eller ingen ventetid for en gitt IOPS. Den er designet for å håndtere en høy datahastighet som gir høyere gjennomstrømming sammenlignet med tradisjonelle MySQL- og PostgreSQL-motorer. Siden den er en radbutikkdatabase, er den ideell for høyt volum, høy samtidige OLTP-arbeidsbelastninger.

Et annet brukstilfelle av Aurora er hybrid transaksjonsanalytisk prosessering (HTAP). Aurora støtter opptil 15 kopier. Hver av disse replikaene kjører innen 15–20 millisekunder fra skriveforekomsten. Med den nylig lagt til Amazon Aurora Parallel Query-funksjon , sendes spørringsbehandling senere til Aurora-lagring. Spørringen bruker potensielt tusenvis av lagringsnoder i en Aurora-klynge for å behandle, avgrense og samle data før de sendes til beregningsnoden.

Konklusjon

I dette innlegget lærte du om beste lagringspraksis for å kjøre en produksjonsarbeidsbelastning på Amazon RDS DB-forekomst og EC2-forekomst-vertsbaserte databaser. Disse praksisene innebar følgende:

  • Tildeling av lesearbeidsbelastninger til en lesereplika.
  • Forstå IOPS-kapasitet og dens avhengighet av lagringsstørrelse og -type.
  • Endring av applikasjonsarkitektur.
  • Undersøker RAID-alternativer.
  • Overvåking av CloudWatch-beregninger.

Du lærte også om Aurora og hvordan dens proprietære lagring fungerer annerledes enn EBS-volumer. All denne kunnskapen hjelper deg med å kjøre en produksjonsarbeidsbelastning jevnt og uten problemer på AWS-databaser. Du kan også se nærmere på detaljene om hvordan Aurora håndterer hastigheten og tilgjengeligheten til databasen ved å bruke lagringslag i dette databaseblogginnlegget: Vi introduserer Aurora Storage Engine.

gjemme seg