मैट्रिक्स की सहायता के लिए uWSGI। यैंडेक्स रिपोर्ट

दूसरे दिन, मॉस्को पायथन मीटअप # 66 आयोजित किया गया था - समुदाय प्रासंगिक उपकरणों पर चर्चा करता है जो भाषा को बढ़ाते हैं और इसे विभिन्न वातावरणों के अनुकूल बनाते हैं। बैठक में शामिल, मेरी रिपोर्ट बनाई गई थी। मेरा नाम नेल है, मैं Yandex.Connect कर रहा हूं।



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

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

हम मेट्रिक्स के बारे में बात करेंगे, इन मेट्रिक्स को कैसे प्राप्त करें, हम अपनी टीम uWSGI में मेट्रिक्स प्राप्त करने के लिए एक उपकरण के रूप में कैसे उपयोग करते हैं, यह कैसे हमारी मदद करता है। तब मैं आपको एक छोटी अनुकूलन कहानी बताऊंगा।

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



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

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



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



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



हम उन्हें कैसे इकट्ठा कर सकते हैं? कई विकल्प हैं। मैं आपको पहले विकल्प के बारे में बताना चाहता हूं - एक पुश योजना। इसमें क्या शामिल है?

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

पुश योजनाओं का उपयोग करने का क्या फायदा है? हम एप्लिकेशन से सीधे मीट्रिक प्रणाली में कुछ मीट्रिक भेज सकते हैं, लेकिन साथ ही हमें मीट्रिक एकत्र करने के लिए किसी प्रकार का नेटवर्क इंटरैक्शन, लेटेंसी, ओवरहेड मिलता है। स्थानीय पुश क्लाइंट के मामले में, यह समतल है।



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



एक अन्य विकल्प लॉग है। हम सभी लॉग लिखते हैं और उन्हें कहीं भेजते हैं। कुछ भी हमें इन लॉग को लेने से रोकता है, किसी तरह उन्हें संसाधित करता है और लॉग के आधार पर मैट्रिक्स प्राप्त करता है।

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



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



यहां पुल योजना के लिए एक उदाहरण प्रतिक्रिया है जो हमारे मीट्रिक संग्रह प्रणाली को उम्मीद है।

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



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

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



यदि हम स्थानीय रूप से बचत करते हैं, तो एक नियम के रूप में, यह एक प्रक्रिया के साथ मामले के लिए उपयुक्त है। और हम, हमारे uWSGI में, समानांतर में कई प्रक्रियाएं चलाते हैं। या हम किसी प्रकार के साझा भंडारण का उपयोग कर सकते हैं। "साझा भंडारण" शब्द के साथ हमारे दिमाग में क्या आता है? यह किसी तरह का Redis, Memcached, relational या non-relational database या एक file है।



UWSGI के बारे में। मुझे आपको उन लोगों को याद दिलाना है जो इसे बहुत कम या शायद ही कभी उपयोग करते हैं: uWSGI एक एप्लिकेशन वेब सर्वर है जो आपको अपने साथ पायथन एप्लिकेशन चलाने की अनुमति देता है। यह इंटरफ़ेस को लागू करता है, uWSGI प्रोटोकॉल। यह प्रोटोकॉल PEP 333 में वर्णित है, जो रुचि रखते हैं, आप पढ़ सकते हैं।



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



प्रयोगों। हम अपने सिंथेटिक परीक्षणों के लिए एक सिंथेटिक अनुप्रयोग बनाएंगे, हम इसे एक टैंक के साथ खोल देंगे। UWSGI एप्लिकेशन में 10 श्रमिकों के साथ एक साधारण संघर्ष होगा।



यहाँ हमारा फ्लास्क ऐप है। पेलोड जो हमारा आवेदन करता है, हम एक खाली लूप का अनुकरण करेंगे।



हम फायर करते हैं, और Yandex.Tank हमें इनमें से एक ग्राफ देता है। वह क्या दिखा रहा है? प्रतिक्रिया समय के प्रतिशत। तिरछी रेखा आरपीएस है जो बढ़ रही है, और हिस्टोग्राम ऐसे हैं जो हमारे वेब सर्वर को ऐसे लोड के तहत फिट करते हैं।

हम इस विकल्प को संदर्भ के रूप में लेंगे और यह देखेंगे कि मैट्रिक्स को संग्रहीत करने के विभिन्न विकल्प प्रदर्शन को कैसे प्रभावित करते हैं।



सबसे सरल विकल्प PostgreSQL का उपयोग करना है। क्योंकि हम PostgreSQL के साथ काम करते हैं, हमारे पास यह है। जो पहले से तैयार है, उसका उपयोग करते हैं।

मान लीजिए कि हमारे पास PostgreSQL में एक लेबल है जिसमें हम केवल काउंटर को बढ़ाते हैं।



पहले से ही आरपीएस की छोटी मात्रा में हम एक मजबूत प्रदर्शन गिरावट देखते हैं। इसे सिर्फ विशाल कहा जा सकता है।



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



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



यहाँ एक वास्तविक संयोजन, हमारी सहायता के लिए आता है। कई अलग-अलग मॉड्यूल हैं। उपप्रोसेस चलाने के लिए खच्चर, कैचिंग फ्रेमवर्क, क्रोन, मेट्रिक्स सबसिस्टम और अलर्टिंग सिस्टम। "सबसिस्टम मेट्रिक्स सिस्टम" - आशाजनक लगता है।



वह जानती है कि कुछ प्रकार के मेट्रिक्स कैसे जोड़े जाएं, काउंटर बढ़ाएं, काउंटर को कम करें, गुणा करें, विभाजित करें - जो भी आपका दिल चाहता है।

एकमात्र मीट्रिक सबसिस्टम वास्तव में निर्मित मेट्रिक्स देने में सक्षम नहीं है।

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



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



कैश सबसिस्टम uWSGI में निर्मित कैश है। एक तेज़ और थ्रेड-सुरक्षित मॉड्यूल, जो एक साधारण कुंजी-मूल्य भंडारण है।



लेकिन चूंकि यह एक कैश है, एक अच्छी तरह से ज्ञात दूसरी समस्या है: चर का नाम कैसे और कैश को कैसे अमान्य किया जाए? हमारे मामले में, आइए देखें कि डिफ़ॉल्ट कैश सेटिंग्स क्या हैं। यह कुंजी की लंबाई पर प्रतिबंध है। हमारे मामले में, यह मीट्रिक का नाम है। डिफ़ॉल्ट 2048 बाइट्स है। और यदि आवश्यक हो तो आप कॉन्फ़िगरेशन बढ़ा सकते हैं। डिफ़ॉल्ट रूप से इसे संग्रहीत करने वाले तत्वों की संख्या 65,536 है। ऐसा लगता है कि यह मान सभी के लिए पर्याप्त होना चाहिए। यह संभावना नहीं है कि कोई भी अपने आवेदन से इतनी संख्या में मीट्रिक एकत्र करेगा।

और डिफ़ॉल्ट रूप से ttl 0. है अर्थात्, संग्रहीत कैश के मान समय-अमान्य नहीं हैं। इसलिए, हम उन्हें कैश से प्राप्त कर सकते हैं और उन्हें मेट्रिक्स सिस्टम पर भेज सकते हैं।



फिर से, विकल्प एक अनुप्रयोग है जो uWSGI बॉक्स का उपयोग करता है।



यहाँ इस आवेदन को पूरा करने के परिणाम हैं।



मैट्रिक्स के बिना परिणाम, अगर uWSGI के साथ, एक खिंचाव के साथ यह लगभग समान दिखता है।



जैसा कि आप देख सकते हैं, uWSGI के मामले में, हम मेट्रिक्स के "वेनिला" संस्करण के सापेक्ष केवल 5% प्रदर्शन खो देते हैं। अन्य विकल्पों में काफी महत्वपूर्ण गिरावट है, और इसलिए, दर्शक मतदान के परिणामस्वरूप, uWSGI जीतता है।



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



हम यह भी ट्रैक करने में रुचि रखते हैं कि कैश कैसे काम करता है। हम केवल ग्राहक मेम के तरीकों को फिर से परिभाषित करते हैं, डेटा प्राप्त करने के लिए समय बचाते हैं, डाउनलोड करने का समय और कैश हिट और कैश मिस की संख्या।



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



नतीजतन, हमें एक ग्राफ मिलता है, इस मामले में यह कैश एक्सेस समय, पढ़ने और लिखने का 99 वां प्रतिशत है।



या, एक विकल्प के रूप में, हमारे एपीआई के लिए तृतीय-पक्ष सेवा अनुरोधों की संख्या।



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



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



हमने अचार से इनकार कर दिया, काशे इंक में स्थानांतरित कर दिया, सब कुछ मापा, यह तेज हो गया।



नए कार्यान्वयन में, हम अपना अधिकांश समय कैश के साथ काम करते हैं, न कि अचार बनाने में।



मैं आपको यह क्यों बता रहा हूँ? मैं आपसे आग्रह करता हूं कि आप मैट्रिक्स इकट्ठा करना, मैट्रिक्स देखना और मेट्रिक्स पर ध्यान केंद्रित करना शुरू करें। एक संभावित मीट्रिक संग्रह विकल्प चुनते समय, विकल्पों की तुलना करें, देखें कि आपके लिए कौन सा सबसे अच्छा है। और, ज़ाहिर है, प्रोफाइलिंग अच्छी है। यदि आप देखते हैं कि कुछ गलत है, तो कुछ धीमा हो रहा है - प्रोफ़ाइल।

आप सभी को धन्यवाद! जैसा कि मैंने वादा किया था, संदर्भ:

• Yandex.Tank ,
• रेज़ में लिखी पाई-स्पाई प्रोफाइलिंग यूटिलिटी,
• uWSGI के उपयोग पर अलेक्जेंडर कोशेलेव की रिपोर्ट।