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

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

आइए जानकारी को फ़िल्टर करने और मूल सूत्र लिखने का प्रयास करें। हम अपनी नई फोटो शेयरिंग साइट ग्रामिंस्टा को चरण दर चरण 1 से 100 उपयोगकर्ताओं तक बढ़ाने जा रहे हैं।

आइए लिखें कि जब दर्शकों की संख्या 10, 100, 1000, 10 और 000 तक बढ़ जाए तो क्या विशिष्ट कार्रवाई करने की आवश्यकता है।

1 उपयोगकर्ता: 1 मशीन

लगभग हर एप्लिकेशन, चाहे वह वेबसाइट हो या मोबाइल एप्लिकेशन, में तीन प्रमुख घटक होते हैं:

• API
• डेटाबेस
• क्लाइंट (स्वयं मोबाइल एप्लिकेशन या वेबसाइट)

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

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

जब हम पहली बार एक एप्लिकेशन बनाना शुरू करते हैं, तो सभी तीन घटकों को एक ही सर्वर पर चलाया जा सकता है। कुछ मायनों में, यह हमारे विकास परिवेश के समान है: एक इंजीनियर एक ही मशीन पर डेटाबेस, एपीआई और क्लाइंट चलाता है।

सिद्धांत रूप में, हम इसे एकल डिजिटलओशन ड्रॉपलेट या AWS EC2 इंस्टेंस पर क्लाउड में तैनात कर सकते हैं, जैसा कि नीचे दिखाया गया है:

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

10 उपयोगकर्ता: डेटाबेस को एक अलग स्तर पर ले जाना

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

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

100 उपयोगकर्ता: क्लाइंट को एक अलग स्तर पर ले जाना

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

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

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

ऐसी प्रणाली इस प्रकार दिखती है:

1000 उपयोगकर्ता: लोड बैलेंसर जोड़ें

स्थितियां बेहतर नज़र आ रही हैं। ग्रामीणस्टा यूजर्स ज्यादा से ज्यादा तस्वीरें अपलोड कर रहे हैं। पंजीकरण की संख्या भी बढ़ रही है। हमारे अकेले एपीआई सर्वर को सभी ट्रैफ़िक को बनाए रखने में कठिनाई हो रही है। अधिक लोहे की आवश्यकता है!

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

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

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

लोड बैलेंसर स्वचालित स्केलिंग भी प्रदान करता है। हम इसे पीक लोड से पहले उदाहरणों की संख्या बढ़ाने के लिए कॉन्फ़िगर कर सकते हैं, और जब सभी उपयोगकर्ता सो रहे हों तो इसे कम कर सकते हैं।

लोड बैलेंसर के साथ, एपीआई स्तर को लगभग अनिश्चित काल तक बढ़ाया जा सकता है, बस अनुरोधों की संख्या बढ़ने पर नए उदाहरण जोड़े जा सकते हैं।

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

10 उपयोगकर्ता: सीडीएन

शायद हमें शुरू से ही ऐसा करना चाहिए था. अनुरोधों को संसाधित करने और नई फ़ोटो स्वीकार करने से हमारे सर्वर पर बहुत अधिक दबाव पड़ने लगा है।

इस स्तर पर, आपको स्थिर सामग्री - चित्र, वीडियो और बहुत कुछ (AWS S3 या डिजिटल ओशन स्पेस) संग्रहीत करने के लिए क्लाउड सेवा का उपयोग करने की आवश्यकता है। सामान्य तौर पर, हमारे एपीआई को छवियों को प्रस्तुत करने और सर्वर पर छवियों को अपलोड करने जैसी चीजों को संभालने से बचना चाहिए।

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

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

100 उपयोगकर्ता: डेटा स्तर को स्केल करना

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

मेट्रिक्स में थोड़ा खोदने पर, हम देखते हैं कि डेटाबेस सर्वर पर सीपीयू 80-90% लोड है। हम सीमा पर हैं.

डेटा स्तर को स्केल करना संभवतः समीकरण का सबसे कठिन हिस्सा है। एपीआई सर्वर स्टेटलेस अनुरोधों को पूरा करते हैं, इसलिए हम बस अधिक एपीआई उदाहरण जोड़ते हैं। नाक बहुमत से डेटाबेस ऐसा नहीं कर सकते. हम लोकप्रिय रिलेशनल डेटाबेस मैनेजमेंट सिस्टम (PostgreSQL, MySQL, आदि) के बारे में बात करेंगे।

कैशिंग

हमारे डेटाबेस के प्रदर्शन को बढ़ाने के सबसे आसान तरीकों में से एक एक नया घटक पेश करना है: कैश परत। सबसे आम कैशिंग विधि इन-मेमोरी की-वैल्यू रिकॉर्ड स्टोर है, जैसे रेडिस या मेम्केच्ड। अधिकांश क्लाउड में इन सेवाओं का एक प्रबंधित संस्करण होता है: AWS पर Elasticache और Google क्लाउड पर मेमोरीस्टोर।

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

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

हम कुंजी द्वारा Redis में डेटाबेस से परिणामों को कैश करेंगे user:id 30 सेकंड की वैधता अवधि के साथ। अब, जब कोई मोब्रिक की प्रोफ़ाइल पर जाता है, तो हम पहले रेडिस की जांच करते हैं, और यदि डेटा वहां है, तो हम इसे सीधे रेडिस से स्थानांतरित कर देते हैं। अब साइट पर सबसे लोकप्रिय प्रोफ़ाइल के अनुरोध व्यावहारिक रूप से हमारे डेटाबेस को लोड नहीं करते हैं।

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

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

प्रतिकृतियाँ पढ़ें

जब डेटाबेस में प्रश्नों की संख्या बहुत बढ़ गई है, तो एक और चीज जो हम कर सकते हैं वह है डेटाबेस प्रबंधन प्रणाली में पढ़ी गई प्रतिकृतियां जोड़ना। ऊपर वर्णित प्रबंधित सेवाओं के साथ, यह एक क्लिक में किया जा सकता है। पढ़ी गई प्रतिकृति मुख्य डेटाबेस में चालू रहेगी और SELECT स्टेटमेंट के लिए उपलब्ध है।

अब हमारा सिस्टम यह है:

अगले चरण

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

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

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

सूत्रों का कहना है

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

फ़ुटनोट

1. हालांकि कई उदाहरणों में लोड वितरण के मामले में समान, रेडिस क्लस्टर का अंतर्निहित कार्यान्वयन लोड बैलेंसर से बहुत अलग है। [वापस करना]

स्रोत: www.habr.com