लोड परीक्षण के लिए सैकड़ों सर्वरों का प्रबंधन करना: ऑटोस्कोलिंग, कस्टम मॉनिटरिंग, देवओप्स संस्कृति

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

• परीक्षण वातावरण बनाने और हटाने के लिए - टेराफ़ॉर्म स्क्रिप्ट;
• कॉन्फ़िगर करने, अद्यतन करने और चलाने के लिए - उत्तर देने योग्य स्क्रिप्ट;
• लोड के आधार पर डायनामिक स्केलिंग के लिए - स्व-लिखित पायथन स्क्रिप्ट।

Terraform और Ansible स्क्रिप्ट के लिए धन्यवाद, सर्वर को शुरू करने के उदाहरण बनाने से लेकर सिर्फ छह आदेशों तक सभी कार्य किए जाते हैं:

#     aws ansible-playbook deploy-config.yml #   ansible-playbook start-application.yml #      ansible-playbook update-test-scenario.yml --ask-vault-pass # Jmeter ,      infrastructure-aws-cluster/jmeter_clients:~# terraform apply # jmeter     ansible-playbook start-jmeter-server-cluster.yml # jmeter  ansible-playbook start-stress-test.yml #  

गतिशील सर्वर स्केलिंग

उत्पादन के समय में, हमारे पास एक ही समय में 20K से अधिक ऑनलाइन उपयोगकर्ता हैं, और अन्य घंटों में 6K हो सकते हैं। सर्वर की पूरी मात्रा को लगातार रखने का कोई मतलब नहीं है, इसलिए हम बोर्ड-सर्वर के लिए ऑटो-स्केलिंग सेट करते हैं, जिस पर उपयोगकर्ता द्वारा दर्ज किए गए क्षणों में खुले हुए बोर्ड, और एपीआई-अनुरोध को संसाधित करने वाले एपीआई-सर्वरों के लिए। अब आवश्यक होने पर सर्वर बनाए और हटाए जाते हैं।

लोड परीक्षण में यह तंत्र बहुत प्रभावी है: डिफ़ॉल्ट रूप से, हमारे पास न्यूनतम संख्या में सर्वर हो सकते हैं, और परीक्षण के समय वे स्वचालित रूप से सही मात्रा में बढ़ेंगे। शुरुआत में, हमारे पास 4 बोर्ड सर्वर हो सकते हैं, और चरम पर - 40 तक। एक ही समय में, नए सर्वर तुरंत नहीं बनाए जाते हैं, लेकिन केवल वर्तमान सर्वर लोड होने के बाद। उदाहरण के लिए, नए उदाहरण बनाने की कसौटी CPU उपयोग का 50% हो सकती है। यह आपको स्क्रिप्ट में वर्चुअल उपयोगकर्ताओं के विकास को धीमा नहीं करने और अनावश्यक सर्वर बनाने की अनुमति नहीं देता है।

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

ठेस के अनुसार मेट्रिक्स का संग्रह

तनाव परीक्षणों की निगरानी के लिए कई दृष्टिकोण और उपकरण हैं, लेकिन हम अपने तरीके से चले गए।

हम एक मानक स्टैक के साथ उत्पादन की निगरानी करते हैं: लॉगस्टैश, इलास्टिसर्च, किबाना, प्रोमेथियस और ग्राफाना। परीक्षणों के लिए हमारा क्लस्टर उत्पाद के समान है, इसलिए हमने उसी मैट्रिक्स के साथ, ठेस के समान निगरानी करने का निर्णय लिया। इसके दो कारण हैं:

• खरोंच से एक निगरानी प्रणाली बनाने की कोई आवश्यकता नहीं है, हमारे पास पहले से ही यह पूरा और तुरंत है;
• हम अतिरिक्त रूप से बिक्री की निगरानी का परीक्षण करते हैं: यदि परीक्षण की निगरानी के दौरान हम समझते हैं कि हमारे पास समस्या का विश्लेषण करने के लिए पर्याप्त डेटा नहीं है, तो वे उत्पादन के लिए पर्याप्त नहीं होंगे, जब ऐसी समस्या वहां दिखाई देगी।

हम रिपोर्ट में क्या दिखाते हैं

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

यह महत्वपूर्ण है कि सभी परिणाम एक ही स्थान पर संग्रहीत हों। इसलिए उन्हें लॉन्च से लॉन्च तक एक-दूसरे के साथ तुलना करना सुविधाजनक होगा।

हम अपने उत्पाद में रिपोर्ट बनाते हैं (एक रिपोर्ट के साथ एक व्हाइटबोर्ड का उदाहरण) :



रिपोर्ट बनाने में बहुत समय लगता है। इसलिए, हम अपने सार्वजनिक एपीआई का उपयोग करके सामान्य जानकारी के संग्रह को स्वचालित बनाने की योजना बनाते हैं।

कोड के रूप में अवसंरचना

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

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

बिक्री के काम को समझने में टीमों की मदद करने के लिए, इन्फ्रास्ट्रक्चर दृष्टिकोण को कोड के रूप में इस्तेमाल किया जा सकता है, जिसे हमने विकास टीम में उपयोग करना शुरू किया।

इस दृष्टिकोण का उपयोग करके हमने किन समस्याओं को हल करना शुरू कर दिया है:

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

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

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

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

हमारी तात्कालिक योजनाओं में ऐसी समस्याओं का समाधान।

निष्कर्ष

1. यह टेस्ट इन्फ्रास्ट्रक्चर के मैनुअल ऑर्केस्ट्रेशन पर समय बर्बाद करने के लायक नहीं है; यह इन क्रियाओं को स्वचालित करने के लिए बेहतर है, ताकि ठेस सहित सभी वातावरणों का अधिक मज़बूती से प्रबंधन किया जा सके;
2. गतिशील स्केलिंग बिक्री और एक बड़े परीक्षण वातावरण को बनाए रखने की लागत को काफी कम करता है, और स्केलिंग करते समय मानव कारक को भी कम करता है;
3. आप परीक्षणों के लिए एक अलग निगरानी प्रणाली का उपयोग नहीं कर सकते हैं, लेकिन इसे बाजार से ले सकते हैं;
4. यह महत्वपूर्ण है कि तनाव परीक्षण रिपोर्ट स्वचालित रूप से एक ही स्थान पर एकत्र की जाती है और एक समान दृष्टिकोण रखती है। यह उन्हें परिवर्तनों की आसानी से तुलना और विश्लेषण करने की अनुमति देगा;
5. तनाव परीक्षण कंपनी में एक प्रक्रिया बन जाएगी जब टीमों को बिक्री के लिए जिम्मेदार महसूस होगा;
6. लोड परीक्षण - अवसंरचना परीक्षण। यदि लोड परीक्षण सफल रहा, तो संभव है कि इसे सही तरीके से संकलित नहीं किया गया था। परीक्षण की शुद्धता की पुष्टि के लिए बिक्री की गहरी समझ की आवश्यकता होती है। टीमों को बिक्री डिवाइस को स्वतंत्र रूप से समझने का अवसर होना चाहिए। हम एक कोड दृष्टिकोण के रूप में इन्फ्रास्ट्रक्चर का उपयोग करके इस समस्या को हल करते हैं;
7. इन्फ्रास्ट्रक्चर तैयारी स्क्रिप्ट को भी किसी अन्य कोड की तरह परीक्षण की आवश्यकता होती है।