स्वास्थ्य जांच और वितरित प्रणालियों का क्रमिक क्षरण

हमेशा की तरह, इस लेख के मसौदे को पढ़ने और कुछ अमूल्य सलाह देने के लिए फ्रेड हेबर्ट और सरगुन ढिल्लन का धन्यवाद।

गति के बारे में उनकी चर्चा में, बॉक्स के तमार बेरकोविची ने स्वचालित डेटाबेस विफलता के लिए प्रदर्शन जांच के महत्व पर जोर दिया। विशेष रूप से, उसने नोट किया कि एंड-टू-एंड प्रश्नों के निष्पादन समय की निगरानी करना, डेटाबेस के स्वास्थ्य को निर्धारित करने के लिए एक विधि के रूप में, सरल पिंग (पिंग) से बेहतर है।

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

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

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

दो तरह की स्वास्थ्य जांच

स्वास्थ्य जांच, यहां तक ​​कि कई आधुनिक प्रणालियों में, एक नियम के रूप में, दो श्रेणियों में आते हैं: नोड स्तर और सेवा स्तर पर जांच।

उदाहरण के लिए, Kubernetes तत्परता और उत्तरजीविता का विश्लेषण करके सत्यापन को लागू करता है। उपलब्धता जांच का उपयोग यातायात की सेवा करने के लिए चूल्हा की क्षमता निर्धारित करने के लिए किया जाता है। यदि तत्परता जांच नहीं की जाती है, तो यह सेवा बनाने वाले एंडपॉइंट से हटा दी जाती है , और इस वजह से, चूल्हा में, जाँच पूरी होने तक, कोई ट्रैफ़िक रूट नहीं किया जाता है। दूसरी ओर, एक जीवितता जांच का उपयोग यह निर्धारित करने के लिए किया जाता है कि क्या सेवा किसी हैंग या लॉक का जवाब दे रही है। यदि यह विफल रहता है, तो क्यूबलेट में अलग-अलग कंटेनर को पुनरारंभ किया जाता है । इसी तरह, कॉन्सल checks कई रूपों की अनुमति देता है: script -आधारित, HTTP- आधारित चेक एक विशिष्ट URL को निर्देशित, TTL- आधारित चेक या यहां तक ​​कि उपनाम।

सेवा स्तर पर स्वास्थ्य जांच को लागू करने के लिए सबसे आम तरीका स्वास्थ्य जांच के समापन बिंदु को निर्धारित करना है। उदाहरण के लिए, gRPC में, एक स्वास्थ्य जाँच स्वयं एक RPC कॉल बन जाती है। जीआरपीसी सेवा स्तर की स्वास्थ्य जांच और सामान्य जीआरपीसी सर्वर स्वास्थ्य जांच के लिए भी अनुमति देता है।

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

दक्षता एक स्पेक्ट्रम है, न कि एक द्विआधारी वर्गीकरण

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

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

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

अक्सर, काम पूरा नहीं किया जा सकता क्योंकि प्रक्रिया अतिभारित है। अत्यधिक प्रतिस्पर्धी सेवाओं में, "भीड़भाड़" बड़े करीने से केवल एक प्रक्रिया द्वारा संसाधित समवर्ती अनुरोधों की संख्या के साथ बड़े पैमाने पर सहसंबद्ध है, जो आरपीसी कॉल के लिए विलंबता में वृद्धि का कारण बन सकता है (हालांकि अधिक बार नहीं, निचले स्तर की सेवा बस अनुरोध को पकड़ और रिट्रीट पर रखती है। एक निर्दिष्ट इंतज़ार कर समय के बाद)। यह विशेष रूप से सच है यदि स्वास्थ्य जांच समापन बिंदु स्वचालित रूप से HTTP 200 स्थिति कोड पर लौटने के लिए कॉन्फ़िगर किया गया है, जबकि सेवा द्वारा निष्पादित वास्तविक ऑपरेशन में नेटवर्क I / O या संगणना शामिल है।

प्रक्रिया प्रदर्शन एक स्पेक्ट्रम है। सबसे पहले, हम सेवा की गुणवत्ता में रुचि रखते हैं, उदाहरण के लिए, कार्य की एक विशिष्ट इकाई के परिणाम को पुनर्स्थापित करने के लिए प्रक्रिया के लिए आवश्यक समय, और परिणाम की सटीकता।

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

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

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

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

बैकप्रेस को लागू करते समय प्रतिक्रिया की आवश्यकता

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

चाल यह है कि जब संसाधन समाप्त हो जाते हैं, तो कहीं न कहीं कुछ दिया जाना चाहिए। मांग बढ़ रही है, और उत्पादकता जादुई रूप से नहीं बढ़ सकती है। आने वाले कार्यों को सीमित करने के लिए, पहली बात यह है कि साइट के स्तर पर कुछ गति सीमा निर्धारित करना है, आईपी पते, उपयोगकर्ता, सत्र, या, सबसे अच्छा, कुछ तत्व द्वारा आवेदन के लिए महत्वपूर्ण है। कई लोड बैलेंसर आने वाले Node.js सर्वर को सीमित करने की तुलना में अधिक जटिल तरीके से गति को सीमित कर सकते हैं, लेकिन आमतौर पर वे समस्याओं को नोटिस नहीं करते हैं जब तक कि प्रक्रिया एक कठिन स्थिति में नहीं होती है।

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

निर्दिष्ट agent-port पैरामीटर के आधार पर पोर्ट के लिए टीसीपी-कनेक्शन द्वारा और एएससीआईआई स्ट्रिंग को पढ़कर एजेंट स्वास्थ्य की जांच की जाती है। एक पंक्ति में किसी भी क्रम में रिक्त स्थान, टैब या कॉमा द्वारा अलग किए गए शब्दों की एक श्रृंखला होती है, वैकल्पिक रूप से /r और / या /n और निम्नलिखित तत्वों सहित:

- ASCII के एक सकारात्मक पूर्णांक प्रतिशत मूल्य का प्रतिनिधित्व, उदाहरण के लिए, 75% । इस प्रारूप में मान प्रारंभिक के अनुपात में वजन निर्धारित करते हैं
HAProxy प्रारंभ करते समय भारित सर्वर मान कॉन्फ़िगर किया गया। कृपया ध्यान दें कि सर्वर पर समान प्रभाव के क्षण से शून्य पृष्ठ मान DRAIN रूप में दर्शाया गया है (इसे LB फ़ार्म से हटा दिया गया है)।

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

- शब्द ready । यह सर्वर की प्रशासनिक स्थिति का अनुवाद करता है
READY मोड, DRAIN या MAINT रद्द करना।

- drain शब्द। यह सर्वर की प्रशासनिक स्थिति का अनुवाद करता है
DRAIN मोड ("ड्रेन"), जिसके बाद सर्वर नए कनेक्शन को स्वीकार नहीं करेगा, डेटाबेस के माध्यम से स्वीकार किए गए कनेक्शन के अपवाद के साथ।

- शब्द maint । यह सर्वर की प्रशासनिक स्थिति का अनुवाद करता है
MAINT मोड ("रखरखाव"), जिसके बाद सर्वर किसी भी नए कनेक्शन को स्वीकार नहीं करेगा, और स्वास्थ्य जांच बंद हो जाएगी।

- शब्द down , failed या stopped , जो कि तेज प्रतीक (#) के बाद एक वर्णन पंक्ति द्वारा हो सकते हैं। वे सभी DOWN सर्वर ("बंद") की परिचालन स्थिति को इंगित करते हैं, लेकिन चूंकि शब्द स्वयं आंकड़े पृष्ठ पर प्रदर्शित होता है, अंतर व्यवस्थापक को यह निर्धारित करने की अनुमति देता है कि क्या स्थिति अपेक्षित थी: सेवा को जानबूझकर रोका जा सकता है, कुछ पुष्टिकरण परीक्षण दिखाई दे सकते हैं, लेकिन पारित करने में विफल। या अक्षम माना जाए (कोई प्रक्रिया नहीं, पोर्ट से कोई प्रतिक्रिया नहीं)।

- शब्द ऊपर UP सर्वर ("पर") की परिचालन स्थिति को इंगित करता है अगर स्वास्थ्य जांच भी सेवा की उपलब्धता की पुष्टि करती है।

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

हालांकि, यह ध्यान में रखा जाना चाहिए कि केवल एजेंट ही अपने कार्यों को रद्द कर सकता है, इसलिए, यदि सर्वर एजेंट के उपयोग के लिए DRAIN मोड या DOWN पर सेट है, तो एजेंट को सेवा को पुनरारंभ करने के लिए अन्य समतुल्य क्रियाएं करनी होंगी।

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

आउटपुट इकाई के साथ सेवा के गतिशील संचार की यह योजना एक आत्म-अनुकूली अवसंरचना बनाने के लिए अत्यंत महत्वपूर्ण है। एक उदाहरण वास्तुकला होगा जिसके साथ मैंने पिछली नौकरी में काम किया था।

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

लोड संतुलन स्तर स्पिलवे सेवा पर आधारित था, जो एक रिवर्स प्रॉक्सी और अनुरोध ब्रोकर के रूप में कार्य करता था। यह विशुद्ध रूप से आंतरिक सेवा थी; कगार पर, हमने nginx और HAProxy और Spillway की शुरुआत की, इसलिए इसे TLS को पूरा करने या उस अनगिनत सेट से कोई अन्य कार्य करने के लिए डिज़ाइन नहीं किया गया था जो आमतौर पर सीमा प्रॉक्सी की क्षमता में होता है।

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

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

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

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

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

नवंबर 2016 में Google NYC में प्रोमेथियस मॉनिटरिंग सिस्टम पर मेरी प्रस्तुति से छवि

मई 2017 में OSCON सम्मेलन में प्रोमेथियस मॉनिटरिंग सिस्टम पर मेरी प्रस्तुति से यह चेतावनी ली गई है।

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

पिछले छह महीनों में विफलताओं का विश्लेषण करते हुए, हमने पाया कि उनमें से 28% को कम किया जा सकता है या चिकनी गिरावट से रोका जा सकता है।

तीन सबसे आम प्रकार की विफलताएं निम्नलिखित कारकों से जुड़ी थीं:

- भीड़ और खराब ऑपरेटर नोड्स सहित आने वाले अनुरोध के स्कीमा में परिवर्तन।
- प्रोसेसर, मेमोरी, इनपुट / आउटपुट सर्किट या नेटवर्क संसाधनों जैसे संसाधनों की कमी।
- इन्फ्रास्ट्रक्चर, डेटा वेयरहाउस और डाउनस्ट्रीम सेवाओं सहित निर्भरता की विफलता।

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

, , , - . 2013 Google «The Tail at Scale» , ( ), ( ) .

, . , .

( )

, , :

1. , , QCon London 2018.
2. : - , , LISA 2017.
3. – , , Strangeloop 2017.
4. : , , , Strangeloop 2017.
5. « » .

निष्कर्ष

, TCP/IP ( ), IP ECN ( IP ) Ethernet, , .

, . . , . .