जसे आपण एका मोनोलिथिक ऍप्लिकेशनमधून मायक्रोसर्व्हिसेस आर्किटेक्चरकडे जात आहोत, तेव्हा आपल्याला नवीन आव्हानांचा सामना करावा लागतो.

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

अशा समस्यांचा सामना करण्यास मदत करणारे साधन मी बर्याच काळापासून शोधत आहे (मी याबद्दल हॅब्रेवर लिहिले: 1, 2), पण शेवटी मी माझे स्वतःचे ओपन सोर्स सोल्यूशन बनवले. या लेखात मी सेवा जाळीच्या दृष्टिकोनाच्या फायद्यांबद्दल बोलतो आणि त्याच्या अंमलबजावणीसाठी एक नवीन साधन सामायिक करतो.

वितरित ट्रेसिंग हे वितरित सिस्टममधील त्रुटी शोधण्याच्या समस्येचे एक सामान्य समाधान आहे. परंतु नेटवर्क परस्परसंवादांबद्दल माहिती गोळा करण्याचा हा दृष्टीकोन अद्याप सिस्टममध्ये लागू केला गेला नसेल किंवा सर्वात वाईट म्हणजे, सिस्टमच्या काही भागांमध्ये ते आधीपासूनच योग्यरित्या कार्य करते, परंतु काही प्रमाणात ते जुन्या सेवांमध्ये जोडले गेले नसल्यामुळे काय केले जाते. ? समस्येचे नेमके मूळ कारण निश्चित करण्यासाठी, सिस्टममध्ये काय घडत आहे याचे संपूर्ण चित्र असणे आवश्यक आहे. मुख्य व्यवसाय-गंभीर मार्गांमध्ये कोणत्या सूक्ष्म सेवांचा समावेश आहे हे समजून घेणे विशेषतः महत्वाचे आहे.

येथे सेवा जाळीचा दृष्टीकोन आमच्या मदतीला येऊ शकतो, जो नेटवर्क माहिती संकलित करण्यासाठी सर्व यंत्रसामग्री स्वत: चालवल्या जाणाऱ्या सेवांपेक्षा कमी स्तरावर हाताळेल. हा दृष्टीकोन आम्हाला सर्व ट्रॅफिकमध्ये अडथळा आणू शकतो आणि फ्लायवर त्याचे विश्लेषण करू देतो. शिवाय, अनुप्रयोगांना याबद्दल काहीही माहित असणे आवश्यक नाही.

सेवा जाळी दृष्टीकोन

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

उपाय

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

परिणामी, आत्ता आम्हाला नेमक्या कोणत्या क्षमतांची गरज आहे हे आम्ही पाहिले आणि ठरवले की आम्ही अशा उपायांची अंमलबजावणी सुरू करण्याचे मुख्य कारण म्हणजे संपूर्ण सिस्टममधून पारदर्शकपणे ट्रेसिंग माहिती गोळा करण्याची क्षमता. आम्हाला सेवांच्या परस्परसंवादावर नियंत्रण हवे होते आणि सेवांमध्ये हस्तांतरित केलेल्या शीर्षलेखांसह विविध फेरफार करायचे होते.

परिणामी, आम्ही आमच्या निर्णयावर आलो:  नेत्रमेश.

नेत्रमेश

नेत्रमेश सिस्टीममधील सेवांची संख्या विचारात न घेता, असीम प्रमाणात मोजण्याची क्षमता असलेले हलके सेवा जाळीचे समाधान आहे.

नवीन सोल्यूशनची मुख्य उद्दिष्टे कमी संसाधन ओव्हरहेड आणि उच्च कार्यक्षमता होती. मुख्य वैशिष्ट्यांपैकी, आम्हाला आमच्या जेगर सिस्टीमवर पारदर्शकपणे ट्रेसिंग स्पॅन पाठवता यायचे होते.

आज, बहुतेक क्लाउड सोल्यूशन्स गोलंगमध्ये लागू केले जातात. आणि, अर्थातच, याची कारणे आहेत. गोलंगमध्‍ये I/O सह समकालिकपणे कार्य करणारे नेटवर्क ऍप्लिकेशन्स लिहिणे आणि आवश्यकतेनुसार कोरमध्ये स्केल करणे सोयीचे आणि अगदी सोपे आहे. आणि, काय खूप महत्वाचे आहे, या समस्येचे निराकरण करण्यासाठी कार्यप्रदर्शन पुरेसे आहे. म्हणूनच आम्हीही गोलंगची निवड केली.

उत्पादकता

जास्तीत जास्त उत्पादकता मिळविण्यावर आम्ही आमचे प्रयत्न केंद्रित केले आहेत. सेवेच्या प्रत्येक उदाहरणाशेजारी उपयोजित केलेल्या सोल्यूशनसाठी, RAM आणि CPU वेळेचा थोडासा वापर आवश्यक आहे. आणि, अर्थातच, प्रतिसाद विलंब देखील लहान असावा.

आम्हाला काय परिणाम मिळाले ते पाहूया.

रॅम

नेत्रमेश ट्रॅफिकशिवाय ~10Mb वापरतो आणि प्रति उदाहरण 50 RPS पर्यंत लोडसह 10000Mb जास्तीत जास्त वापरतो.

आमच्या क्लस्टर्समध्ये हजारो उदाहरणांसह Istio envoy प्रॉक्सी नेहमी ~300Mb वापरते. हे त्यास संपूर्ण क्लस्टरमध्ये मोजले जाऊ देत नाही.

नेत्रमेशसह आम्हाला मेमरी वापरामध्ये ~ 10x कपात मिळाली.

सीपीयू

CPU वापर लोड अंतर्गत तुलनेने समान आहे. हे साइडकारला प्रति युनिट वेळेच्या विनंत्यांच्या संख्येवर अवलंबून असते. शिखरावर प्रति सेकंद 3000 विनंत्यांची मूल्ये:

आणखी एक महत्त्वाचा मुद्दा आहे: नेत्रमेश - कंट्रोल प्लेनशिवाय आणि लोडशिवाय एक उपाय CPU वेळ वापरत नाही. Istio सह, साइडकार नेहमी सर्व्हिस एंडपॉइंट अपडेट करतात. परिणामी, आम्ही हे चित्र लोडशिवाय पाहू शकतो:

सेवांमधील संवादासाठी आम्ही HTTP/1 वापरतो. दूताद्वारे प्रॉक्सी करताना Istio साठी प्रतिसाद वेळेत झालेली वाढ 5-10ms पर्यंत होती, जी मिलिसेकंदात प्रतिसाद देण्यासाठी तयार असलेल्या सेवांसाठी खूप आहे. नेत्रमेशसह ही वेळ 0.5-2ms पर्यंत कमी झाली आहे.

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

प्रत्येक प्रॉक्सीद्वारे वापरल्या जाणार्‍या संसाधनांच्या थोड्या प्रमाणात ते प्रत्येक सेवेच्या पुढे ठेवणे शक्य होते. नेत्रमेश हे जाणूनबुजून प्रत्येक साइडकार हलके ठेवण्यासाठी कंट्रोल प्लेन घटकाशिवाय तयार केले गेले. बर्‍याचदा सर्व्हिस मेश सोल्यूशन्समध्ये, कंट्रोल प्लेन प्रत्येक साइडकारला सेवा शोध माहिती वितरीत करते. सोबतच टाइमआउट्स आणि बॅलन्सिंग सेटिंग्जची माहिती मिळते. हे सर्व आपल्याला बर्‍याच उपयुक्त गोष्टी करण्यास अनुमती देते, परंतु, दुर्दैवाने, ते आकारात साइडकार फुलवते.

सेवा शोध

नेत्रमेश सेवा शोधासाठी कोणतीही अतिरिक्त यंत्रणा जोडत नाही. नेत्रा साइडकारद्वारे सर्व वाहतूक पारदर्शकपणे प्रॉक्सी केली जाते.

नेत्रमेश HTTP/1 ऍप्लिकेशन प्रोटोकॉलला सपोर्ट करतो. ते परिभाषित करण्यासाठी, पोर्ट्सची कॉन्फिगर करण्यायोग्य सूची वापरली जाते. सामान्यतः, सिस्टममध्ये अनेक पोर्ट असतात ज्याद्वारे HTTP संप्रेषण होते. उदाहरणार्थ, आम्ही सेवा आणि बाह्य विनंत्यांमधील परस्परसंवादासाठी 80, 8890, 8080 वापरतो. या प्रकरणात, ते पर्यावरण व्हेरिएबल वापरून सेट केले जाऊ शकतात NETRA_HTTP_PORTS.

जर तुम्ही ऑर्केस्ट्रेटर म्हणून Kubernetes आणि सेवांमधील इंट्रा-क्लस्टर संप्रेषणासाठी त्याची सेवा संस्था यंत्रणा वापरत असाल, तर यंत्रणा अगदी तशीच राहते. प्रथम, मायक्रोसर्व्हिस kube-dns वापरून सेवा IP पत्ता प्राप्त करते आणि त्यास नवीन कनेक्शन उघडते. हे कनेक्शन प्रथम स्थानिक नेत्रा-साइडकारसह स्थापित केले जाते आणि सर्व TCP पॅकेट सुरुवातीला नेत्रा येथे येतात. पुढे, नेट्रा-साइडकार मूळ गंतव्यस्थानाशी संबंध स्थापित करते. नोडवरील पॉड आयपीवरील NAT नेत्राशिवाय बरोबरच राहते.

वितरित ट्रेसिंग आणि संदर्भ फॉरवर्डिंग

नेत्रमेश HTTP परस्परसंवादांबद्दल ट्रेसिंग स्पॅन पाठवण्यासाठी आवश्यक कार्यक्षमता प्रदान करते. Netra-sidecar HTTP प्रोटोकॉल पार्स करते, विनंती विलंब मोजते आणि HTTP शीर्षलेखांमधून आवश्यक माहिती काढते. शेवटी, आम्हाला एकाच जेगर प्रणालीमध्ये सर्व ट्रेस मिळतात. सुक्ष्म कॉन्फिगरेशनसाठी, तुम्ही अधिकृत लायब्ररीद्वारे प्रदान केलेले पर्यावरण व्हेरिएबल्स देखील वापरू शकता jaeger go library.

पण एक अडचण आहे. जोपर्यंत सेवा विशेष उबर हेडर तयार करत नाहीत आणि पाठवत नाहीत, तोपर्यंत आम्हाला सिस्टममध्ये कनेक्ट केलेले ट्रेसिंग स्पॅन दिसणार नाहीत. आणि आपल्याला समस्यांचे कारण त्वरीत शोधण्याची गरज आहे. इथे पुन्हा नेत्रमेशकडे उपाय आहे. प्रॉक्सी HTTP शीर्षलेख वाचतात आणि, त्यांच्यात uber ट्रेस आयडी नसल्यास, एक व्युत्पन्न करतात. नेत्रमेश इनकमिंग आणि आउटगोइंग विनंत्यांची माहिती साइडकारमध्ये संग्रहित करते आणि आवश्यक आउटगोइंग विनंती शीर्षलेखांसह त्यांना समृद्ध करून जुळवते. सेवांमध्ये तुम्हाला फक्त एक शीर्षलेख पाठवायचा आहे X-Request-Id, जे पर्यावरण व्हेरिएबल वापरून कॉन्फिगर केले जाऊ शकते NETRA_HTTP_REQUEST_ID_HEADER_NAME. नेत्रमेशमधील संदर्भाचा आकार नियंत्रित करण्यासाठी, तुम्ही खालील पर्यावरणीय चल सेट करू शकता: 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-स्रोत शीर्षलेख सेट केले जाईल असे मूल्य तुम्ही सेट करू शकता.

हे या उपयुक्त शीर्षलेखाचे वितरण संपूर्ण नेटवर्कमध्ये समान रीतीने वितरित करण्यास अनुमती देते. मग तुम्ही ते सेवांमध्ये वापरू शकता आणि लॉग आणि मेट्रिक्समध्ये जोडू शकता.

वाहतूक मार्ग आणि नेत्रमेश अंतर्गत

नेत्रमेशमध्ये दोन मुख्य घटक असतात. पहिले, नेट्रा-इनिट, रहदारी रोखण्यासाठी नेटवर्क नियम सेट करते. तो वापरतो iptables पुनर्निर्देशित नियम नेत्रमेशचा दुसरा मुख्य घटक असलेल्या साइडकारवरील सर्व किंवा काही भाग ट्रॅफिकमध्ये अडथळा आणणे. इनकमिंग आणि आउटगोइंग टीसीपी सेशनसाठी कोणते पोर्ट इंटरसेप्ट करावे लागेल हे तुम्ही कॉन्फिगर करू शकता: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.

टूलमध्ये एक मनोरंजक वैशिष्ट्य देखील आहे - संभाव्य राउटिंग. जर तुम्ही ट्रेसिंग स्पॅन्स गोळा करण्यासाठी नेत्रमेश वापरत असाल, तर उत्पादन वातावरणात तुम्ही संसाधने वाचवू शकता आणि व्हेरिएबल्स वापरून संभाव्य राउटिंग सक्षम करू शकता. NETRA_INBOUND_PROBABILITY и NETRA_OUTBOUND_PROBABILITY (0 ते 1 पर्यंत). डीफॉल्ट मूल्य 1 आहे (सर्व रहदारी रोखली आहे).

यशस्वी इंटरसेप्शननंतर, नेत्रा साइडकार नवीन कनेक्शन स्वीकारते आणि वापरते SO_ORIGINAL_DST मूळ गंतव्यस्थान मिळविण्यासाठी सॉकेट पर्याय. नेत्रा नंतर मूळ IP पत्त्यावर एक नवीन कनेक्शन उघडते आणि पक्षांमधील द्वि-मार्गी TCP संप्रेषण स्थापित करते, त्यामधून जाणारी सर्व रहदारी ऐकते. जर पोर्ट HTTP म्हणून परिभाषित केले असेल, तर नेत्रा त्याचे विश्लेषण आणि ट्रेस करण्याचा प्रयत्न करते. HTTP पार्सिंग अयशस्वी झाल्यास, नेत्रा TCP वर परत येते आणि पारदर्शकपणे बाइट्स प्रॉक्सी करते.

अवलंबित्व आलेख तयार करणे

Jaeger मध्ये मोठ्या प्रमाणात ट्रेसिंग माहिती मिळाल्यानंतर, मला सिस्टममधील परस्परसंवादांचा संपूर्ण आलेख मिळवायचा आहे. परंतु जर तुमची सिस्टीम बर्‍यापैकी लोड केलेली असेल आणि दररोज कोट्यवधी ट्रेसिंग स्पॅन जमा होत असतील तर त्यांना एकत्रित करणे इतके सोपे काम नाही. हे करण्याचा अधिकृत मार्ग आहे: स्पार्क-अवलंबन. तथापि, संपूर्ण आलेख तयार करण्यासाठी काही तास लागतील आणि तुम्हाला मागील २४ तासांचा संपूर्ण डेटासेट Jaeger वरून डाउनलोड करण्यास भाग पाडेल.

तुम्ही ट्रेसिंग स्पॅन्स साठवण्यासाठी Elasticsearch वापरत असल्यास, तुम्ही वापरू शकता एक साधी गोलंग उपयुक्तता, जे Elasticsearch ची वैशिष्ट्ये आणि क्षमता वापरून मिनिटांत समान आलेख तयार करेल.

नेत्रमेश कसे वापरावे

कोणत्याही ऑर्केस्ट्रेटरवर चालणाऱ्या कोणत्याही सेवेमध्ये नेत्रा सहज जोडता येते. आपण एक उदाहरण पाहू शकता येथे.

याक्षणी, नेत्रा कडे सेवांसाठी साइडकार स्वयंचलितपणे लागू करण्याची क्षमता नाही, परंतु अंमलबजावणीसाठी योजना आहेत.

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

मुख्य ध्येय नेत्रमेश किमान संसाधन खर्च आणि उच्च कार्यप्रदर्शन साध्य करणे, निरीक्षणक्षमता आणि आंतर-सेवा संप्रेषणाच्या नियंत्रणासाठी मूलभूत क्षमता प्रदान करणे.

भविष्यात, नेत्रमेश HTTP व्यतिरिक्त इतर ऍप्लिकेशन लेयर प्रोटोकॉलला सपोर्ट करेल. L7 राउटिंग नजीकच्या भविष्यात उपलब्ध होईल.

तुम्हाला अशाच प्रकारच्या समस्या येत असल्यास नेत्रमेश वापरा आणि आम्हाला प्रश्न आणि सूचना लिहा.

स्त्रोत: www.habr.com