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

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

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

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

1 उपयोगकर्ता: 1 कार

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

एपीआई
डेटाबेस
ग्राहक (मोबाइल एप्लिकेशन या वेबसाइट स्वयं)

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

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

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

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

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

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

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

अब यह व्यवस्था कैसी दिखती है:

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

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

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

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

यहाँ सिस्टम कैसा दिखता है:

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

सब कुच अच्छा है। Graminsta उपयोगकर्ता अधिक से अधिक तस्वीरें अपलोड कर रहे हैं। पंजीकरण की संख्या भी बढ़ रही है। हमारे lone API सर्वर में सभी ट्रैफ़िक को प्रबंधित करने में कठिनाई होती है। अधिक लोहे की आवश्यकता है!

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

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

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

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

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

. , PaaS, Heroku Elastic Beanstalk AWS ( ). Heroku , - API. , Heroku — .

10 000 : CDN

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

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

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

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

100,000 उपयोगकर्ता: डेटा स्तर स्केलिंग

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

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

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

कैशिंग

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

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

उदाहरण के लिए, हमारी Graminsta सेवा में, जब भी कोई व्यक्ति Mobric star profile page पर जाता है, तो API सर्वर डेटाबेस में उसकी प्रोफ़ाइल से जानकारी का अनुरोध करता है। यह बार-बार होता है। चूंकि Mobrick की प्रोफ़ाइल जानकारी हर अनुरोध के साथ नहीं बदलती है, इसलिए यह कैशिंग के लिए बहुत अच्छा है।

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

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

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

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

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

यहाँ अब हमारी प्रणाली है:

आगे की कार्रवाई

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

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

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

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

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

फुटनोट

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

1 से 100,000 उपयोगकर्ताओं को कैसे स्केल करें