दालचीनी को खोलना-उबेर में एक नया लचीलापन दृष्टिकोण

पिछले साल, उबर इंजीनियरिंग टीम ने अपने माइक्रोसर्विस आर्किटेक्चर के लिए डिज़ाइन किए गए नए लोड-शेडिंग तंत्र पर एक लेख प्रकाशित किया था ।

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

शुरू से ही मुझे इस समाधान के निर्माण के लिए इस्तेमाल किए गए सदियों पुराने सिद्धांतों का संदर्भ मिला। यह कुछ ऐसा है जो मुझे पसंद है - विभिन्न क्षेत्रों से अवधारणाओं/विचारों को उधार लेना और एक अलग क्षेत्र में किसी समस्या को हल करने के लिए उन्हें अपनाना।

यदि सिस्टम लचीलेपन और स्थिरता में आपकी रुचि है, तो मैं उत्कृष्ट पुस्तक 'रिलीज़ इट!' को भी पढ़ने की सलाह देता हूँ। माइकल टी. न्यागार्ड द्वारा।

यह एक पुरानी लेकिन अच्छी पुस्तक है - एक ऐसी पुस्तक जो लचीली और स्थिर सॉफ्टवेयर प्रणालियों के निर्माण के लिए रणनीतियों, पैटर्न और व्यावहारिक मार्गदर्शन पर प्रकाश डालती है, और इस बात पर जोर देती है कि विफलताओं को प्रभावी ढंग से कैसे संभालना है।

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

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

यह प्रसिद्ध पीआईडी नियंत्रक क्या है और इसका उपयोग कैसे किया जाता है?

यदि आप इस सदियों पुरानी अवधारणा के बारे में अधिक जानकारी चाहते हैं, तो विकिपीडिया पर जाएँ।

अब, लेख पर वापस आते हैं। पीआईडी का मतलब आनुपातिक, अभिन्न और व्युत्पन्न है। उनके मामले में, वे तीन घटकों (या उपायों) के आधार पर किसी सेवा (इनपुट अनुरोध) के स्वास्थ्य की निगरानी के लिए पीआईडी नियंत्रक के रूप में ज्ञात एक घटक का उपयोग करते हैं।

आनुपातिक

शब्द "आनुपातिक" इंगित करता है कि की गई कार्रवाई वर्तमान त्रुटि के समानुपाती है। सरल शब्दों में, इसका मतलब यह है कि लागू किया गया सुधार वांछित स्थिति और वास्तविक स्थिति के बीच अंतर के सीधे आनुपातिक है। यदि त्रुटि बड़ी है, तो सुधारात्मक कार्रवाई आनुपातिक रूप से बड़ी है।

जब एक समापन बिंदु अतिभारित होता है, तो पृष्ठभूमि गोरोइन प्राथमिकता कतार में अनुरोधों के प्रवाह और बहिर्वाह की निगरानी करना शुरू कर देता है।

तो, लोड शेडर में आनुपातिक (पी) घटक इस आधार पर शेडिंग दर को समायोजित करता है कि वर्तमान कतार का आकार लक्ष्य या वांछित कतार के आकार से कितना दूर है। यदि कतार वांछित से बड़ी है, तो अधिक शेडिंग होती है; यदि यह छोटा है, तो बहाव कम हो जाता है।

इसके बारे में मेरी समझ यही है।

अभिन्न

पीआईडी नियंत्रक का काम कतारबद्ध अनुरोधों की संख्या को कम करना है, जबकि ऑटो-ट्यूनर का काम प्रतिक्रिया विलंबता (बहुत अधिक) का त्याग किए बिना, सेवा के थ्रूपुट को अधिकतम करना है।

हालांकि पाठ में कतार के आकार के संदर्भ में स्पष्ट रूप से "इंटीग्रल (आई)" का उल्लेख नहीं है, लेकिन यह इंगित करता है कि पीआईडी नियंत्रक की भूमिका कतारबद्ध अनुरोधों की संख्या को कम करना है। कतारबद्ध अनुरोधों का न्यूनतमकरण समय के साथ संचित त्रुटियों को संबोधित करने के इंटीग्रल घटक के लक्ष्य के साथ संरेखित होता है।

यह निर्धारित करने के लिए कि कोई समापन बिंदु अतिभारित है या नहीं, हम पिछली बार अनुरोध कतार खाली होने का ट्रैक रखते हैं, और यदि यह अंतिम 10 सेकंड में खाली नहीं हुआ है तो हम समापन बिंदु को अतिभारित मानते हैं (फेसबुक से प्रेरित)।

लोड शेडर में, यह अनुरोध कतार के ऐतिहासिक व्यवहार से संबंधित निर्णयों से जुड़ा हो सकता है, जैसे कि आखिरी बार खाली होने के बाद का समय।

ईमानदारी से कहूं तो यह मेरे लिए पूरी तरह स्पष्ट नहीं है। यह थोड़ा निराशाजनक है, मुझे कहना होगा। हालाँकि वे सदियों पुराने तंत्र का लाभ उठाने का उल्लेख करते हैं, लेकिन यह मददगार होता अगर वे स्पष्ट रूप से बताते कि कौन सा हिस्सा किससे मेल खाता है या यह कैसे संचालित होता है। मैं उनके अद्भुत लेख का मूल्य कम नहीं करना चाहता। यहाँ तो बस यही मेरा बड़बोलापन है... आख़िरकार, मैं फ़्रेंच हूँ... ;)

यौगिक

मुझे लगता है कि इसे पहचानना आसान है।

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

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

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

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

इंटीग्रल और डेरिवेटिव दोनों घटक समय के साथ अनुरोध कतार के व्यवहार की निगरानी में शामिल हैं

• अभिन्न अंग

अधिभार निर्धारित करने के संदर्भ में, अभिन्न घटक यह ट्रैक करने से जुड़ा हो सकता है कि अनुरोध कतार कितनी देर तक गैर-खाली स्थिति में रही है। यह समय के साथ त्रुटि संकेत के अभिन्न अंग को जमा करने के विचार से संरेखित होता है।

"अभिन्न - यह इस पर आधारित है कि अनुरोध कतार में कितने समय से है..."

• व्युत्पन्न घटक

दूसरी ओर, व्युत्पन्न घटक, परिवर्तन की दर से संबंधित है। यह इस बात पर प्रतिक्रिया करता है कि अनुरोध कतार की स्थिति कितनी तेज़ी से बदल रही है।

"व्युत्पन्न - कतार कितनी तेजी से भर रही है इसके आधार पर अस्वीकृति..."

जबकि इंटीग्रल और व्युत्पन्न दोनों पहलुओं में अनुरोध कतार का अवलोकन शामिल है, वे इसके व्यवहार के विभिन्न पहलुओं पर ध्यान केंद्रित करते हैं

इंटीग्रल घटक गैर-रिक्त स्थिति की अवधि पर जोर देता है, जबकि व्युत्पन्न घटक उस दर पर विचार करता है जिस पर कतार बदल रही है।

खेल के अंत में, वे अनुरोध के लिए कार्रवाई की दिशा निर्धारित करने के लिए इन तीन उपायों का उपयोग करते हैं।

मेरा प्रश्न यह है कि वे इन तीन घटकों को कैसे जोड़ते हैं, यदि ऐसा है भी। मुझे यह समझने की उत्सुकता है कि वे उनकी निगरानी कैसे करते हैं।

फिर भी, मुझे लगता है कि मुझे यह विचार मिल गया है...

इन तीन घटकों के आधार पर वे किस अनुरोध को स्थगित करने का निर्णय लेते हैं और कैसे?

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

पहला विचार जो मन में आता है वह यह है कि यह सर्विस मेश आर्किटेक्चर में सहजता से एकीकृत हो जाएगा।

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

यहां कुछ अतिरिक्त विचार दिए गए हैं:

• क्या ऐसी संभावना है कि, समय के साथ, प्रासंगिक बदलावों के आधार पर अनुरोध प्राथमिकता कम हो सकती है या बदल सकती है, जैसे कि अनियोजित उच्च-प्राथमिकता वाली बैच प्रक्रिया या कार्य की शुरुआत, या समयक्षेत्र/क्षेत्र स्तर पर परिवर्तन?

• यह दृष्टिकोण अन्य 'मानक' लचीलापन प्रबंधन दृष्टिकोण/पैटर्न, जैसे सर्किट ब्रेकर, टाइमआउट, पट्टे, बल्कहेड इत्यादि के साथ कैसे काम करता है?

• मुझे यह समझने में दिलचस्पी है कि इनपुट अनुरोध प्राथमिकता के आधार पर सेवा किस हद तक अनुरोधों को हटाने का निर्णय लेती है (निर्णय का मालिक है)। वे कॉन्फ़िगरेशन की कमी का उल्लेख करते हैं (एक पहलू जिसे मैं आगे तलाशना चाहूंगा), इसलिए यह सेवा के लिए विशिष्ट नहीं है और सेवा कार्यान्वयन से पूरी तरह से स्वतंत्र है, एक तरह से पारदर्शी है। यह सर्विस मेश/स्वतंत्र रिलीज़ चक्र बनाम आश्रित लाइब्रेरी के बिंदु को वापस लाता है।

खैर, मैं पक्षपाती हूं, क्योंकि मैं साझा पुस्तकालयों का बड़ा प्रशंसक नहीं हूं, यदि केवल इसलिए कि मुझे लगता है कि वे रिलीज/परिनियोजन प्रक्रिया को जटिल बनाते हैं। हालाँकि, मुझे यकीन नहीं है कि विचार करने के लिए कोई सेवा-विशिष्ट कॉन्फ़िगरेशन पहलू है या नहीं। शायद वे कॉन्फ़िगर करते हैं कि किसी क्वेरी को संसाधित करने और उसे पूरा करने के लिए सेवा को कितनी देर तक प्रतीक्षा करनी चाहिए?

शायद परीक्षण के लायक एक पहलू इजेक्टर की निर्णय लेने की प्रक्रिया है।

जहां तक मैं समझता हूं, यह निर्धारित करता है कि पीआईडी नियंत्रक के आधार पर अनुरोध को अस्वीकार किया जाए या नहीं, जो सेवा के लिए स्थानीयकृत है। क्या अधिक वैश्विक दृष्टिकोण का कोई विकल्प है? उदाहरण के लिए, यदि यह ज्ञात है कि पाइपलाइन में डाउनस्ट्रीम सेवाओं में से एक अतिभारित है (अपने स्वयं के पीआईडी नियंत्रक के कारण), तो क्या कोई भी अपस्ट्रीम सेवा इस अतिभारित सेवा तक पहुंचने से पहले अनुरोध को अस्वीकार करने का निर्णय ले सकती है (जो कि इससे कुछ कदम आगे हो सकता है) पथ)?

यह निर्णय पीआईडी नियंत्रक या डाउनस्ट्रीम सेवा के ऑटो-ट्यूनर द्वारा लौटाए गए मूल्य पर आधारित हो सकता है।

अब, मैं उल्लिखित विभिन्न पहलुओं पर विचार कर रहा हूं क्योंकि वे लेख को समाप्त करते हैं और अपने सिस्टम की दक्षता दिखाने के लिए कुछ संख्याएं प्रदान करते हैं, जो काफी प्रभावशाली है

वे किसी बिंदु पर उल्लेख करते हैं कि 'प्रत्येक अनुरोध में 1 सेकंड का टाइमआउट होता है।'

हम 5 मिनट के परीक्षण चलाते हैं, जहां हम एक निश्चित मात्रा में आरपीएस (उदाहरण के लिए, 1,000) भेजते हैं, जहां 50% ट्रैफ़िक टियर 1 और 50% टियर 5 है। प्रत्येक अनुरोध में 1 सेकंड का टाइमआउट होता है।

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

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

क्या डाउनस्ट्रीम सेवाओं (उनके स्थानीय पीआईडी नियंत्रकों से डेटा शामिल) के 'स्वास्थ्य' को प्रतिक्रियाओं से जुड़े हेडर के रूप में वापस किया जा सकता है और अधिक विकसित सर्किट ब्रेकर/प्रारंभिक प्रीमेप्टिव शेडिंग तंत्र बनाने के लिए उपयोग किया जा सकता है?

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

जब आप गुडपुट और विलंबता के माप की जांच करते हैं, तो इसमें कोई संदेह नहीं है कि कौन सा, QALM या दालचीनी, सबसे अच्छा प्रदर्शन करता है। ध्यान दें कि उन्होंने लेख में QALM दृष्टिकोण के लिंक का उल्लेख किया है। संभवतः वहीं से शुरू करना चाहिए ;)

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

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

- तुरंत एक स्थिर अस्वीकृति दर ढूंढें

- सेवा की क्षमता को स्वचालित रूप से समायोजित करें

- कोई कॉन्फ़िगरेशन पैरामीटर सेट किए बिना उपयोग किया जाए

- बहुत कम ओवरहेड खर्च होता है

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

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

क्या आपको यह लेख उपयोगी लगा? लिंक्डइन , हैकरनून और मीडियम पर मेरा अनुसरण करें ! कृपया इस लेख को साझा करें!