कैसे YouDo में मशीन सीखना उत्पादन में रोल करता है। यैंडेक्स में व्याख्यान

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


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



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



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

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



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



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



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



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



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



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



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

और - घुमंतू। यह ऑर्केस्ट्रेशन की एक प्रणाली है, जो आपकी सेवाओं और कुछ प्रकार की बैच नौकरियों को बहा देती है।



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

आवधिक बैच की नौकरी - यह बिल्कुल वैसा ही है, केवल एक शेड्यूल पर काम करता है।

एक समस्या है। जब हम किसी ऑर्केस्ट्रेशन सिस्टम में कंटेनर को तैनात करते हैं, तो हमें यह इंगित करना होगा कि इस कंटेनर, सीपीयू या मेमोरी की कितनी मेमोरी है। अगर हमारे पास एक पाइपलाइन है जो तीन घंटे चलती है, तो दो घंटे में 10 जीबी रैम, 1 घंटे - 70 जीबी की खपत होती है। यदि हम उसे दी गई सीमा से अधिक हो जाते हैं, तो डॉकर डेमॉन आता है और डॉकर्स को मारता है और (nrzb।) [02:26:13] हम लगातार मेमोरी से बाहर नहीं निकलना चाहते हैं, इसलिए हमें सभी 70 जीबी, पीक मेमोरी लोड को निर्दिष्ट करने की आवश्यकता है। लेकिन यहाँ समस्या है, तीन घंटे के लिए सभी 70 जीबी आवंटित किए जाएंगे और किसी अन्य नौकरी के लिए दुर्गम होंगे।

इसलिए, हम दूसरे रास्ते पर चले गए। हमारी पूरी लुइगी पाइपलाइन किसी भी तरह के व्यापारिक तर्क को शुरू नहीं करती है, यह सिर्फ नामांकित, तथाकथित पैरामीटर वाली नौकरी में पासा का एक सेट लॉन्च करती है। वास्तव में, यह सर्वर (NRZB।) [02:26:39] फ़ंक्शन, AVS लैम्ब्डा का एक एनालॉग है, जो जानता है। जब हम एक पुस्तकालय बनाते हैं, तो हम सीआई के माध्यम से अपने सभी कोड को पैरामीटर वाली नौकरियों, अर्थात् कुछ मापदंडों के साथ एक कंटेनर के रूप में तैनात करते हैं। मान लीजिए, लाइट जेबीएम क्लासिफायरियर, इसके पास प्रशिक्षण के लिए इनपुट डेटा के लिए पथ के लिए एक पैरामीटर है, मॉडल के हाइपरपरमेटर्स और आउटपुट कलाकृतियों के लिए पथ है। यह सब घुमंतू में पंजीकृत है, और फिर लुइगी पाइपलाइन से हम इन सभी घुमंतू नौकरियों को एपीआई के माध्यम से खींच सकते हैं, जबकि लुइगी यह सुनिश्चित करता है कि एक ही कार्य को कई बार न चलाएं।

मान लीजिए हमारे पास एक ही टेक्स्ट प्रोसेसिंग है। 10 सशर्त मॉडल हैं, और हम हर बार पाठ प्रसंस्करण को फिर से शुरू नहीं करना चाहते हैं। यह केवल एक बार शुरू होगा, और एक ही समय में हर बार पुन: उपयोग किए जाने पर एक समाप्त परिणाम होगा। और एक ही समय में, यह सब वितरित तरीके से काम करता है, हम एक बड़े क्लस्टर पर एक विशाल ग्रिड खोज चला सकते हैं, केवल लोहे को डंप करने का समय है।



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

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

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



नतीजतन, सेवा कुछ इस तरह दिखती है। अलग GitLab परियोजना, पाइपलाइन कोड, परीक्षण कोड, सेवा कोड ही, विभिन्न विन्यासों का एक गुच्छा, घुमंतू, CI-configs, एपीआई प्रलेखन, हुक और अधिक।



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



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

सभी सेवाओं को खानाबदोश के लिए तैनात किया जाता है। हमारे पास दो घुमंतू उत्पादन क्लस्टर हैं - एक बैच की नौकरी के लिए और दूसरा सेवाओं के लिए।



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



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

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

यदि सब कुछ ठीक है, तो हम कह सकते हैं कि सब कुछ ठीक है। तैनात, घुमंतू के माध्यम से जाना होगा, धीरे से सभी पुराने संस्करणों को बंद करें और नए पैमाने दें।

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



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

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

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



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