Beheer van productieworkloads op gehoste databases

Geleverd door Amazon-webservices

AWS biedt meerdere opties om uw databases te hosten die OLTP-workloads bedienen - host uw eigen beheerde database op Amazon EC2 instanties of gebruik Amazon RDS beheerd door AWS. RDS beheert hoge beschikbaarheid, geautomatiseerde back-ups, database-upgrades, OS-patches, beveiliging en leesreplica. RDS biedt ook de cloud-native optie Amazone-Aurora database-engine, die compatibel is met MySQL en PostgreSQL. Aurora levert een hogere doorvoer in vergelijking met de standaard MySQL- en PostgreSQL-databases.

Tijdens het uitvoeren van productieworkloads op gehoste databases met Amazon RDS of Amazon EC2, bent u mogelijk de volgende vragen tegengekomen:

• Wat zijn de beste opties voor het type databaseopslag?
• Hoe problemen met opslagprestaties oplossen?
• Wat zijn de RAID-configuratieopties voor door EC2 gehoste databases?
• Wat zijn de applicatie-aanpassingen voor optimale prestaties?
• Problemen met opslagprestaties oplossen met: Amazon CloudWatch ?
• Amazon RDS versus Aurora operationele prestaties?

In dit bericht geef ik de beste opslagmethoden voor het uitvoeren van productieworkloads op Amazon RDS- of EC2-instantie-gehoste databases.

Vergeleken met test-, QA- of staging-omgevingen, vereisen productieworkloads snelle en consistente I/O-prestaties. Hoewel relationele databases voor meerdere doeleinden kunnen worden gebruikt, is hun meest voorkomende gebruik het hosten van een werklast voor online transactieverwerking (OLTP). RDS, door EC2 gehoste databases en Aurora gebruiken verschillende soorten opslagtechnieken, zoals hieronder weergegeven:

• Amazon RDS-database-instanties gebruiken Amazon EBS volumes voor opslag.
• Aurora-instanties gebruiken eigen opslagvolumes van AWS.
• EC2-instanties bieden een verscheidenheid aan opties voor opslag.

Beste opties voor databaseopslagtype

Amazon RDS biedt: drie soorten opslag :

• SSD voor algemeen gebruik (ook bekend als gp2-volumes )
• Voorzien IOPS SSD (ook bekend als io1 )
• Magnetisch

De I/O-capaciteit van het exemplaar is gebaseerd op het opslagtype en de grootte van het exemplaar. Als de DB-instance is geconfigureerd met een gp2-volume, is de baseline IOPS-capaciteit 3x de GiB-opslag. Als de DB-instantie een gp2-volume van 100 GiB heeft toegewezen, is de basis-IOPS-capaciteit 300. Hoe meer opslagruimte u inricht, hoe hoger de IOPS-capaciteit.

Naast de baseline IOPS-capaciteit, leveren gp2-volumes ook burst-capaciteit tot 3.000 IOPS voor langere tijd. De burst-functie is beperkt tot volumes gelijk aan of minder dan 1 TiB aan opslag. DB-instances voor MySQL, MariaDB, Oracle en PostgreSQL kunnen worden geconfigureerd met 20 GiB–32 TiB, maar de maximale baseline-IOPS is beperkt van 100 tot 16.000 IOPS. Een gp2-volume van 5,34 TiB of meer levert dus dezelfde basislijn op: 16.000 IOPS.

Als uw productieworkload een hoge OLTP en snelle, consistent hoge doorvoerprestaties vereist, moet u uw DB-instantie configureren met io1-volumes. Vergeleken met gp2-volumes, die een maximale basislijn van 16.000 IOPS leveren, kunnen io1-volumes tot 40.000 IOPS leveren voor DB-instances voor MySQL, MariaDB, Oracle en PostgreSQL en tot 32.000 voor SQL Server-instances.

Als u merkt dat het patroon van IOPS-gebruik consequent meer dan 16.000 overschrijdt, moet u: wijzig de DB instanceen verander het opslagtype van gp2 in io1. Amazon RDS biedt ook magnetische opslag, maar het is niet geschikt voor een OLTP-workload die consistente I/O-prestaties en lage latentie vereist.

Het magnetische opslagtype wordt niet aanbevolen voor I/O-intensieve workloads omdat de maximale opslag minder is dan die van gp2 of io1. Ook is de IOPS-capaciteit beperkt tot maximaal 1.000 IOPS.

Problemen met opslagprestaties

Het gebruik van gp2-opslag is ideaal voor een breed scala aan DB-workloads. Voor dit opslagtype worden de lees- en schrijfwerkbelastingen van de architectendatabase zodanig dat de som van LeesIOPS en SchrijfIOPS waarden op geen enkel moment de basislijn-IOPS-capaciteit overschrijden.

Burst-capaciteit kan voor een langere periode beschikbaar zijn. Nadat de burst-capaciteit is gebruikt, verslechtert een consistent hoge waarde van lees- en schrijf-IOPS de prestaties van de instantie. Deze degradatie kan worden gezien door verhoogde SchrijvenLatentie of LezenLatentie waarden. Idealiter is gp2-opslag goed voor een milliseconde latentie van enkele cijfers, maar overmatig gebruik van IOPS kan een latentie van >10 ms veroorzaken.

De volgende afbeeldingen tonen verhoogde SchrijvenLatentie waarden, aangezien WriteIOPS consequent 300 IOPS-capaciteit verbruikt op een Amazon RDS DB-instantie. In dit voorbeeld wordt de Amazon RDS PostgreSQL-instantie gehost op een t2.small-instantie met een 100-GiB gp2-volume.

De bovenstaande afbeelding laat zien dat Write IOPS consistent 300 IOPS verbruikt, wat de basisprestatie is.

De bovenstaande afbeelding toont een schrijfvertraging met een piek van 25 milliseconden als gevolg van overmatig gebruik van IOPS.

Zorg er als best practice voor dat uw workload niet verder gaat dan de IOPS-capaciteit van de instance. Enkele manieren om te verminderen: LeesIOPS waarden zijn naar:

• Gebruik een Amazon RDS-leesreplica.
• Gebruik een hoger RAM-geheugen.

Een Amazon RDS-leesreplica gebruiken

Amazon RDS DB-instanties voor MySQL, MariaDB, Oracle en PostgreSQL bieden RDS-replica's lezen . Deze instances zijn afzonderlijke DB-instances die zijn gesynchroniseerd met de bron-DB-instance door transactielogboeken van de database opnieuw af te spelen. Elke wijziging van gegevens op het bron-DB-exemplaar wordt toegepast op de leesreplica. Met een leesreplica vermindert u de belasting van uw bron-DB-instantie door leesquery's van uw toepassingen naar de leesreplica te routeren. U maakt ook IOPS-capaciteit vrij voor extra schrijfactiviteit bij de bron-DB-instantie.

Bij leesreplica's is het belangrijk om de replicatievertraging te bewaken. Over het algemeen wordt een hoge replicatievertraging veroorzaakt door hoge schrijfactiviteit bij de bron-DB-instantie.

In Amazon RDS DB-instanties kunt u replicavertraging controleren aan de hand van de CloudWatch-metriek ReplicaLag . Als u een hoge replicavertraging vindt, moet u ook de schrijfactiviteit op het bron-DB-exemplaar controleren. Dit kan worden bereikt door CloudWatch-statistieken te controleren SchrijfIOPS en Schrijfdoorvoer . Als het bron-DB-exemplaar IOPS-deficiënt is (dat wil zeggen, alle IOPS-capaciteit wordt gebruikt door de schrijf- en leeswerkbelasting), blijft de replica ook achter.

Een van de redenen achter achterblijvende replica's is dat in de meeste DB-engines het herstel van leesreplica's single-treaded-processen omvat. Dat betekent dat hoe hoger de belasting bij een hoofdinstantie, hoe exponentieel langzamer herstel bij leesreplica's. Elke extra hoge schrijfactiviteit op het bron-DB-exemplaar verhoogt de leesreplicavertraging exponentieel. Afgezien van CloudWatch-statistieken, met ReplicaLag u kunt vertraging ook controleren door SQL-query's.

In PostgreSQL kan leesreplicavertraging worden berekend met de volgende query:

|__+_|

In MySQL kunt u de replicatiestatus controleren met de volgende opdracht:

|__+_|

Met een Amazon RDS-leesreplica moet u de client zo configureren dat een bepaald niveau van latentie of replicatiefout die bij een replica wordt gevonden, ertoe leidt dat een ander replica-eindpunt wordt geprobeerd om verbinding te maken.

Een goede manier om ervoor te zorgen dat uw toepassing de gezondste replica kan vinden, is door CloudWatch-statistieken aan te roepen om de huidige waarden van ReplicaLag en lees-/schrijflatentie. Replicatievertraging kan worden gevonden bij SQL-opdrachten, zoals in eerdere voorbeelden is weergegeven. U kunt de huidige staat van de replica ook vinden door de . te bellen AWS-opdrachtregelinterface (AWS CLI) opdracht omschrijven-db-instances. Als de huidige status van de replica anders is dan repliceren, moet de client proberen verbinding te maken met een andere replica.

Afgezien van het voordeel van het distribueren van leestransacties, kunnen leesreplica's ook worden gebruikt om uw gegevens te sharden. Door de niets-delen-architectuur van shards te volgen, kunt u leesreplica's maken die overeenkomen met elk van uw shards en deze promoten wanneer u besluit ze om te zetten in zelfstandige shards.

Hoger RAM gebruiken

Amazon RDS DB-instanties moeten voldoende RAM hebben, zodat uw volledige werkset zich in het geheugen bevindt. Omdat de leesquery's gegevens uit het geheugen kunnen lezen, wordt de communicatie met opslagvolumes verminderd. Als zodanig vermindert het het gebruik van LeesIOPS capaciteit die kan worden gebruikt voor schrijfdoeleinden.

Er is geen eenvoudige manier om de grootte van een werkende dataset te vinden. Kijk naar de leesquery's en ontdek hoeveel gegevens er worden geraakt. Als de grootte van een database bijvoorbeeld 100 GiB is en de werkset is 20 GiB, moet u een Amazon RDS DB-instantie met minimaal 20 GiB geheugen. Zo heb je de complete werkset in het geheugen.

RAID-configuratie-opties voor door EC2 gehoste databases

EBS-volumes zijn opslagvolumes op blokniveau die permanente blokopslag bieden. Deze volumes zijn zeer beschikbare opslagvolumes en kunnen worden gekoppeld aan een EC2-instantie in dezelfde beschikbaarheidszone. EBS-volumes zijn ideaal voor door EC2 gehoste databases. Het gebruik van kortstondige EC2-instance-opslag voor een database wordt niet aanbevolen.

Door EBS-opslagvolumes te gebruiken met EC2-instances, kunt u volumes configureren met elk RAID-niveau. Voor betere I/O-prestaties kunt u bijvoorbeeld kiezen voor RAID 0, dat meerdere volumes samen kan strippen. RAID 1 kan worden gebruikt voor gegevensredundantie omdat het twee volumes aan elkaar spiegelt.

Ongeacht de RAID-configuratie worden EBS-volumegegevens gerepliceerd over secundaire servers om gegevensverlies te voorkomen. RAID 5 en RAID 6 worden niet aanbevolen voor door EC2 gehoste databases omdat de I/O-prestaties niet zo goed zijn als RAID 0 of RAID 1.

De volgende tabel toont de voor- en nadelen tussen het gebruik van deze twee verschillende RAID-configuraties en suggereert mogelijke gebruiksscenario's.

Configuratie	Voordelen:	nadelen	Gebruiksgeval
RAID 0	I/O-prestaties superieur in vergelijking met fouttolerantie	Verlies van een enkel volume veroorzaakt volledig gegevensverlies	Als de database een hogere doorvoer vereist in vergelijking met de beschikbaarheid van gegevens en de gegevens reproduceerbaar zijn
INVAL 1	Fouttolerantie is superieur in vergelijking met I/O-prestaties	Lage schrijfprestaties	Als gegevens essentieel zijn en fouttolerantie van de database belangrijker is dan I/O-prestaties

Applicatie-aanpassingen voor optimale prestaties

Als een database-instance te maken heeft met opslagproblemen en problemen tegenkomt zoals hoge commit-tijd en hoge latenties, kunnen wijzigingen in de toepassing deze degradatie soms verminderen. U kunt toepassingen wijzigen om exponentiële uitstel of foutpogingen mogelijk te maken.

Exponentiële uitstel zorgt ervoor dat applicaties steeds langer moeten wachten tussen nieuwe pogingen voor opeenvolgende foutreacties. Terwijl sommige algoritmen incrementele vertraging gebruiken, gebruiken de meeste exponentiële uitstelalgoritmen gerandomiseerde vertraging. Hier zijn voorbeelden voor een ander algoritme:

Willekeurige vertraging:

1. Applicatie start verzoek.
2. Als het verzoek mislukt, wacht dan rand (1000,3000) milliseconden en start het verzoek opnieuw.
3. Als het verzoek mislukt, wacht dan rand (1000,3000) milliseconden en start het verzoek opnieuw.
4. Als het verzoek mislukt, wacht dan rand (1000,3000) milliseconden en start het verzoek opnieuw.

Incrementele vertraging:

1. Applicatie start verzoek.
2. Als het verzoek mislukt, wacht dan 1 = 1000 milliseconden en start het verzoek opnieuw.
3. Als het verzoek mislukt, wacht 2 = wacht 1 + 1000 milliseconden en start het verzoek opnieuw.
4. Als het verzoek mislukt, wacht 3 = wacht 2 + 1000 milliseconden en start het verzoek opnieuw.

Gebruik bepaalde best practices om een ​​snellere failover te bereiken in Amazon RDS Multi-AZ-instanties en Aurora-clusters. Schakel de keepalive-parameters van TCP in en stel ze agressief in om ervoor te zorgen dat als uw client geen verbinding meer kan maken met de DB-instantie, alle actieve verbindingen snel worden gesloten. Door deze wijziging kunnen toepassingen ook sneller reageren op failover en snel verbinding maken met het nieuwe eindpunt.

U kunt ook de time-out voor DNS-caching op de client verminderen. Lees- en schrijfverbindingen worden snel tot stand gebracht met de juiste eindpunten. Sommige van de server-TCP-instellingsparameters kunnen ook worden gewijzigd. Deze wijzigingen zorgen voor een snellere failover. In PostgreSQL kan dit bijvoorbeeld worden beheerd door de tcp_keepalives_count, tcp_keepalives_idle en tcp_keepalives_interval parameters .

Problemen met opslagprestaties oplossen met CloudWatch

Door regelmatig de status van instantieopslag te controleren, wordt het vroege begin van een prestatieprobleem geïdentificeerd voordat het ernstige gevolgen heeft voor de databaseprestaties. Enkele van de CloudWatch-gerelateerde opslagstatistieken die u regelmatig moet controleren, worden hier vermeld.

Schrijfbewerkingen

• SchrijfIOPS: Gemeten met een snelheid van tellingen per seconde, bepaalt deze CloudWatch-statistiek het gemiddelde aantal schijfschrijf-I/O-bewerkingen per seconde. Richt u op deze statistiek als uw database-exemplaar is geconfigureerd met een Multi-AZ-instelling.
  Met Multi-AZ wordt een secundair exemplaar gemaakt in een andere beschikbaarheidszone met dezelfde exemplaarconfiguratie als de master en het gekoppelde EBS-opslagvolume. Deze opslag wordt synchroon gesynchroniseerd met de hoofdinstantieopslag. Voor gegevensredundantie worden gegevens in elk EBS-volume standaard gekopieerd naar een ander, secundair EBS-volume dat zich in dezelfde beschikbaarheidszone bevindt. Dit betekent dat een schrijftransactie zich op vier plaatsen moet committen voordat een bevestiging naar de klant wordt verzonden. Enorme schrijfactiviteit boven de IOPS en doorvoercapaciteit van de instances verslechtert de algehele prestaties.
• Schrijfdoorvoer: Deze CloudWatch-statistiek vertegenwoordigt het gemiddelde aantal bytes dat per seconde naar schijf wordt geschreven. Boven de instantiedoorvoer of de opslagdoorvoerlimiet gaan, schaadt de instantieprestaties. Ik raad aan om de schrijfactiviteit te controleren en de schrijfwerkbelasting met een passende vertraging te verdelen om de prestaties te optimaliseren.
• Schrijflatentie: Dit is de gemiddelde hoeveelheid tijd die nodig is per schijf-I/O-bewerking. Meestal SchrijvenLatentie stijgingen zijn te wijten aan overmatig gebruik van de instantiebronnen, zoals CPU, IOPS en doorvoer.

Lees bewerkingen

• LeesIOPS: Gemeten met een snelheid van tellingen per seconde, bepaalt deze CloudWatch-statistiek het gemiddelde aantal schijflees-I/O-bewerkingen per seconde. De verhoogde waarde van LeesIOPS suggereert dat de leesbelasting hoog is of dat de instantie meer vrij geheugen nodig heeft.
• Leesdoorvoer: Deze statistiek vertegenwoordigt het gemiddelde aantal bytes dat per seconde van de schijf wordt gelezen. Als u boven de instantie en EBS-limieten gaat, kan de latentie toenemen.
• Leeslatentie: Dit is de gemiddelde hoeveelheid tijd die nodig is per schijf-I/O-bewerking. Als u een hoge waarde voor deze statistiek heeft, kijkt u naar de leeswerkbelasting en zorgt u ervoor dat deze niet te veel instantiebronnen gebruikt.

Andere statistieken

Naast de eerder genoemde statistieken, moet u ook de volgende CloudWatch-statistieken controleren:

• SchijfwachtrijDiepte staat voor het aantal openstaande I/O's (lees-/schrijfverzoeken) die wachten op toegang tot de schijf. Meestal is dit het gevolg van een hoge werkdruk.
• Gratis Opslagruimte bepaalt de hoeveelheid beschikbare opslagruimte. Als best practice moet u instellen: CloudWatch-waarschuwingen zodat u SNS-meldingen kunt ontvangen zodra de gratis opslagruimte van de instantie onder een drempelwaarde komt, zoals 15%.

Amazon RDS versus Aurora operationele prestaties

Zoals eerder vermeld, zijn Amazon RDS DB-instanties en EC2-instanties IOPS-afhankelijk van opslagvolumes. De opslagtypes gp2 en io1 hebben hun eigen IOPS-limieten.

Als uw workload hogere IOPS-prestaties en een hogere doorvoer vereist, kunt u van plan zijn te migreren naar Aurora, een krachtige, zeer beschikbare en kosteneffectieve oplossing die geschikt is voor workloads met een hoge doorvoer. Momenteel, ochtendgloren biedt MySQL- en PostgreSQL-compatibele engines.

Zorg er tijdens het gebruik van Aurora voor dat er technisch geen limiet is voor IOPS, maar dat de doorvoer beperkt kan zijn tot het onderliggende Aurora instantie begrenzing. Ga voor een betere doorvoer voor een hogere Aurora-instantieklasse.

Aurora is het meest geschikt voor toepassingen die weinig tot geen latentie vereisen voor een bepaalde IOPS. Het is ontworpen om een ​​hoge gegevenssnelheid te verwerken en een hogere doorvoer te bieden in vergelijking met traditionele MySQL- en PostgreSQL-engines. Omdat het een row-store-database is, is het bij uitstek geschikt voor OLTP-workloads met een hoog volume en veel gelijktijdige.

Een ander gebruiksvoorbeeld van Aurora is hybride transactie-analyseverwerking (HTAP). Aurora ondersteunt maximaal 15 replica's. Elk van deze replica's wordt uitgevoerd binnen 15-20 milliseconden van de schrijfinstantie. Met de recent toegevoegde Amazon Aurora Parallel Query-functie , wordt de queryverwerking later naar Aurora-opslag gepusht. De query gebruikt mogelijk duizenden opslagknooppunten in een Aurora-cluster om gegevens te verwerken, te verfijnen en samen te voegen voordat ze naar het rekenknooppunt worden verzonden.

Gevolgtrekking

In dit bericht heb je geleerd over de beste opslagpraktijken voor het uitvoeren van een productieworkload op Amazon RDS DB-instantie en EC2-instantie-gehoste databases. Deze praktijken betroffen het volgende:

• Lees werk belastingen toewijzen aan een lees replica.
• Inzicht in IOPS-capaciteit en de afhankelijkheid van opslaggrootte en -type.
• Applicatiearchitectuur wijzigen.
• RAID-opties onderzoeken.
• CloudWatch-statistieken bewaken.

Je hebt ook geleerd over Aurora en hoe zijn eigen opslag anders presteert dan EBS-volumes. Al deze kennis helpt u een productiewerklast soepel en zonder problemen uit te voeren op AWS-databases. U kunt ook de details bekijken van hoe Aurora omgaat met de snelheid en beschikbaarheid van de database met behulp van de opslaglaag in deze database-blogpost: Introductie van de Aurora Storage Engine.

zich verstoppen