बैकएंड इंटरव्यू: आप किसी सर्विस को ओवरलोड से कैसे बचाते हैं?

प्रॉम्प्ट और यह प्रश्न कब लागू होता है

एक ऑर्डर सर्विस की लोड-टेस्टेड सस्टेनेबल क्षमता 250 ms के p99 लेटेंसी पर 3,000 रिक्वेस्ट प्रति सेकंड है। एक प्रमोशन के दौरान, आगमन बढ़कर 8,000 रिक्वेस्ट प्रति सेकंड हो जाता है। एक इन्वेंटरी डिपेंडेंसी धीमी हो जाती है, इन-फ़्लाइट रिक्वेस्ट्स की संख्या और कतार (queue) की उम्र दोनों बढ़ जाती हैं, क्लाइंट्स पुनः प्रयास करते हैं, और ऑटोस्केलिंग को नए इंस्टेंस तैयार करने से पहले तीन मिनट की आवश्यकता होती है। महत्वपूर्ण ऑर्डर सबमिशन, इंटरैक्टिव उपलब्धता जांच (availability checks), और आंतरिक बैच समाधान (reconciliation) इस सर्विस को साझा करते हैं।

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

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

इंटरव्यूअर क्या मूल्यांकन कर रहा है

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

अगला संकेत एक बाउंडेड (सीमित) सिस्टम है। असीमित कतारें अतिरिक्त मांग को मेमोरी वृद्धि और पुरानी रिक्वेस्ट्स में बदल देती हैं। उम्मीदवार को बाधा (bottleneck) पर समवर्ती कार्य को सीमित करना चाहिए, कतार को छोटा रखना चाहिए या हटा देना चाहिए, और महंगे पार्सिंग या डाउनस्ट्रीम कॉल्स से पहले ही कम लागत में अस्वीकार (reject) करना चाहिए। उद्देश्य उपयोगी सफल कार्य है, न कि प्रत्येक रिक्वेस्ट को स्वीकार करना या कच्चे प्रयासों को अधिकतम करना।

इंटरव्यूअर एक व्यवसाय-जागरूक नीति भी चाहता है। महत्वपूर्ण ऑर्डर सबमिशन एक आरक्षित हिस्सा प्राप्त कर सकते हैं; उपलब्धता जांच एक अल्पकालिक कैश का उपयोग कर सकती है; बैच समाधान को रोका जा सकता है। प्राथमिकता के लिए अभी भी प्रति-टेनेंट निष्पक्षता की आवश्यकता होती है ताकि एक बड़ा ग्राहक हर आरक्षित स्लॉट का उपभोग न कर सके। अंत में, डिज़ाइन को एक बंद रिकवरी लूप की आवश्यकता होती है: रिट्राय एम्प्लीफिकेशन को दबाना, धीमी क्षमता प्रतिक्रिया के रूप में स्केल करना, एडमिशन को धीरे-धीरे वापस बढ़ाना, और किसी घटना से पहले डिग्रैडेड पाथ का परीक्षण करना।

उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न

• कौन सा संसाधन सबसे पहले संतृप्त (saturate) होता है? CPU सैचुरेशन एक स्थानीय कॉनकरेंसी या लागत सीमा का समर्थन करता है। एक धीमी डिपेंडेंसी एक अलग कनेक्शन/कॉनकरेंसी बल्कहेड की मांग करती है। मेमोरी वृद्धि या कतार की उम्र के लिए एक छोटी कतार और पहले अस्वीकृति की आवश्यकता हो सकती है। प्रत्येक बॉटलनेक एडमिशन सिग्नल को बदल देता है।
• कौन से ऑपरेशन्स आवश्यक हैं और क्या डिग्रेड किया जा सकता है? यहां, ऑर्डर सबमिट करना महत्वपूर्ण है, उपलब्धता थोड़ा पुराना डेटा सहन कर सकती है, और बैच समाधान को रोका जा सकता है। यदि कानूनी रूप से प्रत्येक ऑपरेशन के लिए ताज़ा इन्वेंटरी का उपयोग करना आवश्यक है, तो कैश फ़ॉलबैक अमान्य है और स्पष्ट विफलता अधिक सुरक्षित है।
• एंड-टू-एंड डेडलाइन क्या है? कतार का समय निष्पादन के समान डेडलाइन की खपत करता है। सर्विस को उस कार्य को छोड़ देना चाहिए जो अब समाप्त नहीं हो सकता है और कैंसलेशन को डाउनस्ट्रीम में प्रचारित (propagate) करना चाहिए।
• क्या सभी रिक्वेस्ट्स समान रूप से महंगी हैं? प्रति रिक्वेस्ट एक टोकन केवल तभी काम करता है जब लागत समान हो। महंगे एंडपॉइंट्स को भारित परमिट या अलग पूल की आवश्यकता हो सकती है ताकि सस्ता महत्वपूर्ण कार्य महंगे बैच जॉब्स के पीछे न फंसे।
• क्या क्लाइंट सुरक्षित रूप से पुनः प्रयास कर सकते हैं? एक अस्वीकृत रीड का बाद में पुनः प्रयास किया जा सकता है। एक ऑर्डर राइट को एक इडेम्पोटेंसी कुंजी और परिणाम लुकअप की आवश्यकता होती है। सर्विस को "बाद में पुनः प्रयास करें" और "पुनः प्रयास न करें" के बीच अंतर करना चाहिए, और सभी लेयर्स को एक रिट्राय बजट साझा करना चाहिए।
• क्या ट्रैफ़िक शिफ्ट उपलब्ध है? स्वस्थ-क्षेत्र (healthy-region) फ़ेलओवर केवल तभी कार्य को अवशोषित कर सकता है जब लक्ष्य के पास सत्यापित अतिरिक्त क्षमता हो। आंख मूंदकर ओवरलोड को स्थानांतरित करने से दूसरी विफलता पैदा हो सकती है।

30-सेकंड उत्तर फ्रेमवर्क

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

चरण-दर-चरण गहन विश्लेषण

मापे गए क्षमता लिफाफे (capacity envelope) से शुरुआत करें। 3,000 रिक्वेस्ट प्रति सेकंड का आंकड़ा केवल परीक्षण किए गए रिक्वेस्ट मिक्स, डिपेंडेंसी लेटेंसी, इंस्टेंस काउंट और 250 ms p99 लक्ष्य के लिए मान्य है। संबंधित प्रति-इंस्टेंस इन-फ़्लाइट कार्य, CPU, मेमोरी, वर्कर उपयोग और डाउनस्ट्रीम कनेक्शन उपयोग को रिकॉर्ड करें। रिक्वेस्ट रेट एक इनपुट है; एडमिशन का निर्णय विफलता के सबसे करीब मौजूद संसाधन के अनुसार होना चाहिए। उदाहरण के लिए, जब इन्वेंटरी धीमी हो जाती है, तो वही आगमन दर अधिक इन-फ़्लाइट कॉल्स बनाती है, इसलिए केवल-रेट कंट्रोलर बहुत देर से प्रतिक्रिया करता है।

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

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

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

स्पष्ट क्षमता आरक्षण के साथ प्राथमिकता नीति का उपयोग करें:

निष्पक्षता के बिना प्राथमिकता छोटे टेनेंट्स को भूखा (starve) रख सकती है। एक वर्ग के अंदर टेनेंट कोटा या निष्पक्ष शेड्यूलिंग लागू करें, और रिकवरी या नियंत्रण ट्रैफ़िक के लिए न्यूनतम हिस्सा रखें। दर्जनों प्राथमिकता स्तरों से बचें: ऑपरेटरों को यह अनुमान लगाने में सक्षम होना चाहिए कि किसी घटना के दौरान कौन सा रिक्वेस्ट स्वीकार किया जाता है।

जब सीमा पूरी हो जाए, तो डेटाबेस या डिपेंडेंसी कार्य से पहले वापस लौटें। HTTP 503 अस्थायी ओवरलोड का प्रतिनिधित्व करता है और इसमें Retry-After शामिल हो सकता है; यह प्रत्येक क्लाइंट को एक साथ पुनः प्रयास करने की अनुमति नहीं देता है। क्लाइंट जिटर, एक डेडलाइन और एक रिट्राय बजट के साथ कैप्ड एक्सपोनेंशियल बैकऑफ़ का उपयोग करते हैं। प्रत्येक लेयर के बजाय एक उपयुक्त लेयर पर पुनः प्रयास करें। ऑर्डर निर्माण एक इडेम्पोटेंसी कुंजी का पुन: उपयोग करता है और एक अस्पष्ट टाइमआउट के बाद पिछले परिणाम की जांच करता है। जिन रिक्वेस्ट्स की कॉलर डेडलाइन समाप्त हो गई है, उन्हें रद्द कर दिया जाता है ताकि सर्वर बेकार काम पूरा न करे।

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

ऑटोस्केलिंग, क्षेत्रीय स्पिलओवर और क्षमता में वृद्धि उपयोगी बनी हुई है, लेकिन वे एडमिशन कंट्रोल के बाद काम करती हैं। कच्चे रिक्वेस्ट काउंट पर स्केलिंग सस्ते ट्रैफ़िक के दौरान इंस्टेंस जोड़ सकती है और महंगे ट्रैफ़िक के दौरान पिछड़ सकती है; कॉनकरेंसी, कतार की उम्र, या संसाधन सैचुरेशन को शामिल करें। नए इंस्टेंसेस को पूरा हिस्सा प्राप्त करने से पहले कनेक्शन्स को वार्म करना चाहिए। फ़ेलओवर को गंतव्य क्षमता जांच की आवश्यकता होती है। कोई भी तंत्र स्थानीय सीमाओं को हटाने का औचित्य सिद्ध नहीं करता है।

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

नाममात्र क्षमता परीक्षण से परे नीति को मान्य करें। प्रोडक्शन रिक्वेस्ट-कॉस्ट मिक्स को दोबारा चलाएं, फिर इन्वेंटरी को धीमा करते हुए और तीन मिनट के लिए ऑटोस्केलिंग में देरी करते हुए आगमन को 3,000 से बढ़ाकर 8,000 रिक्वेस्ट प्रति सेकंड करें। सिंक्रोनाइज़्ड क्लाइंट रिट्राय, एक अनियंत्रित (abusive) टेनेंट, समाप्त हो चुकी डेडलाइन्स, और डिपेंडेंसी की रिकवरी जोड़ें। बाउंडेड कतार और मेमोरी, स्थिर वर्कर और कनेक्शन उपयोग, कम लागत वाली अस्वीकृति, इसके आरक्षण के भीतर ऑर्डर की सफलता, टेनेंट निष्पक्षता, ईमानदार डिग्रेडेशन, नियंत्रित रिट्राय एम्प्लीफिकेशन, और सामान्य स्थिति में क्रमिक वापसी की पुष्टि करें। स्वीकृत रिक्वेस्ट्स और डाउनस्ट्रीम प्रयासों से अलग पूर्ण उपयोगी ऑपरेशन्स को मापें।

उच्च गुणवत्ता वाला नमूना उत्तर

"सस्टेनेबल 3,000 रिक्वेस्ट प्रति सेकंड एक रिक्वेस्ट मिक्स के लिए लोड-टेस्ट परिणाम है, इसलिए मैं सबसे पहले उस सीमा पर संसाधन की पहचान करूंगा। इन्वेंटरी मंदी के दौरान, इन-फ़्लाइट कॉल्स और कनेक्शन अधिभोग रिक्वेस्ट रेट की तुलना में अधिक उपयोगी होते हैं। मैं सर्विस के लिए एक परीक्षण की गई प्रति-इंस्टेंस कॉनकरेंसी सीमा, इन्वेंटरी के लिए एक छोटा बल्कहेड, और एक छोटी कतार सेट करूंगा जिसकी प्रतीक्षा अभी भी रिक्वेस्ट डेडलाइन में फिट बैठती है। एक बार जब कोई भी सीमा पूरी हो जाती है, तो सर्विस महंगे काम से पहले अस्वीकार कर देती है।

मैं ट्रैफ़िक को ऑर्डर सबमिशन, उपलब्धता और समाधान में वर्गीकृत करूंगा। ऑर्डर्स को आरक्षित क्षमता मिलती है लेकिन फिर भी एक कठोर सीमा होती है। उपलब्धता केवल तभी अल्पकालिक कैश का उपयोग कर सकती है जब API उस ताजगी अनुबंध को उजागर करता है। समाधान रुक जाता है और टिकाऊ प्रगति से फिर से शुरू होता है। प्रत्येक वर्ग के भीतर मैं टेनेंट निष्पक्षता लागू करूंगा, ताकि एक ग्राहक पूरे आरक्षण को न ले सके। मैं बाद की सर्विस द्वारा किसी रिक्वेस्ट को बेतरतीब ढंग से छोड़े जाने पर काम बर्बाद करने से बचने के लिए प्राथमिकता को डाउनस्ट्रीम में भी प्रचारित करूंगा।

अस्थायी ओवरलोड एक पहचानने योग्य 503 लौटाता है और जब हम इसका अनुमान लगा सकते हैं, तो Retry-After लौटाता है। क्लाइंट्स को अभी भी कैप्ड बैकऑफ़, जिटर, डेडलाइन्स और एक साझा रिट्राय बजट की आवश्यकता होती है। केवल एक लेयर पुनः प्रयास करती है, और ऑर्डर राइट्स एक इडेम्पोटेंसी कुंजी का पुन: उपयोग करते हैं। समय सीमा समाप्त कॉलर डाउनस्ट्रीम कार्य को रद्द कर देते हैं।

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

सबूत धीमी इन्वेंटरी, विलंबित स्केलिंग, पुनः प्रयास, मिश्रित रिक्वेस्ट लागत और एक शोर वाले टेनेंट के साथ 8,000 रिक्वेस्ट प्रति सेकंड पर एक ओवरलोड परीक्षण है। मैं बाउंडेड मेमोरी और कतारों, स्थिर उपयोगी थ्रूपुट, वादा किए गए ऑर्डर आरक्षण और निष्पक्षता, कम लागत वाली अस्वीकृति, कोई रिट्राय स्टॉर्म नहीं, और इन्वेंटरी वापस आने के बाद नियंत्रित रिकवरी की उम्मीद करता हूं।"

सामान्य गलतियाँ

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

फॉलो-अप प्रश्न और उत्तर

फॉलो-अप 1: इसे एक डिस्ट्रीब्यूटेड रेट लिमिटर से हल क्यों नहीं किया जा सकता?

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

फॉलो-अप 2: आप कॉनकरेंसी सीमा कैसे चुनेंगे?

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

फॉलो-अप 3: क्या होगा यदि 90% ट्रैफ़िक को महत्वपूर्ण चिह्नित किया गया हो?

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

फॉलो-अप 4: क्या एडेप्टिव कॉनकरेंसी डिज़ाइन को बेहतर बना सकती है?

यह एक स्थिर सीमा की तुलना में सर्विस समय में बदलाव का अधिक बारीकी से पालन कर सकता है, लेकिन शोर वाली लेटेंसी और विलंबित फीडबैक दोलन (oscillation) या गलत शेडिंग का कारण बन सकते हैं। परीक्षण की गई स्थिर सीमा से शुरुआत करें। केवल न्यूनतम और अधिकतम सीमाओं, स्मूथ सिग्नल्स, हिस्टैरिसीस, एक स्थिर फ़ॉलबैक मान, और तेजी से गिरावट और धीमी रिकवरी को कवर करने वाले रीप्ले परीक्षणों के साथ एडेप्टिव नियंत्रण जोड़ें।

फॉलो-अप 5: एक गहरे कॉल ग्राफ़ में लोड शेडिंग कहाँ होनी चाहिए?

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

फॉलो-अप 6: कौन से प्रोडक्शन मेट्रिक्स दिखाते हैं कि नीति काम कर रही है?

ऑपरेशन और प्राथमिकता के आधार पर उपयोगी पूर्णता और लेटेंसी ट्रैक करें; स्वीकृत, कतारबद्ध, डिग्रैडेड और अस्वीकृत रिक्वेस्ट्स; सबसे पुरानी कतार की उम्र; इन-फ़्लाइट कार्य; CPU, मेमोरी, वर्कर और कनेक्शन सैचुरेशन; डेडलाइन-समाप्त कार्य; प्रति-टेनेंट निष्पक्षता; प्रति लॉजिकल रिक्वेस्ट भौतिक प्रयास; ऑटोस्केलिंग तत्परता विलंब; और ओवरलोड मोड में बिताया गया समय। महत्वपूर्ण आरक्षण के नुकसान, निरंतर ओवरलोड, सामान्य रिक्वेस्ट लागत के करीब पहुंचने वाली अस्वीकृति लागत, या बार-बार पीछे हटने वाले रिकवरी रैंप पर अलर्ट करें।