दो तरीके से अधिक भार ढोएं
स्वागत
जब एक सेवा लोड के तहत काम करना शुरू करती है, तो एक ऑपरेटर के सामने एक विकल्प आता है। मौजूदा मशीन को बड़ा बनाएं (ज्यादा CPU, ज्यादा RAM, तेज़ डिस्क)। या फिर उसी काम को करने वाली मशीनों को जोड़ें, जिन्होंने भी उसी काम को किया हो।
पहला मार्ग वर्टिकल स्केलिंग (स्केल अप) द्वारा जाता है। जबकि दूसरा हॉरिजोंटल स्केलिंग (स्केल आउट) द्वारा जाता है।
इस पाठशाला में सीखा जाता है कि अधिकांश आधुनिक वेब आर्किटेक्चर क्यों हॉरिजोंटल का चयन करते हैं और किस प्रॉपर्टी के कारण उस चयन को संभव बनाता है। जवाब एक शब्द में छिपा होता है: स्टेट।
इससे क्या होगा:
- वर्टिकल और हॉरिजोंटल स्केलिंग की लागत कривियां और जहां प्रत्येक को समझ में लेना चाहिए
- 'स्टेटफुल' और 'स्टेटलेस' का पрак्टिस में क्या मतलब होता है, और किसे सस्ती में कई गुना बढ़ाया जा सकता है
- एक रिप्लिका फ़्लीट को अनुमानित और सर्ज लोड के तहत साइज़ करने की गणित
- एक टियर को क्यों नहीं गिरने देना (यह कभी नहीं गिरता है) और उसे स्केल करने वाले लेयर्स से बाहर निकालने का तरीका
- जहां स्टेट को रखना होगा (यह कभी नहीं जाता है) और उसे स्केल करने वाले लेयर्स से बाहर निकालने का तरीका
हॉरिजोंटल का जीत क्यों होता है एक सीमा के बाद
वर्टिकल स्केलिंग: एक बड़ा बॉक्स
लाभ: आसान। कोई कोड परिवर्तन नहीं। कोई संगति नहीं। वही प्रक्रिया अब ज्यादा CPU के साथ है।
हानि: छत। व्यापार में उपलब्ध सबसे बडी VM की सीमित RAM और कोर होते हैं। उसे पार करते ही, पैसा और अधिक मंजिल के लिए नहीं खरीद सकते। लागत सुपरलाइनरी रूप से उस वेंडर के ऑफरिंग के स्वीट स्पॉट के बाद बढ़ती हैं। एक ही मशीन की विफलता पूरी सेवा को नीचे ले जाती है।
हॉरिजोंटल स्केलिंग: कई छोटे बॉक्स
लाभ: कोई छत नहीं (सीमा तक आपकी पैसा खर्च करने और मशीनों को समन्वयित करने की इच्छा होती है। क्षमता रिप्लिका की संख्या के साथ लाइनरी रूप से बढ़ती है, पूर्वानुमेय रूप से। एक ही रिप्लिका की विफलता क्षमता का 1/N, नहीं 100% को हटा देती है।
हानि: काम को समर्थन करना होगा। कुछ कार्यलोड (एक बड़े सिंगल डेटाबेस, एक स्टेटफुल गेम सर्वर जो लाइव सेशन को रखता है) हॉरिजोंटल स्केलिंग का विरोध करते हैं। समन्वय और लोड वितरण संचालन के चिंता का मामला बन जाते हैं।
दोलन क्रॉसओवर: किसी भी सेवा को किसी भी एक मशीन के विफल होने पर जीवित रहना होगा जो कम से कम दो मशीनों पर चलना चाहिए। जब आप दो चुन लेते हैं, तब आप हॉरिजॉन्टल स्केलिंग को चुन चुके होते हैं। वहाँ से, प्रश्न 'हम करें?' नहीं है, बल्कि 'हम अगले रिप्लिका को कितनी सस्ती तरह से जोड़ सकते हैं?'
मुख्य सक्षम कारक: मशीन पर खुद को रखने वाली किसी भी अनुरोध राज्य की कमी है। फिर किसी भी रिप्लिका को किसी भी अनुरोध का उत्तर दे सकता है, और एक रिप्लिका जोड़ने से क्षमता बढ़ाता है लेकिन कोई संयुक्तीकरण नहीं।
वस्त्रावस्था और राज्यहीन वस्त्रावस्था की वास्तविकता
राज्य कभी गायब नहीं होता, वह सिर्फ स्थान बदलता है।
राज्यसंगत घटक: जिसकी हानि व्यवहार को बदल देती है। उपयोगकर्ता खातों के साथ एक डेटाबेस। सत्र टोकन के साथ एक कैश। एक वर्कर जो एक विशेष उपयोगकर्ता को एक विशेष स्ट्रीमिंग कनेक्शन को बांधता है।
राज्यहीन घटक: जिसकी हानि का कोई महत्व नहीं होता। एक वेब तीर कि एक अनुरोध पढ़ता है, एक डेटाबेस का प्रयास करता है, और एक उत्तर लिखता है। प्रत्येक अनुरोध स्वतंत्र रूप से खड़ा होता है; तीर को बीच में कुछ नहीं याद रहता है।
मुख्य अहसास: राज्य एक प्रणाली से दूसरे में कभी गायब नहीं होता। वह सिर्फ एक स्तर को डिज़ाइन किया गया होता है जो इसे रखने के लिए बनाया गया है (एक डेटाबेस, एक Redis क्लस्टर, एक वस्तु संग्रहणीय)। जो स्तर ट्रैफ़िक का सामना करते हैं, वे राज्यहीन हो सकते हैं और राज्यहीन स्तर हॉरिजॉन्टली स्केल हो सकते हैं क्योंकि किसी भी रिप्लिका को किसी भी अनुरोध का उत्तर देने की अनुमति है।
प्रैक्टिकल टेस्ट: अगर इस तीर में एक प्रक्रिया को अनियमित रूप से मार दिया गया और इसे फिर से शुरू किया गया, तो किसी उपयोगकर्ता को गलत उत्तर का अनुभव होगा या सत्र की हानि होगी? अगर हाँ, तो यह राज्य रखता है। अगर नहीं, तो यह राज्य नहीं रखता है।
उदाहरण
- एक पायथन वेब प्रक्रिया जो अनुरोध पढ़ती है, पोस्टग्रेस का प्रयास करती है, जेएसओएन वापस करती है: राज्यहीन। राज्य पोस्टग्रेस में रहता है।
- एक पायथन वेब प्रक्रिया जो उपयोगकर्ता के दुकान कार्ट को स्थानीय स्मृति में रखती है: राज्यसंगत। प्रक्रिया को मार देने पर कार्ट खो जाते हैं।
- एक वेबसोकेट सर्वर जो चैट उपयोगकर्ताओं के साथ खुले कनेक्शन को खोल रखता है: राज्यसंगत कनेक्शन के संदर्भ में। प्रक्रिया को मार देने पर कनेक्शन खो जाते हैं; ग्राहकों को पुनः कनेक्ट करना होगा। अक्सर इन्हें हॉरिजॉन्टल स्केलिंग के साथ सावधानी के साथ किया जा सकता है (चिपचिपा सत्र, संगत हैशिंग)।
- एक Redis कैश फ्रंटिंग पोस्टग्रेस: कैश कंटेंट के लिए स्टेटफुल, लेकिन स्वीकार्य यदि कैश मिस सेअच्छा होता है। एक रिप्लिका का विफल होना कैश मिस का मतलब है, नहीं डेटा लॉस।
वертиकल स्केलिंग डिज़ाइन करना = स्केलिंग की आवश्यकता वाले लेयर से स्टेट को बाहर धकेलना।
एक संदिग्ध टियर का ऑडिट
एक टीम 6 पीछे के बैकएंड VMs पर एक सिफारिश API चलाती है। आवेदन: एक उपयोगकर्ता आईडी को अनुरोध से पढ़ता है, पोस्टग्रेस से उपयोगकर्ता की हाल की गतिविधि को निकालता है, स्कोरिंग एल्गोरिदम को चलाता है, और सिफारिश के सूची को वापस करता है। दो गैर-मानक व्यवहार:
- आवेदन ने 'हाल की उपयोगकर्ता गतिविधि' को प्रक्रिया मेमोरी में कैश करता है, जो प्रथम अनुरोध के लिए आउटपुट में आबाद होता है, और बाद में अनुरोधों के लिए पुनरावृत्ति करता है।
- आवेदन में चिपकाने वाले सेशन्स का उपयोग किया जाता है: एक बार जब एक उपयोगकर्ता वीएम # 3 पर आता है, फिर उनके सभी बाद के अनुरोध वीएम # 3 (प्रॉक्सी को कुकी पर चिपकाने के लिए सेट किया गया है) पर जाते हैं।
दублиकार का नियम
सरल क्षमता формула
एक बार जब एक टियर स्टेटलेस बन जाता है, तो इसके आकार को आकार देना गणित हो जाता है। आपको स्थायी लोड के लिए पर्याप्त दублиकार की आवश्यकता होती है ताकि स्थायी लोड आ रहा है और जा रहा है वही दर पर, साथ में स्प्रग के लिए भी स्थान हो।
सूत्र:
दублиकार = ⌈ (पीक_लोड × स्प्रग_फैक्टर) / प्रति_दублиकार_क्षमता ⌉ + हेडरूम
जहां:
- पीक_लोड: आपको सामान्य संचालन में अपेक्षित अधिकतम स्थिर अनुरोध/सेकंड
- स्प्रग_फैक्टर: एक ब्रीफ बोर्स के ऊपर पीक के मुफ्त गुणाकार (सामान्य रूप से 1.5x से 2x के लिए पूर्वानुमेय ट्रैफ़िक, 3x या अधिक वायरल / अनप्रेडिक्टेबल के लिए)
- प्रति_दублиकार_क्षमता: एक दублиकार को स्वीकार्य विलंब और उपयोग (सामान्य रूप से 70% CPU, नहीं संतुलन) पर एक अनुरोध/सेकंड का प्रबंधन करता है।
- हेडरूम: अतिरिक्त दублиकार ताकि कुछ दублиकार के विफल होने पर टियर को ध्वस्त नहीं कर दिया जाए (सामान्य रूप से छोटे फ़्लीट के लिए 1-2 दублиकार, बड़े के लिए 10-20%)
कामयाब उदाहरण: एक बैकएंड 100 req/s को 70% CPU प्रति प्रतिलिपि संभालता है। शिखर भार 600 req/s है। आप कुछ बार में 2x उछाल की उम्मीद करते हैं। आप 2 प्रतिलिपि विफलताओं को सहन करना चाहते हैं।
replicas = ⌈ (600 × 2) / 100 ⌉ + 2 = 12 + 2 = 14 प्रतिलिपियाँ
80% का नियम
प्रति-प्रतिलिपि क्षमता नहीं संतृप्ति बिंदु है। 100% के बजाय 70-80% CPU के उपयोग के आधार पर क्षमता मापें।
80% उपयोग के बारे में अधिक, गिनती के झुंड तेजी से चढ़ते हैं: 60% उपयोग में एक कतार जो 10 मिलीसेकंड में चलती है, 90% उपयोग में 80 मिलीसेकंड में चलती है। लैटेंसी, नहीं होगा प्रवाह, पहले टूटता है। (संगत पाठ 'geometry_of_stateless_horizontal_scaling' इस जोड़ की गणितीय व्याख्या करता है।)
ऑटोस्केलिंग vs स्टैटिक प्रावधान
स्टैटिक: पीक × उछाल के लिए प्रावधान करें, ऑफ-पीक पर कम उपयोग के साथ लागत स्वीकार करें।
ऑटोस्केलिंग: एक नियंत्रक ट्रैफ़िक पर आधारित उपयोग, लक्ष्य लेटेंसी, या कतार गहराई को देखते हुए प्रतिलिपियों को जोड़ता और हटाता है।
ऑटोस्केलिंग की शर्त: ठंडा शुरुआत समय मायने रखता है। यदि नई प्रतिलिपि 2 मिनट का समय लेती है तो ऑटोस्केलिंग 30-सेकंड के उछाल का जवाब नहीं दे सकता। पूर्ण विकसित ऑटोस्केलिंग नीचे स्केल-अप संकेत के ठीक नीचे एक गरम पूल ऑफ प्री-प्रावधान प्रतिलिपियाँ रखता है।
एक नई सेवा के लॉन्च के लिए एक वाहवाही साइज़ करें
आपकी टीम को वीडियो मेटाडेटा एपीआई लॉन्च करने का प्लान है। बेंचमार्कों के अनुसार, एक प्रतिलिपि 250 req/s को 70% CPU और 50 ms p99 लेटेंसी पर संभालती है। मार्केटिंग का अनुमान है कि पीक लोड 4,000 req/s के दौरान प्राइम-टाइम घंटों में होगा। एक प्लानेड प्रमोशनल इवेंट को 3x पीक के लिए उछाल मिल सकता है। आप 3 सिमुल्टेनियस प्रतिलिपि विफलताओं को सहन करना चाहते हैं, और परीक्षार्थियों पर 80% उपयोग के बिना।
ठंडा शुरू, धीरे निकास, और अन्य वास्तविक किनार
वास्तविक फ्लीट में वास्तविक किनार होते हैं
फार्मूला का धारणा है कि प्रतिलिपियाँ एक साथ तत्काल, ट्रैफ़िक को तत्काल स्वीकार करती हैं, और ट्रैफ़िक को तत्काल छोड़ देती हैं। कोई भी इनमें से किसी का भी लागू नहीं होता है प्रोडक्शन में।
कोल्ड स्टार्ट: एक नई रिप्लिका को OS को बूट करने, प्रक्रिया शुरू करने, कॉन्फ़िगरेशन लोड करने, कैल्श को गर्म करने और हेल्थ चेक पास करने की आवश्यकता होती है। कंटेनर रीस्टार्ट के लिए 5 सेकंड (5 मिनट) से लेकर पूरी VM बूट + इमेज पुल के लिए 5 मिनट तक का समय लगता है। ऑटोस्केलिंग को इस विलंब के समय से कम अवधि के बurst का जवाब नहीं दे सकता।
स्लो ड्रेन: एक रिप्लिका को पूल से हटाने के लिए समय चाहिए ताकि सक्रिय अनुरोधों को पूरा करने के लिए समय मिल सके और फिर टर्मिनेट हो जाए। अन्यथा उपयोगकर्ता ट्रंकेटेड रिस्पोंस देखते हैं। रिवर्स प्रॉक्सीज़ ड्रेन (नई अनुरोधों को स्वीकार करना बंद करें, सक्रिय ones को पूरा करें) का समर्थन करते हैं, लेकिन यह सेकंड से लेकर मिनट तक का समय लेता है।
वार्म पूल: प्रोडक्शन फ़्लीट्स एक पूल ऑफ प्री-प्रोवाइडेड लेकिन निष्क्रिय रिप्लिका को ट्रैफ़िक लेने के लिए तैयार रखते हैं। एक छोटे स्थिर लागत का विनिमय करते हैं, तेज़ स्प्रे प्रतिक्रिया।
कनेक्शन ड्रेनिंग vs इमीडिएट किल: स्मूथ शटडाउन मायने रखता है। एक SIGTERM कि ड्रेन को ट्रिगर करता है लंबा समय लेता है बजाय SIGKILL के लेकिन उपयोगकर्ता अनुरोधों को तोड़ नहीं देता।
हेल्थ चेक विंडो: एक रिप्लिका जो बस शुरू हुई है, उसके पहले डेटाबेस कनेक्शन पूल गर्म होने से पहले हेल्थ चेक को पास कर सकती है; प्रॉक्सी फिर वास्तविक ट्रैफ़िक भेजता है और पहले दो दर्जन अनुरोध धीरे होते हैं। हेल्थ चेक्स को वास्तविक पथ की जाँच करने के लिए एडजस्ट करें।
स्टिकीनेस क्रीप: तकनीकी रूप से निष्क्रिय तीरों में समय के साथ स्टिकीनेस प्राप्त होती है (सीडीएन कैश, DNS रेज़ल्वर कैश, कनेक्शन पूल)। 'समान रिप्लिका' के बारे में संदेह करें जो फिर भी अलग-अलग तरह से व्यवहार करते हैं।
वार्म पूल या रिएक्टिव ऑटोस्केलिंग?
आपकी वीडियो मेटाडेटा API (पिछले प्रश्न से एक ही जो साइज़ 51 रिप्लिका के लिए है जो स्थिर पीक + स्प्रे के लिए है) को 30 सेकंड के लिए 5x सामान्य लोड का अनुभव होता है जब किसी नई वायरल वीडियो को अपलोड किया जाता है। वर्तमान में, ऑटोस्केलिंग को कोल्ड स्टार्ट (इमेज पुल + वार्मअप) से 90 सेकंड का समय लगता है। 90-सेकंड के फासले में, लैटेंसी काफी तेज़ी से बढ़ती है और कुछ अनुरोध टाइम-आउट हो जाते हैं।
कंस्ट्रक्टेड स्टेटलेस टियर का डिज़ाइन करें
सिंथेसिस
आप ने किसी छोटे संकेत के बाद वERTICAL स्केलिंग के लाभों को सीखा, प्रैक्टिस में राजद्रोह का अर्थ जाना, एक फ्लीट को साइज़ करने के लिए अपेक्षित और सर्ज लोड का विचार, और किन्हीं दो विफलता के साथ हORIZONTAL स्केलिंग के किन्हीं किन्हीं कोनों पर टिकाव के बारे में जाना।
सभी चार को लागू करें।
डिज़ाइन करें feed.example.com के लिए बैकएंड टियर, एक सोशल फीड API। प्रतिबंध: प्रति रिप्लिका क्षमता 200 req/s at 70% CPU; अपेक्षित शीर्ष लोड 1500 req/s; सर्ज फैक्टर 2.5x (कुछ समय में ट्रेंडिंग स्टोरीज); 2 साथ ही रिप्लिका विफलता का सामन करें; ठंडे शुरुआती समय 60 सेकंड; बुर्स्ट 45 सेकंड तक चल सकते हैं; बजट में कुछ निरस्त क्षमता की अनुमति है, लेकिन 2.5x स्थायी प्रावधान नहीं।
यह पाठ्यक्रम किस दिशा में जाता है
यह पाठ्यक्रम किस दिशा में जाता है
अब आपके पास एक काम कर रहा है मानचित्र है: एक राजद्रोह टियर क्यों स्केल होता है, इसे कैसे साइज़ किया जाता है, इसके किन्हीं कोनों पर क्या टूट सकता है, और जब आप इसे बढ़ने वाले परत को बाहर निकालते हैं तब राजद्रोह को कहाँ जाना चाहिए।
इस पाठ्यक्रम में अगली पाठ (cs_distsys_ingress_egress_separation) एक और अधिक सूक्ष्म समस्या को संबोधित करता है: एक पूरी तरह से साइज की गई राजद्रोह टियर भी अप्रत्याशित रूप से विफल हो सकती है जब आ रही और जा रही ट्रैफिक एक ही नेटवर्क पाथ पर साझा करती है। प्रॉक्सी को स्वयं के साथ जुड़ने का क्लासिक उदाहरण होता है; इस समस्या का समाधान दो अलग-अलग जिम्मेदारियों वाले टायरों में एक परत को विभाजित करके किया जाता है।
साथी पाठ: geometry_of_stateless_horizontal_scaling दोहराव वाली曲线, रिप्लिका फ्लीट पर लिटिल कानून के लागू होने के लिए क्या होता है, और 80% उपयोगिता की घुटने के भौगोलिक अर्थ को निकालता है।
अच्छा काम किया। आगे बढ़ें।