Автоматично мащабиране с Amazon Aurora без сървър

Amazon Aurora Serverless предоставя при поискване, автоматично мащабируема, високодостъпна, релационна база данни, която ви таксува само когато се използва. Той предоставя сравнително проста, рентабилна опция за редки, периодични или непредвидими натоварвания. Това, което прави това възможно е, че автоматично се стартира, мащабира изчислителния капацитет, за да съответства на употребата на приложението ви, и след това се изключва, когато вече не е необходимо.

Следната диаграма показва архитектура на високо ниво без сървър Aurora.

С Aurora Serverless получавате една крайна точка (за разлика от две крайни точки за стандартната предоставена от Aurora DB). Това е основно DNS запис, състоящ се от флота от прокси сървъри, които се намират отгоре на екземпляра на базата данни. От точка на MySQL сървър това означава, че връзките винаги идват от прокси флота.

Автоматично мащабиране без сървър Aurora

Aurora Serverless в момента е достъпна само за MySQL 5.6. По принцип трябва да зададете минимална и максимална единица за капацитет за DB клъстера. Всяка единица за капацитет е еквивалентна на специфична конфигурация за изчисление и памет. Aurora Serverless намалява ресурсите за DB клъстера, когато работното му натоварване е под тези прагове. Aurora Serverless може да намали капацитета до минимум или да увеличи капацитета до максимален капацитет.

Клъстерът автоматично ще се увеличи ако е изпълнено някое от следните условия:

Използването на процесора е над 70% ИЛИ
Повече от 90% от връзките се използват

Клъстерът автоматично ще намалее, ако са изпълнени и двете от следните условия:

Използването на процесора пада под 30% И
Използват се по-малко от 40% от връзките.

Някои от забележителните неща, които трябва да знаете за потока за автоматично мащабиране на Aurora:

Увеличава се само когато открие проблеми с производителността, които могат да бъдат разрешени чрез увеличаване.
След увеличаване на мащаба периодът на охлаждане за намаляване е 15 минути.
След намаляване на мащаба периодът на охлаждане за следващото повторно намаляване е 310 секунди.
Мащабира се до нулев капацитет, когато няма връзки за период от 5 минути.

По подразбиране Aurora Serverless извършва автоматичното мащабиране безпроблемно, без да прекъсва никакви активни връзки към базата данни със сървъра. Той е в състояние да определи точка на мащабиране (момент от време, в който базата данни може безопасно да започне операцията за мащабиране). При следните условия обаче Aurora Serverless може да не успее да намери точка на мащабиране:

В ход са продължителни заявки или транзакции.
Използват се временни таблици или ключалки.

Ако се случи някой от горните случаи, Aurora Serverless продължава да се опитва да намери точка за мащабиране, за да може да инициира операцията за мащабиране (освен ако „Принудително мащабиране“ не е активирано). Прави това, докато определи, че DB клъстерът трябва да бъде мащабиран.

Наблюдаване на поведението при автоматично мащабиране на Aurora

Обърнете внимание, че в Aurora Serverless само малък брой параметри могат да бъдат променени и max_connections не е един от тях. За всички останали конфигурационни параметри, клъстерите без сървър Aurora MySQL използват стойностите по подразбиране. За max_connections той се управлява динамично от Aurora Serverless, като се използва следната формула:

max_connections =НАЙ-ГОЛЯМ({log(DBInstanceClassMemory/805306368)*45},{log(DBInstanceClassMemory/8187281408)*1000})

Където дневникът е log₂ (log base-2) и „DBInstanceClassMemory“ е броят байтове памет, разпределени на класа на DB екземпляр, свързан с текущия DB екземпляр, намален с паметта, използвана от процесите на Amazon RDS, които управляват екземпляра. Доста е трудно да се определи предварително стойността, която Aurora ще използва, затова е добре да направите някои тестове, за да разберете как тази стойност се мащабира съответно.

Ето нашето резюме за внедряване без сървър Aurora за този тест:

За този пример съм избрал минимум 1 единица с капацитет Aurora, която се равнява на 2GB RAM до максималния 256 капацитет с 488GB RAM.

Тестовете бяха извършени с помощта на sysbench, чрез просто изпращане на множество нишки, докато достигне лимита на връзките към базата данни MySQL. Първият ни опит да изпратим 128 едновременни връзки към база данни наведнъж претърпя пълен провал:

$ 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 \
run

Горената команда незабавно върна грешката „Твърде много връзки“:

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 connections

Когато разгледахме настройките на max_connection, получихме следното:

mysql> SELECT @@hostname, @@max_connections;
+----------------+-------------------+
| @@hostname     | @@max_connections |
+----------------+-------------------+
| ip-10-2-56-105 |                90 |
+----------------+-------------------+

Оказва се, че началната стойност на max_connections за нашия екземпляр Aurora с един DB капацитет (2GB RAM) е 90. Това всъщност е много по-ниско от очакваната ни стойност, ако се изчисли с помощта на предоставената формула за оценка на max_connections стойност:

mysql> SELECT GREATEST({log2(2147483648/805306368)*45},{log2(2147483648/8187281408)*1000});
+------------------------------------------------------------------------------+
| GREATEST({log2(2147483648/805306368)*45},{log2(2147483648/8187281408)*1000}) |
+------------------------------------------------------------------------------+
|                                                                     262.2951 |
+------------------------------------------------------------------------------+

Това просто означава, че DBInstanceClassMemory не е равна на действителната памет за екземпляр Aurora. Трябва да е доста по-ниско. Според тази дискусионна тема стойността на променливата се коригира, за да отчете паметта, която вече се използва за услугите на ОС и демона за управление на RDS.

Въпреки това, промяната на стойността на max_connections по подразбиране на нещо по-високо също няма да ни помогне, тъй като тази стойност се контролира динамично от клъстер без сървър Aurora. По този начин трябваше да намалим стойността на началните нишки на sysbench до 84, тъй като вътрешните нишки на Aurora вече резервираха около 4 до 5 връзки чрез 'rdsadmin'@'localhost'. Освен това имаме нужда и от допълнителна връзка за целите на нашето управление и наблюдение.

Така че вместо това изпълнихме следната команда (с --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 \
run

След като горният тест приключи за 10 минути (--time=600), изпълнихме същата команда отново и по това време някои от забележителните променливи и състоянието се промениха, както е показано по-долу:

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    |
+--------------+-----------------+-------------------+--------+

Забележете, че max_connections вече се удвои до 180, с различно име на хост и малко време на работа, сякаш сървърът току-що започваше. От гледна точка на приложението изглежда, че друг „по-голям екземпляр на базата данни“ е поел крайната точка и е конфигуриран с различна променлива max_connections. Гледайки събитието Aurora, се случи следното:

Wed, 04 Sep 2019 08:50:56 GMT The DB cluster has scaled from 1 capacity unit to 2 capacity units.

След това задействахме същата команда sysbench, създавайки още 84 връзки към крайната точка на базата данни. След завършване на генерирания стрес тест сървърът автоматично мащабира до 4 DB капацитет, както е показано по-долу:

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    |
+---------------+-----------------+-------------------+--------+

Можете да разберете, като погледнете различното име на хост, max_connection и стойност на ъптайм в сравнение с предишната. Други по-големи екземпляри "поеха" ролята от предишния екземпляр, където капацитетът на DB беше равен на 2. Действителната точка на мащабиране е, когато натоварването на сървъра падаше и почти падаше на пода. В нашия тест, ако поддържахме връзката пълна и натоварването на базата данни постоянно високо, автоматичното мащабиране нямаше да се осъществи.

Като разгледаме и двете екранни снимки по-долу, можем да кажем, че мащабирането се случва само когато нашият Sysbench е завършил стрес теста за 600 секунди, защото това е най-сигурната точка за извършване на автоматично мащабиране.

Капацитет на DB без сървър Използване на процесора

Използване на процесора

Когато гледахме събитията на Аврора, се случиха следните събития:

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.

Накрая генерирахме много повече връзки до почти 270 и изчакахме, докато приключи, за да влезем в капацитета от 8 DB:

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    |
+---------------+-----------------+-------------------+--------+

В екземпляра с 8 единици капацитет стойността на MySQL max_connections вече е 1000. Повторихме подобни стъпки, като увеличихме максимално връзките към базата данни и до ограничението от 256 единици капацитет. Следната таблица обобщава общия DB капацитет спрямо стойността на max_connections в нашето тестване до максималния капацитет на DB:

Принудително мащабиране

Както беше споменато по-горе, Aurora Serverless ще извърши автоматично мащабиране само когато е безопасно да го направи. Въпреки това, потребителят има опцията да принуди мащабирането на капацитета на DB да се случи незабавно, като постави отметка в квадратчето за отметка Принудително мащабиране под опцията „Допълнителна конфигурация за мащабиране“:

Когато принудителното мащабиране е активирано, мащабирането става веднага щом изтече времето за изчакване достигнат, което е 300 секунди. Това поведение може да причини прекъсване на базата данни от вашето приложение, при което активните връзки към базата данни могат да бъдат прекъснати. Наблюдавахме следната грешка, когато се случи принудително автоматично мащабиране, след като изтече времето за изчакване:

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.

Гореното просто означава, че вместо да намери подходящото време за увеличаване, Aurora Serverless принуждава подмяната на екземпляра да се извърши веднага след достигане на времето за изчакване, което води до прекратяване на транзакциите и обратно възстановяване. Повторният опит на прекъснатата заявка за втори път вероятно ще реши проблема. Тази конфигурация може да се използва, ако приложението ви е устойчиво на прекъсвания на връзката.

Резюме

Автоматичното мащабиране без сървър на Amazon Aurora е решение за вертикално мащабиране, при което по-мощен екземпляр поема по-нисък екземпляр, използвайки ефективно основната технология за споделено съхранение на Aurora. По подразбиране операцията за автоматично мащабиране се извършва безпроблемно, при което Aurora намира безопасна точка на мащабиране, за да извърши превключването на екземпляра. Човек има възможност да принуди автоматично мащабиране с рискове от прекратяване на активни връзки към базата данни.