आम्ही दूरस्थपणे x10 कार्यभार वाढण्यापासून कसे वाचलो आणि आम्ही कोणते निष्कर्ष काढले

अहो हाब्र! गेले काही महिने आम्ही अतिशय मनोरंजक परिस्थितीत जगलो आणि मला आमची पायाभूत सुविधा स्केलिंगची कथा सांगायची आहे. यावेळी, SberMarket ने ऑर्डरमध्ये चौपट वाढ केली आहे आणि 4 नवीन शहरांमध्ये सेवा सुरू केली आहे. किराणा मालाच्या डिलिव्हरीच्या मागणीतील स्फोटक वाढीमुळे आम्हाला आमच्या पायाभूत सुविधांमध्ये वाढ करणे आवश्यक आहे. कट अंतर्गत सर्वात मनोरंजक आणि उपयुक्त निष्कर्षांबद्दल वाचा.

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

कार्यसंघ व्यवस्थापित करताना, व्यवसायाला काय आवश्यक आहे आणि प्रत्येक वैयक्तिक विकासकाच्या गरजा यांच्यातील समतोल समजून घेणे आणि शोधणे महत्त्वाचे आहे. आता SberMarket वर्षातून 13 वेळा वाढत आहे, आणि याचा परिणाम उत्पादनावर होतो, ज्यामुळे व्हॉल्यूम आणि विकासाचा वेग सतत वाढतो. असे असूनही, आम्ही विकासकांना प्राथमिक विश्लेषण आणि उच्च-गुणवत्तेच्या कोडिंगसाठी पुरेसा वेळ देतो. तयार केलेला दृष्टीकोन केवळ कार्यरत उत्पादन तयार करण्यातच नव्हे तर त्याच्या पुढील स्केलिंग आणि विकासामध्ये देखील मदत करतो. या वाढीचा परिणाम म्हणून, SberMarket आधीच किराणा माल वितरण सेवांमध्ये आघाडीवर आहे: आम्ही दिवसाला सुमारे 18 ऑर्डर वितरीत करतो, जरी फेब्रुवारीच्या सुरुवातीस सुमारे 3500 ऑर्डर होते.

एके दिवशी, एका क्लायंटने SberMarket कुरिअरला संपर्करहितपणे किराणा सामान पोहोचवण्यास सांगितले - अगदी बाल्कनीत.

पण तपशील खाली उतरू. गेल्या काही महिन्यांपासून आम्ही आमच्या कंपनीच्या पायाभूत सुविधांमध्ये सक्रियपणे वाढ करत आहोत. ही गरज बाह्य आणि अंतर्गत घटकांद्वारे स्पष्ट केली गेली. याचबरोबर ग्राहकसंख्येच्या विस्तारासह, कनेक्टेड स्टोअर्सची संख्या वर्षाच्या सुरुवातीला 90 वरून मेच्या मध्यापर्यंत 200 वर पोहोचली. अर्थात, आम्ही स्वतःला तयार केले, मुख्य पायाभूत सुविधा राखून ठेवल्या आणि Yandex क्लाउडमध्ये होस्ट केलेल्या सर्व व्हर्च्युअल मशीनच्या अनुलंब आणि क्षैतिज स्केलिंगच्या शक्यतेवर विश्वास ठेवला. तथापि, सरावाने दर्शविले आहे: "जे काही चुकीचे होऊ शकते ते चुकीचे होईल." आणि आज मी या आठवड्यात घडलेल्या सर्वात उत्सुक परिस्थिती सामायिक करू इच्छितो. मला आशा आहे की आमचा अनुभव तुमच्यासाठी उपयुक्त ठरेल.

संपूर्ण लढाई तयारीत गुलाम

साथीचा रोग सुरू होण्यापूर्वीच, आम्हाला आमच्या बॅकएंड सर्व्हरवर विनंत्या वाढल्याचा सामना करावा लागला. होम डिलिव्हरीसह अन्न ऑर्डर करण्याच्या ट्रेंडला गती मिळू लागली आणि COVID-19 च्या संदर्भात सेल्फ-आयसोलेशनचे पहिले उपाय लागू केल्यामुळे दिवसभर भार आपल्या डोळ्यांसमोर नाटकीयपणे वाढला. मुख्य डेटाबेसचे मास्टर सर्व्हर त्वरीत अनलोड करण्याची आणि काही वाचलेल्या विनंत्या प्रतिकृती सर्व्हरवर (स्लेव्ह) हस्तांतरित करण्याची आवश्यकता होती.

आम्ही या चरणाची आगाऊ तयारी करत होतो आणि अशा युक्तीसाठी 2 स्लेव्ह सर्व्हर आधीच चालू होते. त्यांनी प्रामुख्याने भागीदारांसह डेटाची देवाणघेवाण करण्यासाठी माहिती फीड तयार करण्यासाठी बॅच कार्यांवर काम केले. या प्रक्रियेमुळे अतिरिक्त भार निर्माण झाला आणि काही महिन्यांपूर्वीच कंसातून बाहेर काढण्यात आले. 

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

लोडच्या एका विशिष्ट पातळीपर्यंत, HTTP विनंत्यांची प्रक्रिया करताना आमच्याकडे लेखन आणि वाचन दोन्हीसाठी पुरेसे मास्टर होते. मार्चच्या मध्यात, जेव्हा Sbermarket ने रिमोट वर्कवर पूर्णपणे स्विच करण्याचा निर्णय घेतला, तेव्हा आम्ही RPS ची वाढ वाढवू लागलो. आमचे अधिकाधिक क्लायंट सेल्फ आयसोलेशनमध्ये किंवा घरातून कामात गेले, जे लोड इंडिकेटरमध्ये दिसून आले.

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

समस्या लगेच प्रकट झाली नाही, कारण. वाढलेल्या भारामुळे गुलामांचा अनुशेष वाढला. डेटाची विसंगती सकाळी आढळली, जेव्हा, रात्रीच्या आयातीनंतर, गुलामांनी मास्टरशी “पकडले” नाही. आम्ही याचे श्रेय सेवेवरील उच्च भार आणि नवीन स्टोअरच्या लाँचशी संबंधित आयातींना दिले. परंतु अनेक तासांच्या विलंबाने डेटा देणे अस्वीकार्य होते आणि आम्ही प्रक्रिया दुसऱ्या विश्लेषणात्मक स्लेव्हकडे स्विच केली, कारण त्यात होतेоमोठ्या संसाधने आणि वाचलेल्या विनंत्यांसह लोड केलेले नव्हते (ज्याप्रमाणे आम्ही स्वतःला प्रतिकृती अंतराची कमतरता समजावून सांगितली).

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

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

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

अगदी एक भारी क्वेरी ऑप्टिमाइझ केल्याने डेटाबेस पुन्हा जिवंत होऊ शकतो

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

स्लेव्ह सर्व्हर पुनर्प्राप्त होत असताना, मिनिटे हळूहळू ड्रॅग होत गेली, मास्टर ओव्हरलोड झाला आणि आम्ही पॅरेटो नियमानुसार सक्रिय कार्ये ऑप्टिमाइझ करण्यासाठी आमचे सर्व प्रयत्न टाकले: आम्ही सर्वाधिक भार देणार्‍या शीर्ष क्वेरी निवडल्या आणि ट्यूनिंग सुरू केले. हे अगदी माशीवर केले गेले.

एक मनोरंजक परिणाम असा होता की MySQL, नेत्रगोलकांवर लोड केलेले, प्रक्रियांमध्ये अगदी थोड्या सुधारणेस प्रतिसाद देते. एकूण लोडपैकी फक्त 5% देणार्‍या काही क्वेरीच्या ऑप्टिमायझेशनने आधीच लक्षणीय CPU ऑफलोड दर्शविला आहे. परिणामी, आम्ही मास्टरला डेटाबेससह कार्य करण्यासाठी आणि प्रतिकृती पुनर्संचयित करण्यासाठी आवश्यक वेळ मिळविण्यासाठी संसाधनांचा स्वीकार्य राखीव प्रदान करण्यात सक्षम झालो. 

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

भागीदार सेवांच्या आरोग्याचे निरीक्षण आयोजित करा

आम्ही ग्राहकांकडून ऑर्डरवर प्रक्रिया करतो आणि म्हणूनच आमच्या सेवा सतत तृतीय पक्ष API सह संवाद साधतात - हे एसएमएस, पेमेंट प्लॅटफॉर्म, राउटिंग सिस्टम, जिओकोडर, फेडरल टॅक्स सर्व्हिस आणि इतर अनेक प्रणाली पाठवण्याचे गेटवे आहेत. आणि जेव्हा भार वेगाने वाढू लागला, तेव्हा आम्ही आमच्या भागीदार सेवांच्या API च्या मर्यादांमध्ये जाऊ लागलो, ज्याचा आम्ही आधी विचारही केला नव्हता.

भागीदार सेवा कोटा अनपेक्षित ओलांडल्याने तुमचा स्वतःचा डाउनटाइम होऊ शकतो. अनेक API मर्यादा ओलांडणाऱ्या क्लायंटना अवरोधित करतात आणि काही प्रकरणांमध्ये, विनंत्यांचा अतिरेक भागीदाराचे उत्पादन ओव्हरलोड करू शकतो. 

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

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

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

कधी कधी ते बाहेर वळतेआणखी सोन्याची गरज आहे"(c) मदत करत नाही

आम्हाला मुख्य डेटाबेसमध्ये किंवा ऍप्लिकेशन सर्व्हरवर "गॅग" करण्याची सवय आहे, परंतु स्केलिंग करताना, जिथे ते अपेक्षित नव्हते तिथे समस्या दिसू शकतात. साइटवर पूर्ण-मजकूर शोधण्यासाठी, आम्ही Apache Solr इंजिन वापरतो. लोड वाढल्याने, आम्हाला प्रतिसाद वेळेत घट झाल्याचे लक्षात आले आणि सर्व्हर CPU लोड 100% पर्यंत पोहोचला. काय सोपे असू शकते - सोलर कंटेनरला अधिक संसाधने द्या.

कार्यक्षमतेत अपेक्षित वाढ होण्याऐवजी, सर्व्हर फक्त "मृत्यू" झाला. ते लगेच 100% लोड झाले आणि आणखी हळू प्रतिसाद दिला. सुरुवातीला, आमच्याकडे 2 कोर आणि 2 GB RAM होती. आम्ही सामान्यतः काय मदत करते ते करण्याचा निर्णय घेतला - आम्ही सर्व्हरला 8 कोर आणि 32 जीबी दिले. सर्व काही खूपच वाईट झाले (आम्ही तुम्हाला वेगळ्या पोस्टमध्ये कसे आणि का सांगू). 

काही दिवसात, आम्ही या समस्येची गुंतागुंत शोधून काढली आणि 8 कोर आणि 32 GB सह इष्टतम कामगिरी साध्य केली. हे कॉन्फिगरेशन आम्हाला आज लोड वाढविणे सुरू ठेवण्याची परवानगी देते, जे खूप महत्वाचे आहे, कारण वाढ केवळ ग्राहकांच्या दृष्टीनेच नाही तर कनेक्ट केलेल्या स्टोअरच्या संख्येत देखील आहे - 2 महिन्यांत त्यांची संख्या दुप्पट झाली आहे. 

निष्कर्ष: "अधिक लोह जोडा" सारख्या मानक पद्धती नेहमी कार्य करत नाहीत. त्यामुळे कोणतीही सेवा स्केलिंग करताना, ती संसाधने कशी वापरते याची तुम्हाला चांगली माहिती असणे आवश्यक आहे आणि त्याची आगाऊ चाचणी करणे आवश्यक आहे, नवीन परिस्थितींमध्ये तिचे कार्य. 

स्टेटलेस ही साध्या क्षैतिज स्केलिंगची गुरुकिल्ली आहे

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

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

निष्कर्ष: "आम्ही येथे निश्चितपणे विश्रांती घेणार नाही" असे वाटत असले तरीही अपवादाशिवाय सर्व घटकांसाठी राज्यरहित नियम पाळला जाणे आवश्यक आहे. घाईत कोड पुन्हा लिहिण्यापेक्षा आणि ओव्हरलोड केलेल्या सेवेचे निराकरण करण्यापेक्षा सर्व सिस्टमच्या कामाच्या योग्य संस्थेवर थोडा वेळ घालवणे चांगले आहे.

गहन वाढीसाठी 7 तत्त्वे

अतिरिक्त क्षमतेची उपलब्धता असूनही, वाढीच्या प्रक्रियेत, आम्ही काही रेकवर पाऊल ठेवले. यावेळी, ऑर्डरची संख्या 4 पटीने वाढली. आता आम्ही आधीच 17 शहरांमध्ये दररोज 000 पेक्षा जास्त ऑर्डर वितरीत करतो आणि भूगोलाचा आणखी विस्तार करण्याची योजना आखत आहोत - 62 च्या पहिल्या सहामाहीत, संपूर्ण रशियामध्ये ही सेवा सुरू होण्याची अपेक्षा आहे. वाढत्या वर्कलोडचा सामना करण्यासाठी, आधीच भरलेले अडथळे लक्षात घेऊन, सतत वाढीच्या वातावरणात काम करण्यासाठी आम्ही स्वतःसाठी 2020 मूलभूत तत्त्वे तयार केली आहेत:

1. घटना व्यवस्थापन. आम्ही जिरामध्ये एक बोर्ड तयार केला आहे, जिथे प्रत्येक घटना तिकिटाच्या रूपात प्रतिबिंबित होते. हे तुम्हाला घटनेशी संबंधित कार्यांना प्राधान्य देण्यास आणि पूर्ण करण्यात मदत करेल. खरंच, थोडक्यात, चुका करणे भयंकर नाही - एकाच प्रसंगी दोनदा चुका करणे भयंकर आहे. ज्या प्रकरणांमध्ये कारणे दुरुस्त होण्याआधी घटनांची पुनरावृत्ती होते त्या बाबतीत, कारवाईसाठी सूचना तयार केल्या पाहिजेत, कारण जास्त भार असताना विजेच्या वेगाने प्रतिक्रिया देणे महत्वाचे आहे.
2. देखरेख अपवादाशिवाय सर्व पायाभूत घटकांसाठी आवश्यक. त्याच्यामुळेच आम्ही लोडच्या वाढीचा अंदाज लावू शकलो आणि निर्मूलनाला प्राधान्य देण्यासाठी "अडथळे" योग्यरित्या निवडू शकलो. बहुधा, मोठ्या भाराखाली, आपण ज्याचा विचारही केला नसेल त्या सर्व गोष्टी तुटतील किंवा मंद होऊ लागतील. म्हणूनच, पहिल्या घटनांच्या प्रारंभानंतर लगेचच नवीन सूचना तयार करणे आणि त्यांचे निरीक्षण करण्यासाठी आणि अंदाज लावणे चांगले आहे.
3. अचूक सूचना लोडमध्ये तीव्र वाढीसह फक्त आवश्यक आहे. प्रथम, त्यांनी नेमके काय तुटले आहे ते कळवावे. दुसरे म्हणजे, अनेक अलर्ट नसावेत, कारण नॉन-क्रिटिकल अॅलर्ट्सच्या मुबलकतेमुळे सर्वसाधारणपणे सर्व अलर्टकडे दुर्लक्ष केले जाते.
4. अर्ज स्टेटलेस असणे आवश्यक आहे. या नियमाला कोणताही अपवाद नसावा याची आम्ही काळजी घेतली आहे. तुम्हाला रनटाइम वातावरणापासून पूर्ण स्वातंत्र्य आवश्यक आहे. हे करण्यासाठी, आपण डेटाबेसमध्ये सामायिक केलेला डेटा संचयित करू शकता किंवा उदाहरणार्थ, थेट S3 मध्ये. अजून चांगले, नियमांचे पालन करा. https://12factor.net. वेळेत तीव्र वाढ होत असताना, कोड ऑप्टिमाइझ करण्याचा कोणताही मार्ग नाही आणि तुम्हाला थेट संगणकीय संसाधने आणि क्षैतिज स्केलिंग वाढवून लोडचा सामना करावा लागेल.
5. कोटा आणि बाह्य सेवांचे कार्यप्रदर्शन. जलद वाढीसह, समस्या केवळ आपल्या पायाभूत सुविधांमध्येच नाही तर बाह्य सेवेमध्ये देखील उद्भवू शकते. सर्वात त्रासदायक गोष्ट म्हणजे जेव्हा हे अपयशामुळे नाही तर कोटा किंवा मर्यादा गाठल्यामुळे होते. त्यामुळे बाह्य सेवांचे प्रमाण तुम्ही स्वतःप्रमाणेच असावे. 
6. स्वतंत्र प्रक्रिया आणि रांगा. जेव्हा एखाद्या गेटवेवर प्लग येतो तेव्हा हे खूप मदत करते. जर एसएमएस पाठवण्याच्या पूर्ण रांगांनी माहिती प्रणालींमधील सूचनांच्या देवाणघेवाणीमध्ये व्यत्यय आणला नसता तर डेटा ट्रान्समिशनमध्ये आम्हाला विलंब झाला नसता. आणि जर त्यांनी स्वतंत्रपणे काम केले तर कामगारांची संख्या वाढवणे सोपे होईल.
7. आर्थिक वास्तव. जेव्हा डेटा प्रवाहात स्फोटक वाढ होते, तेव्हा दर आणि सदस्यतांबद्दल विचार करण्याची वेळ नसते. परंतु ते लक्षात ठेवले पाहिजे, विशेषत: जर तुम्ही एक लहान कंपनी असाल. मोठे बिल कोणत्याही API चे मालक तसेच तुमच्या होस्टिंग प्रदात्याद्वारे सेट केले जाऊ शकते. त्यामुळे करार काळजीपूर्वक वाचा.

निष्कर्ष

तोट्याशिवाय नाही, परंतु आम्ही या टप्प्यावर टिकून राहिलो, आणि आज आम्ही आढळलेल्या सर्व तत्त्वांचे पालन करण्याचा प्रयत्न करतो आणि प्रत्येक मशीनमध्ये काही आश्चर्यांचा सामना करण्यासाठी सहजपणे x4 कार्यक्षमता वाढवण्याची क्षमता आहे. 

पुढील पोस्ट्समध्ये, आम्ही Apache Solr मधील कामगिरी कमी होण्याच्या तपासाचा आमचा अनुभव सामायिक करू, तसेच क्वेरी ऑप्टिमायझेशन आणि फेडरल टॅक्स सेवेशी परस्परसंवाद कंपनीला पैसे वाचविण्यास कशी मदत करते याबद्दल बोलू. आमच्या ब्लॉगची सदस्यता घ्या जेणेकरुन काहीही चुकू नये आणि ट्रॅफिकच्या वाढीदरम्यान तुम्हाला असाच त्रास झाला असेल तर आम्हाला टिप्पण्यांमध्ये सांगा.

केवळ नोंदणीकृत वापरकर्तेच सर्वेक्षणात भाग घेऊ शकतात. साइन इन करा, आपले स्वागत आहे.

लोडमध्ये तीक्ष्ण वाढ झाल्यामुळे तुम्‍हाला कधी सेवा मंद/मंद झाली आहे का:

• 55,6%संगणकीय संसाधने द्रुतपणे जोडण्यास असमर्थता10

• 16,7%होस्टिंग प्रदाता पायाभूत सुविधा मर्यादा3

• 33,3%तृतीय पक्ष API6 मर्यादा

• 27,8%स्टेटलेस त्यांच्या अर्जांच्या तत्त्वांचे उल्लंघन 5

• 88,9%स्वतःच्या सेवांचा गैर-इष्टतम कोड16

18 वापरकर्त्यांनी मतदान केले. 6 वापरकर्ते दूर राहिले.

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