un — Geometry of Proxies & Origins

un

guest

1 / ?

back to lessons

नोड्स, एजेस, दिशाएं

एक अनुरोध को ग्राफ पर एक वॉक के रूप में

जिस किसी भी घटक का अनुरोध छूता है वह एक नोड होता है: क्लाइंट, DNS रेजोल्वर, CDN एज, रिवर्स प्रॉक्सी, बैकेंड रिप्लिका, डेटाबेस, कैश।

दो नोड्स के बीच किसी भी कनेक्शन को एक निर्देशित एज कहा जाता है: अनुरोध आगे प्रवाहित होते हैं, प्रतिक्रियाएँ वापस प्रवाहित होती हैं। अग्रिम की एज एक खुली TCP कनेक्शन का प्रतिनिधित्व करती है और इसके ऊपरी पर।

एक solitary अनुरोध एक पथ इस ग्राफ के माध्यम से होता है। प्रणाली द्वारा अनुरोध को उत्तर देने का कुल काम प्रत्येक नोड पर काम की कुल राशि के बराबर होता है, साथ ही प्रत्येक एज की लेटेंसी।

क्यों चिंता करें? एक बार जब आप ग्राफ खींच लेते हैं, तो कोड में दिखने वाले गुणों से अधिक गुण सामने आते हैं:

- हॉप काउंट: पथ में किन एजेस की संख्या। प्रत्येक हॉप लेटेंसी (नेटवर्क राउंड ट्रिप + नोड प्रोसेसिंग) जोड़ता है। कम हॉप्स = न्यूनतम लेटेंसी।

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

- आउट-डिग्री: किसी नोड के बाहर कितनी एजेस होती हैं। उच्च आउट-डिग्री का अर्थ है कि नोड कई नीचे के निर्भरता पर निर्भर करता है और कई तरह से विफल हो सकता है।

- कट वेर्टेक्स: एक ऐसा एकल नोड जिसकी हटाने से ग्राफ को एक साथ नहीं जोड़ा जा सकता। एक रिवर्स प्रॉक्सी जिसमें कोई सहयोगी नहीं होता है एक कट वेर्टेक्स होता है; इसके हटाने से इसके मूल स्रोतों के लिए पहुंच समाप्त हो जाती है।

Request as path through directed graph: client, proxy, backend, database

निम्नलिखित के लिए अनुरोध ग्राफ खींचें (या टेक्स्ट में विवरण दें): क्लाइंट ब्राउज़र -> CDN एज -> रिवर्स प्रॉक्सी -> बैकेंड रिप्लिका -> डेटाबेस। हॉप काउंट करें। कट वेर्टेक्स की पहचान करें। कट वेर्टेक्स की क्रम में बहुत सारे होने की स्थिति में एक संचालन परिणाम का अनुमान लगाएं।

ट्रैफिक का स्थानीयकरण

फैन-इन = संलयन

इन-डिग्री ऑफ एक नोड = उसमें अंकगत जोड़ें। एक अनुरोध ग्राफ़ में, इन-डिग्री = उसे अनुरोध करते हुए स्रोतों की संख्या।

फैन-इन पैटर्न: कई ग्राहक -> एक CDN; कई CDN एजेस -> कुछ मूल प्रॉक्सीज; कई प्रॉक्सीज -> कम बैकेंड रिप्लिका; कई बैकेंड -> एक ही डेटाबेस।

संलयन महत्वपूर्ण होता है क्योंकि सबसे अधिक इन-डिग्री नोड देखता है सबसे अधिक समग्र लोड। ग्राफ़ की पूरी सистем में हर सक्रिय अनुरोध से भी, यदि कोई भी उपयोगकर्ता बहुत अधिक नहीं जनरेट करता है, डीबी के अंत में चेन में देखें।

फैन-आउट = निर्भरता

आउट-डिग्री ऑफ एक नोड = उसमें बाहर की ओर जाने वाली जोड़ें। उच्च आउट-डिग्री का अर्थ है कई नीचे की निर्भरता।

एक बैकेंड जो डेटाबेस को कॉल करता है, दो कैश, तीन वाहवापी एपीआई, और एक क्वी है, उसकी आउट-डिग्री 7 होती है। इसकी सफलता की संभावना का लगभग प्रत्येक डाउनस्ट्रीम की सफलता की संभावना के गुणनफल होता है (यदि सभी के लिए सफल प्रतिक्रिया के लिए आवश्यक हैं)।

0.999 ^ 7 ≈ 0.993: एक बैकेंड जिसमें प्रत्येक 7 डाउनस्ट्रीम को 99.9% की विश्वसनीयता के साथ स्वतंत्र रूप से कॉल किया जाता है, यह स्वयं के लिए ~99.3% विश्वसनीयता ही प्राप्त कर सकता है, यहां तक कि अपने आप में कोई त्रुटि नहीं।

आउट-डिग्री को कम करें: डाउनस्ट्रीम के परिणामों को कैश करें, गैर-आवश्यक डाउनस्ट्रीम को वैकल्पिक बनाएं (सौम्य अवमूल्यन), जो संभव हो सके उसे पैरलल करें।

असimetri

फैन-इन लोड को संलयन करता है; फैन-आउट जोखिम को गुणा करता है। एक अच्छी तरह से आकार दिया गया ग्राफ़ दोनों को सर्वोत्तम प्रभाव के नोड पर कम करता है।

डेटाबेस (सबसे अधिक फैन-इन): कैशिंग को बढ़ाएं ताकि लोड कम हो सके। पढ़ने योग्य रिप्लिका को डेटाबेस के लोड को फैन-इन को कई नोड्स पर फैला सकते हैं।

ऑर्केस्ट्रेटर सेवा (सबसे अधिक फैन-आउट): पर निर्भरता के लिए सर्किट-ब्रेकर, सौम्य अवमूल्यन, बुलहेड्स।

एक बैकेंड रिप्लिका 4 डाउनस्ट्रीम सेवाएँ कॉल करती है, प्रत्येक को 99.95% उपलब्धता के साथ स्वतंत्र रूप से। (1) यदि सभी 4 कॉलों के लिए सफल प्रतिक्रिया के लिए आवश्यक है, तो बैकेंड की उपलब्धता का उच्चतम सीमा क्या होती है? (2) यदि 2 में से 4 डाउनस्ट्रीम को वैकल्पिक बनाया जाता है (अवAILABLE के समय कैश्ड फॉलबैक्स से बदल दिया जाता है), तो सीमा क्या होती है?

एक प्रवेशित नोड फ्लेक्सिबिलिटी खरीदता है

Indirection = Adding an Intermediate Node

बिना प्रॉक्सी के, ग्राफ होता है: client -> backend। client को backend के पते की जानकारी होती है। backend को shift करने के लिए client को update करना पड़ता है (DNS या configuration के माध्यम से)। यह एक tight binding है।

प्रॉक्सी के साथ, ग्राफ इस प्रकार बन जाता है: client -> proxy -> backend। client को सिर्फ प्रॉक्सी की जानकारी होती है। backend को shift करने के लिए प्रॉक्सी के upstream configuration को update करना पड़ता है, न कि client को।

ग्राफ़ संचालन: मौजूदा एज के साथ एक नोड इंसर्ट करें। नई एज client -> proxy स्थिर है; नई एज proxy -> backend अब टीम के पास है।

गणितीय पढ़ने: indirection एक लेयर जोड़ता है जो उप-सिस्टम के परिवर्तन को डाउन-स्ट्रीम से अलग करता है। प्रत्येक लेयर की एज स्वतंत्र रूप से rewire कर सकती है।

Indirection का लागत

प्रत्येक लेयर जोड़ती है:

- एक हॉप की लेटेंसी (client से proxy तक की एज)

- पथ में एक और cut vertex (प्रॉक्सी खुद)

- एक और स्थान जहाँ मिसकॉन्फ़िगरेशन हो सकता है

लाभ (rewire, scale, shield, terminate TLS, distribute load) आमतौर पर किसी भी गैर-मामूली सिस्टम के लिए indirection के लागत (rewire, scale, shield, terminate TLS, distribute load) से अधिक होते हैं। लेकिन एक सीमा है: प्रत्येक indirection लेयर एक और हॉप जोड़ती है और एक और SPOF प्रतिस्थापन के उम्मीदवार बनाती है।

लोकप्रिय नियम: किसी भी समस्या को indirection की एक और लेयर जोड़कर हल किया जा सकता है (सिवाय उस समस्या के जो बहुत सारी indirection की लेयर्स होने की समस्या है।)

A team adds a CDN in front of an existing reverse proxy. The path goes from `client -> proxy -> backend` (2 hops) to `client -> CDN -> proxy -> backend` (3 hops). Name two benefits of the indirection (graph-theoretic terms welcome) & two costs.

एक ग्राफ के रूप में एक आर्किटेक्चर को पढ़ें,

Synthesis

अब आप एक सिस्टम आर्किटेक्चर को एक ग्राफ के रूप में पढ़ सकते हैं: हॉप काउंट करना, cut vertices की पहचान करना, फैन-इन की सांद्रता मापना, फैन-आउट से उपलब्धता के छत को compute करना, और indirection के व्यापारिक विकल्पों की evaluation करना।

सभी चार को लागू करें।

एक नई सेवा का यह आर्किटेक्चर है: क्लाइंट्स -> CDN -> रिवर्स प्रॉक्सी (2 प्रतिलिपियाँ) -> बैकएंड टियर (8 प्रतिलिपियाँ) -> { प्राथमिक डीबी, क्याश क्लस्टर (3 नोड्स), बाहरी API }.

विश्लेषण करें: (1) एक सिंगल रिक्वेस्ट पाथ पर मैक्सिमम हॉप काउंट क्या है, (2) कौन सा टियर फैन-इन में सबसे ज्यादा होता है (और इसका scaling पर क्या संकेत होता है), (3) यदि DB 99.95%, cache 99.95%, और external API 99.9% सभी आवश्यक हैं, तो backend की उपलब्धता के छत क्या होता है, और (4) यदि एक नोड को हटा दिया जाए, तो सबसे ज्यादा यूजर्स को disconnect क्या होता है,

साथी नोट्स

यह ज्यामिति-of पाठ Proxies & Origins मुख्य पाठ को निर्देशाकुंजी विश्लेषण के रूप में पुनर्स्थापित करता है।

इस कोर्स की अगली साथी, geometry_of_stateless_horizontal_scaling, मुख्य स्केलिंग पाठ से रिप्लिका गणित लेती है और क्यू-इन क्राइव, लिटिल कानून और 80% उपयोगगति की ज्यामितीय की गणना करती है।

बहुत अच्छा किया।