Hantera produktionsbelastningar på värdbaserade databaser

Tillhandahålls av Amazon webbtjänster





AWS erbjuder flera alternativ för att vara värd för dina databaser som betjänar OLTP-arbetsbelastningar – värd för din egen hanterade databas Amazon EC2 instanser eller användning Amazon RDS hanteras av AWS. RDS hanterar hög tillgänglighet, automatiserade säkerhetskopieringar, databasuppgraderingar, OS-patchar, säkerhet och läsreplika. RDS erbjuder också det molnbaserade alternativet Amazon-Aurora databasmotor, som är kompatibel med MySQL och PostgreSQL. Aurora levererar högre genomströmning jämfört med standarddatabaserna MySQL och PostgreSQL.

När du kör produktionsbelastningar på värdbaserade databaser med Amazon RDS eller Amazon EC2 kan du ha stött på följande frågor:



  • Vilka är de bästa alternativen för databaslagringstyp?
  • Hur löser man problem med lagringsprestanda?
  • Vilka är RAID-konfigurationsalternativen för EC2-instansbaserade databaser?
  • Vilka är applikationsändringarna för optimal prestanda?
  • Hur man felsöker lagringsprestanda med Amazon CloudWatch ?
  • Amazon RDS vs. Aurora operativ prestanda?

I det här inlägget ger jag bästa lagringspraxis för att köra produktionsbelastningar på Amazon RDS- eller EC2-instansbaserade databaser.

Jämfört med test-, QA- eller iscensättningsmiljöer kräver produktionsarbetsbelastningar snabb och konsekvent I/O-prestanda. Även om relationsdatabaser kan användas för flera ändamål, är deras vanligaste användningsfall att vara värd för en arbetsbelastning för onlinetransaktionsbehandling (OLTP). RDS, EC2-värdbaserade databaser och Aurora använder olika typer av lagringstekniker som visas nedan:

  • Amazon RDS-databasinstanser använder Amazon EBS volymer för lagring.
  • Aurora-instanser använder AWS proprietära lagringsvolymer.
  • EC2-instanser möjliggör en mängd olika alternativ för lagring.

De bästa alternativen för databaslagringstyp

Amazon RDS tillhandahåller tre förvaringstyper :



  • General Purpose SSD (även känd som gp2 volymer )
  • Provisioned IOPS SSD (även känd som io1 )
  • Magnetisk

I/O-kapaciteten för instansen baseras på instansens lagringstyp och storlek. Om DB-instansen är konfigurerad med en gp2-volym är baslinjekapaciteten för IOPS 3 gånger GiB-lagringen. Om DB-instansen har allokerat en 100-GiB gp2-volym är IOPS-baskapaciteten 300. Ju mer lagringsutrymme du tillhandahåller, desto högre IOPS-kapacitet.

Förutom baslinje IOPS-kapacitet, levererar gp2-volymer också burstkapacitet upp till 3 000 IOPS under längre tidsperioder. Burst-funktionen är begränsad till volymer lika med eller mindre än 1 TiB lagring. DB-instanser för MySQL, MariaDB, Oracle och PostgreSQL kan konfigureras med 20 GiB–32 TiB, men den maximala baslinjens IOPS är begränsad från 100 till 16 000 IOPS. Så en gp2-volym på 5,34 TiB eller mer ger samma baslinje: 16 000 IOPS.

Om din produktionsbelastning kräver hög OLTP och snabb, konsekvent hög genomströmningsprestanda, bör du konfigurera din DB-instans med io1-volymer. Jämfört med gp2-volymer, som levererar en maximal baslinje på 16 000 IOPS, kan io1-volymer leverera upp till 40 000 IOPS för DB-instanser för MySQL, MariaDB, Oracle och PostgreSQL och upp till 32 000 för SQL Server-instanser.



Om du upptäcker att mönstret för IOPS-användning konsekvent överstiger mer än 16 000 bör du göra det ändra DB instans och ändra lagringstypen från gp2 till io1. Amazon RDS erbjuder också magnetisk lagring, men den är inte lämplig för en OLTP-arbetsbelastning som kräver konsekvent I/O-prestanda och låg latens.

Den magnetiska lagringstypen rekommenderas inte för I/O-intensiva arbetsbelastningar eftersom det maximala lagringsutrymmet är mindre än det för gp2 eller io1. IOPS-kapaciteten är också begränsad till maximalt 1 000 IOPS.

Problem med lagringsprestanda

Att använda gp2-lagring är idealiskt för en mängd olika DB-arbetsbelastningar. För denna lagringstyp belastar arkitektdatabasen läs-och-skriv på ett sådant sätt att summan av ReadIOPS och SkrivIOPS värden inte överstiger baslinjens IOPS-kapacitet vid någon given tidpunkt.



Burstkapacitet kan vara tillgänglig under en längre tid. Men efter att skurkapaciteten har använts försämrar ett konsekvent högt värde på läs- och skriv-IOPS instansens prestanda. Denna nedbrytning kan ses genom ökad SkrivLatency eller LäsLatency värden. Helst är gp2-lagring bra för ensiffrig millisekunds latens, men överanvändning av IOPS kan orsaka >10 ms latens.

Följande bilder visar ökad SkrivLatency värden eftersom WriteIOPS konsekvent förbrukar baslinje 300 IOPS-kapacitet på en Amazon RDS DB-instans. I det här exemplet är Amazon RDS PostgreSQL-instansen värd på en t2.small-instans med en 100-GiB gp2-volym.

Bilden ovan visar att Write IOPS förbrukar 300 IOPS konsekvent vilket är baslinjeprestandan.

Bilden ovan visar skrivlatensen ökad med upp till 25 millisekunder på grund av överanvändning av IOPS.

Som en bästa praxis, se till att din arbetsbelastning inte går utöver IOPS-kapaciteten för instansen. Några av sätten att minska ReadIOPS värdena är att:

  • Använd en Amazon RDS-läsreplika.
  • Använd högre RAM.

Använder en Amazon RDS-läsreplika

Amazon RDS DB-instanser för MySQL, MariaDB, Oracle och PostgreSQL erbjuder RDS läsa kopior . Dessa instanser är separata DB-instanser som synkroniseras med käll-DB-instansen genom att spela upp databastransaktionsloggar. Alla dataändringar på käll-DB-instansen tillämpas på läsrepliken. Med en läsreplik minskar du belastningen på din käll-DB-instans genom att dirigera läsfrågor från dina applikationer till läsreplikan. Du frigör också IOPS-kapacitet för ytterligare skrivaktivitet vid käll-DB-instansen.

Med läsrepliker är det viktigt att övervaka replikeringsfördröjning. I allmänhet orsakas hög replikeringsfördröjning av hög skrivaktivitet vid käll-DB-instansen.

I Amazon RDS DB-instanser kan du övervaka replikfördröjning med CloudWatch-måttet ReplicaLag . Om du hittar hög replikfördröjning bör du också övervaka skrivaktiviteten vid käll-DB-instansen. Detta kan uppnås genom att övervaka CloudWatch-mätvärden SkrivIOPS och WriteThroughput . Om käll-DB-instansen är IOPS-defekt (det vill säga all IOPS-kapacitet används av skriv- och läsarbetsbelastningen), fortsätter repliken att släpa efter.

En av anledningarna till eftersläpande repliker är att i de flesta DB-motorer involverar återställning av läsreplika engångsprocesser. Det betyder att ju högre belastningen är vid en masterinstans, desto exponentiellt långsammare återhämtning vid läsrepliker. All ytterligare hög skrivaktivitet vid käll-DB-instansen ökar exponentiellt läsreplikfördröjningen. Bortsett från CloudWatch-mått, med ReplicaLag du kan också övervaka eftersläpning med SQL-frågor.

I PostgreSQL kan läsreplikfördröjning beräknas med hjälp av följande fråga:

|_+_|

I MySQL kan du kontrollera replikeringsstatusen med följande kommando:

|_+_|

Med en Amazon RDS read replika, konfigurera klienten på ett sådant sätt att en viss nivå av latens eller replikeringsfel som hittas vid en replik utlöser försök med en annan replikslutpunkt för anslutning.

Ett bra sätt att säkerställa att din applikation kan hitta den hälsosammaste kopian är att ringa CloudWatch-mätvärden för att hitta de aktuella värdena för ReplicaLag och läs/skrivfördröjning. Replikeringsfördröjning kan hittas med SQL-kommandon, som visas i tidigare exempel. Du kan också hitta det aktuella tillståndet för repliken genom att ringa AWS Command Line Interface (AWS CLI) kommandot describe-db-instanser. Om det aktuella tillståndet för repliken är annat än replikering, bör klienten försöka ansluta till en annan replik.

Förutom fördelen med att distribuera lästransaktioner kan läsrepliker också användas för att klippa dina data. Genom att följa shards share-nothing-arkitekturen kan du skapa läsrepliker som motsvarar var och en av dina shards och marknadsföra dem när du bestämmer dig för att konvertera dem till fristående shards.

Använder högre RAM

Amazon RDS DB-instanser bör ha tillräckligt med RAM så att hela din arbetsuppsättning finns i minnet. Eftersom läsfrågorna kan läsa data från minnet minskar det kommunikationen med lagringsvolymer. Som sådan minskar det användningen av ReadIOPS kapacitet som kan användas för skrivändamål.

Det finns inget enkelt sätt att hitta storleken på en fungerande datauppsättning. Titta på läsfrågorna och ta reda på hur mycket data som träffas. Till exempel, om storleken på en databas är 100 GiB och arbetsuppsättningen är 20 GiB, bör du använda en Amazon RDS DB-instans med minst 20 GiB minne. Det gör att du kan ha hela arbetsuppsättningen i minnet.

RAID-konfigurationsalternativ för EC2-instansbaserade databaser

EBS-volymer är lagringsvolymer på blocknivå som tillhandahåller beständig blocklagring. Dessa volymer är mycket tillgängliga lagringsvolymer och kan kopplas till en EC2-instans i samma tillgänglighetszon. EBS-volymer är idealiska för EC2-instansbaserade databaser. Det rekommenderas inte att använda tillfällig lagring av EC2-instanser för en databas.

Genom att använda EBS-lagringsvolymer med EC2-instanser kan du konfigurera volymer med alla RAID-nivåer. Till exempel, för bättre I/O-prestanda, kan du välja RAID 0, som kan sammanföra flera volymer. RAID 1 kan användas för dataredundans eftersom den speglar två volymer tillsammans.

Oavsett RAID-konfiguration replikeras EBS-volymdata över sekundära servrar för att undvika dataförlust. RAID 5 och RAID 6 rekommenderas inte på EC2-instansbaserade databaser eftersom I/O-prestandan inte är lika bra som RAID 0 eller RAID 1.

Följande tabell visar fördelarna och nackdelarna mellan att använda dessa två olika RAID-konfigurationer, och föreslår möjliga användningsfall.

Konfiguration Fördelar Nackdelar Användningsfall
RAID 0 I/O-prestanda överlägsen jämfört med feltolerans Förlust av en enda volym orsakar fullständig dataförlust Om databasen kräver högre genomströmning jämfört med datatillgänglighet och data är reproducerbara
RAID 1 Feltoleransen är överlägsen jämfört med I/O-prestanda Låg skrivprestanda Om data är kritiska och databasens feltolerans är viktigare än I/O-prestanda

Applikationsändringar för optimal prestanda

Om en databasinstans står inför lagringsproblem och stöter på problem som hög commit-tid och höga latenser, kan ändringar i applikationen ibland mildra denna försämring. Du kan modifiera applikationer för att aktivera exponentiell backoff eller felförsök.

Exponentiell backoff tillåter applikationer successivt längre väntetider mellan återförsök för på varandra följande felsvar. Medan vissa algoritmer använder inkrementell fördröjning, använder de flesta exponentiella backoff-algoritmer randomiserad fördröjning. Här är exempel på en annan algoritm:

Slumpmässig fördröjning:

  1. Ansökan initierar begäran.
  2. Om begäran misslyckas, vänta rand(1000,3000) millisekunder och initiera begäran igen.
  3. Om begäran misslyckas, vänta rand(1000,3000) millisekunder och initiera begäran igen.
  4. Om begäran misslyckas, vänta rand(1000,3000) millisekunder och initiera begäran igen.

Inkrementell fördröjning:

  1. Ansökan initierar begäran.
  2. Om begäran misslyckas, vänta 1 = 1000 millisekunder och initiera begäran igen.
  3. Om begäran misslyckas, vänta 2 = vänta 1 + 1000 millisekunder och initiera begäran igen.
  4. Om begäran misslyckas, vänta 3 = vänta 2 + 1000 millisekunder och initiera begäran igen.

Använd vissa bästa metoder för att uppnå snabbare failover i Amazon RDS Multi-AZ-instanser och Aurora-kluster. Aktivera TCP Keepalive-parametrar och ställ in dem aggressivt för att säkerställa att om din klient inte längre kan ansluta till DB-instansen så stängs alla aktiva anslutningar snabbt. Denna modifiering tillåter också applikationer att reagera på failover snabbare och ansluta snabbt till den nya slutpunkten.

Du kan också minska DNS-cachetiden hos klienten. Läs- och skrivanslutningar upprättas snabbt till lämpliga slutpunkter. Vissa av serverns TCP-inställningsparametrar kan också ändras. Dessa ändringar bidrar till snabbare failover. Till exempel, i PostgreSQL kan detta styras av tcp_keepalives_count, tcp_keepalives_idle och tcp_keepalives_interval parametrar .

Felsökning av lagringsprestanda med CloudWatch

Genom att regelbundet övervaka tillståndet för instanslagring identifieras det tidiga uppkomsten av ett prestandaproblem innan det har en allvarlig effekt på databasens prestanda. Några av de CloudWatch-relaterade mätvärdena som du bör övervaka regelbundet listas här.

Skriv operationer

  • SkrivIOPS: Mätt med en hastighet av antal/sekund, bestämmer detta CloudWatch-mått det genomsnittliga antalet diskskrivnings-I/O-operationer per sekund. Fokusera på detta mått om din databasinstans är konfigurerad med en Multi-AZ-inställning.
    Med Multi-AZ skapas en sekundär instans i en annan tillgänglighetszon med samma instanskonfiguration som huvud- och ansluten EBS-lagringsvolym. Denna lagring synkroniseras synkront med huvudinstansminnet. För dataredundans kopieras som standard data i varje EBS-volym till en annan sekundär EBS-volym som finns i samma tillgänglighetszon. Detta innebär att en skrivtransaktion måste utföras på fyra ställen innan en bekräftelse skickas till kunden. Massiv skrivaktivitet över instansernas IOPS och genomströmningskapacitet försämrar den övergripande prestandan.
  • WriteThroughput: Detta CloudWatch-mått representerar det genomsnittliga antalet byte som skrivs till disken per sekund. Att gå över instansens genomströmning eller lagringskapacitetsgränsen skadar instansens prestanda. Jag föreslår att du övervakar skrivaktiviteten och fördelar skrivarbetsbelastningen med en lämplig fördröjning för att optimera prestandan.
  • WriteLatency: Detta är den genomsnittliga tid det tar per disk I/O-operation. För det mesta SkrivLatency ökningar beror på överanvändning av instansresurserna, såsom CPU, IOPS och genomströmning.

Läs operationer

  • LäsIOPS: Mätt med en hastighet av antal/sekund, bestämmer detta CloudWatch-mått det genomsnittliga antalet disklästa I/O-operationer per sekund. Det ökade värdet på ReadIOPS antyder att antingen läsarbetsbelastningen är hög eller så kräver instansen mer ledigt minne.
  • ReadThroughput: Detta mått representerar det genomsnittliga antalet byte som läses från disken per sekund. Att gå över instans- och EBS-gränserna kan öka latens.
  • ReadLatency: Detta är den genomsnittliga tid det tar per disk I/O-operation. Om du har ett högt värde för detta mått, titta på läsarbetsbelastningen och se till att det inte överanvänder instansresurser.

Andra mätvärden

Tillsammans med de tidigare nämnda mätvärdena bör du också övervaka följande CloudWatch-mätvärden:

  • DiskQueueDepth representerar antalet utestående I/O (läs/skrivförfrågningar) som väntar på att få åtkomst till disken. Vanligtvis är detta resultatet av hög arbetsbelastning.
  • FreeStorageSpace bestämmer mängden tillgängligt lagringsutrymme. Som en bästa praxis bör du ställa in CloudWatch-varningar så att du kan få SNS-aviseringar så snart instansens kostnadsfria lagringsutrymme går under ett tröskelvärde, till exempel 15 %.

Amazon RDS vs. Aurora operativa prestanda

Som nämnts tidigare har Amazon RDS DB-instanser och EC2-instanser IOPS-beroende av lagringsvolymer. Lagringstyperna gp2 och io1 har sina egna IOPS-gränser.

Om din arbetsbelastning kräver högre IOPS-prestanda och högre genomströmning, kanske du planerar att migrera till Aurora, som är en högpresterande, mycket tillgänglig och kostnadseffektiv lösning som lämpar sig för arbetsbelastningar med hög genomströmning. För närvarande, gryning erbjuder MySQL- och PostgreSQL-kompatibla motorer.

När du använder Aurora, se till att det tekniskt inte finns någon gräns för IOPS men genomströmningen kan begränsas till det underliggande Aurora exempel begränsa. För bättre genomströmning, gå för en högre Aurora-instansklass.

Aurora är bäst lämpad för applikationer som kräver liten eller ingen latens för en given IOPS. Den är utformad för att hantera en hög datahastighet som ger högre genomströmning jämfört med traditionella MySQL- och PostgreSQL-motorer. Eftersom den är en radbutiksdatabas är den idealisk för höga volymer, höga samtidiga OLTP-arbetsbelastningar.

Ett annat användningsfall av Aurora är hybrid transaktionsanalytisk bearbetning (HTAP). Aurora stöder upp till 15 repliker. Var och en av dessa repliker körs inom 15–20 millisekunder från skrivinstansen. Med den nyligen tillagda Amazon Aurora Parallel Query-funktion , sökbearbetning skjuts senare till Aurora-lagring. Frågan använder potentiellt tusentals lagringsnoder i ett Aurora-kluster för att bearbeta, förfina och samla data innan den skickas till beräkningsnoden.

Slutsats

I det här inlägget lärde du dig om bästa lagringspraxis för att köra en produktionsbelastning på Amazon RDS DB-instanser och EC2-instansbaserade databaser. Dessa metoder involverade följande:

  • Tilldela läsarbetsbelastningar till en läsreplika.
  • Förstå IOPS-kapacitet och dess beroende av lagringsstorlek och typ.
  • Ändra applikationsarkitektur.
  • Undersöker RAID-alternativ.
  • Övervakning av CloudWatch-statistik.

Du lärde dig också om Aurora och hur dess proprietära lagring fungerar annorlunda än EBS-volymer. All denna kunskap hjälper dig att köra en produktionsbelastning smidigt och utan problem på AWS-databaser. Du kan också titta på detaljerna om hur Aurora hanterar hastigheten och tillgängligheten för databaser med lagringslager i detta databasblogginlägg: Vi presenterar Aurora Storage Engine.

Dölj