👩‍👩‍👦‍👦 👩🏾‍🤝‍👨🏼 🤴🏿 हॉस्टन हमारे पास समस्या हे। सिस्टम डिज़ाइन विफलता ➕ 🔏 🏛️

1970 में, अमेरिकी इंजीनियरों ने चांद पर अपोलो 13 अंतरिक्ष यान लॉन्च किया था। बोर्ड पर ईंधन कोशिकाओं की तीन बैटरी हैं, चिंता की कोई बात नहीं है, सब कुछ मज़बूती से और बार-बार दोहराया जाता है। लेकिन कोई भी कल्पना नहीं कर सकता था कि ऑक्सीजन सिलेंडर का विस्फोट तीन में से दो बैटरी को निष्क्रिय कर देगा। शोकपूर्ण घटना! अंतरिक्ष यात्री घर लौट आए, टॉम हैंक्स के साथ घटना के बारे में एक फीचर फिल्म बनाई गई, और अंतरिक्ष यात्री जैक स्विगर्ट के वाक्यांश: "ह्यूस्टन, हमें एक समस्या है!", इतिहास में नीचे चला गया।

अपोलो 13 की कहानी प्रसिद्ध तथ्य का एक और सबूत है जिसे आप सभी संभावित परेशानियों के लिए तैयार नहीं कर सकते हैं। यह दुनिया की एक प्राकृतिक संपत्ति है: समय-समय पर लोहा टूटता है, कोड क्रैश होता है, और लोग गलती करते हैं। इसे पूरी तरह से खत्म करना असंभव है।

बड़ी वितरित प्रणालियों के लिए, यह व्यवहार सामान्य है, यह पैमाने और आंकड़ों की अर्थव्यवस्थाओं का परिणाम है। यही कारण है कि डिजाइन फॉर फेल्योर (AWS) AWS क्लाउड सेवाओं के लिए मूल डिजाइन सिद्धांत है। सिस्टम को शुरू में इस तरह से बनाया जाता है कि फुल-टाइम ऑपरेशन को जल्द से जल्द बहाल किया जा सके और ज्ञात और अभी तक अज्ञात विफलताओं से नुकसान को कम किया जा सके। पर HighLoad ++, वसीली Pantyukhin, एक उदाहरण के रूप मुकाबला सेवाओं के साथ वास्तविक जीवन की समस्याओं का उपयोग कर, वितरण प्रणाली के लिए पता चला है कि डिजाइन पैटर्न एडब्ल्यूएस डेवलपर्स का उपयोग करें।

वसीली पंत्यूखिन (मुर्गी) यूरोप, मध्य पूर्व और अफ्रीका में अमेज़ॅन वेब सेवाओं का वास्तुकार है। उन्होंने यूनिक्स प्रशासक के रूप में शुरुआत की, 6 साल के लिए सन माइक्रोसिस्टम में काम किया, तकनीकी पाठ्यक्रम पढ़ाए और 11 साल तक उन्होंने दुनिया की डेटा-केंद्रितता को ईएमसी में पढ़ाया। एक अंतरराष्ट्रीय टीम में, उन्होंने केप टाउन से ओस्लो तक की परियोजनाओं को डिजाइन और कार्यान्वित किया। अब यह बड़ी और छोटी कंपनियों को सार्वजनिक बादलों में काम करने में मदद करता है।

1949 में, कैलिफोर्निया के वायुसेना अड्डे पर एक हवाई जहाज दुर्घटना की जांच की गई थी। जिन इंजीनियरों ने ऐसा किया उनमें से एक एडवर्ड मर्फी था। उन्होंने स्थानीय तकनीशियनों के काम का वर्णन इस प्रकार किया: "अगर कुछ करने के दो तरीके हैं और उनमें से एक आपदा की ओर जाता है, तो कोई इस पद्धति का चयन करेगा।"

बाद में, आर्थर बलोच के लिए धन्यवाद, बयान मर्फी के कानूनों में से एक के रूप में इतिहास में नीचे चला गया। रूसी में - मतलब का नियम। इसका सार यह है कि यह टूटने और मानवीय त्रुटियों से बचने के लिए संभव नहीं होगा, और किसी तरह इसके साथ रहना होगा। इसीलिए, डिजाइन करते समय, हम तुरंत अपने सिस्टम में व्यक्तिगत घटकों की विफलताओं और विफलताओं को डालते हैं।

विफलता डिजाइन

विफलता के लिए डिजाइन में, हम तीन विशेषताओं में सुधार करने की कोशिश कर रहे हैं:

पहुँच क्षमता (उन्हीं "नाइन");
विश्वसनीयता - सेवा का आवश्यक स्तर प्रदान करने के लिए सिस्टम की संपत्ति;
गलती सहिष्णुता - समस्याओं की घटना को रोकने और उनके बाद जल्दी से ठीक होने के लिए सिस्टम की एक संपत्ति।

विश्वसनीयता में " ज्ञात अज्ञात" की संपत्ति है । हम ज्ञात समस्याओं से खुद को बचाते हैं, लेकिन यह नहीं जानते कि वे कब होंगे।

" संयुक्त राष्ट्र के नाम से जाना जाता अज्ञात" है सहिष्णुता गलती को जोड़ा गया - इन आश्चर्य समस्याओं के बारे में हम कुछ नहीं जानते हैं। क्लाउड में इन समस्याओं में से कई पैमाने की अर्थव्यवस्थाओं से संबंधित हैं: सिस्टम आकार में बढ़ता है जब नए, आश्चर्यजनक और अप्रत्याशित प्रभाव दिखाई देते हैं।

विफलता आमतौर पर एक द्विआधारी घटना नहीं है। इसकी मुख्य संपत्ति "ब्लास्ट त्रिज्या" या सेवा की गिरावट का स्तर, विनाश की त्रिज्या है। हमारा कार्य सिस्टम के "ब्लास्ट रेडियस" को कम करना है।

अगर हम समझते हैं कि समस्याओं से बचा नहीं जा सकता है, तो हमें उनके लिए तैयार रहना चाहिए। इसका मतलब है कि हम सेवाओं को इस तरह से डिजाइन करते हैं कि मुसीबतों के मामले में (वे निश्चित रूप से होंगे), हम समस्याओं को नियंत्रित करते हैं, न कि इसके विपरीत।

जब हम किसी समस्या का जवाब देते हैं, तो यह हमें नियंत्रित करता है।

डाटा प्लेन और कंट्रोल प्लेन

निश्चित रूप से, आपके पास घर पर इलेक्ट्रॉनिक्स हैं जो रिमोट कंट्रोल द्वारा नियंत्रित होते हैं, जैसे कि टीवी। टीवी स्क्रीन डेटा प्लेन का हिस्सा है - जो सीधे कार्य करता है। रिमोट कंट्रोल यूजर इंटरफेस - कंट्रोल प्लेन है। इसका उपयोग सेवा को प्रबंधित और कॉन्फ़िगर करने के लिए किया जाता है। क्लाउड में, हम परीक्षण और विकास के लिए डेटा प्लेन और कंट्रोल प्लेन को अलग करने का प्रयास करते हैं।

उपयोगकर्ता, अक्सर, नियंत्रण विमान की जटिलता को नहीं देखते हैं। लेकिन इसके डिजाइन और कार्यान्वयन में गलतियां बड़े पैमाने पर विफलताओं का सबसे आम कारण हैं। इसलिए मेरी सलाह नियंत्रण विमान पर केंद्रित है - कभी-कभी स्पष्ट रूप से, कभी-कभी नहीं।

एक मुसीबत की कहानी

जुलाई 2012 में, उत्तरी वर्जीनिया में एक भयंकर तूफान गुजरा। डेटा सेंटर में सुरक्षा, डीजल जनरेटर और बहुत कुछ है, लेकिन ऐसा हुआ कि उत्तरी वर्जीनिया क्षेत्र के उपलब्धता क्षेत्रों (उपलब्धता क्षेत्र, AZ) के डेटा केंद्रों में से एक में बिजली खो गई। बिजली जल्दी से बहाल हो गई, लेकिन सेवाओं की बहाली घंटों तक खींची गई।

मैं आपको मूल सेवाओं में से एक - CLB (क्लासिक लोड बैलेंसर) के उदाहरण के कारणों के बारे में बताऊंगा। यह बस काम करता है: जब आप प्रत्येक उपलब्धता क्षेत्र में एक नया बैलेंसर शुरू करते हैं, तो अलग-अलग उदाहरण बनाए जाते हैं, जिनमें से आईपी डीएनएस को हल करेगा।

जब कोई उदाहरण विफल हो जाता है, तो इसके बारे में एक संदेश एक विशेष डेटाबेस को भेजा जाता है।

प्रतिक्रिया में, प्रक्रियाएं शुरू होती हैं: डीएनएस से रिकॉर्ड हटाना, एक नया उदाहरण शुरू करना और डीएनएस में एक नया आईपी जोड़ना।

नोट: यह इस प्रकार है कि सिस्टम अतीत में काम करता था, अब सब कुछ मौलिक रूप से अलग है।

सब कुछ सरल है - तोड़ने के लिए कुछ भी नहीं है। लेकिन एक सामूहिक विफलता के दौरान, जब हजारों उदाहरण एक ही समय में गिरते हैं, तो प्रसंस्करण के लिए संदेशों से डेटाबेस में एक बड़ा बैकलॉग प्रकट होता है ।

लेकिन यह खराब हो गया। नियंत्रण विमान एक वितरित प्रणाली है। बग के कारण, हमने डुप्लिकेट प्राप्त किए और डेटाबेस में हजारों रिकॉर्ड सैकड़ों की संख्या में स्वाहा हो गए। इससे काम करना बहुत मुश्किल हो गया।

जब एक विफलता होती है, तो सभी ट्रैफ़िक को लगभग तुरंत ही जीवित मशीनों और लोड डबल्स पर स्विच कर दिया जाता है (उदाहरण के लिए, सादगी के लिए, केवल दो एक्सेस ज़ोन हैं)।

पर्याप्त संसाधन नहीं हैं, एक जीवित उदाहरण स्वचालित रूप से पैमाने पर शुरू होता है। प्रक्रिया में अपेक्षाकृत लंबा समय लगता है। सब कुछ चरम पर होता है और एक ही समय में बड़ी संख्या में उदाहरणों के साथ - उपलब्धता क्षेत्र के मुक्त संसाधन बाहर चल रहे हैं। संसाधनों के लिए "लड़ाई" शुरू होती है।

उत्तरी वर्जीनिया में, स्वचालन भारी विफलता से निपटने में विफल रहा, और इंजीनियरों ने स्वयं (स्क्रिप्ट का उपयोग करके) काम करने के लिए सेवाओं को बहाल किया। ऐसी मुसीबतें कम ही होती हैं। डीब्रीफिंग के दौरान, विफलता के कारणों के बारे में सवाल उठे, उन्होंने फैसला किया कि स्थिति को अब दोहराया नहीं जाना चाहिए और पूरी सेवा को बदलना चाहिए।

आठ पैटर्न जो मैं कवर करूंगा, उनमें से कुछ सवालों के जवाब हैं।

ध्यान दें। यह सेवा के डिजाइन में हमारा अनुभव है, न कि व्यापक उपयोग के लिए सार्वभौमिक ज्ञान। विशिष्ट स्थितियों में पैटर्न का उपयोग किया जाता है।

— . AWS . — , . . — . !

विफलताओं के प्रभाव को कम करने के लिए, बहुत सारे दृष्टिकोण। उनमें से एक सवाल का जवाब देना है: "मैं यह कैसे सुनिश्चित कर सकता हूं कि जो उपयोगकर्ता किसी समस्या के बारे में नहीं जानते हैं, वे विफलता के दौरान और पुनर्प्राप्ति के दौरान इसके बारे में कुछ भी नहीं जानते हैं?"

हमारे विशाल बैकलॉग को न केवल दुर्घटना संदेश मिलते हैं, बल्कि दूसरों को भी, उदाहरण के लिए, स्केलिंग के बारे में या कि कोई नया बैलेंसर लॉन्च कर रहा है। ऐसे संदेशों को एक-दूसरे से अलग-थलग करने की आवश्यकता होती है, कार्यात्मक रूप से समूहीकरण: एक विफलता के बाद वसूली संदेशों का एक अलग समूह, अलग से एक नया बैलेंसर लॉन्च करना।

मान लीजिए कि दस उपयोगकर्ताओं ने एक समस्या पर ध्यान दिया - उनके बेलेंसरों में से एक नोड गिर गया। सेवाएं किसी तरह शेष संसाधनों पर काम करती हैं, लेकिन समस्या महसूस होती है।

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

ऐसा होने से रोकने के लिए, हम कुछ अनुरोधों को प्राथमिकता देते हैं - हम शीर्ष पर कतारें लगाते हैं, उदाहरण के लिए, नए संसाधनों के लिए अनुरोध। सामूहिक विफलता के साथ, इस तरह के अनुरोधों की अपेक्षाकृत कम संख्या अन्य ग्राहकों के संसाधनों की वसूली समय को प्रभावित नहीं करेगी। लेकिन पुनर्प्राप्ति प्रक्रिया में, हम समस्या में शामिल उपयोगकर्ताओं की संख्या को नियंत्रित करेंगे।

पूर्णकालिक नौकरी

समस्या रिपोर्ट की प्रतिक्रिया पुनर्प्राप्ति प्रक्रियाओं का शुभारंभ है, विशेष रूप से, DNS के साथ काम करती है। नियंत्रण विमान पर बड़े पैमाने पर विफलताएं हैं। दूसरा पैटर्न ऐसी स्थिति में नियंत्रण विमान को अधिक स्थिर और अनुमानित होने में मदद करता है।

हम निरंतर कार्य - स्थायी कार्य नामक दृष्टिकोण का उपयोग करते हैं ।

उदाहरण के लिए, DNS को थोड़ा चालाक बनाया जा सकता है: यह लगातार बैलेंसर के उदाहरणों की जांच करेगा, कि वे जीवित हैं या नहीं। परिणाम हर बार एक बिटमैप होगा: उदाहरण प्रतिक्रिया करता है - 1, मृत - 0.

DNS हर कुछ सेकंड में उदाहरणों की जांच करता है, भले ही एक सामूहिक विफलता के बाद सिस्टम बहाल हो या सामान्य रूप से काम कर रहा हो। वह एक ही काम करता है - कोई चोटियां नहीं, सब कुछ पूर्वानुमान और स्थिर है।

एक और सरलीकृत उदाहरण: हम एक बड़े बेड़े पर कॉन्फ़िगरेशन बदलना चाहते हैं। हमारी शब्दावली में, एक बेड़े आभासी मशीनों का एक समूह है जो एक साथ कुछ काम करते हैं।

हम S3 बाल्टी में कॉन्फ़िगरेशन परिवर्तन रखते हैं, और हर 10 सेकंड (उदाहरण के लिए) इस सभी कॉन्फ़िगरेशन को वर्चुअल मशीन के हमारे बेड़े में धक्का देते हैं। दो महत्वपूर्ण बिंदु।

हम नियमित रूप से ऐसा करते हैं और नियम को कभी नहीं तोड़ते। यदि आप 10 सेकंड का एक सेगमेंट चुनते हैं, तो स्थिति की परवाह किए बिना केवल इस तरह से धक्का दें।
हम हमेशा पूरे कॉन्फ़िगरेशन देते हैं , भले ही यह बदल गया हो या नहीं। डाटा प्लेन (वर्चुअल मशीन) खुद तय करते हैं कि उसे क्या करना है। हम डेल्टा को आगे नहीं बढ़ाते हैं। बड़े पैमाने पर व्यवधान या परिवर्तन के साथ यह बहुत बड़ा हो सकता है। संभावित रूप से, यह अस्थिरता और अप्रत्याशितता में योगदान कर सकता है।

जब हम किसी प्रकार का स्थायी कार्य करते हैं, तो हम उसके लिए अधिक भुगतान करते हैं। उदाहरण के लिए, 100 आभासी मशीनें हर सेकंड एक कॉन्फ़िगरेशन का अनुरोध करती हैं। इसकी लागत लगभग 1200 डॉलर प्रति वर्ष है। यह राशि अनिवार्य रूप से एक प्रोग्रामर के वेतन से कम है, जिसे हम एक शास्त्रीय दृष्टिकोण के साथ एक नियंत्रण विमान के विकास को सौंप सकते हैं - एक विफलता की प्रतिक्रिया और केवल कॉन्फ़िगरेशन परिवर्तन का वितरण।

यदि आप हर कुछ सेकंड में कॉन्फ़िगरेशन को बदलते हैं, उदाहरण के लिए, तो यह धीमा है। लेकिन कई मामलों में, एक कॉन्फ़िगरेशन परिवर्तन या सेवाओं के लॉन्च में मिनट लगते हैं - कुछ सेकंड कुछ भी हल नहीं करते हैं।

सेकंड उन सेवाओं के लिए महत्वपूर्ण हैं जिनमें कॉन्फ़िगरेशन को तुरंत बदलना होगा, उदाहरण के लिए, वीपीसी सेटिंग्स बदलते समय। यहां "स्थायी कार्य" लागू नहीं है। यह सिर्फ एक पैटर्न है, एक नियम नहीं है। यदि यह आपके मामले में काम नहीं करता है, तो उपयोग न करें।

प्रारंभिक स्केलिंग

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

दो उपलब्धता क्षेत्रों के मामले में, हम 50% से कम निपटान करते समय बड़े पैमाने पर करते हैं।

यदि सब कुछ पहले से किया जाता है, तो विफलता के मामले में बैलेंसर के जीवित उदाहरण दोगुने ट्रैफ़िक को स्वीकार करने के लिए तैयार हैं।

पहले, हमने केवल उच्च उपयोग के साथ स्केल किया, उदाहरण के लिए, 80%, और अब 45% पर। सिस्टम ज्यादातर समय बेकार रहता है और अधिक महंगा हो जाता है। लेकिन हम इस पर ध्यान देने और पैटर्न का सक्रिय रूप से उपयोग करने के लिए तैयार हैं, क्योंकि यह बीमा है। आपको बीमा के लिए भुगतान करना होगा, लेकिन गंभीर परेशानी के मामले में जीत सभी खर्चों को कवर करती है। यदि आप पैटर्न का उपयोग करने का निर्णय लेते हैं, तो पहले से सभी जोखिमों और कीमत की गणना करें।

सेलुलर वास्तुकला

सेवाओं को बनाने और ढालने के दो तरीके हैं: अखंड और छत्ते की संरचना (सेल-आधारित)।

मोनोलिथ एक बड़े कंटेनर के रूप में विकसित और बढ़ता है। हम संसाधन जोड़ते हैं, सिस्टम सूज जाता है, हम विभिन्न सीमाओं में भागते हैं, रैखिक विशेषताएं गैर-रैखिक हो जाती हैं और संतृप्त हो जाती हैं, और सिस्टम का "ब्लास्ट त्रिज्या" - पूरी प्रणाली।

यदि मोनोलिथ का खराब परीक्षण किया जाता है, तो यह आश्चर्य की संभावना को बढ़ाता है - "अज्ञात अज्ञात"। लेकिन एक बड़े मोनोलिथ का पूरी तरह से परीक्षण नहीं किया जा सकता है। कभी-कभी इसके लिए आपको एक अलग एक्सेस ज़ोन का निर्माण करना होगा, उदाहरण के लिए, एक लोकप्रिय सेवा के लिए जो एक्सेस ज़ोन के भीतर एक मोनोलिथ के रूप में बनाया गया है (यह बहुत सारे डेटा केंद्र हैं)। किसी भी तरह एक विशाल परीक्षण भार पैदा करना जो वर्तमान के समान है, यह वित्तीय दृष्टिकोण से असंभव है।

इसलिए, ज्यादातर मामलों में, हम एक सेलुलर आर्किटेक्चर का उपयोग करते हैं - एक कॉन्फ़िगरेशन जिसमें एक सिस्टम एक निश्चित आकार की कोशिकाओं से बनाया गया है। कोशिकाओं को जोड़कर, हम इसे स्केल करते हैं।

सेल्यूलर आर्किटेक्चर AWS क्लाउड में लोकप्रिय है। यह ग्लिट्स को अलग करने और ब्लास्ट त्रिज्या को कम करने में मदद करता है ।एक या अधिक कोशिकाओं के लिए। हम मध्यम आकार की कोशिकाओं का पूरी तरह से परीक्षण कर सकते हैं, यह गंभीर रूप से जोखिम को कम करता है।

एक समान दृष्टिकोण का उपयोग जहाज निर्माण में किया जाता है: एक जहाज या पोत का पतवार विभाजन द्वारा डिब्बों में विभाजित किया जाता है। छेद होने की स्थिति में, एक या एक से अधिक डिब्बों में पानी भर जाता है, लेकिन जहाज डूबता नहीं है। हां, इसने टाइटैनिक की मदद नहीं की, लेकिन हम शायद ही कभी हिमखंड की समस्याओं का सामना करते हैं।

मैं उदाहरण के रूप में सरल आकृतियाँ सेवा का उपयोग करके मेष दृष्टिकोण के अनुप्रयोग का वर्णन करूँगा। यह AWS सेवा नहीं है, मैं खुद इसे लेकर आया हूं। यह सरल ज्यामितीय आकृतियों के साथ काम करने के लिए सरल एपीआई का एक सेट है। आप एक ज्यामितीय आकार का एक उदाहरण बना सकते हैं, इसके आईडी के आकार के प्रकार का अनुरोध कर सकते हैं या किसी दिए गए प्रकार के सभी उदाहरणों की गणना कर सकते हैं। उदाहरण के लिए, put(triangle)कुछ आईडी के साथ "त्रिकोण" ऑब्जेक्ट अनुरोध पर बनाया गया है ।getShape(id)प्रकार "त्रिकोण", "सर्कल" या "रोम्बस" लौटाता है।

सर्विस क्लाउड बनाने के लिए, इसका उपयोग एक ही समय में विभिन्न उपयोगकर्ताओं द्वारा किया जाना चाहिए। चलो इसे बहु-किरायेदार बनाते हैं।

अगला, आपको विभाजन के तरीके के साथ आने की जरूरत है - आंकड़ों को कोशिकाओं में अलग करने के लिए। विभाजन कुंजी चुनने के लिए कई विकल्प हैं। सबसे सरल एक ज्यामितीय आकार में है : पहले सेल में सभी rhombuses, दूसरे में सर्कल, तीसरे में त्रिकोण।

इस विधि में पेशेवरों और विपक्ष हैं।

यदि अन्य आंकड़ों की तुलना में काफी कम मंडलियां हैं, तो संबंधित सेल अविकसित (असमान वितरण) रहेगा।
कुछ एपीआई अनुरोधों को लागू करना आसान है। उदाहरण के लिए, दूसरी सेल में सभी ऑब्जेक्ट्स की गिनती करते हुए, हम सिस्टम में सर्कल की संख्या पाते हैं।
अन्य प्रश्न अधिक जटिल हैं। उदाहरण के लिए, आईडी द्वारा एक ज्यामितीय आकार खोजने के लिए, आपको सभी कोशिकाओं से गुजरना होगा।

दूसरा तरीका श्रेणियों द्वारा वस्तुओं की आईडी का उपयोग करना है : पहली सेल में पहली हजार वस्तुएं, दूसरे में दूसरा। तो वितरण अधिक समान है, लेकिन अन्य कठिनाइयां हैं। उदाहरण के लिए, सभी त्रिभुजों को गिनने के लिए, आपको विधि का उपयोग करने की आवश्यकता है scatter/gather: हम प्रत्येक सेल में अनुरोधों को वितरित करते हैं, यह त्रिभुजों को अपने अंदर गिनता है, फिर यह उत्तर एकत्र करता है, सारांशित करता है और परिणाम उत्पन्न करता है।

तीसरा तरीका - किरायेदार विभाजन(उपयोगकर्ताओं के लिए)। यहाँ हम एक क्लासिक समस्या का सामना कर रहे हैं। आमतौर पर क्लाउड में बहुत सारे "छोटे" उपयोगकर्ता होते हैं जो कुछ करने की कोशिश करते हैं और व्यावहारिक रूप से सेवा को लोड नहीं करते हैं। मास्टोडन उपयोगकर्ता हैं। वे कम हैं, लेकिन वे बड़ी मात्रा में संसाधनों का उपभोग करते हैं। ऐसे उपयोगकर्ता कभी भी किसी भी सेल में फिट नहीं होंगे। आपको कई कोशिकाओं के बीच वितरित करने के लिए मुश्किल तरीकों से आना होगा।

कोई आदर्श तरीका नहीं है, प्रत्येक सेवा व्यक्तिगत है। अच्छी खबर यह है कि सांसारिक ज्ञान यहां काम करता है - फायरवुड को काटना तंतुओं के बीच अधिक सुविधाजनक है, बजाय उन्हें पार करने के। कई सेवाओं में, ये "फाइबर" कम या ज्यादा स्पष्ट हैं। तब आप प्रयोग कर सकते हैं और इष्टतम विभाजन कुंजी पा सकते हैं।

कोशिकाएं परस्पर जुड़ी होती हैं (यद्यपि दुर्बलता से)। इसलिए, एक कनेक्टिंग स्तर होना चाहिए। अक्सर इसे रूटिंग या मैपिंग लेयर कहा जाता है। यह समझने की जरूरत है कि किन कोशिकाओं को विशिष्ट अनुरोध भेजने हैं। यह स्तर यथासंभव सरल होना चाहिए। कोशिश करें कि इसमें व्यावसायिक तर्क न रखें।

कोशिकाओं के आकार पर सवाल उठता है: छोटा - बुरा, बड़ा - बुरा भी। कोई सार्वभौमिक सलाह नहीं है - स्थिति के अनुसार निर्णय लें।

AWS क्लाउड में, हम विभिन्न आकारों के तार्किक और भौतिक कोशिकाओं का उपयोग करते हैं। एक बड़े सेल आकार के साथ क्षेत्रीय सेवाएँ हैं, ज़ोन सेवाएँ हैं, जहाँ कोशिकाएँ छोटी हैं।

ध्यान दें। मैंने इस वर्ष अप्रैल की शुरुआत में सेंट हाईलोड + ++ पर माइक्रोकल्स के बारे में बात की। वहाँ मैंने विस्तार से इस पैटर्न के विशिष्ट उपयोग का एक उदाहरण हमारी अमेज़ॅन ईबीएस कोर सेवा में चर्चा की।

बहु किरायेदार

जब कोई उपयोगकर्ता एक नया बैलेंसर लॉन्च करता है, तो वह प्रत्येक उपलब्धता क्षेत्र में उदाहरण प्राप्त करता है। भले ही संसाधनों का उपयोग किया जाए या नहीं, वे आवंटित किए जाते हैं और विशेष रूप से क्लाउड के इस किरायेदार के होते हैं।

AWS के लिए, यह दृष्टिकोण अक्षम है, क्योंकि सेवा संसाधनों का उपयोग औसतन बहुत कम है। इससे लागत प्रभावित होती है। क्लाउड उपयोगकर्ताओं के लिए, यह एक लचीला समाधान नहीं है। यह तेजी से बदलती परिस्थितियों के अनुकूल नहीं हो सकता है, उदाहरण के लिए, कम से कम समय में अप्रत्याशित रूप से बढ़े हुए भार के साथ संसाधन प्रदान करना।

सीएलबी अमेज़ॅन क्लाउड में पहला बैलेंसर था। सेवाएं आज एक बहु-किरायेदार दृष्टिकोण का उपयोग करती हैं, जैसे कि एनएलबी (नेटवर्क लोड बैलेंसर)। आधार, ऐसी नेटवर्क सेवाओं का "इंजन" हाइपरप्लेन है। यह एक आंतरिक, अंत उपयोगकर्ताओं के लिए अदृश्य, आभासी मशीनों (नोड्स) का विशाल बेड़ा है।

के लाभ मल्टी-टेनेंट दृष्टिकोण या पांचवें पैटर्न।

दोष सहिष्णुता मौलिक रूप से अधिक है । HyperPlane में, बड़ी संख्या में नोड्स पहले से ही चल रहे हैं और लोड की प्रतीक्षा कर रहे हैं। नोड्स एक-दूसरे की स्थिति जानते हैं - जब कुछ संसाधन विफल हो जाते हैं, तो शेष लोगों के बीच लोड तुरंत वितरित किया जाता है। उपयोगकर्ताओं को बड़े पैमाने पर क्रैश की सूचना भी नहीं है।
पीक लोड सुरक्षा । किरायेदार अपने स्वयं के जीवन जीते हैं और उनके भार आमतौर पर एक दूसरे के साथ सहसंबंधित नहीं होते हैं। हाइपरप्लेन पर कुल औसत लोड काफी आसान है।
ऐसी सेवाओं का उपयोग मौलिक रूप से बेहतर है । इसलिए, बेहतर प्रदर्शन प्रदान करते हुए, वे सस्ते हैं।

यह सुनने में अच्छा लगा! लेकिन बहुपरत दृष्टिकोण में कमियां हैं। आकृति में, हाइपरप्लेन के बेड़े में तीन किरायेदार (rhombuses, मंडलियां और त्रिकोण) होते हैं, जो सभी नोड्स में वितरित किए जाते हैं ।

यह क्लासिक शोर पड़ोसी समस्या को जन्म देता है: किरायेदार की विनाशकारी कार्रवाई, जो अति-उच्च या खराब यातायात उत्पन्न करती है, संभावित रूप से सभी उपयोगकर्ताओं को प्रभावित करेगी।

ऐसी प्रणाली में "ब्लास्ट त्रिज्या" सभी किरायेदारों है। वास्तविक AWS उपलब्धता क्षेत्र में एक विनाशकारी "शोर पड़ोसी" की संभावना अधिक नहीं है। लेकिन हमें हमेशा सबसे बुरे के लिए तैयार रहना चाहिए। हम एक मेष दृष्टिकोण का उपयोग कर अपना बचाव करते हैं - हम कोशिकाओं के रूप में नोड्स के समूहों का चयन करते हैं। इस संदर्भ में, हम उन्हें शार्क कहते हैं। सेल, शार्द, विभाजन - यहाँ यह एक और एक ही है।

इस उदाहरण में, एक रोम्बस, "शोर पड़ोसी" के रूप में, केवल एक किरायेदार को प्रभावित करेगा - एक त्रिकोण। लेकिन त्रिकोण बहुत दर्दनाक होगा। प्रभाव को सुचारू करने के लिए, छठे पैटर्न को लागू करें - मिश्रण को तेज करना।

झकझोरने वाला तेज

हम बेतरतीब ढंग से किरायेदारों को नोड्स में वितरित करते हैं। उदाहरण के लिए, 1, 3, और 6 नोड्स पर एक समभुज भूमि, और 2, 6 और 8 पर एक त्रिकोण। हमारे पास 8 नोड्स और आकार का एक हिस्सा है। 3.

यहाँ साधारण कॉम्बिनेटरिक्स काम करते हैं। 54% की संभावना के साथ, किरायेदारों के बीच केवल एक चौराहा होगा।

"शोर पड़ोसी" केवल एक किरायेदार को प्रभावित करेगा, और पूरे भार को नहीं, बल्कि केवल 30 प्रतिशत।

वास्तविक के करीब कॉन्फ़िगरेशन पर विचार करें - 100 नोड, शार्प आकार 5. 77% की संभावना के साथ, कोई चौराहा नहीं होगा।

शफ़ल शार्किंग "ब्लास्ट रेडियस" को काफी कम कर सकती है। इस दृष्टिकोण का उपयोग कई AWS सेवाओं में किया जाता है।

"एक छोटा बेड़ा एक बड़े बेड़े का कारण बनता है, और इसके विपरीत नहीं"

बड़े पैमाने पर विफलता से उबरने पर, हम कई घटकों के कॉन्फ़िगरेशन को अपडेट करते हैं। इस मामले में एक विशिष्ट प्रश्न एक परिवर्तित कॉन्फ़िगरेशन को पुश या बुलेट करना है? परिवर्तनों का आरंभकर्ता कौन है: कॉन्फ़िगरेशन परिवर्तन वाला स्रोत, या इसके उपभोक्ता? लेकिन ये सवाल गलत हैं। सही सवाल यह है कि कौन सा बेड़ा बड़ा है?

एक साधारण स्थिति पर विचार करें: फ्रंट-एंड वर्चुअल मशीनों का एक बड़ा बेड़ा और निश्चित संख्या में बैकएंड।

हम एक मेष दृष्टिकोण का उपयोग करते हैं - फ्रंट-एंड इंस्टेंस के समूह कुछ बैकएंड के साथ काम करेंगे। ऐसा करने के लिए, उनके साथ काम करने वाले बैकेंड और फ्रंटेंड की राउटिंग - मैपिंग निर्धारित करें।

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

मान लीजिए कि हमारे पास एक बड़ी दुर्घटना थी, कई फ्रंट-एंड उदाहरण गिर गए। वे बड़े पैमाने पर पुनर्प्राप्त करना शुरू करते हैं और लगभग एक साथ रूटिंग सेवा से मानचित्रण कॉन्फ़िगरेशन का अनुरोध करते हैं।

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

इसलिए, यह एक छोटी सेवा से कॉन्फ़िगरेशन परिवर्तन का अनुरोध नहीं करने के लिए सही है, बल्कि आपके सिस्टम का निर्माण करता है ताकि "शिशु" स्वयंइंस्टेंसेस का एक बड़ा बेड़ा की ओर विन्यास शुरू हुआ ।

हम निरंतर काम के पैटर्न का उपयोग करते हैं। एक छोटी सी राउटिंग सेवा हर कुछ सेकंड में एक बार सभी फ्रंट-एंड बेड़े उदाहरणों के लिए कॉन्फ़िगरेशन भेज देगी। वह कभी भी एक महान सेवा को अधिभार नहीं दे पाएंगे। सातवीं पैटर्न स्थिरता और लचीलापन में सुधार करने में मदद करता है ।

पहले सात पैटर्न सिस्टम को बढ़ाते हैं। बाद वाला पैटर्न अलग तरह से काम करता है।

गिराने का भार

नीचे देरी बनाम लोड का एक क्लासिक ग्राफ है। ग्राफ के दाईं ओर "घुटने" है, जब अत्यधिक उच्च भार पर भी एक छोटी सी वृद्धि में विलंबता में उल्लेखनीय वृद्धि होती है।

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

हमने चार्ट पर क्लाइंट टाइमआउट रखा। कोई भी ग्राहक हो सकता है, उदाहरण के लिए, हमारी सेवा के अंदर एक और घटक। सादगी के लिए, हम 50 प्रतिशत की देरी ग्राफ खींचते हैं।

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

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

हमने एक दोहरी समस्या का सामना किया: हम पहले से ही अतिभारित हैं और शेड्यूल के दाईं ओर हैं, लेकिन साथ ही हम अभी भी "हवा को गर्म कर रहे हैं", बहुत सारे बेकार काम कर रहे हैं। इससे कैसे बचा जाए?

"घुटने" का पता लगाएं - चार्ट पर विभक्ति बिंदु । हम मापते हैं या सैद्धांतिक रूप से अनुमान लगाते हैं।

ड्रॉप ट्रैफ़िक जो हमें विभक्ति बिंदु के दाईं ओर जाने के लिए मजबूर करता है ।

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

उसी समय, अनुरोधों का एक और हिस्सा गारंटीकृत कम विलंबता के साथ संसाधित किया जाता है। नतीजतन, हम बेकार काम नहीं करते हैं, और हम क्या करते हैं, हम अच्छा करते हैं।

विफलता के लिए डिजाइनिंग सिस्टम के पैटर्न का संक्षिप्त निचोड़

अलगाव और विनियमन । कभी-कभी यह कुछ प्रकार के प्रश्नों को प्राथमिकता देने के लिए समझ में आता है। उदाहरण के लिए, नए संसाधन बनाने के अनुरोधों की अपेक्षाकृत कम मात्रा के साथ, उन्हें कतार में सबसे ऊपर रखा जा सकता है। यह महत्वपूर्ण है कि यह अन्य उपयोगकर्ताओं पर उल्लंघन नहीं करता है। बड़े पैमाने पर आउटेज में, जो उपयोगकर्ता अपने संसाधनों को पुनर्प्राप्त करने के लिए इंतजार कर रहे हैं, वे एक महत्वपूर्ण अंतर महसूस नहीं करेंगे।

पूर्णकालिक नौकरी । सेवा मोड के स्विचिंग को कम या पूरी तरह से समाप्त करें। एक मोड, जो स्थिर और लगातार काम करता है, आपातकालीन या कामकाजी स्थितियों की परवाह किए बिना, मौलिक रूप से नियंत्रण विमान की स्थिरता और पूर्वानुमानशीलता में सुधार करता है।

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

सेलुलर वास्तुकला । एक मोनोलिथ के ऊपर कई शिथिल युग्मित कोशिकाएं पसंद की जाती हैं। मेष दृष्टिकोण "ब्लास्ट त्रिज्या" और आश्चर्य त्रुटियों की संभावना को कम करता है।

बहुपरत दृष्टिकोण सेवा के उपयोग में काफी सुधार करता है, इसकी लागत को कम करता है और "ब्लास्ट त्रिज्या" को कम करता है।

झकझोरने वाला तेज । यह एक दृष्टिकोण है जो बहु-किरायेदार सेवाओं पर लागू होता है। यह अतिरिक्त रूप से आपको "ब्लास्ट त्रिज्या" को नियंत्रित करने की अनुमति देता है।

"एक छोटा बेड़ा एक बड़े बेड़े का कारण बनता है, और इसके विपरीत नहीं"। हम सेवाओं का निर्माण करने की कोशिश करते हैं ताकि छोटी सेवाएं बड़े कॉन्फ़िगरेशन में परिवर्तन शुरू करें। हम अक्सर इसे एक निरंतर लोड पैटर्न के साथ संयोजन में उपयोग करते हैं।

भार छोड़ना । आपातकालीन स्थितियों में, हम केवल उपयोगी काम करने की कोशिश करते हैं, और इसे अच्छी तरह से करते हैं। ऐसा करने के लिए, हम लोड का हिस्सा छोड़ देते हैं, जिसे हम अभी भी संभाल नहीं सकते हैं।

— , Saint HighLoad++ Online. -- , Q&A-, , . - . , - .

telegram- @HighLoadChannel — , .

हॉस्टन हमारे पास समस्या हे। सिस्टम डिज़ाइन विफलता