हामी मोनोलिथिक एप्लिकेसनबाट माइक्रोसर्भिसेस आर्किटेक्चरमा जाँदा, हामीले नयाँ चुनौतीहरूको सामना गर्छौं।

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

म यस्तो समस्याहरूको सामना गर्न मद्दत गर्ने उपकरणको लागि लामो समयदेखि खोज्दै छु (मैले यस बारे Habré मा लेखेको छु: 1, 2), तर अन्तमा मैले मेरो आफ्नै खुला स्रोत समाधान गरें। यस लेखमा म सेवा जाल दृष्टिकोण को फाइदाहरु को बारे मा कुरा गर्छु र यसको कार्यान्वयन को लागी एक नयाँ उपकरण साझा।

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

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

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

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

समाधानहरू

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

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

नतिजाको रूपमा, हामी हाम्रो निर्णयमा पुग्यौं:  नेत्रमेश.

नेत्रमेश

नेत्रमेश प्रणालीमा सेवाहरूको संख्यालाई ध्यान नदिई असीम मापन गर्ने क्षमताको साथ एक हल्का सेवा जाल समाधान हो।

नयाँ समाधानको मुख्य लक्ष्यहरू कम स्रोत ओभरहेड र उच्च प्रदर्शन थिए। मुख्य सुविधाहरू मध्ये, हामी तुरुन्तै हाम्रो Jaeger प्रणालीमा पारदर्शी रूपमा ट्रेसिङ स्प्यानहरू पठाउन सक्षम हुन चाहन्थ्यौं।

आज, अधिकांश क्लाउड समाधानहरू Golang मा लागू गरिएको छ। र, निस्सन्देह, यसको लागि कारणहरू छन्। Golang मा सञ्जाल अनुप्रयोगहरू लेख्न जुन I/O सँग एसिन्क्रोनस रूपमा काम गर्दछ र आवश्यकता अनुसार कोरहरू मापन गर्न सुविधाजनक र एकदम सरल छ। र, के पनि धेरै महत्त्वपूर्ण छ, प्रदर्शन यो समस्या समाधान गर्न पर्याप्त छ। त्यसैले हामीले गोलाङलाई पनि रोज्यौं।

उत्पादकता

हामीले अधिकतम उत्पादकत्व हासिल गर्न हाम्रो प्रयासलाई केन्द्रित गरेका छौं। सेवाको प्रत्येक उदाहरणको छेउमा तैनाथ गरिएको समाधानको लागि, RAM र CPU समयको सानो खपत आवश्यक छ। र, निस्सन्देह, प्रतिक्रिया ढिलाइ पनि सानो हुनुपर्छ।

हेरौं नतिजा के भयो।

राम

Netramesh ले ट्राफिक बिना ~ 10Mb खपत गर्छ र 50Mb अधिकतम 10000 RPS प्रति उदाहरण लोड हुन्छ।

Istio envoy proxy ले हाम्रा क्लस्टरहरूमा हजारौं उदाहरणहरूमा सधैं ~300Mb खपत गर्छ। यसले यसलाई सम्पूर्ण क्लस्टरमा मापन गर्न अनुमति दिँदैन।

नेत्रमेशसँग हामीले मेमोरी खपतमा ~10x कमी पायौं।

CPU

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

त्यहाँ अर्को महत्त्वपूर्ण बिन्दु छ: Netramesh - एक नियन्त्रण विमान बिना समाधान र लोड बिना CPU समय खपत गर्दैन। Istio संग, sidecars सधैं सेवा समाप्ति बिन्दुहरू अद्यावधिक। नतिजाको रूपमा, हामी लोड बिना यो तस्वीर देख्न सक्छौं:

हामी सेवाहरू बीच सञ्चारको लागि HTTP/1 प्रयोग गर्छौं। दूत मार्फत प्रोक्सी गर्दा Istio को लागि प्रतिक्रिया समय मा वृद्धि 5-10ms सम्म थियो, जुन एक मिलिसेकेन्ड मा प्रतिक्रिया गर्न तयार सेवाहरु को लागी धेरै धेरै छ। नेत्रमेशको साथ यो समय ०.५-२ मिलिएसमा घटेको छ।

स्केलेबिलिटी

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

सेवा आविष्कार

नेत्रमेशले सेवा खोजको लागि कुनै पनि अतिरिक्त संयन्त्र थप्दैन। सबै यातायात नेत्रा साइडकार मार्फत पारदर्शी रूपमा प्रोक्सी गरिएको छ।

Netramesh HTTP/1 अनुप्रयोग प्रोटोकल समर्थन गर्दछ। यसलाई परिभाषित गर्न, पोर्टहरूको कन्फिगर योग्य सूची प्रयोग गरिन्छ। सामान्यतया, प्रणालीमा धेरै पोर्टहरू छन् जसको माध्यमबाट HTTP संचार हुन्छ। उदाहरणका लागि, हामी सेवाहरू र बाह्य अनुरोधहरू बीच अन्तरक्रियाको लागि 80, 8890, 8080 प्रयोग गर्छौं। यस अवस्थामा, तिनीहरू वातावरण चर प्रयोग गरेर सेट गर्न सकिन्छ। NETRA_HTTP_PORTS.

यदि तपाइँ कुबर्नेट्सलाई अर्केस्ट्रेटरको रूपमा प्रयोग गर्नुहुन्छ र सेवाहरू बीचको अन्तर-क्लस्टर सञ्चारको लागि यसको सेवा निकाय संयन्त्रको रूपमा, तब संयन्त्र ठ्याक्कै उस्तै रहन्छ। पहिले, माइक्रोसर्भिसले kube-dns प्रयोग गरेर सेवा IP ठेगाना प्राप्त गर्छ र यसमा नयाँ जडान खोल्छ। यो जडान पहिलो पटक स्थानीय नेत्रा-साइडकारसँग स्थापित हुन्छ र सबै TCP प्याकेटहरू सुरुमा नेत्रामा आइपुग्छन्। अर्को, नेट्रा-साइडकारले मूल गन्तव्यसँग जडान स्थापित गर्दछ। नोडमा पोड आईपीमा NAT ठ्याक्कै नेट्रा बिना जस्तै रहन्छ।

वितरित ट्रेसिङ र सन्दर्भ फर्वार्डिङ

नेत्रमेशले HTTP अन्तरक्रियाहरू बारे ट्रेसिङ स्प्यानहरू पठाउन आवश्यक कार्यक्षमता प्रदान गर्दछ। नेट्रा-साइडकारले HTTP प्रोटोकल पार्स गर्दछ, अनुरोध ढिलाइ उपाय गर्दछ, र HTTP हेडरहरूबाट आवश्यक जानकारी निकाल्छ। अन्ततः, हामीले एकल जेगर प्रणालीमा सबै ट्रेसहरू पाउँछौं। फाइन-ग्रेन्ड कन्फिगरेसनको लागि, तपाईंले आधिकारिक पुस्तकालयद्वारा प्रदान गरिएको वातावरणीय चरहरू पनि प्रयोग गर्न सक्नुहुन्छ। jaeger go पुस्तकालय.

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

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

अनुरोध स्रोत निर्धारण गर्दै

अनुरोध कहाँबाट आयो भनेर निर्धारण गर्न, तपाइँ स्रोतको साथ स्वचालित रूपमा हेडर थप्ने कार्यक्षमता प्रयोग गर्न सक्नुहुन्छ। वातावरण चर प्रयोग गर्दै NETRA_HTTP_X_SOURCE_HEADER_NAME तपाईले हेडर नाम निर्दिष्ट गर्न सक्नुहुन्छ जुन स्वचालित रूपमा स्थापित हुनेछ। प्रयोग गरेर NETRA_HTTP_X_SOURCE_VALUE तपाईले सबै बहिर्गमन अनुरोधहरूको लागि X-स्रोत हेडर सेट गरिने मान सेट गर्न सक्नुहुन्छ।

यसले यो उपयोगी हेडरको वितरणलाई नेटवर्कमा समान रूपमा वितरण गर्न अनुमति दिन्छ। त्यसपछि तपाइँ यसलाई सेवाहरूमा प्रयोग गर्न सक्नुहुन्छ र लग र मेट्रिक्समा थप्न सक्नुहुन्छ।

ट्राफिक मार्ग र नेत्रमेश आन्तरिक

नेत्रमेश दुई मुख्य घटकहरू मिलेर बनेको छ। पहिलो, netra-init, ट्राफिक अवरोध गर्न नेटवर्क नियमहरू सेट गर्दछ। उसले प्रयोग गर्छ iptables नियमहरू पुन: निर्देशित गर्दछ नेत्रमेशको दोस्रो मुख्य कम्पोनेन्ट हो, साइडकारमा ट्राफिकको सबै वा केही अंश रोक्न। तपाईंले आगमन र बाहिर जाने TCP सत्रहरूको लागि कुन पोर्टहरू अवरोध गर्न आवश्यक छ कन्फिगर गर्न सक्नुहुन्छ: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.

उपकरणमा एक रोचक सुविधा पनि छ - सम्भावित मार्ग। यदि तपाइँ ट्रेसिङ स्प्यानहरू सङ्कलन गर्नको लागि विशेष रूपमा नेत्रमेश प्रयोग गर्नुहुन्छ भने, त्यसपछि उत्पादन वातावरणमा तपाइँ स्रोतहरू बचत गर्न सक्नुहुन्छ र भेरिएबलहरू प्रयोग गरेर सम्भाव्य रूटिङ सक्षम गर्न सक्नुहुन्छ। NETRA_INBOUND_PROBABILITY и NETRA_OUTBOUND_PROBABILITY (० देखि १ सम्म)। पूर्वनिर्धारित मान 0 हो (सबै यातायात रोकिएको छ)।

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

निर्भरता ग्राफ निर्माण गर्दै

Jaeger मा ट्रेसिङ जानकारी को एक ठूलो मात्रा प्राप्त पछि, म प्रणाली मा अन्तरक्रिया को एक पूर्ण ग्राफ प्राप्त गर्न चाहन्छु। तर यदि तपाइँको प्रणाली धेरै लोड भएको छ र प्रति दिन अरबौं ट्रेसिङ स्प्यानहरू जम्मा हुन्छन् भने, तिनीहरूलाई जम्मा गर्नु त्यति सजिलो काम हुँदैन। यो गर्ने आधिकारिक तरिका हो: स्पार्क-निर्भरताहरू। जे होस्, यसले पूर्ण ग्राफ बनाउन घन्टा लाग्नेछ र तपाइँलाई विगत २४ घण्टाको लागि Jaeger बाट सम्पूर्ण डेटासेट डाउनलोड गर्न बाध्य पार्नेछ।

यदि तपाइँ ट्रेसिङ स्प्यानहरू भण्डारण गर्न Elasticsearch प्रयोग गर्दै हुनुहुन्छ भने, तपाइँ प्रयोग गर्न सक्नुहुन्छ एक साधारण Golang उपयोगिता, जसले Elasticsearch को सुविधाहरू र क्षमताहरू प्रयोग गरेर मिनेटमा समान ग्राफ निर्माण गर्नेछ।

Netramesh कसरी प्रयोग गर्ने

नेत्रा कुनै पनि अर्केस्ट्रेटर चलाउने कुनै पनि सेवामा सजिलै थप्न सकिन्छ। तपाईं एक उदाहरण देख्न सक्नुहुन्छ यहाँ.

हाल, नेत्रासँग सेवाहरूमा साइडकारहरू स्वचालित रूपमा लागू गर्ने क्षमता छैन, तर कार्यान्वयनका लागि योजनाहरू छन्।

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

मुख्य लक्ष्य नेत्रमेश न्यूनतम स्रोत लागत र उच्च कार्यसम्पादन हासिल गर्नु हो, अवलोकन योग्यता र अन्तर-सेवा सञ्चारको नियन्त्रणको लागि आधारभूत क्षमताहरू प्रदान गर्नु हो।

भविष्यमा, नेत्रमेशले HTTP बाहेक अन्य अनुप्रयोग तह प्रोटोकलहरूलाई समर्थन गर्नेछ। L7 राउटिङ निकट भविष्यमा उपलब्ध हुनेछ।

यदि तपाइँ समान समस्याहरू सामना गर्नुहुन्छ भने नेत्रमेश प्रयोग गर्नुहोस् र प्रश्न र सुझावहरूको साथ हामीलाई लेख्नुहोस्।

स्रोत: www.habr.com