हामी कसरी टाढाबाट x10 लोडमा तीव्र वृद्धिबाट बच्यौं र हामीले के निष्कर्ष निकाल्यौं

नमस्ते, Habr! हामी पछिल्ला दुई महिनाको लागि धेरै रोचक परिस्थितिमा बाँचिरहेका छौं र म हाम्रो पूर्वाधार मापन कथा साझा गर्न चाहन्छु। यस अवधिमा, SberMarket 4 पटक अर्डर बढेको छ र 17 नयाँ शहरहरूमा सेवा सुरु गरेको छ। किराना डेलिभरीको मागमा विस्फोटक वृद्धिले हामीलाई हाम्रो पूर्वाधार मापन गर्न आवश्यक थियो। कट अन्तर्गत सबैभन्दा रोचक र उपयोगी निष्कर्ष बारे पढ्नुहोस्।

मेरो नाम Dima Bobylev हो, म SberMarket को प्राविधिक निर्देशक हुँ। यो हाम्रो ब्लगमा पहिलो पोष्ट भएकोले, म आफ्नो र कम्पनीको बारेमा केही शब्दहरू भन्नेछु। पछिल्लो पतनमा मैले युवा रुनेट नेताहरूको लागि प्रतिस्पर्धामा भाग लिएँ। प्रतियोगिताको लागि म छोटो कथा लेखे हामीले SberMarket मा कसरी आन्तरिक संस्कृति र सेवा विकासको दृष्टिकोण देख्छौं भन्ने बारे। र यद्यपि मैले प्रतियोगिता जित्न सकेको छैन, मैले IT इकोसिस्टमको विकासको लागि आधारभूत सिद्धान्तहरू आफैंले बनाएको छु।

टोलीको प्रबन्ध गर्दा, व्यापारको आवश्यकता र प्रत्येक व्यक्तिगत विकासकर्ताको आवश्यकताहरू बीचको सन्तुलन बुझ्न र पत्ता लगाउन महत्त्वपूर्ण छ। अब SberMarket वर्षमा 13 पटक बढ्दै छ, र यसले उत्पादनलाई असर गर्छ, यसले निरन्तर विकासको मात्रा र गति बढाउन आवश्यक छ। यसका बावजुद, हामी प्रारम्भिक विश्लेषण र गुणस्तर कोडिङका लागि विकासकर्ताहरूलाई पर्याप्त समय छुट्याउँछौं। गठन गरिएको दृष्टिकोणले काम गर्ने उत्पादन सिर्जना गर्न मात्र होइन, यसको थप मापन र विकासमा पनि मद्दत गर्दछ। यस वृद्धिको नतिजाको रूपमा, SberMarket पहिले नै किराना वितरण सेवाहरूको बीचमा एक अग्रणी बनिसकेको छ: हामीले हरेक दिन लगभग 18 हजार अर्डरहरू डेलिभर गर्छौं, यद्यपि फेब्रुअरीको सुरुमा त्यहाँ लगभग 3500 थिए।

एक दिन, एक ग्राहकले एक SberMarket कुरियरलाई सम्पर्कविना उसलाई किराना सामानहरू पुर्‍याउन भन्यो - दायाँ बालकनीमा

तर स्पेसिफिकेशनमा जाऔं। पछिल्ला केही महिनाहरूमा, हामीले हाम्रो कम्पनीको पूर्वाधारलाई सक्रिय रूपमा मापन गरिरहेका छौं। यो आवश्यकता बाह्य र आन्तरिक कारकहरू द्वारा व्याख्या गरिएको थियो। ग्राहक आधारको विस्तारसँगै जोडिएका पसलको संख्या वर्षको सुरुमा ९० बाट मेको मध्यसम्ममा २०० भन्दा बढी पुगेको छ । हामी, निस्सन्देह, तयार थियौं, मुख्य पूर्वाधार आरक्षित गर्यौं, साथै हामीले Yandex क्लाउडमा होस्ट गरिएका सबै भर्चुअल मेसिनहरूको ठाडो र तेर्सो स्केलिंगको सम्भावनामा गणना गर्यौं। तथापि, अभ्यासले देखाएको छ: "गल्ती हुन सक्ने सबै कुरा गलत हुनेछ।" र आज म यी हप्ताहरूमा भएका सबैभन्दा रोचक अवस्थाहरू साझा गर्न चाहन्छु। मलाई आशा छ कि हाम्रो अनुभव तपाईलाई उपयोगी हुनेछ।

दास पूर्ण लडाई तयारीमा छ

महामारी सुरु हुनु अघि नै, हामीले हाम्रो ब्याकएन्ड सर्भरहरूमा अनुरोधहरूको संख्यामा बृद्धिको सामना गर्‍यौं। होम डेलिभरीको लागि किराना सामानहरू अर्डर गर्ने प्रवृत्तिले गति लिन थाल्यो, र COVID-19 को कारणले पहिलो आत्म-पृथक उपायहरूको परिचयसँगै, दिनभरि कामको बोझ नाटकीय रूपमा बढ्यो। त्यहाँ मुख्य डाटाबेसको मास्टर सर्भरहरू तुरुन्तै अनलोड गर्न र केही पढ्ने अनुरोधहरू प्रतिकृति सर्भर (दास) मा स्थानान्तरण गर्न आवश्यक थियो।

हामीले यस चरणको लागि अग्रिम तयारी गर्यौं, र 2 दास सर्भरहरू पहिले नै यस्तो चालको लागि सुरू गरिएको थियो। तिनीहरू मुख्यतया साझेदारहरूसँग डाटा आदानप्रदानको लागि सूचना फिडहरू उत्पन्न गर्ने ब्याच कार्यहरूको लागि प्रयोग गरिन्थ्यो। यी प्रक्रियाहरूले एक अतिरिक्त बोझ सिर्जना गर्‍यो र केही महिना अघि समीकरणबाट एकदम सही रूपमा हटाइयो। 

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

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

"मास्टर" को प्रदर्शन अब पर्याप्त थिएन, त्यसैले हामीले प्रतिकृतिमा केहि भारी पढ्ने अनुरोधहरू स्थानान्तरण गर्न थाल्यौं। पारदर्शी रूपमा मालिकलाई अनुरोधहरू लेख्न र दासलाई अनुरोधहरू पढ्नको लागि, हामीले रूबी रत्न प्रयोग गर्यौं "अक्टोपस" हामीले लेख्ने अधिकार बिना _readonly postfix को साथ एक विशेष प्रयोगकर्ता सिर्जना गर्यौं। तर होस्टहरू मध्ये एकको कन्फिगरेसनमा त्रुटिको कारणले, केही लेखन अनुरोधहरू उपयुक्त अधिकार भएका प्रयोगकर्ताको तर्फबाट दास सर्भरमा गए।

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

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

तर हामीले डाटाबेस मात्र डम्प गरेनौं (त्यस समयमा पुनर्स्थापनाले लगभग 5 घण्टा लियो), तर मास्टर सर्भरको स्न्यापसट पनि, हामीले 2 घण्टा भित्र प्रतिकृति सुरु गर्न व्यवस्थित गर्यौं। साँचो, यस पछि हामीले लामो समयको लागि प्रतिकृति लग रोलिङको सामना गर्‍यौं (किनभने प्रक्रिया एकल-थ्रेडेड मोडमा चल्छ, तर त्यो पूर्ण रूपमा फरक कथा हो)।

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

एक भारी प्रश्नलाई पनि अप्टिमाइज गर्नाले डाटाबेसलाई जीवन्त बनाउन सक्छ

यद्यपि हामी निरन्तर साइटमा क्याटलग अपडेट गर्छौं, हामीले स्लेभ सर्भरहरूमा पठाएको अनुरोधहरूले मास्टरबाट थोरै ढिलो गर्न अनुमति दियो। जुन समयमा हामीले दासहरूको समस्या "अचानक टाढा छोड्ने" पत्ता लगायौं र उन्मूलन गर्यौं त्यो "मनोवैज्ञानिक अवरोध" भन्दा बढी थियो (यस समयमा मूल्यहरू अद्यावधिक गर्न सकिन्थ्यो, र ग्राहकहरूले पुरानो डाटा देखेका थिए), र हामी बाध्य भयौं। सबै अनुरोधहरूलाई मुख्य डाटाबेस सर्भरमा स्विच गर्नुहोस्। नतिजाको रूपमा, साइट ढिलो थियो ... तर कम्तिमा यसले काम गर्यो। र जब स्लेभ निको हुँदै थियो, हामीसँग अप्टिमाइजेसनको विकल्प थिएन। 

जब स्लेभ सर्भरहरू रिकभर हुँदै थिए, मिनेटहरू बिस्तारै बित्यो, मास्टर ओभरलोड रह्यो, र हामीले "Pareto नियम" अनुसार सक्रिय कार्यहरू अनुकूलन गर्न हाम्रा सबै प्रयासहरू फ्याँक्यौं: हामीले लोडको बहुमत उत्पन्न गर्ने शीर्ष अनुरोधहरू चयन गर्यौं र ट्युनिङ सुरु गर्‍यौं। । यो ठीक उडान मा गरियो।

एउटा चाखलाग्दो प्रभाव थियो कि MySQL, क्षमतामा भरिएको, प्रक्रियाहरूमा थोरै सुधारको लागि पनि प्रतिक्रिया दियो। कुल लोडको 5% मात्र उत्पादन गर्ने केही प्रश्नहरूको अनुकूलनले पहिले नै उल्लेखनीय CPU लोड देखाएको छ। नतिजाको रूपमा, हामीले मास्टरलाई डेटाबेससँग काम गर्न र प्रतिकृतिहरू पुनर्स्थापना गर्न आवश्यक समय प्राप्त गर्न स्रोतहरूको स्वीकार्य आपूर्ति प्रदान गर्न सक्षम भयौं। 

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

साझेदार सेवाहरूको कार्यसम्पादनको अनुगमनलाई व्यवस्थित गर्नुहोस्

हामी ग्राहकहरूबाट अर्डरहरू प्रशोधन गर्छौं, र त्यसैले हाम्रा सेवाहरू लगातार तेस्रो-पक्ष APIs सँग अन्तरक्रिया गर्छौं - यी SMS, भुक्तानी प्लेटफर्महरू, रूटिङ प्रणालीहरू, जियोकोडर, संघीय कर सेवा र अन्य धेरै प्रणालीहरू पठाउने गेटवेहरू हुन्। र जब लोड द्रुत रूपमा बढ्न थाल्यो, हामीले हाम्रा साझेदार सेवाहरूको API सीमितताहरूमा भाग्न थाल्यौं, जुन हामीले पहिले सोचेका थिएनौं।

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

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

धेरै संगठनात्मक उपायहरू लिइयो र टोलीको राम्रोसँग समन्वय गरिएको कामले समय प्राप्त गर्न मद्दत गर्‍यो जब हामी नयाँ सर्तहरूमा सहमत छौं र केही साझेदारहरूबाट सेवाहरूको आधुनिकीकरणको लागि पर्खिरहेका छौं। त्यहाँ अन्य API हरू छन् जसले उच्च ट्राफिकको अवस्थामा उच्च सहनशीलता र अपमानजनक दरहरू घमण्ड गर्दछ। उदाहरणका लागि, सुरुमा हामीले डेलिभरी पोइन्टको ठेगाना निर्धारण गर्न एउटा प्रख्यात म्यापिङ API प्रयोग गर्यौं। तर महिनाको अन्त्यमा हामीले लगभग 2 मिलियन रूबलको लागि एक व्यवस्थित बिल प्राप्त गर्यौं। त्यस पछि, तिनीहरूले चाँडै यसलाई प्रतिस्थापन गर्ने निर्णय गरे। म विज्ञापनमा संलग्न छैन, तर म भन्छु कि हाम्रो खर्च उल्लेखनीय रूपमा घटेको छ।

निष्कर्ष: सबै साझेदार सेवाहरूको सञ्चालन अवस्थाहरू अनुगमन गर्न र तिनीहरूलाई दिमागमा राख्न आवश्यक छ। यदि आज यो देखिन्छ कि तिनीहरू तपाईंको लागि "ठूलो मार्जिनको साथ" छन्, यसको मतलब यो होइन कि भोलि तिनीहरू विकासको लागि बाधा बन्नेछैनन्। र, निस्सन्देह, अग्रिम सेवाको लागि बढेको अनुरोधहरूको वित्तीय सर्तहरूमा सहमत हुनु राम्रो छ। 

कहिले काहिँ यस्तो हुन्छ कि "थप सुन चाहिन्छ"(c) मद्दत गर्दैन

हामी मुख्य डाटाबेस वा एप्लिकेसन सर्भरहरूमा "ग्यागहरू" को अभ्यस्त छौं, तर मापन गर्दा, समस्याहरू जहाँ अपेक्षा गरिएको थिएन त्यहाँ देखा पर्न सक्छ। साइटमा पूर्ण-पाठ खोजको लागि, हामी Apache Solr इन्जिन प्रयोग गर्छौं। लोड बढ्दै जाँदा, हामीले प्रतिक्रिया समय घटेको देख्यौं, र सर्भर प्रोसेसर लोड पहिले नै 100% पुगेको छ। के सरल हुन सक्छ - सोलर थप स्रोतहरूसँग कन्टेनर दिनुहोस्।

अपेक्षित प्रदर्शन बृद्धिको सट्टा, सर्भर मात्र "मर्यो"। यो तुरुन्तै 100% मा लोड भयो र अझ बिस्तारै प्रतिक्रिया दियो। सुरुमा हामीसँग २ कोर र २ जीबी र्याम थियो। हामीले सामान्यतया मद्दत गर्ने कुरा गर्ने निर्णय गर्यौं - हामीले सर्भरलाई 2 कोर र 2 GB दियौं। सबै कुरा धेरै खराब भयो (हामी तपाईंलाई कसरी र किन छुट्टै पोष्टमा बताउनेछौं)। 

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

निष्कर्ष: मानक विधिहरू जस्तै "थप फलाम थप्नुहोस्" सधैं काम गर्दैन। त्यसोभए कुनै पनि सेवा मापन गर्दा, तपाइँसँग यसले स्रोतहरू कसरी प्रयोग गर्दछ भन्ने बारे राम्रोसँग बुझ्नुपर्छ र पहिले नै नयाँ अवस्थाहरूमा यसको सञ्चालन परीक्षण गर्न आवश्यक छ। 

स्टेटलेस सजिलो तेर्सो स्केलिंगको कुञ्जी हो

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

जब प्रोसेसर लाममा कार्यहरूको संख्या बढ्यो (र यो स्वाभाविक रूपमा अर्डरहरूको संख्यामा बृद्धि भएको थियो), होस्टको प्रदर्शन जसमा प्रोसेसर र फाइल भण्डारण अवस्थित थियो एक सीमित कारक बन्यो। नतिजाको रूपमा, वर्गीकरण र मूल्यहरू अद्यावधिक गर्ने, प्रयोगकर्ताहरूलाई सूचनाहरू पठाउने, र लाममा अड्किएका अन्य धेरै महत्त्वपूर्ण कार्यहरू रोकिए। 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%होस्टिङ प्रदायक पूर्वाधार सीमा ३

• 33,3%तेस्रो-पक्ष APIs को सीमाहरू6

• 27,8%तिनीहरूको आवेदनको राज्यविहीन सिद्धान्तहरूको उल्लङ्घन ५

• 88,9%आफ्नै सेवाहरूको गैर-इष्टतम कोड16

18 प्रयोगकर्ताहरूले मतदान गरे। 6 प्रयोगकर्ताहरू रोकिए।

स्रोत: www.habr.com