फाइन ट्यून लोड बैलेंसिंग

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



"पांच सौ" के 84 आरपीएस पर छोटे मिनट की चोटी पांच हजार त्रुटियां हैं जो वास्तविक उपयोगकर्ताओं को मिली हैं। यह बहुत कुछ है और यह बहुत महत्वपूर्ण है। कारणों की तलाश करना, त्रुटियों पर काम करना और ऐसी स्थितियों को रोकने के लिए जारी रखने का प्रयास करना आवश्यक है।

निकोले सिवको ( निकोलेसेवको ) ने रूटकॉन्फ 2018 पर अपनी रिपोर्ट में सूक्ष्म और लोड संतुलन के बहुत लोकप्रिय पहलुओं के बारे में बात नहीं की:

• जब अनुरोध (पुन: प्रयास) को दोहराने के लिए;
• टाइमआउट के लिए मूल्यों का चयन कैसे करें;
• कैसे दुर्घटना / भीड़ के समय अंतर्निहित सर्वर को मारने के लिए नहीं;
• क्या स्वास्थ्य जांच की आवश्यकता है;
• कैसे चंचल समस्याओं को संभालने के लिए।

इस रिपोर्ट की कैट डिकोडिंग के तहत।


वक्ता के बारे में: निकोले शिवको okmeter.io के सह-संस्थापक। उन्होंने सिस्टम प्रशासक और प्रशासकों के समूह के नेता के रूप में काम किया। Hh.ru पर सुपरवाइज्ड ऑपरेशन। उन्होंने निगरानी सेवा okmeter.io की स्थापना की। इस रिपोर्ट के हिस्से के रूप में, विकास के अनुभव की निगरानी करना मामलों का मुख्य स्रोत है।

हम किस बारे में बात करने जा रहे हैं?

यह लेख वेब परियोजनाओं के बारे में बात करेगा। नीचे लाइव उत्पादन का एक उदाहरण है: ग्राफ़ एक निश्चित वेब सेवा के लिए प्रति सेकंड अनुरोध दिखाता है।



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



वास्तव में, यह पूरी तरह से सच नहीं है। यह समस्या बहुत कम कंपनियों के लिए प्रासंगिक है। अधिक बार व्यापार त्रुटियों और सिस्टम स्थिरता के बारे में चिंतित है।



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

एक नियम के रूप में, सभी के पास ऐसी चोटियां हैं, और प्रवेशकर्ता हमेशा उन्हें जवाब नहीं देते हैं। बहुत बार, जब कोई व्यवसाय पूछता है कि यह क्या था, तो उन्होंने उसे जवाब दिया:

• "यह एक छोटी फट है!"
• "यह सिर्फ एक रिलीज रोलिंग है।"
• "सर्वर मर चुका है, लेकिन सब कुछ पहले से ही क्रम में है।"
• "वास्या ने बैकएंड में से एक के नेटवर्क को स्विच किया।"

अक्सर लोग उन कारणों को समझने की कोशिश भी नहीं करते हैं कि ऐसा क्यों हुआ, और कोई भी पोस्ट-वर्क न करें ताकि ऐसा दोबारा न हो।

ठीक धुन

मैंने रिपोर्ट को "फाइन ट्यूनिंग" (इंजी। ट्यूनिंग) कहा, क्योंकि मैंने सोचा था कि हर कोई इस कार्य को नहीं करता है, लेकिन इसके लायक होगा। वे वहाँ क्यों नहीं मिलते?

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

मैं पुष्टि करता हूं कि यह कार्य कई कारणों से करने का समय है:

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

टेस्ट स्टैंड

चलो सरल, स्पष्ट मामलों से शुरू करते हैं। स्पष्टता के लिए, मैं एक परीक्षण बेंच का उपयोग करूंगा। यह एक गोलांग एप्लिकेशन है जो http-200 देता है, या आप इसे "http-503" मोड पर स्विच कर सकते हैं।

हम 3 उदाहरण शुरू करते हैं:

• 127.0.0.1:20001
• 127.0.0.1:20002
• 127.0.0.1:20003

हम nandx के माध्यम से yandex.tank के माध्यम से 100rps की सेवा करते हैं।

बॉक्स से बाहर Nginx:

upstream backends { server 127.0.0.1:20001; server 127.0.0.1:20002; server 127.0.0.1:20003; } server { listen 127.0.0.1:30000; location / { proxy_pass http://backends; } } 

आदिम परिदृश्य

कुछ बिंदु पर, 503 मोड में बैकएंड में से एक को चालू करें, और हमें त्रुटियों का एक तिहाई हिस्सा मिलता है।



यह स्पष्ट है कि कुछ भी बॉक्स से बाहर काम नहीं करता है: यदि सर्वर से कोई प्रतिक्रिया मिली, तो नग्नेक्स बॉक्स से बाहर नहीं निकलता है।

 Nginx default: proxy_next_upstream error timeout; 

वास्तव में, यह नगनेक्स डेवलपर्स के पक्ष से काफी तार्किक है: नगनेक्स को आपके लिए निर्णय लेने का अधिकार नहीं है कि आप क्या लेना चाहते हैं और क्या नहीं।

तदनुसार, हमें रिट्रीट - रिट्रीट की आवश्यकता है, और हम उनके बारे में बात करना शुरू करते हैं।

पुनर्प्रयास

इसके बीच समझौता करना आवश्यक है:

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

सच्चाई, हमेशा की तरह, इन तीन बिंदुओं के बीच संतुलन बनाने के लिए मजबूर है। आइए समझने की कोशिश करें कि क्या और कैसे।

मैंने असफल प्रयासों को 3 श्रेणियों में विभाजित किया है:

1. परिवहन त्रुटि
HTTP ट्रांसपोर्ट के लिए TCP है, और, एक नियम के रूप में, यहां हम कनेक्शन सेटअप त्रुटियों और कनेक्शन सेटअप टाइमआउट के बारे में बात करते हैं। अपनी रिपोर्ट में, मैं 3 सामान्य बैनक्रैकर्स का उल्लेख करूँगा (हम थोड़ा और आगे दूत के बारे में बात करेंगे):

• nginx : त्रुटियाँ + टाइमआउट (प्रॉक्सी_कनेक्ट_टाइम);
• HAProxy : टाइमआउट कनेक्ट;
• दूत : कनेक्ट-विफलता + इनकार-धारा।

नेग्नेक्स के पास यह कहने का अवसर है कि एक असफल प्रयास एक कनेक्शन त्रुटि और एक कनेक्शन टाइमआउट है; HAProxy का कनेक्शन टाइमआउट है, Envoy में सब कुछ मानक और सामान्य है।

2. अनुरोध समयबाह्य:
मान लीजिए कि हमने सर्वर से एक अनुरोध भेजा है, सफलतापूर्वक उससे जुड़ा है, लेकिन जवाब हमारे पास नहीं आता है, हमने इसका इंतजार किया और हम समझते हैं कि अब और इंतजार करने का कोई मतलब नहीं है। इसे अनुरोध टाइमआउट कहा जाता है:

• Nginx में: टाइमआउट (prox_send_timeout * +xy_read_timeout *);
• HAProxy का OOPS है :( - यह सिद्धांत रूप में मौजूद नहीं है। बहुत से लोग यह नहीं जानते हैं कि HAProxy, यदि यह सफलतापूर्वक एक कनेक्शन स्थापित कर चुका है, तो अनुरोध को फिर से भेजने का प्रयास नहीं करेगा।
• दूत सब कुछ कर सकता है: टाइमआउट || per_try_timeout।

3. HTTP स्थिति
HAProxy को छोड़कर सभी बैलेंसर प्रक्रिया करने में सक्षम हैं, अगर फिर भी बैकएंड ने आपको जवाब दिया, लेकिन किसी तरह के गलत कोड के साथ।

• nginx : http_ *
• HAProxy : OOPS :(
• एनवॉय : 5xx, गेटवे-एरर (502, 503, 504), रिट्रीएबल -4xx (409)

समय समाप्ति

अब समय के बारे में विस्तार से बात करते हैं, यह मुझे लगता है कि इस पर ध्यान देने योग्य है। आगे कोई रॉकेट साइंस नहीं होगा - यह केवल संरचित जानकारी है जो आम तौर पर होती है और इससे कैसे संबंधित है।

टाइमआउट कनेक्ट करें

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

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

 fail fast: listen backlog + net.ipv4.tcp_abort_on_overflow 

टाइमआउट का अनुरोध करें

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

नंगेक्स के पास स्वयं पूरे अनुरोध के लिए एक टाइमआउट नहीं है। उसके पास है:

• xy_send_timeout: दो सफल लेखन कार्यों के बीच का समय लिखना ();
• xy_read_timeout: दो सफल रीड रीड () के बीच का समय।

यही है, यदि आपके पास धीरे-धीरे बैकएंड है, तो एक बार बाइट, टाइमआउट में कुछ देता है, तो सब कुछ ठीक है। जैसे, nginx में request_timeout नहीं है। लेकिन हम ऊपर की बात कर रहे हैं। हमारे डेटा सेंटर में वे हमारे द्वारा नियंत्रित होते हैं, इसलिए, यह मानते हुए कि नेटवर्क में स्लो लोरिस नहीं है, फिर, सिद्धांत रूप में, read_timeout request_timeout के रूप में उपयोग किया जा सकता है।

एन्वॉय के पास यह सब है: टाइमआउट || per_try_timeout।

अनुरोध टाइमआउट का चयन करें

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

• यदि हम एक एकल सर्वर की विफलता को संभालना चाहते हैं, तो टाइमआउट अधिकतम स्वीकार्य टाइमआउट से कम होना चाहिए: request_timeout अधिकतम।
• यदि आप दो अलग-अलग बैकेंड के लिए अनुरोध भेजने के लिए 2 गारंटीकृत प्रयास करना चाहते हैं, तो एक प्रयास के लिए टाइमआउट इस स्वीकार्य अंतराल के आधे के बराबर है: per_try_timeout = 0.5 * मैक्स।
• एक मध्यवर्ती विकल्प भी है - पहले बैकेंड के "सुस्त" होने की स्थिति में 2 आशावादी प्रयास , लेकिन दूसरा तुरंत जवाब देगा: per_try_timeout = k * max (जहां k> 0.5)।

अलग-अलग दृष्टिकोण हैं, लेकिन सामान्य तौर पर, टाइमआउट चुनना मुश्किल है । हमेशा सीमा के मामले होंगे, उदाहरण के लिए, 99% मामलों में एक ही हैंडलर को 10 एमएस में संसाधित किया जाता है, लेकिन 500 एमएस की प्रतीक्षा करने पर 1% मामले होते हैं और यह सामान्य है। इसे हल करना होगा।

इस 1% के साथ, कुछ करने की आवश्यकता है, क्योंकि अनुरोधों का पूरा समूह, उदाहरण के लिए, SLA का अनुपालन करना चाहिए और 100 ms में फिट होना चाहिए। इन क्षणों में बहुत बार आवेदन संसाधित किया जाता है:

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

यहां हमें एक निर्णय लेने की आवश्यकता है, जो मनोवैज्ञानिक दृष्टिकोण से बहुत सरल नहीं है, कि अगर हमारे पास आवंटित समय में उपयोगकर्ता को जवाब देने के लिए समय नहीं है, तो हम एक त्रुटि देंगे (यह एक प्राचीन चीनी कहावत है: "यदि घोड़ी मर गई है, तो उतरें!") ।

उसके बाद, उपयोगकर्ता के दृष्टिकोण से आपकी सेवा की निगरानी की प्रक्रिया सरल हो जाती है:

• यदि त्रुटियां हैं, तो सब कुछ खराब है, इसे ठीक करने की आवश्यकता है।
• यदि कोई त्रुटि नहीं है, हम सही प्रतिक्रिया समय में फिट होते हैं, तो सब कुछ ठीक है।

सट्टा रिट्रीट # निफ़ग

हमने सुनिश्चित किया कि टाइमआउट मूल्य चुनना काफी कठिन है। जैसा कि आप जानते हैं, कुछ को सरल बनाने के लिए, आपको कुछ जटिल करना होगा :)

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

मुझे यह पता नहीं था कि मुझे बैलेन्सर में यह सुविधा दिखाई देती है, लेकिन कैसेंड्रा (तेजी से पढ़ने की सुरक्षा) के साथ एक उत्कृष्ट उदाहरण है:

सट्टा_रेट्री = एन एमएस | एम ^वें परसेंटाइल

इस तरह से आपको टाइम आउट नहीं करना है । आप इसे स्वीकार्य स्तर पर छोड़ सकते हैं और किसी भी मामले में अनुरोध पर प्रतिक्रिया प्राप्त करने का दूसरा प्रयास करते हैं।

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

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



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

रिट्रीट के बारे में आपको और क्या जानने की जरूरत है?

नो रिटर्न का बिंदु (V1)

यहाँ V1 संस्करण 1 नहीं है। विमानन में ऐसी अवधारणा है - गति V1। यह गति है जिसके बाद रनवे पर त्वरण को धीमा करना असंभव है। इसे उतारना आवश्यक है, और फिर आगे क्या करना है, इसके बारे में निर्णय लें।

नो रिटर्न का एक ही बिंदु लोड बैलेंसर्स में है: जब आपने अपने क्लाइंट को प्रतिक्रिया का 1 बाइट पास किया, तो कोई त्रुटि तय नहीं की जा सकती है । यदि इस बिंदु पर बैकएंड मर जाता है, तो कोई भी रिट्रीट मदद नहीं करेगा। आप केवल इस तरह के परिदृश्य के ट्रिगर होने की संभावना को कम कर सकते हैं, एक सुंदर शटडाउन कर सकते हैं, अर्थात्, अपने आवेदन को बताएं: "आप अब नए अनुरोधों को स्वीकार नहीं करते हैं, लेकिन पुराने को संशोधित करते हैं!" और उसके बाद ही इसे बुझा दें।

यदि आप क्लाइंट को नियंत्रित करते हैं, तो यह कुछ मुश्किल अजाक्स या मोबाइल एप्लिकेशन है, यह अनुरोध को दोहराने की कोशिश कर सकता है, और फिर आप इस स्थिति से बाहर निकल सकते हैं।

नो रिटर्न का बिंदु [दूत]

दूत की ऐसी अजीब चाल थी। Per_try_timeout है - यह सीमित करता है कि किसी अनुरोध पर प्रतिक्रिया प्राप्त करने के लिए प्रत्येक प्रयास कितना ले सकता है। यदि इस समयबाह्य ने काम किया, लेकिन बैकएंड ने पहले ही क्लाइंट को जवाब देना शुरू कर दिया, तो सब कुछ बाधित हो गया, क्लाइंट को एक त्रुटि मिली।

मेरे सहयोगी पावेल त्रुखानोव ( tru_pablo ) ने एक पैच बनाया, जो पहले से ही मास्टर एनवॉय में है और 1.7 में होगा। अब यह उसी तरह काम करता है जैसे कि: यदि प्रतिक्रिया प्रसारित होना शुरू हो गई है, तो केवल वैश्विक टाइमआउट काम करेगा।

रिट्रीट: को सीमित करने की आवश्यकता है

रिट्रीट अच्छा है, लेकिन तथाकथित हत्यारे अनुरोध हैं: भारी प्रश्न जो बहुत जटिल तर्क करते हैं, डेटाबेस तक बहुत पहुंच बनाते हैं और अक्सर per_try_timeout में फिट नहीं होते हैं। यदि हम बार-बार रिट्रीट भेजते हैं, तो हम अपने आधार को मार देते हैं। क्योंकि अधिकांश (99.9%) डेटाबेस सेवाओं में कोई अनुरोध रद्द नहीं होता है ।

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

तदनुसार, रिट्रीज को सीमित करने की आवश्यकता है, जो लगभग सभी बैलेंसरों की अनुमति देता है (हम अब से हाप्रोसी पर विचार करना बंद कर देते हैं)।

nginx:

• प्रॉक्सी_नेक्स्ट_अपस्ट्रीम_टाइम (वैश्विक)
• proxt_read_timeout ** per_try_timeout के रूप में
• proxy_next_upstream_tries

दूत:

• टाइमआउट (वैश्विक)
• per_try_timeout
• num_retries

Nginx में, हम यह कह सकते हैं कि हम विंडो X भर में रिट्रीस करने की कोशिश कर रहे हैं, अर्थात् एक निश्चित समय अंतराल पर, उदाहरण के लिए, 500 एमएस, हम फिट के रूप में कई रिट्रीस करते हैं। या एक सेटिंग है जो दोहराया नमूनों की संख्या को सीमित करती है। एनवॉय में , समान मात्रा या टाइमआउट (वैश्विक) है।

पुनः प्रयास करें: लागू करें [nginx]

एक उदाहरण पर विचार करें: हमने nginx 2 में पुनः प्रयास का प्रयास किया है - तदनुसार, HTTP 503 प्राप्त करने के बाद, हम सर्वर पर दोबारा अनुरोध भेजने का प्रयास करते हैं। फिर दोनों बैकेंड को बंद कर दें।

 upstream backends { server 127.0.0.1:20001; server 127.0.0.1:20002; server 127.0.0.1:20003; } server { listen 127.0.0.1:30000; proxy_next_upstream error timeout http_503; proxy_next_upstream_tries 2; location / { proxy_pass http://backends; } } 

नीचे हमारी परीक्षण बेंच के ग्राफ़ दिए गए हैं। ऊपरी ग्राफ़ पर कोई त्रुटि नहीं है, क्योंकि उनमें से बहुत कम हैं। यदि आप केवल त्रुटियां छोड़ते हैं, तो यह स्पष्ट है कि वे हैं।





क्या हुआ?

• xy_next_upstream_tries = 2।
• मामले में जब आप "मृत" सर्वर पर पहला प्रयास करते हैं, और दूसरा - दूसरे "मृत" के लिए, आपको "खराब" सर्वरों के लिए दोनों प्रयासों के मामले में HTTP-503 मिलता है।
• वहाँ कुछ त्रुटियाँ हैं, क्योंकि nginx "बैन" एक खराब सर्वर है। यही है, अगर nginx में कुछ त्रुटियां बैकएंड से वापस आ गईं हैं, तो यह एक अनुरोध भेजने के लिए निम्नलिखित प्रयास करना बंद कर देता है। यह fail_timeout चर द्वारा नियंत्रित होता है ।

लेकिन गलतियाँ हैं, और यह हमें शोभा नहीं देता।

इसके बारे में क्या करना है?

हम या तो रिट्रीट की संख्या बढ़ा सकते हैं (लेकिन फिर "हत्यारे अनुरोधों" की समस्या पर लौट सकते हैं), या हम "मृत" बैकएंड के लिए अनुरोध की संभावना को कम कर सकते हैं। यह स्वास्थ्य जांच के साथ किया जा सकता है ।

स्वास्थ्य की जाँच

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

स्वास्थ्य जांच: बैकएंड के संदर्भ में

बैकएंड के दृष्टिकोण से, आप दिलचस्प चीजें कर सकते हैं:

• सभी अंतर्निहित उप-प्रणालियों के संचालन के लिए तत्परता की जांच करें, जिस पर बैकएंड ऑपरेशन निर्भर करता है: डेटाबेस से कनेक्शन की आवश्यक संख्या स्थापित है, पूल में मुफ्त कनेक्शन हैं, आदि, आदि।
• आप स्वास्थ्य जांच URL पर अपने स्वयं के तर्क लटका सकते हैं यदि उपयोग किया गया बैलेंसर बहुत बुद्धिमान नहीं है (उदाहरण के लिए, आप होस्ट से लोड बैलेंसर लेते हैं)। सर्वर यह याद रख सकता है कि "आखिरी मिनट में मैंने इतनी सारी त्रुटियां दीं - शायद मैं किसी तरह का" गलत "सर्वर हूं, और अगले 2 मिनट के लिए मैं स्वास्थ्य जांच के लिए" पांच सौ "के साथ जवाब दूंगा। इस प्रकार मैं स्वयं पर प्रतिबंध लगा दूंगा! " यह कभी-कभी बहुत मदद करता है जब आपके पास एक अनियंत्रित लोड बैलेंसर होता है।
• आमतौर पर, चेक अंतराल एक सेकंड के बारे में होता है, और आपको अपने सर्वर को मारने के लिए हेल्थ चेक हैंडलर की आवश्यकता होती है। यह हल्का होना चाहिए।

स्वास्थ्य जांच: कार्यान्वयन

एक नियम के रूप में, यहां सब कुछ सभी के लिए समान है:

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

Nginx को लागू करता है स्वास्थ्य जांच केवल nginx + के सशुल्क संस्करण में कार्य करती है।

मैं एनवॉय की एक विशेषता पर ध्यान देता हूं, इसमें हेल्थ चेक पैनिक मोड है। जब हमने प्रतिबंधित किया, "अस्वास्थ्यकर" के रूप में, एन% से अधिक मेजबान (70% कहते हैं), उनका मानना ​​है कि हमारे सभी स्वास्थ्य जांच झूठ हैं, और सभी मेजबान वास्तव में जीवित हैं। एक बहुत बुरे मामले में, यह आपको ऐसी स्थिति में नहीं दौड़ने में मदद करेगा जहाँ आपने खुद अपने पैर को गोली मारी थी और सभी सर्वरों पर प्रतिबंध लगाया था। यह फिर से सुरक्षित होने का एक तरीका है।

यह सब एक साथ रखना

आमतौर पर स्वास्थ्य जांच सेट के लिए:

• या नगनेक्स +;
• या नगनेक्स + कुछ और :)

हमारे देश में, nginx + HAProxy को सेट करने की प्रवृत्ति है, क्योंकि nginx के मुफ्त संस्करण में स्वास्थ्य जांच नहीं होती है, और 1.11.5 तक बैकएंड पर कनेक्शन की संख्या की कोई सीमा नहीं थी। लेकिन यह विकल्प खराब है क्योंकि HAProxy को पता नहीं है कि कनेक्शन स्थापित करने के बाद रिटायर कैसे किया जाए। बहुत से लोग सोचते हैं कि अगर HAProxy nginx और nginx पर एक त्रुटि देता है, तो सब कुछ ठीक हो जाएगा। वास्तव में नहीं। आप एक और HAProxy और एक ही बैकएंड पर जा सकते हैं, क्योंकि बैकेंड पूल समान हैं। तो आप अपने लिए एक और स्तर का अमूर्त परिचय देते हैं, जो आपके संतुलन की सटीकता को कम करता है और, तदनुसार, सेवा की उपलब्धता।

हमारे पास nginx + Envoy है, लेकिन यदि आप भ्रमित हो जाते हैं, तो आप खुद को केवल Envoy तक सीमित कर सकते हैं।

किस तरह का दूत?

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

मैं आपको उसके बन्स के बारे में कुछ शब्द बताऊंगा।

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

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

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


सर्किट ब्रेकर (हिस्टिक्स लाइक लिबास), मूल eBay के ब्लॉग पर।

ऊपर हिस्ट्रिक्स सर्किट ब्रेकर सर्किट है। हिस्टिक्स नेटफ्लिक्स की जावा लाइब्रेरी है जिसे फॉल्ट टॉलरेंस पैटर्न को लागू करने के लिए बनाया गया है।

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

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

आपके पास रिट्रीट नहीं थे, कुछ विस्फोट हो गया - रिट्रीट भेजें। दूत समझता है कि एन से अधिक असामान्य है, और सभी अनुरोधों को एक त्रुटि के साथ शूट किया जाना चाहिए।

सर्किट ब्रेकिंग [दूत]

• क्लस्टर (अपस्ट्रीम समूह) अधिकतम कनेक्शन
• क्लस्टर अधिकतम लंबित अनुरोध
• क्लस्टर अधिकतम अनुरोध
• क्लस्टर अधिकतम सक्रिय पुनर्प्रयास

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

सर्किट ब्रेकर: हमारा अनुभव

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

और एजेंट लगातार हमें डेटा भेजने का प्रयास करते हैं, वे इस बात से परेशान नहीं होते कि हम किसी तरह से गलत जवाब देते हैं, और नहीं छोड़ते।

( , ) , , .

nginx limit req. , , , 200 RPS. , , , limit req.

TCP HTTP ( nginx limit req). . limit req .

, , . Circuit breaker, , N , , - , , . , , spool .

Circuit breaker + request cancellation ( ). , N Cassandra, N Elastic, , — , . — , .





, (: — «», — «»). , 800 RPS 20-30. «», , .

— , .

, , — . .

, , , , Health checks — HTTP 200.

.



Load Balancer, 3 , Cassandra. Cassandra, Cassandra , Cassandra data noda.

— : kernel: NETDEV WATCHDOG: eth0 (ixgbe): transmit queue 3 timed out.

: ( ), 64 . , 1/64 . reboot, .

, , , . , , , . , , . , .

Cassandra: coordinator -> nodes

Cassandra, (speculative retries), . latency 99 , .

App -> cassandra coordinator

. Cassandra «» , , , latency ..

gocql — cassandra client. . HostSelectionPolicy, bitly/go-hostpool . Epsilon greedy , .

, Epsilon-greedy .

(multi-armed bandit): , , N .

:

1. « explore» — : 10 , , .
   
2. « exploit» — .
   

, (10 — 30%) round - robin , , , . 70 — 90% .

Host-pool . . ( — , , ). . , , , .

«» () —Cassandra Cassandra coordinator-data. (nginx, Envoy — ) «» Application, Cassandra , , .

Envoy Outlier detection :

• Consecutive http-5xx.
• Consecutive gateway errors (502,503,504).
• Success rate.

«» , - , . , . — , , . , , .

, «», max_ejection_percent. , outlier, . , 70% — , — , !

, — !

, , . , latency , :

• , ..
• , -, .

, , . , , , — , .

. 99% nginx/ HAProxy /Envoy. proxy , «».

proxy ( HAProxy:)), , .

DevOpsConf Russia Kubernetes . .

, — DevOps.

, , YouTube- — .