अनेक स्टार्टअप्स यातून गेले आहेत: नवीन वापरकर्त्यांची गर्दी दररोज नोंदणी करतात आणि विकास कार्यसंघ सेवा चालू ठेवण्यासाठी धडपडत आहे.

ही एक चांगली समस्या आहे, परंतु वेब ऍप्लिकेशनचे शेकडो हजारो वापरकर्त्यांपर्यंत काळजीपूर्वक स्केल कसे करावे याबद्दल वेबवर थोडी स्पष्ट माहिती आहे. सामान्यत: एकतर फायर सोल्यूशन्स किंवा बॉटलनेक सोल्यूशन्स (आणि बर्‍याचदा दोन्ही) असतात. म्हणून, लोक त्यांच्या हौशी प्रकल्पाला खरोखर गंभीर स्वरूप देण्यासाठी ऐवजी क्लिच तंत्र वापरतात.

चला माहिती फिल्टर करण्याचा प्रयत्न करू आणि मूलभूत सूत्र लिहू. आम्‍ही आमच्‍या नवीन फोटो शेअरिंग साइट ग्रामिन्‍स्‍टाला 1 ते 100 वापरकर्त्‍यांमध्‍ये चरणबद्ध करणार आहोत.

जेव्हा प्रेक्षक 10, 100, 1000, 10 आणि 000 लोकांपर्यंत वाढतात तेव्हा कोणत्या विशिष्ट कृती करणे आवश्यक आहे ते लिहूया.

1 वापरकर्ता: 1 मशीन

जवळपास प्रत्येक अॅप्लिकेशन, मग ते वेबसाइट असो किंवा मोबाइल अॅप्लिकेशन, त्यात तीन प्रमुख घटक असतात:

• API
• база данных
• क्लायंट (मोबाईल ऍप्लिकेशन स्वतः किंवा वेबसाइट)

डेटाबेस सतत डेटा संग्रहित करतो. API या डेटासाठी आणि त्याच्या आसपासच्या विनंत्या देते. क्लायंट वापरकर्त्याला डेटा पाठवतो.

मी या निष्कर्षाप्रत पोहोचलो की, आर्किटेक्चरल दृष्टिकोनातून, क्लायंट आणि एपीआय घटक पूर्णपणे विभक्त केले असल्यास अनुप्रयोग स्केलिंगबद्दल बोलणे खूप सोपे आहे.

जेव्हा आपण प्रथम एखादे अॅप्लिकेशन बनवण्यास सुरुवात करतो, तेव्हा तिन्ही घटक एकाच सर्व्हरवर चालवता येतात. काही मार्गांनी, हे आमच्या विकास वातावरणासारखे आहे: एक अभियंता डेटाबेस, API आणि क्लायंट एकाच मशीनवर चालवतो.

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

असे म्हटल्यास, साइटवर एकापेक्षा जास्त वापरकर्ते असतील तर, डेटाबेस स्तर समर्पित करणे जवळजवळ नेहमीच अर्थपूर्ण ठरते.

10 वापरकर्ते: डेटाबेस वेगळ्या स्तरावर हलवित आहे

Amazon RDS किंवा Digital Ocean Managed Database सारख्या व्यवस्थापित सेवांमध्ये डेटाबेसचे विभाजन केल्याने आम्हाला दीर्घकाळ चांगली सेवा मिळेल. हे एका मशीनवर किंवा EC2 उदाहरणावर सेल्फ-होस्टिंगपेक्षा थोडे अधिक महाग आहे, परंतु या सेवांसह तुम्हाला बॉक्समधून बरेच उपयुक्त विस्तार मिळतात जे भविष्यात उपयोगी पडतील: बहु-क्षेत्र बॅकअप, प्रतिकृती वाचा, स्वयंचलित बॅकअप, आणि अधिक.

सिस्टम आता असे दिसते:

100 वापरकर्ते: क्लायंटला वेगळ्या स्तरावर हलवणे

सुदैवाने, आमच्या पहिल्या वापरकर्त्यांना आमचा अनुप्रयोग खरोखर आवडला. रहदारी अधिक स्थिर होत आहे, म्हणून क्लायंटला वेगळ्या स्तरावर हलवण्याची वेळ आली आहे. याची नोंद घ्यावी वेगळे करणे स्केलेबल ऍप्लिकेशन तयार करण्यासाठी संस्था ही एक महत्त्वाची बाब आहे. सिस्टमच्या एका भागाला अधिक ट्रॅफिक मिळत असल्याने, विशिष्ट ट्रॅफिक पॅटर्नवर आधारित सेवा कशी मोजली जाते हे नियंत्रित करण्यासाठी आम्ही त्याचे विभाजन करू शकतो.

म्हणूनच मला क्लायंटचा API पेक्षा वेगळा विचार करायला आवडतो. हे एकाधिक प्लॅटफॉर्मसाठी विकसित करण्याबद्दल विचार करणे खूप सोपे करते: वेब, मोबाइल वेब, iOS, Android, डेस्कटॉप अनुप्रयोग, तृतीय-पक्ष सेवा इ. ते सर्व समान API वापरणारे फक्त क्लायंट आहेत.

उदाहरणार्थ, आता आमचे वापरकर्ते बहुतेकदा मोबाईल ऍप्लिकेशन सोडण्यास सांगतात. तुम्ही क्लायंट आणि API घटक वेगळे केल्यास, हे सोपे होईल.

अशी प्रणाली अशी दिसते:

1000 वापरकर्ते: लोड बॅलन्सर जोडा

गोष्टी दिसत आहेत. ग्रामिन्स्टा वापरकर्ते अधिकाधिक फोटो अपलोड करत आहेत. नोंदणीची संख्याही वाढत आहे. आमच्या एकमेव API सर्व्हरला सर्व ट्रॅफिक चालू ठेवण्यास कठीण जात आहे. अधिक लोह आवश्यक आहे!

लोड बॅलन्सर ही एक अतिशय शक्तिशाली संकल्पना आहे. मुख्य कल्पना अशी आहे की आम्ही API समोर लोड बॅलन्सर ठेवतो आणि ते वैयक्तिक सेवा उदाहरणांमध्ये रहदारी वितरीत करते. अशा प्रकारे आम्ही क्षैतिज स्केल करतो, म्हणजे आम्ही समान कोडसह अधिक सर्व्हर जोडतो, आम्ही प्रक्रिया करू शकणार्‍या विनंत्यांची संख्या वाढवतो.

आम्ही वेब क्लायंटच्या समोर आणि API समोर स्वतंत्र लोड बॅलन्सर ठेवणार आहोत. याचा अर्थ तुम्ही 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 आणि मेमरी वापर कमी ठेवला आहे (दहा API उदाहरणे चालू आहेत), परंतु आम्हाला विनंत्यांवर भरपूर कालबाह्यता मिळू लागली आहे... हे विलंब कुठून येत आहेत?

मेट्रिक्समध्ये थोडेसे खोदले असता, आम्ही पाहतो की डेटाबेस सर्व्हरवरील CPU 80-90% लोड केलेले आहे. आम्ही मर्यादेत आहोत.

डेटा लेयर स्केलिंग करणे हा कदाचित समीकरणाचा सर्वात कठीण भाग आहे. API सर्व्हर स्टेटलेस विनंत्या देतात, म्हणून आम्ही फक्त अधिक API उदाहरणे जोडतो. नाक बहुसंख्य डेटाबेस हे करू शकत नाहीत. आम्ही लोकप्रिय रिलेशनल डेटाबेस मॅनेजमेंट सिस्टम (PostgreSQL, MySQL, इ.) बद्दल बोलू.

कॅशिंग

आमच्या डेटाबेसची कार्यक्षमता वाढवण्याचा सर्वात सोपा मार्ग म्हणजे एक नवीन घटक सादर करणे: कॅशे लेयर. सर्वात सामान्य कॅशिंग पद्धत ही इन-मेमरी की-व्हॅल्यू रेकॉर्ड स्टोअर आहे, जसे की Redis किंवा Memcached. बर्‍याच क्लाउड्समध्ये या सेवांची व्यवस्थापित आवृत्ती असते: AWS वर Elasticache आणि Google Cloud वर Memorystore.

जेव्हा एखादी सेवा समान माहिती पुनर्प्राप्त करण्यासाठी डेटाबेसवर अनेक वारंवार कॉल करते तेव्हा कॅशे उपयुक्त ठरते. मूलत:, आम्ही डेटाबेसमध्ये फक्त एकदाच प्रवेश करतो, कॅशेमध्ये माहिती संचयित करतो आणि त्यास पुन्हा स्पर्श करत नाही.

उदाहरणार्थ, आमच्या ग्रामिन्स्टा सेवेमध्ये, प्रत्येक वेळी जेव्हा कोणी स्टार मोब्रिकच्या प्रोफाइल पेजवर जातो तेव्हा API सर्व्हर त्याच्या प्रोफाइलमधील माहितीसाठी डेटाबेसची चौकशी करतो. हे पुन्हा पुन्हा घडते. Mobrik ची प्रोफाइल माहिती प्रत्येक विनंतीनुसार बदलत नसल्यामुळे, कॅशिंगसाठी ती उत्कृष्ट आहे.

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

बर्‍याच कॅशिंग सेवांचा आणखी एक फायदा असा आहे की ते डेटाबेस सर्व्हरपेक्षा मोजणे सोपे आहे. रेडिसमध्ये अंगभूत रेडिस क्लस्टर मोड आहे. लोड बॅलन्सर प्रमाणेच1, हे तुम्हाला तुमची Redis कॅशे एकाधिक मशीनवर वितरित करण्यास अनुमती देते (आवश्यक असल्यास हजारो सर्व्हरवर).

जवळजवळ सर्व मोठ्या प्रमाणात अनुप्रयोग कॅशिंग वापरतात; हा वेगवान API चा पूर्णपणे अविभाज्य भाग आहे. जलद क्वेरी प्रक्रिया आणि अधिक उत्पादक कोड हे सर्व महत्त्वाचे आहेत, परंतु कॅशेशिवाय लाखो वापरकर्त्यांसाठी सेवा मोजणे जवळजवळ अशक्य आहे.

प्रतिकृती वाचा

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

आता आमची प्रणाली येथे आहे:

पुढील क्रिया

जसजसे अॅप्लिकेशनचे प्रमाण वाढत जाईल, तसतसे आम्ही सेवांना स्वतंत्रपणे मोजण्यासाठी वेगळे करणे सुरू ठेवू. उदाहरणार्थ, जर आम्ही वेबसॉकेट्स वापरण्यास सुरुवात केली, तर वेबसॉकेट्स प्रोसेसिंग कोड वेगळ्या सेवेमध्ये खेचण्यात अर्थ आहे. आम्ही ते आमच्या स्वतःच्या लोड बॅलन्सरच्या मागे नवीन उदाहरणांवर ठेवू शकतो, जे ओपन वेबसॉकेट कनेक्शनच्या आधारे आणि HTTP विनंत्यांची संख्या विचारात न घेता वर आणि कमी करू शकते.

आम्ही डेटाबेस स्तरावर निर्बंधांविरुद्ध लढत राहू. या टप्प्यावर डेटाबेस विभाजन आणि शार्डिंगचा अभ्यास करण्याची वेळ आली आहे. दोन्ही पध्दतींना अतिरिक्त ओव्हरहेड आवश्यक आहे, परंतु तुम्हाला डेटाबेस जवळजवळ अनिश्चित काळासाठी स्केल करण्याची अनुमती देते.

आम्हाला New Relic किंवा Datadog सारखी देखरेख आणि विश्लेषण सेवा देखील स्थापित करायची आहे. हे तुम्हाला धीमे क्वेरी ओळखण्यात आणि कुठे सुधारणा आवश्यक आहे हे समजून घेण्यात मदत करेल. जसजसे आम्ही मोजमाप करतो, तसतसे आम्ही अडथळे शोधणे आणि त्यांना दूर करणे यावर लक्ष केंद्रित करू इच्छितो—अनेकदा मागील विभागातील काही कल्पना वापरून.

स्त्रोत

हे पोस्ट त्यापैकी एकाने प्रेरित आहे उच्च स्केलेबिलिटी बद्दल माझ्या आवडत्या पोस्ट. मला प्रकल्पाच्या सुरुवातीच्या टप्प्यासाठी लेख थोडा अधिक विशिष्ट बनवायचा होता आणि एका विक्रेत्याकडून तो सोडवायचा होता. तुम्हाला या विषयात रस असेल तर जरूर वाचा.

तळटीप

1. बहुविध उदाहरणांमध्ये लोड वितरणाच्या बाबतीत समान असले तरी, रेडिस क्लस्टरची मूलभूत अंमलबजावणी लोड बॅलन्सरपेक्षा खूप वेगळी आहे. [परत]

स्त्रोत: www.habr.com