कसरी AWS ले यसको लोचदार सेवाहरू पकाउँछ। स्केलिंग सर्भर र डाटाबेस

क्लाउडहरू एउटा जादुई बाकस जस्तै हुन् - तपाईलाई के चाहिन्छ भनेर सोध्नुहोस्, र स्रोतहरू कतैबाट बाहिर देखा पर्दैन। भर्चुअल मेशिनहरू, डाटाबेसहरू, नेटवर्कहरू - यी सबै तपाईंसँग मात्र सम्बन्धित छन्। त्यहाँ अन्य क्लाउड भाडामा लिनेहरू छन्, तर तपाईंको ब्रह्माण्डमा तपाईं एकमात्र शासक हुनुहुन्छ। तपाइँ निश्चित हुनुहुन्छ कि तपाइँ सधैं आवश्यक स्रोतहरू प्राप्त गर्नुहुनेछ, तपाइँ कसैलाई पनि खातामा लिनु हुन्न र तपाइँ स्वतन्त्र रूपमा नेटवर्क कस्तो हुनेछ भनेर निर्धारण गर्नुहुन्छ। क्लाउडलाई लोचदार रूपमा स्रोतहरू आवंटित गर्ने र भाडामा लिनेहरूलाई एकअर्काबाट पूर्ण रूपमा अलग गर्ने यो जादुले कसरी काम गर्छ?

AWS क्लाउड एक मेगा-सुपर जटिल प्रणाली हो जुन 2006 देखि क्रमिक रूपमा विकसित भइरहेको छ। यस विकासको एक भाग भयो Vasily Pantyukhin - अमेजन वेब सेवा आर्किटेक्ट। एक वास्तुकारको रूपमा, उसले अन्तिम नतिजामा मात्र होइन, तर AWS लाई पार गर्ने चुनौतीहरूमा पनि भित्री रूप पाउँछ। प्रणालीले कसरी काम गर्छ भन्ने जति ठूलो बुझाइ हुन्छ, त्यति नै ठूलो विश्वास हुन्छ। तसर्थ, Vasily AWS क्लाउड सेवाहरूको रहस्य साझा गर्नेछ। तल भौतिक AWS सर्भरहरूको डिजाइन, लोचदार डाटाबेस स्केलेबिलिटी, अनुकूलन अमेजन डाटाबेस र भर्चुअल मेसिनहरूको प्रदर्शन बढाउनका लागि विधिहरू छन् जबकि एकै साथ तिनीहरूको मूल्य घटाउँदै। Amazon को आर्किटेक्चरल दृष्टिकोणको ज्ञानले तपाईंलाई AWS सेवाहरू अझ प्रभावकारी रूपमा प्रयोग गर्न मद्दत गर्नेछ र तपाईंलाई आफ्नै समाधानहरू निर्माण गर्न नयाँ विचारहरू दिन सक्छ।

वक्ता को बारे मा: Vasily Pantyukhin (Hen) .ru कम्पनीहरूमा युनिक्स प्रशासकको रूपमा सुरु भयो, 6 वर्षसम्म ठूलो सन माइक्रोसिस्टम हार्डवेयरमा काम गर्नुभयो, र 11 वर्षसम्म EMC मा डाटा-केन्द्रित संसारको प्रचार गर्नुभयो। यो स्वाभाविक रूपमा निजी क्लाउडहरूमा विकसित भयो, र 2017 मा सार्वजनिकमा सारियो। अब उसले AWS क्लाउडमा बाँच्न र विकास गर्न मद्दत गर्न प्राविधिक सल्लाह प्रदान गर्दछ।

अस्वीकरण: तलका सबै कुरा Vasily को व्यक्तिगत विचार हो र Amazon Web Services को स्थिति संग मेल खाँदैन। भिडियो रेकर्डिङ रिपोर्ट जसमा आधारित लेख हाम्रो YouTube च्यानलमा उपलब्ध छ।

म किन अमेजन उपकरणको बारेमा कुरा गर्दैछु?

मेरो पहिलो कारमा म्यानुअल ट्रान्समिसन थियो। म कार चलाउन सक्छु र यसमा पूर्ण नियन्त्रण राख्न सक्छु भन्ने भावनाको कारण यो राम्रो थियो। मलाई यो पनि मन पर्यो कि मैले कम्तिमा यसको सञ्चालनको सिद्धान्त बुझेको छु। स्वाभाविक रूपमा, मैले बाकसको संरचना एकदम आदिम भएको कल्पना गरें - साइकलमा गियरबक्स जस्तो।

सबै कुरा राम्रो थियो, एक चीज बाहेक - ट्राफिक जाममा फसेको। यस्तो देखिन्छ कि तपाईं बसिरहनु भएको छ र केहि पनि गरिरहनु भएको छैन, तर तपाईं लगातार गियरहरू परिवर्तन गर्दै हुनुहुन्छ, क्लच, ग्यास, ब्रेक थिच्दै हुनुहुन्छ - यसले तपाईंलाई साँच्चै थकित बनाउँछ। परिवारले अटोमेटिक कार पाएपछि ट्राफिक जामको समस्या केही हदसम्म समाधान भएको छ । ड्राइभिङ गर्दा, मसँग केहि सोच्ने र अडियोबुक सुन्न समय थियो।

मेरो जीवनमा अर्को रहस्य देखा पर्‍यो, किनकि मैले मेरो कारले कसरी काम गर्छ भन्ने कुरा बुझ्न छाडेको थिएँ। आधुनिक कार एक जटिल उपकरण हो। कार एकै साथ दर्जनौं फरक मापदण्डहरूमा अनुकूल हुन्छ: ग्यास थिच्ने, ब्रेक, ड्राइभिङ शैली, सडक गुणस्तर। मलाई यो अब कसरी काम गर्छ बुझ्दिन।

जब मैले अमेजन क्लाउडमा काम गर्न थालें, यो पनि मेरो लागि रहस्य थियो। केवल यो रहस्य ठूलो परिमाणको आदेश हो, किनभने कारमा एक चालक छ, र AWS मा ती लाखौं छन्। सबै प्रयोगकर्ताहरू एकैसाथ स्टेयर, ग्यास थिच्नुहोस् र ब्रेक गर्नुहोस्। यो अचम्मको छ कि तिनीहरू जहाँ चाहन्छन् त्यहाँ जान्छन् - यो मेरो लागि चमत्कार हो! प्रणालीले प्रत्येक प्रयोगकर्तालाई स्वचालित रूपमा अनुकूलन, तराजू र लोचदार रूपमा समायोजन गर्दछ ताकि यो ब्रह्माण्डमा उहाँ एक्लै हुनुहुन्छ जस्तो देखिन्छ।

म पछि Amazon मा वास्तुकारको रूपमा काम गर्न आउँदा यो जादू अलिकति घट्यो। हामीले के कस्ता समस्याहरू सामना गर्छौं, कसरी समाधान गर्छौं र कसरी सेवाहरू विकास गर्छौं भन्ने मैले देखेको छु। प्रणाली कसरी काम गर्छ भन्ने बढ्दो बुझाइ संग, सेवा मा अधिक विश्वास देखिन्छ। त्यसैले म AWS क्लाउडको हुड मुनि के छ भन्ने तस्वीर साझा गर्न चाहन्छु।

हामी के कुरा गरौं

मैले एक विविध दृष्टिकोण रोजें - मैले 4 रोचक सेवाहरू चयन गरें जुन कुरा गर्न लायक छ।

सर्भर अप्टिमाइजेसन। भौतिक अवतारका साथ क्षणिक बादलहरू: भौतिक डेटा केन्द्रहरू जहाँ त्यहाँ भौतिक सर्भरहरू छन् जुन गुनगुनाने, तातो हुन्छ र बत्तीहरू झिम्काउँछ।

सर्भररहित कार्यहरू (Lambda) सम्भवतः क्लाउडमा सबैभन्दा स्केलेबल सेवा हो।

डाटाबेस स्केलिंग। हामी कसरी हाम्रो आफ्नै स्केलेबल डाटाबेसहरू निर्माण गर्छौं भन्ने बारे म तपाईंलाई बताउनेछु।

नेटवर्क स्केलिंग। अन्तिम भाग जसमा म हाम्रो नेटवर्कको उपकरण खोल्नेछु। यो अचम्मको कुरा हो - प्रत्येक क्लाउड प्रयोगकर्ताले विश्वास गर्दछ कि ऊ क्लाउडमा एक्लै छ र अन्य भाडामा लिनेहरूलाई देख्दैन।

नोट। यस लेखले सर्भर अप्टिमाइजेसन र डाटाबेस स्केलिङबारे छलफल गर्नेछ। हामी अर्को लेखमा नेटवर्क स्केलिङबारे विचार गर्नेछौं। सर्भररहित कार्यहरू कहाँ छन्? उनीहरूको बारेमा छुट्टै ट्रान्सक्रिप्ट प्रकाशित गरिएको थियो "सानो, तर स्मार्ट। अनबक्सिङ फायरक्रेकर माइक्रोभर्चुअल" यसले धेरै फरक स्केलिंग विधिहरूको बारेमा कुरा गर्छ, र फायरक्राकर समाधानको विस्तृत रूपमा छलफल गर्दछ - भर्चुअल मेसिन र कन्टेनरहरूको उत्कृष्ट गुणहरूको सिम्बायोसिस।

सर्भरहरू

बादल क्षणिक छ। तर यो क्षणिकता अझै पनि एक भौतिक अवतार छ - सर्भर। सुरुमा, तिनीहरूको वास्तुकला शास्त्रीय थियो। मानक x86 चिपसेट, नेटवर्क कार्डहरू, लिनक्स, Xen हाइपरवाइजर जसमा भर्चुअल मेसिनहरू चलाइएका थिए।

2012 मा, यो वास्तुकला आफ्नो कार्यहरु संग राम्रो संग सामना गर्यो। Xen एक महान हाइपरवाइजर हो, तर यसको एउटा प्रमुख कमजोरी छ। उहाँसँग पर्याप्त छ उपकरण अनुकरणको लागि उच्च ओभरहेड। नयाँ, छिटो नेटवर्क कार्ड वा SSD ड्राइभहरू उपलब्ध हुँदा, यो ओभरहेड धेरै उच्च हुन्छ। यो समस्या कसरी सामना गर्ने? हामीले एकैचोटि दुई मोर्चामा काम गर्ने निर्णय गर्यौं - हार्डवेयर र हाइपरभाइजर दुवै अनुकूलन गर्नुहोस्। कार्य धेरै गम्भीर छ।

हार्डवेयर र हाइपरवाइजर अनुकूलन गर्दै

सबै कुरा एकैचोटि गरेर राम्ररी गर्नेले काम गर्दैन। के "राम्रो" थियो पनि सुरुमा अस्पष्ट थियो।

हामीले एक विकासवादी दृष्टिकोण लिने निर्णय गर्‍यौं - हामी वास्तुकलाको एउटा महत्त्वपूर्ण तत्व परिवर्तन गर्छौं र यसलाई उत्पादनमा फ्याँक्छौं।

हामी हरेक रेकमा कदम चाल्छौं, गुनासो र सुझावहरू सुन्छौं। त्यसपछि हामी अर्को घटक परिवर्तन। त्यसोभए, सानो वृद्धिमा, हामी प्रयोगकर्ताहरू र समर्थनबाट प्रतिक्रियाको आधारमा सम्पूर्ण संरचनालाई आमूल परिवर्तन गर्छौं।

रूपान्तरण 2013 मा सबैभन्दा जटिल कुरा संग सुरु भयो - नेटवर्क। IN С3 उदाहरणहरू, मानक नेटवर्क कार्डमा विशेष नेटवर्क एक्सेलेरेटर कार्ड थपिएको थियो। यो शाब्दिक रूपमा अगाडि प्यानलमा छोटो लुपब्याक केबलको साथ जोडिएको थियो। यो सुन्दर छैन, तर यो बादल मा देखिने छैन। तर हार्डवेयरसँग प्रत्यक्ष अन्तरक्रियाले मौलिक रूपमा सुधारिएको जिटर र नेटवर्क थ्रुपुट।

अर्को हामीले ब्लक डेटा भण्डारण EBS - इलास्टिक ब्लक भण्डारणमा पहुँच सुधार गर्ने निर्णय गर्यौं। यो नेटवर्क र भण्डारणको संयोजन हो। कठिनाई यो छ कि नेटवर्क एक्सेलरेटर कार्डहरू बजारमा अवस्थित हुँदा, त्यहाँ भण्डारण एक्सेलरेटर हार्डवेयर किन्नको लागि कुनै विकल्प थिएन। त्यसैले हामी स्टार्टअपतिर लाग्यौं अन्नपूर्ण ल्याब्स, जसले हाम्रो लागि विशेष ASIC चिप्स विकास गर्यो। तिनीहरूले रिमोट EBS भोल्युमहरूलाई NVMe यन्त्रहरूको रूपमा माउन्ट गर्न अनुमति दिए।

उदाहरणहरूमा C4 हामीले दुई समस्या समाधान गर्यौं। पहिलो हो कि हामीले आशाजनक भविष्यको लागि आधार लागू गर्यौं, तर त्यस समयमा नयाँ, NVMe प्रविधि। दोस्रो, हामीले नयाँ कार्डमा अनुरोधहरूको प्रक्रियालाई EBS मा स्थानान्तरण गरेर केन्द्रीय प्रोसेसरलाई उल्लेखनीय रूपमा अनलोड गर्यौं। यो राम्रो भयो, त्यसैले अब अन्नपूर्ण ल्याब्स Amazon को हिस्सा हो।

नोभेम्बर 2017 सम्म, हामीले महसुस गर्यौं कि यो हाइपरभाइजर आफैं परिवर्तन गर्ने समय हो।

नयाँ हाइपरभाइजर परिमार्जित KVM कर्नेल मोड्युलहरूमा आधारित विकसित गरिएको थियो।

यसले यन्त्र इम्युलेसनको ओभरहेडलाई मौलिक रूपमा कम गर्न र नयाँ ASIC हरूसँग प्रत्यक्ष रूपमा काम गर्न सम्भव बनायो। उदाहरणहरू С5 हुड अन्तर्गत चलिरहेको नयाँ हाइपरभाइजरको साथ पहिलो भर्चुअल मेसिनहरू थिए। हामीले उनको नाम राख्यौं निट्रो.

टाइमलाइनमा उदाहरणहरूको विकास।

नोभेम्बर 2017 देखि देखा परेका सबै नयाँ प्रकारका भर्चुअल मेसिनहरू यस हाइपरभाइजरमा चल्छन्। बेयर मेटल उदाहरणहरूमा हाइपरवाइजर हुँदैन, तर तिनीहरूलाई नाइट्रो पनि भनिन्छ, किनकि तिनीहरूले विशेष नाइट्रो कार्डहरू प्रयोग गर्छन्।

अर्को दुई वर्षमा, नाइट्रो उदाहरणहरूको संख्या दुई दर्जन भन्दा बढी भयो: A1, C5, M5, T3 र अन्य।

उदाहरणका प्रकारहरू।

कसरी आधुनिक नाइट्रो मिसिन काम गर्दछ

तिनीहरूसँग तीन मुख्य घटकहरू छन्: नाइट्रो हाइपरवाइजर (माथि छलफल गरिएको), सुरक्षा चिप र नाइट्रो कार्डहरू।

सुरक्षा चिप मदरबोर्डमा सीधा एकीकृत। यसले धेरै महत्त्वपूर्ण कार्यहरू नियन्त्रण गर्दछ, जस्तै होस्ट OS को लोडिङ नियन्त्रण।

नाइट्रो कार्डहरू - ती चार प्रकारका छन्। ती सबै अन्नपूर्ण ल्याब्स द्वारा विकसित र साझा ASIC मा आधारित छन्। तिनीहरूको केहि फर्मवेयर पनि सामान्य छ।

चार प्रकारका नाइट्रो कार्डहरू।

कार्ड मध्ये एउटा काम गर्न डिजाइन गरिएको छ नेटवर्कVPC। यो नेटवर्क कार्डको रूपमा भर्चुअल मेसिनहरूमा देखिने कुरा हो ENA - लोचदार नेटवर्क एडाप्टर। यसले भौतिक नेटवर्क मार्फत प्रसारण गर्दा ट्राफिकलाई पनि समेट्छ (हामी यस बारे लेखको दोस्रो भागमा कुरा गर्नेछौं), सुरक्षा समूह फायरवाल नियन्त्रण गर्दछ, र मार्ग र अन्य नेटवर्क चीजहरूको लागि जिम्मेवार छ।

ब्लक भण्डारण संग काम कार्ड चयन गर्नुहोस् EBS र सर्भरमा निर्मित डिस्कहरू। तिनीहरू अतिथि भर्चुअल मेसिनको रूपमा देखा पर्छन् NVMe एडेप्टरहरू। तिनीहरू डाटा एन्क्रिप्शन र डिस्क निगरानीको लागि पनि जिम्मेवार छन्।

नाइट्रो कार्ड, हाइपरभाइजर र सेक्युरिटी चिपको प्रणालीलाई SDN नेटवर्कमा एकीकृत गरिएको छ वा सफ्टवेयर परिभाषित नेटवर्क। यो नेटवर्क प्रबन्ध गर्न जिम्मेवार (नियन्त्रण विमान) नियन्त्रक कार्ड.

अवश्य पनि, हामी नयाँ ASIC विकास गर्न जारी राख्छौं। उदाहरणका लागि, 2018 को अन्त्यमा तिनीहरूले Inferentia चिप जारी गरे, जसले तपाईंलाई मेसिन लर्निङ कार्यहरूमा अझ प्रभावकारी रूपमा काम गर्न अनुमति दिन्छ।

इन्फेरेन्शिया मेसिन लर्निङ प्रोसेसर चिप।

स्केलेबल डाटाबेस

एक परम्परागत डाटाबेस एक स्तरित संरचना छ। धेरै सरल बनाउन, निम्न स्तरहरू प्रतिष्ठित छन्।

• SQL - ग्राहक र अनुरोध प्रेषकहरूले यसमा काम गर्छन्।
• प्रावधानहरू लेनदेन - यहाँ सबै कुरा स्पष्ट छ, ACID र सबै।
• क्यासिङ, जुन बफर पूल द्वारा प्रदान गरिएको छ।
• लगिङ - रिडू लग संग काम प्रदान गर्दछ। MySQL मा तिनीहरूलाई बिन लगहरू भनिन्छ, PosgreSQL मा - अगाडि लगहरू (WAL) लेख्नुहोस्।
• भण्डारण - डिस्कमा प्रत्यक्ष रेकर्डिङ।

स्तरित डाटाबेस संरचना।

डाटाबेसहरू मापन गर्ने विभिन्न तरिकाहरू छन्: शार्डिङ, सेयर नथिङ आर्किटेक्चर, साझा डिस्क।

यद्यपि, यी सबै विधिहरूले एउटै मोनोलिथिक डाटाबेस संरचना कायम राख्छन्। यसले महत्त्वपूर्ण रूपमा स्केलिंग सीमित गर्दछ। यो समस्या समाधान गर्न, हामीले हाम्रो आफ्नै डाटाबेस - विकास गर्यौं अमेजन अरोड़ा। यो MySQL र PostgreSQL सँग उपयुक्त छ।

अमेजन अरोड़ा

मुख्य आर्किटेक्चरल विचार भनेको भण्डारण र लगिङ स्तरहरूलाई मुख्य डाटाबेसबाट अलग गर्नु हो।

अगाडि हेर्दै, म भन्छु कि हामीले क्यासिंग स्तरलाई पनि स्वतन्त्र बनायौं। वास्तुकला एक मोनोलिथ हुन बन्द हुन्छ, र हामीले व्यक्तिगत ब्लकहरू मापन गर्न स्वतन्त्रताको अतिरिक्त डिग्री प्राप्त गर्छौं।

लगिङ र भण्डारण स्तरहरू डाटाबेसबाट अलग छन्।

एक परम्परागत DBMS ले ब्लकको रूपमा भण्डारण प्रणालीमा डाटा लेख्छ। Amazon Aurora मा, हामीले भाषा बोल्न सक्ने स्मार्ट भण्डारण सिर्जना गर्यौं redo-logs। भित्र, भण्डारणले लगहरूलाई डेटा ब्लकहरूमा परिणत गर्दछ, तिनीहरूको अखण्डता निगरानी गर्दछ र स्वचालित रूपमा ब्याकअप गर्दछ।

यो दृष्टिकोणले तपाईंलाई यस्तो रोचक चीजहरू लागू गर्न अनुमति दिन्छ क्लोनिङ। यसले मौलिक रूपमा छिटो र अधिक आर्थिक रूपमा काम गर्दछ किनभने यसले सबै डेटाको पूर्ण प्रतिलिपि सिर्जना गर्न आवश्यक पर्दैन।

भण्डारण तहलाई वितरण प्रणालीको रूपमा लागू गरिएको छ। यसले भौतिक सर्भरहरूको धेरै ठूलो संख्या समावेश गर्दछ। प्रत्येक रिडू लग प्रशोधन गरिन्छ र एकै साथ बचत गरिन्छ छ गाँठ। यसले डाटा सुरक्षा र लोड सन्तुलन सुनिश्चित गर्दछ।

उपयुक्त प्रतिकृतिहरू प्रयोग गरेर पढ्ने स्केलिंग प्राप्त गर्न सकिन्छ। वितरित भण्डारणले मुख्य डाटाबेस उदाहरण बीचको सिङ्क्रोनाइजेसनको आवश्यकतालाई हटाउँछ, जसको माध्यमबाट हामी डाटा लेख्छौं, र बाँकी प्रतिकृतिहरू। अप-टु-डेट डाटा सबै प्रतिकृतिहरूमा उपलब्ध हुने ग्यारेन्टी छ।

पढ्ने प्रतिकृतिहरूमा पुरानो डाटा क्यास गर्ने मात्र समस्या हो। तर यो समस्या समाधान भइरहेको छ सबै redo लग को स्थानान्तरण आन्तरिक नेटवर्कमा प्रतिकृतिहरू गर्न। यदि लग क्यासमा छ भने, यो गलत र अधिलेखन रूपमा चिन्ह लगाइन्छ। यदि यो क्यासमा छैन भने, यो केवल खारेज गरिन्छ।

हामीले भण्डारणलाई व्यवस्थित गर्यौं।

कसरी DBMS स्तरहरू मापन गर्ने

यहाँ, तेर्सो मापन धेरै गाह्रो छ। त्यसैले पिटेको बाटोमा जाऔं क्लासिक ठाडो स्केलिंग.

मानौं कि हामीसँग एउटा अनुप्रयोग छ जुन मास्टर नोड मार्फत DBMS सँग सञ्चार गर्दछ।

ठाडो रूपमा मापन गर्दा, हामी नयाँ नोड आवंटित गर्छौं जसमा धेरै प्रोसेसर र मेमोरी हुनेछ।

अर्को, हामी पुरानो मास्टर नोडबाट नयाँमा एप्लिकेसन स्विच गर्छौं। समस्याहरू उत्पन्न हुन्छन्।

• यो महत्त्वपूर्ण आवेदन डाउनटाइम आवश्यक हुनेछ।
• नयाँ मास्टर नोडमा चिसो क्यास हुनेछ। क्यास वार्म अप गरेपछि मात्र डाटाबेस प्रदर्शन अधिकतम हुनेछ।

स्थिति कसरी सुधार गर्ने? एप्लिकेसन र मास्टर नोड बीच प्रोक्सी सेटअप गर्नुहोस्।

यसले हामीलाई के दिनेछ? अब सबै अनुप्रयोगहरूलाई म्यानुअल रूपमा नयाँ नोडमा रिडिरेक्ट गर्न आवश्यक छैन। स्विच प्रोक्सी अन्तर्गत गर्न सकिन्छ र मौलिक रूपमा छिटो छ।

समस्या समाधान भएको देखिन्छ । तर होइन, हामी अझै पनि क्यास न्यानो अप गर्न आवश्यकताबाट ग्रस्त छौं। थप रूपमा, नयाँ समस्या देखा पर्‍यो - अब प्रोक्सी असफलताको सम्भावित बिन्दु हो।

अमेजन अरोरा सर्भरलेसको साथ अन्तिम समाधान

हामीले यी समस्याहरू कसरी समाधान गर्यौं?

प्रोक्सी छोडियो। यो छुट्टै उदाहरण होइन, तर प्रोक्सीहरूको सम्पूर्ण वितरित फ्लीट हो जसको माध्यमबाट अनुप्रयोगहरू डाटाबेसमा जडान हुन्छन्। असफलताको अवस्थामा, कुनै पनि नोडहरू लगभग तुरुन्तै बदल्न सकिन्छ।

विभिन्न आकारका न्यानो नोडहरूको पोखरी थपियो। त्यसकारण, यदि यो ठूलो वा सानो आकारको नयाँ नोड आवंटित गर्न आवश्यक छ भने, यो तुरुन्तै उपलब्ध छ। यसलाई लोड गर्न पर्खनु पर्दैन।

सम्पूर्ण स्केलिंग प्रक्रिया एक विशेष निगरानी प्रणाली द्वारा नियन्त्रित छ। अनुगमनले हालको मास्टर नोडको अवस्थालाई निरन्तर निगरानी गर्छ। यदि यसले पत्ता लगायो, उदाहरणका लागि, प्रोसेसर लोडले महत्वपूर्ण मानमा पुगेको छ भने, यसले नयाँ नोड आवंटित गर्ने आवश्यकताको बारेमा न्यानो उदाहरणहरूको पूललाई ​​सूचित गर्दछ।

वितरित प्रोक्सीहरू, न्यानो उदाहरणहरू र निगरानी।

आवश्यक शक्ति संग एक नोड उपलब्ध छ। बफर पूलहरू यसमा प्रतिलिपि गरिएका छन्, र प्रणालीले स्विच गर्न सुरक्षित क्षणको लागि पर्खन थाल्छ।

सामान्यतया स्विच गर्ने क्षण एकदम चाँडो आउँछ। त्यसपछि प्रोक्सी र पुरानो मास्टर नोड बीचको संचार निलम्बित छ, सबै सत्रहरू नयाँ नोडमा स्विच हुन्छन्।

डाटाबेस पुन: सुरु संग काम गर्नुहोस्।

ग्राफले देखाउँछ कि निलम्बन साँच्चै धेरै छोटो छ। नीलो ग्राफले लोड देखाउँदछ, र रातो चरणहरूले स्केलिंग क्षणहरू देखाउँदछ। नीलो ग्राफमा छोटो अवधिको डुब्न भनेको छोटो ढिलाइ हो।

वैसे, Amazon Aurora ले तपाईंलाई पैसा बचत गर्न र डाटाबेस बन्द गर्न अनुमति दिन्छ जब यो प्रयोगमा छैन, उदाहरणका लागि, सप्ताहन्तमा। लोड बन्द गरेपछि, DB बिस्तारै यसको शक्ति घटाउँछ र केहि समयको लागि बन्द हुन्छ। जब लोड फिर्ता हुन्छ, यो फेरि सहज रूपमा बढ्नेछ।

अमेजन उपकरणको बारेमा कथाको अर्को भागमा, हामी नेटवर्क स्केलिंगको बारेमा कुरा गर्नेछौं। सदस्यता लिनुहोस् मेल र ट्यून रहनुहोस् ताकि तपाईंले लेख नछुटाउनुहोस्।

मा हाईलोड++ Vasily Pantyukhin ले रिपोर्ट दिनेछ "ह्युस्टन, हामीसँग समस्या छ। विफलताको लागि प्रणालीहरूको डिजाइन, आन्तरिक अमेजन क्लाउड सेवाहरूको लागि विकास ढाँचा" अमेजन विकासकर्ताहरू द्वारा वितरित प्रणालीहरूको लागि कुन डिजाइन ढाँचाहरू प्रयोग गरिन्छ, सेवा विफलताका कारणहरू के हुन्, सेल-आधारित आर्किटेक्चर के हो, निरन्तर कार्य, शफल शार्डिङ - यो रोचक हुनेछ। सम्मेलन आउन एक महिनाभन्दा कम समय - आफ्नो टिकट बुक। अक्टोबर 24 अन्तिम मूल्य वृद्धि।

स्रोत: www.habr.com