वेब एप्लिकेशन लोड स्केलिंग

वेब-अनुप्रयोगों की बढ़ती लोकप्रियता के साथ, इसके समर्थन को अनिवार्य रूप से अधिक से अधिक संसाधनों की आवश्यकता होती है। सबसे पहले, आप आवेदन के एल्गोरिदम और / या वास्तुकला को अनुकूलित करके लोड से निपटने के लिए (और निश्चित रूप से आवश्यकता हो सकती है)। हालांकि, क्या करना है अगर सब कुछ जिसे अनुकूलित किया जा सकता है, पहले से ही अनुकूलित है, और एप्लिकेशन अभी भी लोड का सामना नहीं कर सकता है?

अनुकूलन

पहला कदम यह है कि आप बैठें और सोचें कि क्या आप पहले से ही सब कुछ अनुकूलित करने में कामयाब रहे हैं:

• क्या डेटाबेस क्वेरी इष्टतम हैं (विश्लेषण, अनुक्रमित का उपयोग करें)?
• क्या डेटा सही ढंग से संग्रहीत है (SQL बनाम NoSQL)?
• कैशिंग का उपयोग किया जाता है?
• एफएस या डेटाबेस के लिए कोई अनावश्यक प्रश्न हैं?
• क्या डेटा प्रोसेसिंग एल्गोरिदम इष्टतम हैं?
• क्या पर्यावरण सेटिंग्स इष्टतम हैं: Apache / Nginx, MySQL / PostgreSQL, PHP / पायथन?

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

स्केलिंग

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

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

अनुप्रयोग वास्तुकला

अधिकांश वेब एप्लिकेशन एक प्राथमिकता वितरित की जाती हैं, क्योंकि उनकी वास्तुकला को कम से कम तीन परतों में विभाजित किया जा सकता है: वेब सर्वर, व्यावसायिक तर्क (एप्लिकेशन), डेटा (डेटाबेस, स्टैटिक्स)।



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

टोंटी

सिस्टम को स्केल करना शुरू करते समय, पहला कदम यह निर्धारित करना है कि कौन सी परत एक अड़चन है - अर्थात, यह सिस्टम के बाकी हिस्सों की तुलना में धीमी गति से काम करता है। शुरुआत के लिए, आप प्रोसेसर / मेमोरी खपत और df, iostat को डिस्क की खपत का अनुमान लगाने के लिए शीर्ष (htop) जैसी सामान्य उपयोगिताओं का उपयोग कर सकते हैं। हालांकि, एक अलग मेजबान को आवंटित करने की सलाह दी जाती है जो मुकाबला लोड ( एबी या जेमेटर का उपयोग करके) का अनुकरण करता है , जिस पर xdebug , oprofile, और जैसे उपयोगिताओं का उपयोग करके एप्लिकेशन को प्रोफाइल करना संभव होगा। संकीर्ण डेटाबेस प्रश्नों की पहचान करने के लिए, आप pgFouine जैसी उपयोगिताओं का उपयोग कर सकते हैं (यह स्पष्ट है कि मुकाबला सर्वर से लॉग के आधार पर ऐसा करना बेहतर है)।

आमतौर पर, सब कुछ आवेदन की वास्तुकला पर निर्भर करता है, लेकिन सामान्य मामले में एक अड़चन के लिए सबसे अधिक संभावना उम्मीदवार डेटाबेस और कोड हैं। यदि आपका एप्लिकेशन बड़ी मात्रा में उपयोगकर्ता डेटा के साथ काम करता है, तो क्रमशः "अड़चन", स्थिर भंडारण होने की सबसे अधिक संभावना है।

डीबी स्केलिंग

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

आप इसे कई मेजबानों तक फैलाकर डेटाबेस पर लोड को कम कर सकते हैं। इसी समय, उनके बीच सिंक्रनाइज़ेशन की एक तीव्र समस्या है, जिसे सिंक्रोनस या एसिंक्रोनस प्रतिकृति के साथ मास्टर / दास योजना को लागू करके हल किया जा सकता है। PostgreSQL के मामले में, सिंक्रोनस प्रतिकृति को Slony-I , अतुल्यकालिक प्रतिकृति - PgPool-II या Wal (9.0) का उपयोग करके लागू किया जा सकता है। आप एक विशेष डेटाबेस एक्सेस लेयर (PgPool-II) की स्थापना करके, मौजूदा दासों के बीच लोड को संतुलित करने के साथ-साथ पढ़ने और लिखने के अनुरोधों को अलग करने की समस्या को हल कर सकते हैं।

संबंधपरक DBMS का उपयोग करने के मामले में बड़ी मात्रा में डेटा संग्रहीत करने की समस्या को PostgreSQL में विभाजन तंत्र का उपयोग करके या Hadoop DFS जैसे वितरित FS पर डेटाबेसों को तैनात करके हल किया जा सकता है।

दोनों समाधान उत्कृष्ट PostgreSQL ट्यूनिंग पुस्तक में पाए जा सकते हैं।

हालाँकि, बड़ी मात्रा में डेटा संग्रहीत करने के लिए, सबसे अच्छा समाधान " डेटािंग " करना होगा, जो कि अधिकांश NoSQL डेटाबेस का एक अंतर्निहित लाभ है (उदाहरण के लिए, MongoDB )।

इसके अलावा, NoSQL डेटाबेस आमतौर पर अपने SQL भाइयों की तुलना में पार्सिंग के लिए ओवरहेड की कमी / क्वेरी को अनुकूलित करने, डेटा संरचना की अखंडता की जांच करने आदि के कारण तेजी से होता है। संबंधपरक और NoSQL डेटाबेस की तुलना का विषय भी काफी व्यापक है और एक अलग लेख के योग्य है।

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

कोड स्केलिंग

कोड को स्केल करने में कठिनाई इस बात पर निर्भर करती है कि मेजबानों को आपके एप्लिकेशन को चलाने के लिए कितने साझा संसाधनों की आवश्यकता है। क्या यह केवल सत्र होगा, या एक सामान्य कैश और फ़ाइलों की आवश्यकता होगी? किसी भी मामले में, पहली चीज जो आपको करने की आवश्यकता है वह एक ही वातावरण के साथ कई मेजबानों पर एप्लिकेशन की प्रतियां चलाती है।

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

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

स्टेटिक फाइल को NFS / CIFS के माध्यम से कुछ साझा फ़ाइल स्टोरेज से माउंट किया जा सकता है या वितरित फाइल सिस्टम ( HDFS , GlusterFS , Ceph ) का उपयोग कर सकते हैं।

डेटाबेस में फ़ाइलों को संग्रहीत करना भी संभव है (उदाहरण के लिए, Mongo GridFS ), जिससे उपलब्धता और स्केलेबिलिटी की समस्याओं को हल किया जा सकता है (इस तथ्य को ध्यान में रखते हुए कि नोएसक्यूएल डेटाबेस के लिए स्केलेबिलिटी समस्या को शार्डिंग द्वारा हल किया गया था)।

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

एफएस स्केलिंग

यदि आपको बड़ी मात्रा में स्टैटिक्स संग्रहीत करने की आवश्यकता है, तो दो समस्याओं को अलग किया जा सकता है: स्थान की कमी और डेटा एक्सेस की गति। जैसा कि पहले ही ऊपर उल्लेख किया गया है, अंतरिक्ष की कमी की समस्या को कम से कम तीन तरीकों से हल किया जा सकता है: वितरित एफएस, एक डेटाबेस में डेटा को साझा करने के लिए समर्थन के साथ संग्रहीत करना, और कोड स्तर पर "मैन्युअल रूप से" को व्यवस्थित करना।

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

निगरानी

यह स्पष्ट है कि एक बड़ी और जटिल प्रणाली को निरंतर निगरानी की आवश्यकता होती है। मेरी राय में, समाधान यहाँ मानक है - ज़ैबिक्स, जो सिस्टम नोड्स के लोड / कार्य की निगरानी करता है और सुरक्षा के लिए डेमॉन के लिए मौन है।

निष्कर्ष

ऊपर, हमने वेब एप्लिकेशन को स्केल करने की समस्याओं के बारे में संक्षेप में कई समाधानों की जांच की। उनमें से प्रत्येक के अपने फायदे और नुकसान हैं। हर चीज को सही और सही तरीके से करने का कोई नुस्खा नहीं है - प्रत्येक कार्य के लिए उनके पेशेवरों और विपक्षों के साथ कई समाधान हैं। कौन सा चुनना है आप पर निर्भर है।