sophiagworld द्वारे गमावले

या लेखात अभियंत्यांना लाखो वापरकर्त्यांद्वारे अ‍ॅक्सेस केलेल्या मोठ्या प्रमाणात सेवांसह काम करण्यात मदत करण्यासाठी काही सामान्य नमुने आहेत. 

लेखकाच्या अनुभवानुसार, ही एक संपूर्ण यादी नाही, परंतु खरंच प्रभावी सल्ला तर, चला सुरुवात करूया.

समर्थनासह अनुवादित Mail.ru क्लाउड सोल्यूशन्स.

प्रथम स्तर

खाली सूचीबद्ध केलेले उपाय अंमलात आणण्यासाठी तुलनेने सोपे आहेत परंतु त्यांचा प्रभाव जास्त आहे. आपण यापूर्वी त्यांचा प्रयत्न केला नसल्यास, आपण लक्षणीय सुधारणांबद्दल आश्चर्यचकित व्हाल.

कोड म्हणून पायाभूत सुविधा

सल्ल्याचा पहिला भाग म्हणजे कोड म्हणून पायाभूत सुविधा लागू करणे. याचा अर्थ असा की तुमच्याकडे संपूर्ण पायाभूत सुविधा तैनात करण्यासाठी प्रोग्रामेटिक मार्ग असणे आवश्यक आहे. हे क्लिष्ट वाटते, परंतु आम्ही प्रत्यक्षात खालील कोडबद्दल बोलत आहोत:

100 व्हर्च्युअल मशीनची तैनाती

• उबंटू सह
• प्रत्येकी 2 GB रॅम
• त्यांच्याकडे खालील कोड असेल
• या पॅरामीटर्ससह

तुम्ही तुमच्या इन्फ्रास्ट्रक्चरमधील बदलांचा मागोवा घेऊ शकता आणि आवृत्ती नियंत्रण वापरून त्यांच्याकडे त्वरीत परत येऊ शकता.

माझ्यामधला आधुनिकतावादी म्हणतो की तुम्ही वरील सर्व गोष्टी करण्यासाठी कुबर्नेट्स/डॉकर वापरू शकता आणि तो बरोबर आहे.

याव्यतिरिक्त, आपण शेफ, पपेट किंवा टेराफॉर्म वापरून ऑटोमेशन प्रदान करू शकता.

सतत एकत्रीकरण आणि वितरण

स्केलेबल सेवा तयार करण्यासाठी, प्रत्येक पुल विनंतीसाठी बिल्ड आणि चाचणी पाइपलाइन असणे महत्त्वाचे आहे. जरी चाचणी अगदी सोपी असली तरीही, ते किमान हे सुनिश्चित करेल की आपण उपयोजित केलेला कोड संकलित करतो.

प्रत्येक वेळी या टप्प्यावर तुम्ही प्रश्नाचे उत्तर द्या: माझी असेंब्ली संकलित करेल आणि चाचण्या पास करेल, ते वैध आहे का? हे कमी बारसारखे वाटू शकते, परंतु ते बर्याच समस्यांचे निराकरण करते.

या टिक्स पाहण्यापेक्षा सुंदर काहीही नाही

या तंत्रज्ञानासाठी तुम्ही Github, CircleCI किंवा Jenkins चे मूल्यांकन करू शकता.

लोड बॅलन्सर्स

त्यामुळे, ट्रॅफिक पुनर्निर्देशित करण्यासाठी आणि सर्व नोड्सवर समान भार सुनिश्चित करण्यासाठी किंवा अयशस्वी झाल्यास सेवा सुरू ठेवण्यासाठी आम्हाला लोड बॅलन्सर चालवायचा आहे:

लोड बॅलन्सर सामान्यतः रहदारीचे वितरण करण्यासाठी चांगले काम करतो. सर्वोत्तम सराव म्हणजे अतिसंतुलित करणे जेणेकरून तुमच्याकडे अपयशाचा एकही बिंदू राहणार नाही.

सामान्यतः, लोड बॅलन्सर तुम्ही वापरत असलेल्या क्लाउडमध्ये कॉन्फिगर केले जातात.

विनंत्यांसाठी RayID, सहसंबंध आयडी किंवा UUID

तुम्हाला कधी यासारख्या संदेशासह अनुप्रयोग त्रुटी आली आहे: "काहीतरी चूक झाली. हा आयडी सेव्ह करा आणि आमच्या सपोर्ट टीमला पाठवा"?

युनिक आयडेंटिफायर, कॉरिलेशन आयडी, रेआयडी किंवा कोणतीही विविधता, एक युनिक आयडेंटिफायर आहे जो तुम्हाला विनंतीचा त्याच्या संपूर्ण जीवनकाळात मागोवा घेऊ देतो. हे तुम्हाला लॉगमधील संपूर्ण विनंती पथ ट्रॅक करण्यास अनुमती देते.

वापरकर्ता सिस्टम A ला विनंती करतो, नंतर A संपर्क B, जो C ला संपर्क करतो, तो X मध्ये संग्रहित करतो आणि नंतर विनंती A ला परत केली जाते.

जर तुम्ही व्हर्च्युअल मशीन्सशी दूरस्थपणे कनेक्ट करत असाल आणि विनंतीचा मार्ग शोधण्याचा प्रयत्न कराल (आणि कोणते कॉल केले जात आहेत ते मॅन्युअली परस्परसंबंधित करा), तुम्ही वेडे व्हाल. युनिक आयडेंटिफायर असल्‍याने जीवन खूप सोपे होते. तुमची सेवा वाढत असताना वेळ वाचवण्यासाठी तुम्ही करू शकता अशा सोप्या गोष्टींपैकी ही एक आहे.

मध्यम पातळी

येथे दिलेला सल्ला मागीलपेक्षा अधिक क्लिष्ट आहे, परंतु योग्य साधने हे कार्य सुलभ करतात, लहान आणि मध्यम आकाराच्या कंपन्यांसाठीही गुंतवणुकीवर परतावा देतात.

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

अभिनंदन! तुम्ही 100 आभासी मशीन तैनात केल्या आहेत. दुसर्‍या दिवशी, सीईओ येतो आणि सेवेची चाचणी घेत असताना त्यांना मिळालेल्या त्रुटीबद्दल तक्रार करतो. आम्ही वर बोललो त्या संबंधित आयडीचा अहवाल देतो, परंतु ज्याच्यामुळे क्रॅश झाला ते शोधण्यासाठी तुम्हाला 100 मशीनचे लॉग पहावे लागतील. आणि उद्याच्या सादरीकरणापूर्वी ते शोधणे आवश्यक आहे.

हे एक मजेदार साहस वाटत असले तरी, तुमच्याकडे सर्व मासिके एकाच ठिकाणी शोधण्याची क्षमता असल्याची खात्री करणे सर्वोत्तम आहे. मी ELK स्टॅकच्या अंगभूत कार्यक्षमतेचा वापर करून लॉग सेंट्रलाइझ करण्याच्या समस्येचे निराकरण केले: ते शोधण्यायोग्य लॉग संग्रहास समर्थन देते. हे विशिष्ट जर्नल शोधण्याच्या समस्येचे निराकरण करण्यात खरोखर मदत करेल. बोनस म्हणून, तुम्ही तक्ते आणि त्यासारख्या इतर मजेदार गोष्टी तयार करू शकता.

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

देखरेख एजंट

आता तुमची सेवा चालू आहे आणि ती सुरळीत चालेल याची तुम्हाला खात्री करणे आवश्यक आहे. हे करण्याचा सर्वोत्तम मार्ग म्हणजे अनेक चालवणे एजंट, जे समांतर कार्य करते आणि ते कार्य करते आणि मूलभूत ऑपरेशन्स केले जातात हे तपासा.

यावेळी तुम्ही ते तपासा चालू बिल्ड चांगले वाटते आणि चांगले कार्य करते.

लहान ते मध्यम आकाराच्या प्रकल्पांसाठी, मी API चे निरीक्षण आणि दस्तऐवजीकरण करण्यासाठी पोस्टमनची शिफारस करतो. परंतु सर्वसाधारणपणे, तुम्ही फक्त खात्री करून घेऊ इच्छिता की तुमच्याकडे आउटेज कधी झाला हे जाणून घेण्याचा मार्ग आहे आणि वेळेवर सूचित केले जाईल.

लोडवर अवलंबून ऑटोस्केलिंग

हे खूप सोपे आहे. जर तुमच्याकडे VM सर्व्हिसिंग विनंत्या असतील आणि ते 80% मेमरी वापरापर्यंत पोहोचत असेल, तर तुम्ही एकतर त्याची संसाधने वाढवू शकता किंवा क्लस्टरमध्ये अधिक VM जोडू शकता. लोड अंतर्गत लवचिक शक्ती बदलांसाठी या ऑपरेशन्सची स्वयंचलित अंमलबजावणी उत्कृष्ट आहे. परंतु तुम्ही किती पैसे खर्च करता याची नेहमी काळजी घेतली पाहिजे आणि वाजवी मर्यादा सेट करा.

बर्‍याच क्लाउड सेवांसह, तुम्ही अधिक सर्व्हर किंवा अधिक शक्तिशाली सर्व्हर वापरून ऑटोस्केलवर कॉन्फिगर करू शकता.

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

अद्यतने सुरक्षितपणे रोल आउट करण्याचा एक चांगला मार्ग म्हणजे एका तासासाठी 1% वापरकर्त्यांसाठी काहीतरी तपासण्यात सक्षम असणे. तुम्ही अर्थातच अशा यंत्रणा कृती करताना पाहिल्या असतील. उदाहरणार्थ, वापरकर्त्यांना हे बदल कसे समजतात हे पाहण्यासाठी Facebook प्रेक्षकांच्या काही भागांना भिन्न रंग दाखवते किंवा फॉन्ट आकार बदलते. याला A/B चाचणी म्हणतात.

नवीन वैशिष्ट्य रिलीझ करणे देखील एक प्रयोग म्हणून सुरू केले जाऊ शकते आणि नंतर ते कसे सोडायचे ते ठरवले जाऊ शकते. तुमच्या सेवेमध्ये अधोगती कारणीभूत असलेल्या फंक्शनच्या आधारावर तुम्हाला "लक्षात ठेवण्याची" किंवा कॉन्फिगरेशन बदलण्याची क्षमता देखील मिळते.

प्रगत पातळी

येथे टिपा आहेत ज्या अंमलात आणणे खूप कठीण आहे. तुम्हाला आणखी काही संसाधनांची आवश्यकता असेल, त्यामुळे लहान किंवा मध्यम आकाराच्या कंपनीला हे व्यवस्थापित करणे कठीण जाईल.

निळ्या-हिरव्या तैनाती

यालाच मी उलगडण्याचा "एर्लांग" मार्ग म्हणतो. टेलिफोन कंपन्या दिसू लागल्यावर एर्लांगचा मोठ्या प्रमाणावर वापर झाला. टेलिफोन कॉल्स रूट करण्यासाठी सॉफ्टस्विचचा वापर होऊ लागला. या स्विचेसवरील सॉफ्टवेअरचा मुख्य उद्देश सिस्टम अपग्रेड दरम्यान कॉल ड्रॉप न करणे हा होता. एर्लांगकडे मागील मोड्यूल क्रॅश न करता नवीन मॉड्यूल लोड करण्याचा एक चांगला मार्ग आहे.

ही पायरी लोड बॅलन्सरच्या उपस्थितीवर अवलंबून असते. समजा तुमच्याकडे तुमच्या सॉफ्टवेअरची आवृत्ती N आहे आणि नंतर तुम्हाला N+1 आवृत्ती उपयोजित करायची आहे. 

आपण आम्ही करू शकतो फक्त सेवा थांबवा आणि तुमच्या वापरकर्त्यांसाठी काम करणाऱ्या वेळी पुढील आवृत्ती आणा आणि थोडा डाउनटाइम मिळवा. पण समजा तुमच्याकडे आहे खरोखर कठोर SLA अटी. तर, SLA 99,99% म्हणजे तुम्ही ऑफलाइन जाऊ शकता फक्त प्रति वर्ष 52 मिनिटे.

जर तुम्हाला खरोखर असे संकेतक साध्य करायचे असतील, तर तुम्हाला एकाच वेळी दोन उपयोजनांची आवश्यकता आहे: 

• जो सध्या आहे (N);
• पुढील आवृत्ती (N+1). 

तुम्ही लोड बॅलन्सरला ट्रॅफिकची टक्केवारी नवीन आवृत्तीवर (N+1) पुनर्निर्देशित करण्यास सांगता, जेव्हा तुम्ही रीग्रेशनसाठी सक्रियपणे निरीक्षण करता.

येथे आमच्याकडे हिरवा N उपयोजन आहे जो चांगले कार्य करतो. आम्ही या उपयोजनाच्या पुढील आवृत्तीवर जाण्याचा प्रयत्न करत आहोत

आमची N+1 उपयोजन थोड्या प्रमाणात रहदारीसह कार्य करते की नाही हे पाहण्यासाठी प्रथम आम्ही एक लहान चाचणी पाठवतो:

शेवटी, आमच्याकडे स्वयंचलित तपासण्यांचा संच आहे जो आम्ही आमची तैनाती पूर्ण होईपर्यंत चालतो. जर तू खूप खूप सावधगिरी बाळगा, खराब रीग्रेशनच्या बाबतीत त्वरित रोलबॅकसाठी तुम्ही तुमची N तैनाती कायमची जतन करू शकता:

तुम्हाला आणखी प्रगत स्तरावर जायचे असल्यास, निळ्या-हिरव्या उपयोजनातील प्रत्येक गोष्ट आपोआप चालू द्या.

विसंगती शोधणे आणि स्वयंचलित शमन

तुमच्याकडे केंद्रीकृत लॉगिंग आणि चांगले लॉग कलेक्शन आहे हे लक्षात घेऊन, तुम्ही आधीच उच्च ध्येये सेट करू शकता. उदाहरणार्थ, अयशस्वी होण्याचा अंदाज लावा. मॉनिटर्सवर आणि लॉगमध्ये फंक्शन्सचा मागोवा घेतला जातो आणि विविध आकृत्या तयार केल्या जातात - आणि काय चूक होईल याचा तुम्ही आधीच अंदाज लावू शकता:

एकदा विसंगती आढळून आल्यावर, तुम्ही सेवा प्रदान करत असलेल्या काही संकेतांचे परीक्षण करण्यास सुरुवात करता. उदाहरणार्थ, CPU लोडमधील स्पाइक हे सूचित करू शकते की हार्ड ड्राइव्ह अयशस्वी होत आहे, तर विनंत्यांची वाढ सूचित करू शकते की तुम्हाला स्केल वाढवण्याची आवश्यकता आहे. या प्रकारचा सांख्यिकीय डेटा तुम्हाला सेवा सक्रिय करण्यास अनुमती देतो.

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

इतकंच!

जर तुम्ही क्लाउड सेवा वाढवत असाल तर प्राधान्यक्रमांची ही यादी तुम्हाला बर्‍याच समस्यांपासून वाचवेल.

मूळ लेखाचा लेखक वाचकांना त्यांच्या टिप्पण्या सोडण्यासाठी आणि बदल करण्यासाठी आमंत्रित करतो. लेख ओपन सोर्स म्हणून वितरीत केला गेला आहे, लेखकाने विनंती केली आहे Github वर स्वीकारते.

या विषयावर आणखी काय वाचायचे:

1. जा आणि CPU कॅशे
2. अंमलबजावणीसाठी टेम्पलेटसह चाचेगिरीच्या भावनेत कुबर्नेट्स
3. आमचे चॅनेल अराउंड कुबरनेटेस टेलीग्राममध्ये

स्त्रोत: www.habr.com