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

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

वर्षों से सीखे गए पाठों में से एक यह है कि व्यक्तिगत इंजीनियर आमतौर पर खुद को उनके हित के क्षेत्र में बहुत गहराई से विसर्जित करते हैं, और बाकी का सतही अध्ययन करते हैं। यह योजना सामान्य तौर पर अच्छे संचार वाले इंजीनियरों की टीम में काम करती है, जहां ज्ञान ओवरलैप होता है और उनमें से प्रत्येक के लिए व्यक्तिगत अंतराल को भरता है। लेकिन कम अनुभव वाले या व्यक्तिगत इंजीनियरों के लिए टीमों में, एक विफलता होती है।

यदि आपने ऐसे वातावरण में काम करना शुरू कर दिया है, और फिर खरोंच से एक वेब एप्लिकेशन बनाना और तैनात करना शुरू कर दिया है, तो आप जल्दी से पता लगा लेंगे कि "खतरनाक सतह ज्ञान क्या है"।

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

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

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

शुरुआत

कल्पना करें कि होस्टिंग के लिए आपका बजट प्रति वर्ष $ 500 है, इसलिए आपने Amazon AWS पर एक t2.medium सर्वर किराए पर देने का निर्णय लिया। लेखन के समय, यह लगभग $ 400 प्रति वर्ष है।

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


अंजीर। 1

यह अभी के लिए पर्याप्त है। वास्तव में, ऐसी प्रणाली काफी समय तक काम कर सकती है। सेवा छोटी है, प्रति दिन 10 से कम विज़िट। शायद एक छोटा उदाहरण पर्याप्त था, लेकिन हम कंपनी के विकास के बारे में आशावादी हैं, इसलिए हमने विवेकपूर्ण रूप से t2.medium लिया।

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

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

अब सिस्टम कुछ इस तरह दिखता है:


अंजीर। 2

आपने डेटाबेस की विश्वसनीयता बढ़ा दी है, और यह सर्वर पर लोड परीक्षण चलाकर "हैब्राफेक्ट" के लिए तैयार करने का समय है। 500 त्रुटियां दिखाई देने तक सब कुछ ठीक हो जाता है, और फिर 404 त्रुटि स्ट्रीम होती है, इसलिए आप जांच कर रहे हैं कि क्या हुआ।

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

आप systemd सर्विस बनाकर समस्या को स्वचालित रीस्टार्ट से ठीक करते हैं, वेब सर्वर शुरू करते हैं, जो एक साथ लॉगिंग की समस्या को हल करता है। फिर सत्यापित करने के लिए एक और लोड परीक्षण चलाएँ।

और फिर से हम त्रुटियों को देखते हैं 500 (सौभाग्य से, 404 के बिना)। आप लॉग की जाँच करें। यह पता चला है कि डेटाबेस कनेक्शन पूल भरा हुआ है क्योंकि 10 कनेक्शनों की एक छोटी सी सीमा निर्धारित की गई है। प्रतिबंध को अपडेट करें, डेटाबेस को पुनरारंभ करें और लोड परीक्षण फिर से चलाएं। सब कुछ ठीक चल रहा है, इसलिए आप अपनी साइट के बारे में हैबे पर बात करने का फैसला करते हैं।

लॉन्च का दिन

भगवान की माँ! आपकी सेवा तुरंत हिट हो जाती है। आप मुख्य पृष्ठ पर पहुंचे और पहले 30 मिनट में 5000 बार देखें - और आप टिप्पणियों को देखें। वे वहां क्या लिखते हैं?

मेरे पास 404 त्रुटि है, इसलिए मुझे पृष्ठ का कैश्ड संस्करण खोलना पड़ा। यहाँ लिंक है, अगर किसी को इसकी आवश्यकता है: ...

...

कुछ नहीं खुलता। इसके अलावा, मेरे पास जावास्क्रिप्ट अक्षम है। लोगों को क्यों लगता है कि मैं उनकी 2 एमबी जावास्क्रिप्ट लोड करना चाहता हूं ...

...

होम पेज को डाउनलोड करने में 4 सेकंड का समय लगता है। ऑस्ट्रेलिया के ट्रेसरआउट ने दिखाया कि सर्वर टेक्सास में कहीं स्थित है। इसके अलावा, पहले पृष्ठ पर जावास्क्रिप्ट का 2 मेगाबाइट क्यों लोड होता है?

एक पागल भीड़ में, आप अपने आवेदन के लिए रिवर्स प्रॉक्सी सर्वर के रूप में नग्नेक्स को कॉन्फ़िगर करते हैं और वहां एक स्थिर 404 पृष्ठ को कॉन्फ़िगर करते हैं। आप एस 3 को स्थिर फाइलें भेजने के लिए तैनाती की प्रक्रिया को भी बदलते हैं: ऑस्ट्रेलिया में लोड समय को कम करने के लिए क्लाउडफ्रंट सीडीएन के लिए यह आवश्यक है।


अंजीर। 3

आपने सबसे अधिक दबाने वाली समस्या को हल किया है, सर्वर पर जाएं और लॉग की जांच करें। आपका SSH कनेक्शन असामान्य रूप से पिछड़ रहा है। कुछ अध्ययन के बाद, आप देखते हैं कि लॉग फ़ाइलों ने डिस्क स्थान का पूरी तरह से उपयोग किया है, जिसके कारण प्रक्रिया दुर्घटनाग्रस्त हो गई और इसे फिर से शुरू करने से रोका गया। एक बहुत बड़ी डिस्क बनाएं और वहां लॉग्स को माउंट करें। लॉग को कॉन्फ़िगर करें ताकि लॉग फ़ाइल अब ऐसे आकारों में न logrotate ।

प्रदर्शन के मुद्दे

महीनों बीत जाते हैं। दर्शक बढ़ रहा है। साइट धीमा होने लगती है। आपने CloudWatch की निगरानी में देखा कि यह केवल 00:00 और 12:00 UTC के बीच होता है। एक ही शुरुआत और अंत अंतराल समय के कारण, आपको पता चलता है कि यह सर्वर पर निर्धारित कार्य के कारण है। Crontab की जाँच करें और महसूस करें कि एक नौकरी आधी रात के लिए निर्धारित है: बैकअप। बेशक, बैकअप में बारह घंटे लगते हैं और डेटाबेस अधिभार की ओर जाता है, जिससे साइट में एक महत्वपूर्ण मंदी होती है।

आप इसके बारे में पहले पढ़ते हैं - और एक गुलाम डेटाबेस में बैकअप चलाने का निर्णय लेते हैं। फिर याद रखें: आपके पास एक अधीनस्थ डेटाबेस नहीं है, इसलिए आपको इसे बनाने की आवश्यकता है। यह एक ही सर्वर पर दास डेटाबेस को चलाने के लिए बहुत मायने नहीं रखता है, इसलिए आप विस्तार करने का निर्णय लेते हैं। दो नए सर्वर बनाएँ: एक मास्टर डेटाबेस के लिए और एक दास डेटाबेस के लिए। अधीनस्थ डेटाबेस के साथ काम करने के लिए बैकअप बदलें।


अंजीर। 4

टीम की बढ़त

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

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

विपणन विभाग संस्करण 2.0 के लिए जोर दे रहा है। आप काफी नहीं समझते हैं कि 2.0 का मतलब क्या है, लेकिन आप सहमत हैं। ट्रैफिक में अगले उछाल के लिए तैयार होने का समय आ गया है। आप वर्तमान सर्वर पर पहले से ही चोटी के करीब हैं, इसलिए लोड संतुलन के लिए समय आ गया है। अमेज़न ईएलबी यह आसान बनाता है। इस समय के दौरान, आप देखते हैं कि इस लेख में स्तरित आरेख ऊपर से नीचे तक परतें दिखा सकते हैं, न कि बाएं से दाएं।


अंजीर। 5

आत्मविश्वास है कि आप लोड से सामना करेंगे, आप फिर से हैबे पर अपनी साइट का उल्लेख करें। ओह चमत्कार, यह यातायात का सामना कर सकता है। बड़ी सफलता!

जब तक आप लॉग की जांच करने के लिए नहीं गए तब तक सब कुछ ठीक लग रहा था। 12 सर्वर (प्रत्येक वातावरण में चार सर्वर) का परीक्षण करने में एक घंटे का समय लगा। एक असली परेशानी। सौभाग्य से, एक ELK स्टैक (ElasticSearch, LogStash, Kibana) खरीदने के लिए पर्याप्त पैसा है। आप इसे तैनात करते हैं और सभी वातावरणों से सर्वर को निर्देशित करते हैं।


अंजीर। 6

अब, आप लॉग को फिर से चालू कर सकते हैं, आप उन्हें देख सकते हैं - और कुछ अजीब नोटिस कर सकते हैं। वे ऐसी प्रविष्टियों से भरे हुए हैं:

 GET /wp-login.php HTTP/1.1" 404 169 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1 GET /wp-login.php HTTP/1.1" 404 169 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1 GET /wp-login.php HTTP/1.1" 404 169 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1 GET /wp-login.php HTTP/1.1" 404 169 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1 GET /wp-login.php HTTP/1.1" 404 169 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1 GET /wp-login.php HTTP/1.1" 404 169 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1 GET /wp-login.php HTTP/1.1" 404 169 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1 GET /wp-login.php HTTP/1.1" 404 169 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1 GET /wp-login.php HTTP/1.1" 404 169 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1 GET /wp-login.php HTTP/1.1" 404 169 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1 

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


अंजीर। 7

लॉग को फिर से जांचें। हैकिंग के प्रयास बने रहे, लेकिन अब वे लोड बैलेंसर पर पोर्ट 80 तक सीमित हैं, जो थोड़ा आरामदायक है, क्योंकि एप्लिकेशन सर्वर, डेटाबेस सर्वर और ईएलके स्टैक अब सार्वजनिक डोमेन में नहीं हैं।

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

चिकना ऑपरेशन

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

हमने बैकअप, रोलबैक (उत्पादन और मध्यवर्ती चरण के बीच नीले / हरे रंग की तैनाती का उपयोग करके), केंद्रीकृत लॉग, निगरानी और अधिसूचना के साथ एक स्केलेबल वेब एप्लिकेशन बनाया। आगे स्केलिंग, एक नियम के रूप में, आवेदन की विशिष्ट आवश्यकताओं पर निर्भर करता है।

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

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

निष्कर्ष

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

इस पोस्ट का उद्देश्य सामान्य अवलोकन है कि उत्पादन में एक उचित वेब अनुप्रयोग कैसा दिखना चाहिए। भविष्य के लेख यहां लिंक कर सकते हैं और विषय का विस्तार कर सकते हैं।

अभी के लिए बस इतना ही।

पढ़ने और अच्छी कोडिंग के लिए धन्यवाद!

नोट: वस्तुतः इस दृष्टांत लेख से अनुक्रम न लें। अलग-अलग, ये सभी घटनाएं वास्तव में मेरे साथ हुईं, लेकिन अलग-अलग समय पर, पूरी तरह से अलग-अलग वातावरणों में और विभिन्न कार्यों पर।