सिटीमोबिल - स्टार्टअप्स के लिए व्यावसायिक विकास के बीच उपलब्धता में सुधार के लिए एक मैनुअल। भाग ४

यह श्रृंखला का अगला लेख है जिसमें बताया गया है कि हम सिटीमोबिल में हमारी सेवा उपलब्धता कैसे बढ़ा रहे हैं (आप पिछले भागों को यहाँ पढ़ सकते हैं: भाग 1 , भाग 2 , भाग 3 )। आगे के भागों में, मैं दुर्घटनाओं और विस्तार के बारे में विस्तार से बात करूँगा।

1. खराब रिलीज: डेटाबेस अधिभार

मुझे इस प्रकार के आउटेज के एक विशिष्ट उदाहरण के साथ शुरू करना चाहिए। हमने एक अनुकूलन तैनात किया: USE INDEX को SQL क्वेरी में जोड़ा; परीक्षण के साथ-साथ उत्पादन में, इसने छोटे प्रश्नों को जन्म दिया, लेकिन लंबे समय तक - धीमा हो गया। लंबे प्रश्नों की मंदी केवल उत्पादन में देखी गई थी। परिणामस्वरूप, बहुत सारे लंबे समानांतर प्रश्नों के कारण डेटाबेस एक घंटे के लिए डाउन हो गया। हमने USE INDEX के काम करने के तरीके का गहन अध्ययन किया; हमने इसे डू और डॉन्ट की फाइल में वर्णित किया और इंजीनियरों को गलत उपयोग के खिलाफ चेतावनी दी। हमने क्वेरी का भी विश्लेषण किया और महसूस किया कि यह ज्यादातर ऐतिहासिक डेटा को पुनः प्राप्त करता है और इसलिए, ऐतिहासिक अनुरोधों के लिए एक अलग प्रतिकृति पर चलाया जा सकता है। यदि यह प्रतिकृति एक अधिभार के कारण नीचे जाती है, तो भी व्यवसाय चलता रहेगा।

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

• मास्टर डेटाबेस - लिखने के संचालन और प्रश्नों के लिए जो डेटा ताजगी के लिए अति संवेदनशील हैं;
  
• उत्पादन प्रतिकृतियां - छोटे प्रश्नों के लिए जो डेटा ताजगी के लिए कम संवेदनशील हैं;
  
• मूल्य वृद्धि गुणांक के लिए प्रतिकृतियां। ये प्रतिकृतियां 30-60 सेकंड पीछे हो सकती हैं; यह महत्वपूर्ण नहीं है क्योंकि गुणांक में परिवर्तन नहीं होता है और यदि यह प्रतिकृति नीचे जाती है, तो सेवा काम करना बंद नहीं करेगी; कीमतें पूरी तरह से आपूर्ति और मांग संतुलन से मेल नहीं खातीं;
  
• परिचालन सेटिंग्स और कॉल सेंटर के लिए प्रतिकृति। यदि यह दुर्घटनाग्रस्त हो जाता है, तो व्यवसाय चलता रहेगा लेकिन ग्राहक और ड्राइवर के समर्थन के बिना, और हम कुछ सेटिंग्स को अस्थायी रूप से बदलने में सक्षम नहीं होंगे;
  
• तदर्थ विश्लेषिकी और डैशबोर्ड के लिए कई प्रतिकृतियां;
  
• ऐतिहासिक डेटा पर संपूर्ण स्लाइस के साथ कुछ बड़े एनालिटिक्स के लिए एमपीपी (बड़े पैमाने पर समानांतर प्रसंस्करण) डेटाबेस।
  

इस वास्तुकला ने हमें विकास के लिए विशाल स्थान प्रदान किया और गैर-अपनाने योग्य SQL प्रश्नों के कारण कई दुर्घटनाओं को कम किया। लेकिन यह अभी भी परिपूर्ण होने से बहुत दूर है। हम शार्किंग को लागू करने की योजना बना रहे हैं, ताकि हम अपडेट और डिलीट और सुपर सेंसिटिव डेटा के प्रति संवेदनशील हो सकें। सुरक्षा के MySQL मार्जिन अनंत नहीं है। हमें जल्द ही कुछ इन-मेमोरी डेटाबेस (जैसे टारनटूल) के रूप में कुछ भारी तोपों की आवश्यकता होगी। मैं निश्चित रूप से अपने अगले लेखों में इसके बारे में बात करूंगा।

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

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

• यदि कोई SQL क्वेरी उपयोगकर्ता पर निर्भर नहीं करता है (उदाहरण के लिए, अधिकतम किराए और सर्ज गुणांक वाले ड्राइवर की डिमांड मैप - यह मैप ड्राइवर ऐप के किसी भी उपयोगकर्ता के लिए समान है), तो इस क्वेरी को क्रोन स्क्रिप्ट में किया जाना चाहिए कुछ विशिष्ट आवृत्ति (एक बार एक मिनट उस मामले में पर्याप्त होती है)। परिणाम को कैश (मेम्केच्ड या रेडिस) में लिखा जाना चाहिए जिसका उपयोग उत्पादन कोड में किया जाना चाहिए।
  
• यदि SQL क्वेरी डेटा के साथ काम करती है, जो व्यवसाय के लिए महत्वपूर्ण नहीं है, तो इसका परिणाम कैश में कुछ TTL (30 सेकंड, उदाहरण के लिए) के साथ रखा जाना चाहिए और फिर उत्पादन कोड द्वारा कैश से पढ़ा जाना चाहिए।
  
• यदि एक विशिष्ट सर्वर विधि कार्यान्वयन (PHP या किसी अन्य सर्वर-साइड भाषा में) आप SQL क्वेरी बनाने का निर्णय लेते हैं, तो आपको यह सुनिश्चित करने की आवश्यकता है कि आपको किसी अन्य SQL क्वेरी के साथ या आने वाले डेटा की आवश्यकता नहीं है नीचे आपका कोड
  
• ऊपर के रूप में भी एक कैश के लिए अनुरोध करने के लिए चला जाता है। एक कैश तेज़ है लेकिन अभी भी एक डेटाबेस है। इसलिए इसे ओवरलोड भी किया जा सकता है। एक सामान्य गलती यह है कि आपको लगता है कि कैश सामान्य इन-मेमोरी चर की तरह है और इसे चर के रूप में उपयोग करें। लेकिन इसे एक्सेस करने के लिए एक नेटवर्क राउंड ट्रिप शामिल है और Redis या Memcached को वर्कलोड जनरेट करता है। इसलिए, यदि डेटा पहले ही कैश से आ चुका है, तो अभी जो कैश पहले से लिया गया है, उसे कैश से न लें।
  
• यदि एक वेब अनुरोध प्रसंस्करण के दौरान (फिर से PHP या किसी अन्य भाषा में) आपको किसी फ़ंक्शन को कॉल करने की आवश्यकता है, तो आपको यह सुनिश्चित करने की आवश्यकता है कि कोई अतिरिक्त SQL क्वेरी या कैश एक्सेस नहीं होगा। यदि ऐसी फ़ंक्शन कॉल अपरिहार्य है, तो आपको यह सुनिश्चित करना चाहिए कि इसे संशोधित नहीं किया जा सकता है, या अनावश्यक डेटाबेस / कैश प्रश्नों को रोकने के लिए इसके तर्क को तोड़ा नहीं गया है।
  
• यदि यह SQL क्वेरी करने के लिए आवश्यक है, तो आपको पूरी तरह से सुनिश्चित होना चाहिए कि जिन फ़ील्ड्स की आपको आवश्यकता है, उन्हें आपके कोड में पहले से मौजूद प्रश्नों के ऊपर या नीचे जोड़ा नहीं जा सकता है।
  

2. खराब मैनुअल ऑपरेशन

इन दुर्घटनाओं के उदाहरण:

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

इन कारणों से होने वाले नुकसान को कम करने के लिए, हमें हर बार होने वाली दुर्घटना प्रकृति की जांच करनी होगी। हमने अभी तक एक सामान्य नियम नहीं निकाला है। फिर, आइए कुछ विशिष्ट उदाहरण देखें। सर्ज गुणांक (समय और उच्च मांग के स्थान पर टैक्सी किराया उनके द्वारा गुणा किया जाता है) ने कुछ बिंदु पर काम करना बंद कर दिया। कारण यह था कि एक डेटाबेस प्रतिकृति सर्वर पर एक पायथन स्क्रिप्ट काम कर रही थी, जहां गुणांकों की गणना के लिए डेटा लिया गया था और स्क्रिप्ट ने सभी मेमोरी और प्रतिकृति का उपयोग किया था। स्क्रिप्ट कुछ समय से चल रही थी; यह सुविधा के लिए प्रतिकृति पर सही तरीके से चल रहा था। स्क्रिप्ट को पुनरारंभ करने से समस्या हल हो गई थी। निम्नलिखित निष्कर्ष निकाले गए: एक डेटाबेस सर्वर पर विदेशी स्क्रिप्ट न चलाएं (यह Do's में लिखा गया था और अन्यथा, अन्यथा यह एक खाली शॉट होगा!), डेटाबेस सर्वर पर मेमोरी उपयोग की निगरानी करें और एसएमएस के माध्यम से अलर्ट करें। अगर वह सर्वर मेमोरी से बाहर निकलने वाला है।

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

निगरानी और अलर्ट दिखाई नहीं दे रहे हैं, लेकिन वे लोहे के हुक की तरह काम करते हैं, अज्ञात की चट्टान में काटने से हमें अपने सेवा स्तर के समझौते से नीचे गिरने से रोकते हैं कि हम लगातार बढ़ रहे हैं।

3. ईस्टर अंडा

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

उदाहरण के लिए:

• 32-बिट auto_increment ;
  
• उच्च वर्कलोड द्वारा ट्रिगर किए गए कोड / कॉन्फ़िगरेशन की गैर-समरूपता;
  
• उपयोग के एक नए पैटर्न द्वारा या भारी कार्यभार द्वारा लाई गई एक नॉनटॉइमल क्वेरी द्वारा विलंबित प्रतिकृति;
  
• नए वर्कलोड पैटर्न के कारण होने वाले मास्टर पर एक नॉन-यूपीडल ऑपरेशन के द्वारा प्रतिकृति की देरी और प्रतिकृति में देरी हुई।
  

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

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

हालाँकि, हमारे पास ईस्टर से संबंधित कुछ कार्यभार नहीं थे। उदाहरण के लिए, MYSQL में एक 32-बिट auto_increment फ़ील्ड। 2 बिलियन से अधिक पंक्तियों के बाद, आवेषण विफल हो जाते हैं। इसलिए, आधुनिक दुनिया में, हमें केवल 64-बिट auto_increment फ़ील्ड का उपयोग करना चाहिए। हमने उस पाठ को अच्छी तरह से सीखा।

ईस्टर अंडे से कैसे निपटें? उत्तर सीधा लगता है: ए) पुराने अंडे की खोज करते हैं, बी) नए लोगों को प्रकट होने की अनुमति नहीं देते हैं। हम दोनों करने की कोशिश कर रहे हैं। पुराने अंडों की खोज हमारे निरंतर कोड अनुकूलन के साथ हाथ से जाती है। हमने लगभग पूरे समय अनुकूलन करने के लिए सबसे अनुभवी इंजीनियरों में से दो को नियुक्त किया। वे slow.log में क्वेरीज़ ढूंढते हैं जो डेटाबेस संसाधनों का सबसे अधिक उपयोग करते हैं; वे इन प्रश्नों और उनके आसपास के कोड को अनुकूलित करते हैं। हम उपरोक्त उल्लिखित संवेदी इंजीनियरों द्वारा किए गए इष्टतमता के लिए हर प्रतिबद्ध के परीक्षण के माध्यम से नए अंडों के उभरने की संभावना को कम करते हैं। उनका काम प्रदर्शन को प्रभावित करने वाली गलतियों को इंगित करना है, चीजों को बेहतर बनाने का तरीका सुझाना और अन्य इंजीनियरों पर इस ज्ञान को पास करना है।

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

4. बाहरी कारण

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

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

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

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

---

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