धेरै स्टार्टअपहरू यसबाट गुज्रिएका छन्: नयाँ प्रयोगकर्ताहरूको भीड हरेक दिन दर्ता हुन्छ, र विकास टोलीले सेवा चलाउन संघर्ष गर्दछ।

यो हुनु राम्रो समस्या हो, तर वेब अनुप्रयोगलाई कसरी सावधानीपूर्वक मापन गर्ने भन्ने बारे वेबमा थोरै स्पष्ट जानकारी छ हजारौं प्रयोगकर्ताहरू सम्म। सामान्यतया त्यहाँ या त आगो समाधान वा बाधा समाधान (र अक्सर दुवै) छन्। तसर्थ, मानिसहरूले आफ्नो एमेच्योर प्रोजेक्टलाई साँच्चै गम्भीर कुरामा मापन गर्न बरु क्लिच गरिएका प्रविधिहरू प्रयोग गर्छन्।

जानकारी फिल्टर गर्ने प्रयास गरौं र आधारभूत सूत्र लेखौं। हामी हाम्रो नयाँ फोटो सेयरिङ साइट ग्रामिन्स्टालाई चरणबद्ध रूपमा 1 देखि 100 प्रयोगकर्ताहरू मापन गर्न जाँदैछौं।

श्रोता १०, १००, १०००, १०,००० र १०,००,००० मानिसहरूमा पुग्दा के-के विशेष कार्यहरू गर्न आवश्यक छ भनेर लेखौं।

१ प्रयोगकर्ता: १ मेसिन

लगभग हरेक अनुप्रयोग, यो वेबसाइट होस् वा मोबाइल अनुप्रयोग, तीन प्रमुख घटकहरू छन्:

• एपीआई
• डाटाबेस
• ग्राहक (मोबाइल अनुप्रयोग आफैं वा वेबसाइट)

डाटाबेसले निरन्तर डाटा भण्डारण गर्दछ। API ले यो डाटा र वरपर अनुरोधहरू सेवा गर्दछ। ग्राहकले प्रयोगकर्तालाई डाटा पठाउँछ।

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

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

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

त्यसको साथमा, यदि साइटमा एक भन्दा बढी प्रयोगकर्ताहरू हुनेछन् भने, यो लगभग सधैं डाटाबेस तह समर्पित गर्न अर्थ बनाउँछ।

१० प्रयोगकर्ताहरू: डाटाबेसलाई छुट्टै स्तरमा सार्दै

Amazon RDS वा Digital Ocean Managed Database जस्ता व्यवस्थित सेवाहरूमा डाटाबेस विभाजन गर्नाले हामीलाई लामो समयसम्म राम्रोसँग सेवा दिनेछ। यो एकल मेसिन वा EC2 उदाहरणमा सेल्फ-होस्टिङ भन्दा अलि महँगो छ, तर यी सेवाहरूसँग तपाईंले भविष्यमा काममा आउने बाकसबाट धेरै उपयोगी विस्तारहरू प्राप्त गर्नुहुनेछ: बहु-क्षेत्र ब्याकअप, प्रतिकृतिहरू पढ्नुहोस्, स्वचालित ब्याकअप, र थप।

यो प्रणाली अहिले जस्तो देखिन्छ:

100 प्रयोगकर्ताहरू: ग्राहकलाई छुट्टै स्तरमा सार्दै

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

यसैले म ग्राहकलाई API बाट अलग रूपमा सोच्न चाहन्छु। यसले धेरै प्लेटफर्महरू: वेब, मोबाइल वेब, iOS, एन्ड्रोइड, डेस्कटप अनुप्रयोगहरू, तेस्रो-पक्ष सेवाहरू, इत्यादिका लागि विकास गर्ने बारे सोच्न धेरै सजिलो बनाउँछ। तिनीहरू सबै एउटै API प्रयोग गर्ने ग्राहकहरू मात्र हुन्।

उदाहरणका लागि, अब हाम्रा प्रयोगकर्ताहरू प्रायः मोबाइल अनुप्रयोग जारी गर्न सोध्छन्। यदि तपाइँ ग्राहक र एपीआई निकायहरू अलग गर्नुहुन्छ भने, यो सजिलो हुन्छ।

यो यस्तो प्रणाली जस्तो देखिन्छ:

1000 प्रयोगकर्ताहरू: लोड ब्यालेन्सर थप्नुहोस्

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

लोड ब्यालेन्सर एक धेरै शक्तिशाली अवधारणा हो। मुख्य विचार यो हो कि हामीले API को अगाडि लोड ब्यालेन्सर राख्छौं, र यसले व्यक्तिगत सेवा उदाहरणहरूमा ट्राफिक वितरण गर्दछ। यसरी हामी तेर्सो रूपमा मापन गर्छौं, यसको मतलब हामी समान कोडसँग थप सर्भरहरू थप्छौं, हामीले प्रक्रिया गर्न सक्ने अनुरोधहरूको संख्या बढाउँछौं।

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

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

लोड ब्यालेन्सरले स्वचालित स्केलिंग पनि प्रदान गर्दछ। हामी यसलाई अधिकतम लोड हुनु अघि उदाहरणहरूको संख्या बढाउन कन्फिगर गर्न सक्छौं, र सबै प्रयोगकर्ताहरू सुतिरहेका बेला यसलाई घटाउन सक्छौं।

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

नोट। अहिले हाम्रो प्रणाली AWS मा Heroku वा Elastic Beanstalk जस्ता PaaS कम्पनीहरूले बक्स बाहिर प्रस्ताव गर्ने जस्तै छ (जसले गर्दा तिनीहरू धेरै लोकप्रिय छन्)। Heroku ले डाटाबेसलाई छुट्टै होस्टमा राख्छ, स्वत: स्केलिंग लोड ब्यालेन्सर प्रबन्ध गर्दछ, र तपाइँलाई API बाट अलग वेब क्लाइन्ट होस्ट गर्न अनुमति दिन्छ। प्रारम्भिक चरणका परियोजनाहरू वा स्टार्टअपहरूका लागि Heroku प्रयोग गर्ने यो एउटा ठूलो कारण हो - तपाईंले बक्सबाट सबै आधारभूत सेवाहरू प्राप्त गर्नुहुन्छ।

10 प्रयोगकर्ताहरू: CDN

सायद हामीले यो सुरुदेखि नै गर्नुपर्थ्यो। अनुरोधहरू प्रशोधन गर्दै र नयाँ फोटोहरू स्वीकार गर्नाले हाम्रो सर्भरहरूमा धेरै तनाव हुन थालेको छ।

यस चरणमा, तपाईंले स्थिर सामग्री भण्डारण गर्न क्लाउड सेवा प्रयोग गर्न आवश्यक छ - छविहरू, भिडियोहरू र अधिक (AWS S3 वा Digital Ocean Spaces)। सामान्यतया, हाम्रो API ले छविहरू सेवा गर्ने र सर्भरमा छविहरू अपलोड गर्ने जस्ता चीजहरू ह्यान्डल गर्नबाट बच्नुपर्छ।

क्लाउड होस्टिङको अर्को फाइदा CDN हो (AWS ले यसलाई एड-अन क्लाउडफ्रन्ट भनिन्छ, तर धेरै क्लाउड भण्डारण प्रदायकहरूले यसलाई बक्स बाहिर प्रस्ताव गर्छन्)। CDN ले स्वचालित रूपमा हाम्रा छविहरू विश्वभरका विभिन्न डाटा केन्द्रहरूमा क्यास गर्दछ।

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

100 प्रयोगकर्ताहरू: डेटा तह मापन गर्दै

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

मेट्रिक्समा थोरै खन्ने, हामी डाटाबेस सर्भरमा CPU 80-90% लोड भएको देख्छौं। हामी सीमामा छौं।

डाटा तह मापन सम्भवतः समीकरणको सबैभन्दा कठिन भाग हो। API सर्भरहरूले स्टेटलेस अनुरोधहरू सेवा गर्दछ, त्यसैले हामी केवल थप API उदाहरणहरू थप्छौं। नाक बहुमत डाटाबेसले यो गर्न सक्दैन। हामी लोकप्रिय रिलेशनल डाटाबेस व्यवस्थापन प्रणाली (PostgreSQL, MySQL, आदि) को बारेमा कुरा गर्नेछौं।

क्यासिङ

हाम्रो डाटाबेसको कार्यसम्पादन बृद्धि गर्ने एउटा सजिलो तरिका भनेको नयाँ कम्पोनेन्ट परिचय गराउनु हो: क्यास तह। सबैभन्दा सामान्य क्यासिङ विधि इन-मेमोरी कुञ्जी-मान रेकर्ड स्टोर हो, जस्तै Redis वा Memcached। धेरै जसो क्लाउडहरूमा यी सेवाहरूको व्यवस्थित संस्करण हुन्छ: AWS मा Elasticache र Google Cloud मा Memorystore।

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

उदाहरणका लागि, हाम्रो ग्रामिन्स्टा सेवामा, प्रत्येक पटक जब कोही स्टार मोब्रिकको प्रोफाइल पृष्ठमा जान्छ, API सर्भरले उसको प्रोफाइलबाट जानकारीको लागि डाटाबेसलाई सोध्छ। यो बारम्बार हुन्छ। Mobrik को प्रोफाइल जानकारी प्रत्येक अनुरोध संग परिवर्तन गर्दैन, यो क्यासिंग को लागी उत्कृष्ट छ।

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

धेरै क्यासिङ सेवाहरूको अर्को फाइदा यो हो कि तिनीहरू डाटाबेस सर्भरहरू भन्दा मापन गर्न सजिलो छन्। Redis मा निर्मित Redis क्लस्टर मोड छ। लोड ब्यालेन्सर जस्तै1, यसले तपाइँलाई तपाइँको Redis क्यास धेरै मेसिनहरूमा वितरण गर्न अनुमति दिन्छ (आवश्यक भएमा हजारौं सर्भरहरूमा)।

लगभग सबै ठूला-ठूला एप्लिकेसनहरूले क्यासिङ प्रयोग गर्छन्; यो द्रुत API को पूर्ण रूपमा अभिन्न अंग हो। द्रुत क्वेरी प्रशोधन र थप उत्पादक कोड सबै महत्त्वपूर्ण छन्, तर क्यास बिना लाखौं प्रयोगकर्ताहरूलाई सेवा मापन गर्न लगभग असम्भव छ।

प्रतिकृतिहरू पढ्नुहोस्

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

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

अर्को चरणहरू

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

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

हामी New Relic वा Datadog जस्तै निगरानी र विश्लेषण सेवा पनि स्थापना गर्न चाहन्छौं। यसले तपाईंलाई ढिलो प्रश्नहरू पहिचान गर्न र कहाँ सुधार आवश्यक छ भनेर बुझ्न मद्दत गर्नेछ। हामीले मापन गर्दा, हामी अवरोधहरू फेला पार्न र तिनीहरूलाई हटाउनमा ध्यान केन्द्रित गर्न चाहन्छौं — प्रायः अघिल्लो खण्डहरूका केही विचारहरू प्रयोग गरेर।

स्रोतहरू

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

फुटनोटहरू

1. यद्यपि धेरै उदाहरणहरूमा लोड वितरणको सन्दर्भमा समान, Redis क्लस्टरको अन्तर्निहित कार्यान्वयन लोड ब्यालेन्सर भन्दा धेरै फरक छ। [फर्किनु]

स्रोत: www.habr.com