Amazon Aurora Serverless के साथ स्वचालित स्केलिंग

Amazon Aurora Serverless एक ऑन-डिमांड, ऑटो-स्केलेबल, अत्यधिक-उपलब्ध, रिलेशनल डेटाबेस प्रदान करता है जो उपयोग में होने पर ही आपसे शुल्क लेता है। यह विरल, रुक-रुक कर या अप्रत्याशित कार्यभार के लिए अपेक्षाकृत सरल, लागत प्रभावी विकल्प प्रदान करता है। यह जो संभव बनाता है वह यह है कि यह स्वचालित रूप से शुरू होता है, आपके एप्लिकेशन के उपयोग से मेल खाने के लिए क्षमता की गणना करता है, और फिर जब इसकी आवश्यकता नहीं होती है तो बंद हो जाता है।

निम्न आरेख Aurora सर्वर रहित उच्च-स्तरीय आर्किटेक्चर दिखाता है।

Aurora Serverless के साथ, आपको एक समापन बिंदु मिलता है (जैसा कि मानक Aurora प्रावधानित DB के लिए दो समापन बिंदुओं के विपरीत है)। यह मूल रूप से एक डीएनएस रिकॉर्ड है जिसमें प्रॉक्सी का एक बेड़ा होता है जो डेटाबेस इंस्टेंस के शीर्ष पर बैठता है। एक MySQL सर्वर बिंदु से इसका मतलब है कि कनेक्शन हमेशा प्रॉक्सी बेड़े से आ रहे हैं।

अरोड़ा सर्वर रहित ऑटो-स्केलिंग

Aurora Serverless वर्तमान में केवल MySQL 5.6 के लिए उपलब्ध है। आपको मूल रूप से डीबी क्लस्टर के लिए न्यूनतम और अधिकतम क्षमता इकाई निर्धारित करनी होगी। प्रत्येक क्षमता इकाई एक विशिष्ट गणना और स्मृति विन्यास के बराबर है। Aurora Serverless DB क्लस्टर के लिए संसाधनों को कम करता है जब इसका कार्यभार इन थ्रेसहोल्ड से नीचे होता है। Aurora Serverless क्षमता को न्यूनतम तक कम कर सकता है या क्षमता को अधिकतम क्षमता इकाई तक बढ़ा सकता है।

यदि निम्न में से कोई भी शर्त पूरी होती है तो क्लस्टर अपने आप बड़ा हो जाएगा:

• CPU उपयोग 70% से ऊपर है या
• 90% से अधिक कनेक्शन का उपयोग किया जा रहा है

यदि निम्नलिखित दोनों शर्तें पूरी होती हैं, तो क्लस्टर अपने आप छोटा हो जाएगा:

• CPU उपयोग 30% से नीचे चला जाता है और
• 40% से कम कनेक्शन का उपयोग किया जा रहा है।

अरोड़ा स्वचालित स्केलिंग प्रवाह के बारे में जानने योग्य कुछ उल्लेखनीय बातें:

• यह केवल तभी बड़ा होता है जब यह उन प्रदर्शन समस्याओं का पता लगाता है जिन्हें स्केल करके हल किया जा सकता है।
• स्केलिंग अप के बाद, स्केलिंग डाउन के लिए कूलडाउन अवधि 15 मिनट है।
• स्केलिंग डाउन के बाद, अगली स्केलिंग डाउन के लिए कूलडाउन अवधि 310 सेकंड है।
• 5 मिनट की अवधि के लिए कोई कनेक्शन नहीं होने पर यह शून्य क्षमता तक बढ़ जाता है।

डिफ़ॉल्ट रूप से, Aurora Serverless सर्वर से किसी भी सक्रिय डेटाबेस कनेक्शन को काटे बिना, निर्बाध रूप से स्वचालित स्केलिंग करता है। यह एक स्केलिंग पॉइंट निर्धारित करने में सक्षम है (एक ऐसा समय जिस पर डेटाबेस सुरक्षित रूप से स्केलिंग ऑपरेशन शुरू कर सकता है)। हालांकि, निम्न स्थितियों के तहत, Aurora Serverless को एक स्केलिंग बिंदु नहीं मिल सकता है:

• लंबे समय से चल रहे प्रश्न या लेन-देन प्रगति पर हैं।
• अस्थायी टेबल या टेबल लॉक उपयोग में हैं।

यदि उपरोक्त में से कोई भी मामला होता है, तो Aurora Serverless एक स्केलिंग बिंदु खोजने का प्रयास जारी रखता है ताकि वह स्केलिंग ऑपरेशन शुरू कर सके (जब तक कि "फोर्स स्केलिंग" सक्षम न हो)। यह तब तक करता है जब तक यह निर्धारित करता है कि डीबी क्लस्टर को बढ़ाया जाना चाहिए।

अरोड़ा ऑटो स्केलिंग व्यवहार का अवलोकन करना

ध्यान दें कि Aurora Serverless में, केवल कुछ ही पैरामीटर संशोधित किए जा सकते हैं और max_connections उनमें से एक नहीं है। अन्य सभी कॉन्फ़िगरेशन पैरामीटर के लिए, Aurora MySQL सर्वर रहित क्लस्टर डिफ़ॉल्ट मानों का उपयोग करते हैं। max_connections के लिए, इसे निम्न सूत्र का उपयोग करके Aurora Serverless द्वारा गतिशील रूप से नियंत्रित किया जाता है: 

max_connections =GREATEST({log(DBInstanceClassMemory/805306368)*45},{log(DBInstanceClassMemory/8187281408)*1000})

जहां लॉग लॉग होता है₂ (लॉग बेस-2) और "DBInstanceClassMemory" वर्तमान डीबी इंस्टेंस से जुड़े डीबी इंस्टेंस क्लास को आवंटित मेमोरी के बाइट्स की संख्या है, अमेज़ॅन आरडीएस प्रक्रियाओं द्वारा उपयोग की जाने वाली मेमोरी कम है जो इंस्टेंस का प्रबंधन करती है। Aurora द्वारा उपयोग किए जाने वाले मान को पूर्वनिर्धारित करना बहुत कठिन है, इस प्रकार यह समझने के लिए कुछ परीक्षण करना अच्छा है कि यह मान तदनुसार कैसे बढ़ाया जाता है।

इस परीक्षण के लिए हमारा Aurora सर्वर रहित परिनियोजन सारांश यहां दिया गया है:

इस उदाहरण के लिए मैंने कम से कम 1 Aurora क्षमता वाली इकाई का चयन किया है, जो 488GB RAM वाली अधिकतम 256 क्षमता इकाई तक 2GB 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 |
+----------------+-------------------+

यह पता चला है, एक DB क्षमता (2GB RAM) के साथ हमारे Aurora इंस्टेंस के लिए max_connections का शुरुआती मान 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 औरोरा उदाहरण के लिए वास्तविक मेमोरी के बराबर नहीं है। यह बहुत कम होना चाहिए। इस चर्चा सूत्र के अनुसार, चर का मान OS सेवाओं और RDS प्रबंधन डेमॉन के लिए पहले से उपयोग की जा रही मेमोरी के हिसाब से समायोजित किया जाता है।

फिर भी, डिफ़ॉल्ट max_connections मान को किसी उच्चतर में बदलने से हमें कोई मदद नहीं मिलेगी क्योंकि यह मान गतिशील रूप से Aurora Serverless क्लस्टर द्वारा नियंत्रित किया जाता है। इस प्रकार, हमें sysbench के शुरुआती थ्रेड्स के मान को 84 तक कम करना पड़ा क्योंकि ऑरोरा आंतरिक थ्रेड्स पहले से ही 'rdsadmin'@'localhost' के माध्यम से लगभग 4 से 5 कनेक्शन आरक्षित कर चुके हैं। साथ ही, हमें अपने प्रबंधन और निगरानी उद्देश्यों के लिए एक अतिरिक्त कनेक्शन की भी आवश्यकता है।

इसलिए हमने इसके बजाय निम्नलिखित कमांड निष्पादित की (--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 चर के साथ कॉन्फ़िगर किया गया है। औरोरा घटना को देखते हुए, निम्नलिखित हुआ है:

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

फिर, हमने उसी sysbench कमांड को सक्रिय किया, जिससे डेटाबेस एंडपॉइंट के लिए अन्य 84 कनेक्शन बन गए। उत्पन्न तनाव परीक्षण पूरा होने के बाद, सर्वर स्वचालित रूप से 4 डीबी क्षमता तक बढ़ जाता है, जैसा कि नीचे दिखाया गया है:

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 और अपटाइम मान को देखकर बता सकते हैं। एक और बड़े उदाहरण ने पिछले उदाहरण से भूमिका को "अधिग्रहण" कर लिया है, जहां डीबी क्षमता 2 के बराबर थी। वास्तविक स्केलिंग बिंदु तब होता है जब सर्वर लोड गिर रहा था और लगभग फर्श से टकरा रहा था। हमारे परीक्षण में, यदि हम कनेक्शन को पूर्ण रखते हैं और डेटाबेस लोड लगातार उच्च होता है, तो स्वचालित स्केलिंग नहीं होगी।

नीचे दिए गए दोनों स्क्रीनशॉट को देखकर, हम बता सकते हैं कि स्केलिंग तभी होती है जब हमारे Sysbench ने 600 सेकंड के लिए अपना स्ट्रेस टेस्ट पूरा कर लिया हो क्योंकि यह स्वचालित स्केलिंग करने के लिए सबसे सुरक्षित बिंदु है।

CPU उपयोग

औरोरा की घटनाओं को देखते समय, निम्नलिखित घटनाएं हुईं:

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 डीबी क्षमता में आने के लिए इसके समाप्त होने तक प्रतीक्षा करें:

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 क्षमता इकाई की सीमा तक समान चरणों को दोहराया। निम्न तालिका हमारे परीक्षण में अधिकतम डीबी क्षमता तक समग्र डीबी क्षमता इकाई बनाम max_connections मान को सारांशित करती है:

जबरन स्केलिंग

जैसा कि ऊपर बताया गया है, Aurora Serverless केवल तभी स्वचालित स्केलिंग करेगा जब ऐसा करना सुरक्षित होगा। हालांकि, उपयोगकर्ता के पास 'अतिरिक्त स्केलिंग कॉन्फ़िगरेशन' विकल्प के तहत फ़ोर्स स्केलिंग चेकबॉक्स पर टिक करके डीबी क्षमता स्केलिंग को तुरंत होने के लिए बाध्य करने का विकल्प होता है:

जब ज़बरदस्ती स्केलिंग सक्षम की जाती है, तो समय समाप्त होते ही स्केलिंग हो जाती है। जो 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 इंस्टेंस प्रतिस्थापन को उसके समय समाप्त होने के तुरंत बाद करने के लिए बाध्य करता है, जिसके कारण लेन-देन निरस्त हो जाता है और रोल बैक हो जाता है। निरस्त क्वेरी को दूसरी बार पुनः प्रयास करने से समस्या का समाधान होने की संभावना है। यदि आपका एप्लिकेशन कनेक्शन ड्रॉप के लिए लचीला है तो इस कॉन्फ़िगरेशन का उपयोग किया जा सकता है।

सारांश

अमेज़ॅन ऑरोरा सर्वरलेस ऑटो स्केलिंग एक लंबवत स्केलिंग समाधान है, जहां एक अधिक शक्तिशाली उदाहरण एक निम्न उदाहरण पर ले जाता है, अंतर्निहित अरोड़ा साझा स्टोरेज तकनीक का कुशलतापूर्वक उपयोग करता है। डिफ़ॉल्ट रूप से, ऑटो स्केलिंग ऑपरेशन निर्बाध रूप से किया जाता है, जिससे Aurora इंस्टेंस स्विचिंग करने के लिए एक सुरक्षित स्केलिंग बिंदु ढूंढता है। किसी के पास सक्रिय डेटाबेस कनेक्शन के जोखिम के साथ स्वचालित स्केलिंग के लिए बाध्य करने का विकल्प होता है।