एक मोनोलिथिक आर्किटेक्चर के लिए एक अखंड अनुप्रयोग से संक्रमण की प्रक्रिया में, हमें नई समस्याओं का सामना करना पड़ रहा है।

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

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

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

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

सेवा जाल दृष्टिकोण

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

समाधान

इस दृष्टिकोण के पहले से ही कई कार्यान्वयन हैं: Istio और linkerd2 । वे कई सुविधाएँ बॉक्स से बाहर प्रदान करते हैं। लेकिन एक ही समय में संसाधनों के लिए एक बड़ा उपरि आता है। इसके अलावा, बड़ा क्लस्टर जिसमें ऐसी प्रणाली काम करती है, नए बुनियादी ढांचे को बनाए रखने के लिए अधिक संसाधनों की आवश्यकता होगी। एविटो में, हम हजारों सेवा उदाहरणों के साथ कुबेरनेट क्लस्टर का संचालन करते हैं (और उनकी संख्या तेजी से बढ़ रही है)। वर्तमान कार्यान्वयन में, Istio प्रति सेवा उदाहरण में ~ 300Mb RAM की खपत करता है। बड़ी संख्या में सुविधाओं के कारण, पारदर्शी संतुलन सेवाओं की कुल प्रतिक्रिया समय (10ms तक) को भी प्रभावित करता है।

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

अंत में, हम अपने निर्णय पर आए: नेत्रम ।

Netramesh

Netramesh सिस्टम में सेवाओं की संख्या की परवाह किए बिना अनंत मापनीयता के साथ एक हल्का सेवा जाल समाधान है।

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

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

उत्पादकता

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

आइए देखें कि परिणाम क्या हैं।

रैम

Netramesh बिना ट्रैफ़िक के ~ 10Mb और प्रति माह 10,000 RPS तक के भार के साथ अधिकतम 50Mb खपत करता है।

इस्तियो दूत प्रॉक्सी हमेशा हमारे समूहों में हजारों उदाहरणों के साथ ~ 300Mb की खपत करता है। यह आपको पूरे क्लस्टर में स्केल करने की अनुमति नहीं देता है।

Netramesh के साथ, हमें ~ 10 गुना कम मेमोरी खपत मिली।

सीपीयू

सीपीयू का उपयोग लोड के तहत अपेक्षाकृत बराबर है। यह प्रति इकाई समय अनुरोधों की संख्या पर निर्भर करता है। प्रति सेकंड 3000 अनुरोधों का मान शिखर पर:

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

हम सेवाओं के बीच संवाद करने के लिए HTTP / 1 का उपयोग करते हैं। इस्तियो के लिए प्रतिक्रिया समय में वृद्धि जब दूत के माध्यम से 5-10 5-10 तक की थी, जो कि एक मिलीसेकंड में जवाब देने के लिए तैयार सेवाओं के लिए काफी है। नेत्रम के साथ, यह समय घटकर 0.5-2ms हो गया।

scalability

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

सेवा खोज

Netramesh सेवा खोज के लिए कोई अतिरिक्त तंत्र नहीं जोड़ता है। सभी ट्रैफ़िक को नेट्रा साइडकार के माध्यम से पारदर्शी रूप से अनुमानित किया गया है।

Netramesh HTTP / 1 एप्लिकेशन प्रोटोकॉल का समर्थन करता है। इसे निर्धारित करने के लिए बंदरगाहों की एक विन्यास योग्य सूची का उपयोग किया जाता है। आमतौर पर, एक सिस्टम पर कई पोर्ट होते हैं जो HTTP पर संचार करते हैं। उदाहरण के लिए, हम सेवाओं और बाहरी अनुरोधों की बातचीत के लिए 80, 8890, 8080 का उपयोग करते हैं। इस मामले में, उन्हें NETRA_HTTP_PORTS पर्यावरण NETRA_HTTP_PORTS का उपयोग करके सेट किया जा सकता है।

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

वितरित अनुरेखण और संदर्भ स्क्रॉल

Netramesh HTTP इंटरैक्शन के बारे में ट्रेसिंग स्पैन भेजने के लिए आवश्यक कार्यक्षमता प्रदान करता है। Netra-sidecar HTTP प्रोटोकॉल को पार्स करता है, अनुरोधों की देरी को मापता है, HTTP हेडर से आवश्यक जानकारी प्राप्त करता है। अंत में, हम एक एकल Jaeger प्रणाली में सभी निशान प्राप्त करते हैं। फाइन- ट्यूनिंग के लिए, आप आधिकारिक जॅगर गो लाइब्रेरी द्वारा प्रदान किए गए पर्यावरण चर का उपयोग कर सकते हैं ।

लेकिन एक समस्या है। जब तक सेवाएं उत्पन्न नहीं होती हैं और एक विशेष uber हेडर को आगे बढ़ाया जाता है, तब तक हम सिस्टम में कनेक्टेड ट्रेसिंग स्पैन नहीं देखेंगे। और यही वह है जो हमें समस्याओं का कारण खोजने की आवश्यकता है। यहां पर नेत्राेश के पास फिर से समाधान है। प्रॉक्सी HTTP हेडर पढ़ता है और, यदि उनके पास uber ट्रेस आईडी नहीं है, तो इसे जनरेट करें। Netramesh भी साइडकार में आने वाले और बाहर जाने वाले अनुरोधों के बारे में जानकारी संग्रहीत करता है और आउटगोइंग अनुरोधों के आवश्यक हेडर को समृद्ध करके उनकी तुलना करता है। सेवाओं में जो कुछ भी करने की आवश्यकता है वह सिर्फ एक X-Request-Id हेडर को फेंकने के लिए है, जिसे NETRA_HTTP_REQUEST_ID_HEADER_NAME परिवेश NETRA_HTTP_REQUEST_ID_HEADER_NAME का उपयोग करके कॉन्फ़िगर किया जा सकता है। Netramesh में संदर्भ के आकार को नियंत्रित करने के लिए, आप निम्न वातावरण चर सेट कर सकते हैं: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (उस समय के दौरान संदर्भ संग्रहीत किया जाएगा) और NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (संदर्भ सफाई की आवधिकता)।

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

अनुरोध के स्रोत का निर्धारण

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

यह आपको पूरे नेटवर्क में समान रूप से इस उपयोगी हेडर के वितरण को बनाने की अनुमति देता है। फिर आप पहले से ही इसे सेवाओं में उपयोग कर सकते हैं और इसे लॉग और मैट्रिक्स में जोड़ सकते हैं।

Netramesh ट्रैफ़िक और इंटर्नल्स रूटिंग

Netramesh में दो मुख्य घटक होते हैं। पहला, नेट्रा-इनिट, यातायात को बाधित करने के लिए नेटवर्क नियम स्थापित करता है। यह फुटपाथ पर यातायात के सभी या अवरोधन को बाधित करने के लिए iptables पुनर्निर्देशन नियमों का उपयोग करता है, जो कि नेत्राे का दूसरा मुख्य घटक है। आप इनकमिंग और आउटगोइंग टीसीपी सत्रों के लिए कौन से पोर्ट इंटरसेप्ट करना चाहते हैं, इसे कॉन्फ़िगर कर सकते हैं: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS ।

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

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

एक निर्भरता ग्राफ का निर्माण

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

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

Netramesh का उपयोग कैसे करें

Netra को किसी भी आर्केस्ट्रा चलाने वाली सेवा में आसानी से जोड़ा जा सकता है। आप यहां एक उदाहरण देख सकते हैं।

फिलहाल, नेट्रा में स्वचालित रूप से सेवाओं के लिए साइडकार तैनात करने की क्षमता नहीं है, लेकिन कार्यान्वयन के लिए योजनाएं हैं।

भविष्य के नेताराम

Netramesh का मुख्य लक्ष्य न्यूनतम संसाधन लागत और उच्च प्रदर्शन प्राप्त करना है, जो चौराहे की बातचीत के अवलोकन और नियंत्रण के मुख्य अवसर प्रदान करता है।

भविष्य में, Netramesh को HTTP के अलावा एप्लिकेशन-स्तरीय प्रोटोकॉल के लिए समर्थन प्राप्त होगा। निकट भविष्य में L7 रूटिंग की संभावना होगी।

यदि आप इसी तरह की समस्याओं का सामना करते हैं और हमें सवाल और सुझाव लिखते हैं तो नेट्रैम का उपयोग करें।