यह लेख कुछ सामान्य पैटर्न एकत्रित करता है, जिससे इंजीनियरों को बड़े पैमाने की सेवाओं के साथ काम करने में मदद मिलेगी, जिनके बारे में लाखों उपयोगकर्ता पूछते हैं।

लेखक के अनुभव के अनुसार, यह कोई संपूर्ण सूची नहीं है, लेकिन यह सच है। प्रभावी तो, चलिए शुरू करते हैं।

के सहयोग से अनुवादित Mail.ru क्लाउड सॉल्यूशंस.

प्रथम स्तर

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

कोड के रूप में बुनियादी ढांचा

सलाह का पहला भाग बुनियादी ढांचे को कोड के रूप में लागू करना है। इसका मतलब है कि आपके पास अपने सभी बुनियादी ढांचे को तैनात करने का एक प्रोग्रामेटिक तरीका होना चाहिए। यह जटिल लगता है, लेकिन हम वास्तव में इस तरह के कोड के बारे में बात कर रहे हैं:

100 वर्चुअल मशीनें तैनात करना

उबंटू के साथ

2GB रैम प्रत्येक

उनके पास निम्नलिखित कोड होगा

ऐसे मापदंडों के साथ

आप अपने बुनियादी ढांचे में परिवर्तनों को ट्रैक कर सकते हैं और संस्करण नियंत्रण प्रणाली का उपयोग करके उन्हें तुरंत वापस ला सकते हैं।

मेरे अंदर का आधुनिकतावादी कहता है कि आप उपरोक्त सभी कार्य करने के लिए कुबेरनेट्स/डॉकर का उपयोग कर सकते हैं, और वह सही है।

इसके अतिरिक्त, शेफ, पपेट या टेराफॉर्म का उपयोग करके स्वचालन प्राप्त किया जा सकता है।

निरंतर एकीकरण और वितरण

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

इस स्तर पर हर बार आप प्रश्न का उत्तर देते हैं: क्या मेरा निर्माण संकलित होगा और परीक्षण पास करेगा, क्या यह वैध है? यह एक छोटा सा कदम लग सकता है, लेकिन इससे बहुत सारी समस्याएं हल हो जाती हैं।

इन चेक मार्कों को देखने से अधिक सुन्दर कुछ भी नहीं है।

इस तकनीक के लिए आप Github, CircleCI या Jenkins देख सकते हैं।

लोड बैलेंसर्स

इसलिए, हम ट्रैफ़िक को पुनर्निर्देशित करने और विफलता के मामले में सभी नोड्स या सेवा संचालन पर समान लोड सुनिश्चित करने के लिए एक लोड बैलेंसर चलाना चाहते हैं:

लोड बैलेंसर आम तौर पर ट्रैफ़िक वितरित करने का अच्छा काम करता है। सबसे अच्छा अभ्यास अनावश्यक रूप से संतुलन बनाना है ताकि आपके पास विफलता का एक भी बिंदु न हो।

आमतौर पर, लोड बैलेंसर्स आपके द्वारा उपयोग किए जा रहे क्लाउड में कॉन्फ़िगर किए जाते हैं।

प्रश्नों के लिए RayID, सहसंबंध ID या UUID

क्या आपने कभी किसी एप्लिकेशन में इस तरह के संदेश के साथ कोई त्रुटि देखी है: "कुछ गड़बड़ हो गई है। इस आईडी को सेव करें और हमारी सहायता टीम को भेजें"?

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

उपयोगकर्ता सिस्टम A से अनुरोध करता है, फिर A सिस्टम B से संपर्क करता है, जो C से संपर्क करता है, उसे X में संग्रहीत करता है, और फिर अनुरोध सिस्टम A के पास वापस आता है

यदि आप अपने VM से दूर से कनेक्ट होते हैं और किसी अनुरोध के पथ का अनुसरण करने का प्रयास करते हैं (और मैन्युअल रूप से सहसंबंधित करते हैं कि कौन सी कॉल की जा रही थी), तो आप पागल हो जाएंगे। एक अद्वितीय पहचानकर्ता होने से जीवन बहुत आसान हो जाता है। यह सबसे आसान चीजों में से एक है जो आप अपनी सेवा के बढ़ने के साथ समय बचाने के लिए कर सकते हैं।

मध्यवर्ती स्तर

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

केंद्रीकृत लॉगिंग

बधाई हो! आपने 100 वर्चुअल मशीनें तैनात कर दी हैं। अगले दिन, सीईओ आता है और सेवा का परीक्षण करते समय मिली त्रुटि के बारे में शिकायत करता है। वह आपको प्रासंगिक आईडी देता है जिसके बारे में हमने ऊपर बात की थी, लेकिन आपको क्रैश हुई मशीन को खोजने के लिए 100 मशीनों के लॉग को छानना होगा। और आपको इसे कल प्रेजेंटेशन से पहले खोजना होगा।

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

ELK स्टैक कार्यक्षमता

निगरानी एजेंट

अब जब आपकी सेवा चालू हो गई है, तो आपको यह सुनिश्चित करना होगा कि यह सुचारू रूप से चले। ऐसा करने का सबसे अच्छा तरीका कुछ चलाना है एजेंट, जो समानांतर रूप से चलते हैं और जांचते हैं कि यह काम करता है और बुनियादी संचालन किया जाता है।

इस स्तर पर आप जाँच करें कि चलती हुई असेंबली अच्छी लगती है और ठीक से काम करती है.

छोटे से मध्यम प्रोजेक्ट के लिए, मैं API की निगरानी और दस्तावेज़ीकरण के लिए Postman की सलाह देता हूँ। लेकिन सामान्य तौर पर, आप बस यह सुनिश्चित करना चाहते हैं कि आपके पास यह जानने का कोई तरीका हो कि कब कुछ गलत हो रहा है और समय पर अलर्ट हो जाए।

लोड के आधार पर ऑटोस्केलिंग

यह बहुत आसान है। यदि आपके पास अनुरोधों को पूरा करने वाला कोई VM है और यह 80% मेमोरी पर कब्जा कर रहा है, तो आप या तो इसके संसाधन बढ़ा सकते हैं या क्लस्टर में और VM जोड़ सकते हैं। लोड के तहत लोचदार क्षमता स्केलिंग के लिए इन चीजों को स्वचालित रूप से करना बहुत अच्छा है। लेकिन आपको हमेशा इस बात का ध्यान रखना चाहिए कि आप कितना पैसा खर्च करते हैं और उचित सीमाएँ निर्धारित करें।

अधिकांश क्लाउड सेवाएं आपको अधिक सर्वर या अधिक शक्तिशाली सर्वर का उपयोग करके स्वचालित स्केलिंग सेट करने की अनुमति देती हैं।

प्रायोगिक प्रणाली

अपडेट को सुरक्षित रूप से रोल आउट करने का एक अच्छा तरीका है कि किसी चीज़ को 1% उपयोगकर्ताओं पर एक घंटे तक टेस्ट किया जाए। आपने निश्चित रूप से इसे कार्रवाई में देखा होगा। उदाहरण के लिए, फेसबुक दर्शकों के एक हिस्से को एक अलग रंग या फ़ॉन्ट आकार दिखाता है ताकि यह देखा जा सके कि उपयोगकर्ता परिवर्तन पर कैसे प्रतिक्रिया करते हैं। इसे A/B परीक्षण कहा जाता है।

यहां तक कि एक नई सुविधा जारी करना भी एक प्रयोग के रूप में शुरू किया जा सकता है और फिर यह निर्धारित किया जा सकता है कि इसे कैसे जारी किया जाए। आपको अपनी सेवा को ख़राब करने वाली सुविधा के आधार पर कॉन्फ़िगरेशन को "वापस बुलाने" या बदलने की क्षमता भी मिलती है।

उन्नत स्तर

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

ब्लू-ग्रीन तैनाती

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

यह चरण लोड बैलेंसर की मौजूदगी पर निर्भर करता है। मान लीजिए कि आपके पास अपने सॉफ़्टवेयर का संस्करण N है, और फिर आप संस्करण N+1 को तैनात करना चाहते हैं।

आप सकता है बस सेवा बंद कर दें और अपने उपयोगकर्ताओं के लिए सुविधाजनक समय पर अगला संस्करण तैनात करें, और कुछ डाउनटाइम पाएँ। लेकिन मान लें कि आपके पास वास्तव में सख्त SLA शर्तें। तो, SLA 99,99% का मतलब है कि आप ऑफ़लाइन जा सकते हैं केवल प्रति वर्ष 52 मिनट की वृद्धि होगी।

यदि आप वास्तव में इन संख्याओं को प्राप्त करना चाहते हैं, तो आपको एक ही समय में दो तैनाती की आवश्यकता होगी:

जो अभी है (एन);
अगला संस्करण (N+1).

आप लोड बैलेंसर को ट्रैफ़िक के एक प्रतिशत को नए संस्करण (N+1) पर पुनर्निर्देशित करने के लिए कहते हैं, जबकि आप सक्रिय रूप से प्रतिगमन की निगरानी करते हैं।

यहाँ हमारे पास एक हरा परिनियोजन N है, जो ठीक काम करता है। हम इस परिनियोजन के अगले संस्करण पर जाने का प्रयास कर रहे हैं।

सबसे पहले हम यह देखने के लिए एक छोटा सा परीक्षण भेजते हैं कि क्या हमारा N+1 परिनियोजन कम मात्रा में ट्रैफ़िक के साथ काम करता है:

अंत में, हमारे पास स्वचालित जाँचों का एक सेट है जिसे हम अंततः तब तक चलाते हैं जब तक कि हमारी तैनाती पूरी नहीं हो जाती। बहुत-बहुत सावधान रहें, आप खराब प्रतिगमन के मामले में त्वरित रोलबैक के लिए अपने एन परिनियोजन को हमेशा के लिए सहेज सकते हैं:

यदि आप चीजों को और भी आगे ले जाना चाहते हैं, तो ब्लू-ग्रीन डिप्लॉय में सब कुछ स्वचालित रूप से होने दें।

विसंगति का पता लगाना और स्वचालित शमन

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

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

इस अंतर्दृष्टि के साथ, आप किसी भी आयाम में स्केल कर सकते हैं, मशीनों, डेटाबेस, कनेक्शन और अन्य संसाधनों की विशेषताओं को सक्रिय और प्रतिक्रियात्मक रूप से बदल सकते हैं।

वह सब है!

यदि आप क्लाउड सेवा चला रहे हैं तो यह प्राथमिकता सूची आपको बहुत परेशानी से बचाएगी।

मूल लेख के लेखक पाठकों को अपनी टिप्पणियाँ छोड़ने और परिवर्तन करने के लिए आमंत्रित करते हैं। लेख को ओपन सोर्स के रूप में वितरित किया जाता है, लेखक द्वारा अनुरोध किया जाता है गिटहब पर स्वीकार करता है.

विषय पर और क्या पढ़ें:

स्रोत: www.habr.com