Amazon Aurora Serverless biedt een on-demand, automatisch schaalbare, zeer beschikbare, relationele database die alleen kosten in rekening brengt wanneer deze in gebruik is. Het biedt een relatief eenvoudige, kosteneffectieve optie voor onregelmatige, intermitterende of onvoorspelbare workloads. Wat dit mogelijk maakt, is dat het automatisch opstart, de rekencapaciteit schaalt om overeen te komen met het gebruik van uw toepassing en vervolgens wordt uitgeschakeld wanneer het niet langer nodig is.
Het volgende diagram toont Aurora Serverless architectuur op hoog niveau.
Met Aurora Serverless krijg je één eindpunt (in tegenstelling tot twee eindpunten voor de standaard door Aurora ingerichte DB). Dit is in feite een DNS-record dat bestaat uit een vloot van proxy's die zich bovenop de database-instantie bevinden. Vanaf een MySQL-serverpunt betekent dit dat de verbindingen altijd afkomstig zijn van de proxyvloot.
Aurora Serverloos automatisch schalen
Aurora Serverless is momenteel alleen beschikbaar voor MySQL 5.6. U moet in principe de minimum- en maximumcapaciteitseenheid voor het DB-cluster instellen. Elke capaciteitseenheid is gelijk aan een specifieke reken- en geheugenconfiguratie. Aurora Serverless vermindert de bronnen voor het DB-cluster wanneer de werkbelasting onder deze drempels ligt. Aurora Serverless kan de capaciteit tot het minimum verlagen of de capaciteit verhogen tot de maximale capaciteit.
Het cluster wordt automatisch opgeschaald als aan een van de volgende voorwaarden wordt voldaan:
- CPU-gebruik is meer dan 70% OF
- Meer dan 90% van de verbindingen wordt gebruikt
Het cluster wordt automatisch kleiner als aan beide van de volgende voorwaarden wordt voldaan:
- CPU-gebruik daalt tot onder 30% EN
- Minder dan 40% van de verbindingen wordt gebruikt.
Enkele opmerkelijke dingen die u moet weten over de automatische schaalstroom van Aurora:
- Het schaalt alleen op wanneer het prestatieproblemen detecteert die kunnen worden opgelost door op te schalen.
- Na opschalen is de afkoelperiode voor opschalen 15 minuten.
- Na het terugschalen is de afkoelperiode voor de volgende terugschaaltijd 310 seconden.
- Het schaalt naar nul capaciteit wanneer er gedurende een periode van 5 minuten geen verbindingen zijn.
Aurora Serverless voert de automatische schaling standaard naadloos uit, zonder actieve databaseverbindingen met de server te verbreken. Het is in staat om een schaalpunt te bepalen (een tijdstip waarop de database de schaalbewerking veilig kan starten). Onder de volgende omstandigheden kan Aurora Serverless echter geen schaalpunt vinden:
- Langlopende zoekopdrachten of transacties zijn in uitvoering.
- Tijdelijke tafels of tafelsloten zijn in gebruik.
Als een van de bovenstaande gevallen zich voordoet, blijft Aurora Serverless proberen een schaalpunt te vinden zodat het de schaalbewerking kan starten (tenzij "Forceer schalen" is ingeschakeld). Het doet dit zolang het bepaalt dat het DB-cluster moet worden geschaald.
Het gedrag van Aurora automatisch schalen observeren
Merk op dat in Aurora Serverless slechts een klein aantal parameters kan worden gewijzigd en max_connections is daar niet een van. Voor alle andere configuratieparameters gebruiken Aurora MySQL Serverless-clusters de standaardwaarden. Voor max_connections wordt het dynamisch bestuurd door Aurora Serverless met behulp van de volgende formule:
max_connections =GROOTSTE({log(DBInstanceClassMemory/805306368)*45},{log(DBInstanceClassMemory/8187281408)*1000})
Waar, log is log2 (log base-2) en "DBInstanceClassMemory" is het aantal bytes geheugen dat is toegewezen aan de DB-instantieklasse die is gekoppeld aan de huidige DB-instantie, minus het geheugen dat wordt gebruikt door de Amazon RDS-processen die de instantie beheren. Het is vrij moeilijk om vooraf te bepalen welke waarde Aurora zal gebruiken, dus het is goed om wat tests uit te voeren om te begrijpen hoe deze waarde dienovereenkomstig wordt geschaald.
Hier is ons Aurora Serverless-implementatieoverzicht voor deze test:
Voor dit voorbeeld heb ik minimaal 1 Aurora-capaciteitseenheid geselecteerd, wat gelijk is aan 2 GB RAM tot de maximale capaciteit van 256 met 488 GB RAM.
Tests zijn uitgevoerd met sysbench, door simpelweg meerdere threads te versturen totdat de limiet van MySQL-databaseverbindingen is bereikt. Onze eerste poging om 128 gelijktijdige databaseverbindingen in één keer uit te sturen, liep op een regelrechte mislukking uit:
$ sysbench \
/usr/share/sysbench/oltp_read_write.lua \
--report-interval=2 \
--threads=128 \
--delete_inserts=5 \
--time=360 \
--max-requests=0 \
--db-driver=mysql \
--db-ps-mode=disable \
--mysql-host=${_HOST} \
--mysql-user=sbtest \
--mysql-db=sbtest \
--mysql-password=password \
--tables=20 \
--table-size=100000 \
runDe bovenstaande opdracht gaf onmiddellijk de foutmelding 'Te veel verbindingen':
FATAL: unable to connect to MySQL server on host 'aurora-sysbench.cluster-cdw9q2wnb00s.ap-southeast-1.rds.amazonaws.com', port 3306, aborting...
FATAL: error 1040: Too many connectionsAls we naar de max_connection-instellingen kijken, zien we het volgende:
mysql> SELECT @@hostname, @@max_connections;
+----------------+-------------------+
| @@hostname | @@max_connections |
+----------------+-------------------+
| ip-10-2-56-105 | 90 |
+----------------+-------------------+Het blijkt dat de startwaarde van max_connections voor onze Aurora-instantie met één DB-capaciteit (2 GB RAM) 90 is. Dit is in feite veel lager dan onze verwachte waarde, indien berekend met behulp van de verstrekte formule om de max_connections waarde:
mysql> SELECT GREATEST({log2(2147483648/805306368)*45},{log2(2147483648/8187281408)*1000});
+------------------------------------------------------------------------------+
| GREATEST({log2(2147483648/805306368)*45},{log2(2147483648/8187281408)*1000}) |
+------------------------------------------------------------------------------+
| 262.2951 |
+------------------------------------------------------------------------------+Dit betekent simpelweg dat de DBInstanceClassMemory niet gelijk is aan het daadwerkelijke geheugen voor de Aurora-instantie. Het moet veel lager. Volgens deze discussiethread wordt de waarde van de variabele aangepast om rekening te houden met geheugen dat al in gebruik is voor OS-services en RDS-beheerdaemon.
Desalniettemin zal het veranderen van de standaard max_connections-waarde naar iets hoger ons ook niet helpen, aangezien deze waarde dynamisch wordt beheerd door het Aurora Serverless-cluster. We moesten dus de waarde van de sysbench-startthreads verlagen naar 84 omdat de interne Aurora-threads al ongeveer 4 tot 5 verbindingen hadden gereserveerd via 'rdsadmin'@'localhost'. Bovendien hebben we ook een extra aansluiting nodig voor onze beheer- en monitoringdoeleinden.
Dus hebben we in plaats daarvan het volgende commando uitgevoerd (met --threads=84):
$ sysbench \
/usr/share/sysbench/oltp_read_write.lua \
--report-interval=2 \
--threads=84 \
--delete_inserts=5 \
--time=600 \
--max-requests=0 \
--db-driver=mysql \
--db-ps-mode=disable \
--mysql-host=${_HOST} \
--mysql-user=sbtest \
--mysql-db=sbtest \
--mysql-password=password \
--tables=20 \
--table-size=100000 \
runNadat de bovenstaande test in 10 minuten (--time=600) was voltooid, hebben we dezelfde opdracht opnieuw uitgevoerd en op dit moment waren enkele van de opmerkelijke variabelen en status veranderd, zoals hieronder wordt weergegeven:
mysql> SELECT @@hostname AS hostname, @@max_connections AS max_connections,
(SELECT VARIABLE_VALUE FROM global_status WHERE VARIABLE_NAME = 'THREADS_CONNECTED') AS threads_connected,
(SELECT VARIABLE_VALUE FROM global_status WHERE VARIABLE_NAME = 'UPTIME') AS uptime;
+--------------+-----------------+-------------------+--------+
| hostname | max_connections | threads_connected | uptime |
+--------------+-----------------+-------------------+--------+
| ip-10-2-34-7 | 180 | 179 | 157 |
+--------------+-----------------+-------------------+--------+Merk op dat de max_connections nu verdubbeld zijn tot 180, met een andere hostnaam en een kleine uptime, alsof de server net begon. Vanuit het oogpunt van de toepassing lijkt het erop dat een andere "grotere database-instantie" het eindpunt heeft overgenomen en geconfigureerd met een andere max_connections-variabele. Kijkend naar het Aurora-evenement, is het volgende gebeurd:
Wed, 04 Sep 2019 08:50:56 GMT The DB cluster has scaled from 1 capacity unit to 2 capacity units.Vervolgens hebben we hetzelfde sysbench-commando gestart, waardoor nog eens 84 verbindingen met het database-eindpunt zijn gemaakt. Nadat de gegenereerde stresstest is voltooid, wordt de server automatisch opgeschaald naar een capaciteit van 4 DB, zoals hieronder weergegeven:
mysql> SELECT @@hostname AS hostname, @@max_connections AS max_connections,
(SELECT VARIABLE_VALUE FROM global_status WHERE VARIABLE_NAME = 'THREADS_CONNECTED') AS threads_connected,
(SELECT VARIABLE_VALUE FROM global_status WHERE VARIABLE_NAME = 'UPTIME') AS uptime;
+---------------+-----------------+-------------------+--------+
| hostname | max_connections | threads_connected | uptime |
+---------------+-----------------+-------------------+--------+
| ip-10-2-12-75 | 270 | 6 | 300 |
+---------------+-----------------+-------------------+--------+Je kunt het zien door te kijken naar de verschillende hostnaam, max_connection en uptime-waarde in vergelijking met de vorige. Een andere grotere instantie heeft de rol "overgenomen" van de vorige instantie, waar de DB-capaciteit gelijk was aan 2. Het werkelijke schaalpunt is wanneer de serverbelasting daalde en bijna de grond raakte. Als we in onze test de verbinding vol zouden houden en de databasebelasting constant hoog, zou automatisch schalen niet plaatsvinden.
Als we naar beide screenshots hieronder kijken, kunnen we zien dat het schalen alleen plaatsvindt wanneer onze Sysbench de stresstest van 600 seconden heeft voltooid, omdat dat het veiligste punt is om automatisch te schalen.
Serverloze DB-capaciteit CPU-gebruik 
CPU-gebruik Als we kijken naar Aurora-gebeurtenissen, gebeurden de volgende gebeurtenissen:
Wed, 04 Sep 2019 16:25:00 GMT Scaling DB cluster from 4 capacity units to 2 capacity units for this reason: Autoscaling.
Wed, 04 Sep 2019 16:25:05 GMT The DB cluster has scaled from 4 capacity units to 2 capacity units.Eindelijk hebben we veel meer verbindingen gegenereerd tot bijna 270 en wachten tot het klaar is, om in de 8 DB-capaciteit te komen:
mysql> SELECT @@hostname as hostname, @@max_connections AS max_connections,
(SELECT VARIABLE_VALUE FROM global_status WHERE VARIABLE_NAME = 'THREADS_CONNECTED') AS threads_connected,
(SELECT VARIABLE_VALUE FROM global_status WHERE VARIABLE_NAME = 'UPTIME') AS uptime;
+---------------+-----------------+-------------------+--------+
| hostname | max_connections | threads_connected | uptime |
+---------------+-----------------+-------------------+--------+
| ip-10-2-72-12 | 1000 | 144 | 230 |
+---------------+-----------------+-------------------+--------+In de instantie met 8 capaciteitseenheden is de MySQL max_connections-waarde nu 1000. We herhaalden vergelijkbare stappen door de databaseverbindingen te maximaliseren en tot de limiet van 256 capaciteitseenheden. De volgende tabel geeft een overzicht van de totale DB-capaciteitseenheid versus max_connections-waarde in onze tests tot de maximale DB-capaciteit:
Geforceerd schalen
Zoals hierboven vermeld, zal Aurora Serverless alleen automatisch schalen als het veilig is om dit te doen. De gebruiker heeft echter de mogelijkheid om het schalen van de DB-capaciteit onmiddellijk te forceren door het selectievakje Schaal forceren aan te vinken onder de optie 'Aanvullende schalingsconfiguratie':
Als geforceerd schalen is ingeschakeld, vindt het schalen plaats zodra de time-out is verstreken. bereikt, wat 300 seconden is. Dit gedrag kan een database-onderbreking van uw toepassing veroorzaken, waardoor actieve verbindingen met de database kunnen worden verbroken. We hebben de volgende fout waargenomen toen geforceerd automatisch schalen plaatsvond nadat de time-out was bereikt:
FATAL: mysql_drv_query() returned error 1105 (The last transaction was aborted due to an unknown error. Please retry.) for query 'SELECT c FROM sbtest19 WHERE id=52824'
FATAL: `thread_run' function failed: /usr/share/sysbench/oltp_common.lua:419: SQL error, errno = 1105, state = 'HY000': The last transaction was aborted due to an unknown error. Please retry.Het bovenstaande betekent simpelweg dat Aurora Serverless, in plaats van het juiste moment te vinden om op te schalen, de vervanging van de instantie dwingt onmiddellijk na het bereiken van de time-out plaats te vinden, waardoor transacties worden afgebroken en teruggedraaid. Als u de afgebroken zoekopdracht voor de tweede keer opnieuw probeert, wordt het probleem waarschijnlijk opgelost. Deze configuratie kan worden gebruikt als uw toepassing bestand is tegen verbroken verbindingen.
Samenvatting
Amazon Aurora Serverless automatisch schalen is een verticale schaaloplossing, waarbij een krachtigere instantie een inferieure instantie overneemt, waarbij efficiënt gebruik wordt gemaakt van de onderliggende Aurora shared storage-technologie. Standaard wordt de automatische schaalbewerking naadloos uitgevoerd, waarbij Aurora een veilig schaalpunt vindt om de instantiewisseling uit te voeren. Men heeft de optie om automatisch schalen af te dwingen met het risico dat actieve databaseverbindingen worden verbroken.