तंत्रिका नेटवर्कहरूमा आधारित उपस्थिति मूल्याङ्कनको लागि सेवा वास्तुकलाको सामान्य सिंहावलोकन

प्रवेश

नमस्ते!

यस लेखमा म न्यूरल नेटवर्कहरू प्रयोग गरेर परियोजनाको लागि माइक्रोसर्भिस आर्किटेक्चर निर्माण गर्ने मेरो अनुभव साझा गर्नेछु।

वास्तुकला आवश्यकताहरूको बारेमा कुरा गरौं, विभिन्न संरचनात्मक रेखाचित्रहरू हेर्नुहोस्, समाप्त वास्तुकलाको प्रत्येक घटकको विश्लेषण गर्नुहोस्, र समाधानको प्राविधिक मेट्रिक्स पनि मूल्याङ्कन गर्नुहोस्।

पढाइको आनन्द लिनुहोस्!

समस्या र यसको समाधान बारे केही शब्दहरू

मुख्य विचार तस्विरको आधारमा दस-बिन्दु स्केलमा व्यक्तिको आकर्षणको मूल्याङ्कन गर्नु हो।

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

अब हामी शीर्ष स्तरमा मूल्याङ्कन पाइपलाइन मार्फत जान्छौं, र समग्र परियोजना वास्तुकलाको सन्दर्भमा माइक्रो सेवाहरूको अन्तरक्रियामा ध्यान केन्द्रित गर्नेछौं। 

आकर्षकता मूल्याङ्कन पाइपलाइनमा काम गर्दा, कार्यलाई निम्न घटकहरूमा विघटन गरिएको थियो:

1. फोटोहरूमा अनुहारहरू चयन गर्दै
2. प्रत्येक व्यक्तिको मूल्याङ्कन
3. परिणाम प्रस्तुत गर्नुहोस्

पहिलो पूर्व प्रशिक्षित को बल द्वारा हल गरिएको छ MTCNN। दोस्रो को लागी, एक convolutional न्यूरल नेटवर्क PyTorch मा प्रशिक्षित गरिएको थियो, प्रयोग गरेर ResNet34 - सन्तुलनबाट "CPU मा अनुमानको गुणस्तर / गति"

मूल्याङ्कन पाइपलाइनको कार्यात्मक रेखाचित्र

परियोजना वास्तुकला आवश्यकताहरूको विश्लेषण

जीवन चक्रमा ML वास्तुकला र मोडेल डिप्लोइमेन्टको स्वचालनमा कामको परियोजना चरणहरू प्रायः धेरै समय-उपभोग गर्ने र स्रोत-उपभोग गर्नेहरू मध्येका हुन्छन्।

एमएल परियोजनाको जीवन चक्र

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

1. एकीकृत लग भण्डारण - सबै सेवाहरूले एकै ठाउँमा लगहरू लेख्नुपर्छ, तिनीहरू विश्लेषण गर्न सुविधाजनक हुनुपर्छ
2. मूल्याङ्कन सेवाको तेर्सो स्केलिंगको सम्भावना - सबैभन्दा सम्भावित बाधाको रूपमा
3. अनुमानको लागि समयको वितरणमा आउटलियरहरूबाट बच्न प्रत्येक छविको मूल्याङ्कन गर्न प्रोसेसर स्रोतहरूको समान मात्रा आवंटित गरिनु पर्छ।
4. विशेष सेवाहरू र समग्र रूपमा स्ट्याक दुवैको द्रुत (पुन:) तैनाती
5. क्षमता, आवश्यक भएमा, विभिन्न सेवाहरूमा साझा वस्तुहरू प्रयोग गर्न

वास्तुकला

आवश्यकताहरू विश्लेषण गरेपछि, यो स्पष्ट भयो कि माइक्रोसेवा वास्तुकला लगभग पूर्ण रूपमा फिट हुन्छ।

अनावश्यक टाउको दुखाइबाट छुटकारा पाउनको लागि, टेलिग्राम एपीआईलाई फ्रन्टएन्डको रूपमा रोजिएको थियो।

पहिले, समाप्त वास्तुकलाको संरचनात्मक रेखाचित्र हेरौं, त्यसपछि प्रत्येक घटकको विवरणमा जानुहोस्, र सफल छवि प्रशोधनको प्रक्रियालाई औपचारिकता दिनुहोस्।

समाप्त वास्तुकला को संरचनात्मक रेखाचित्र

चित्रको मूल्याङ्कन प्रक्रियामा तिनीहरूलाई एकल उत्तरदायित्व जनाउँदै, रेखाचित्रको प्रत्येक घटकको बारेमा थप विस्तारमा कुरा गरौं।

माइक्रोसर्भिस "attrai-telegram-bot"

यो माइक्रोसर्भिसले Telegram API सँग सबै अन्तर्क्रियाहरू समेट्छ। त्यहाँ २ मुख्य परिदृश्यहरू छन्: अनुकूलन छविसँग काम गर्ने र मूल्याङ्कन पाइपलाइनको नतिजासँग काम गर्ने। सामान्य सर्तहरूमा दुवै परिदृश्यहरू हेरौं।

छविको साथ अनुकूलन सन्देश प्राप्त गर्दा:

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

साथै, यो माइक्रो सर्भिस, सेलेरी कार्यकर्ताले जस्तै, "after_estimate" लाई सुन्छ, जुन मूल्याङ्कन पाइपलाइनबाट गुज्रिएका कार्यहरूको लागि हो।

"after_estimate" बाट नयाँ कार्य प्राप्त गर्दा:

1. यदि छवि सफलतापूर्वक प्रशोधन भयो भने, हामी प्रयोगकर्तालाई परिणाम पठाउँछौं; यदि होइन भने, हामी त्रुटिको बारेमा सूचित गर्दछौं।
2. छवि हटाउँदै जुन मूल्याङ्कन पाइपलाइनको परिणाम हो

मूल्याङ्कन माइक्रोसेवा "एट्राई-एस्टिमेटर"

यो माइक्रोसर्भिस एक सेलेरी कार्यकर्ता हो र छवि मूल्याङ्कन पाइपलाइनसँग सम्बन्धित सबै कुराहरू समावेश गर्दछ। यहाँ एउटा मात्र काम गर्ने एल्गोरिथ्म छ - यसलाई विश्लेषण गरौं।

"to_estimate" बाट नयाँ कार्य प्राप्त गर्दा:

1. मूल्याङ्कन पाइपलाइन मार्फत छवि चलाउनुहोस्:
   1. मेमोरीमा छवि लोड गर्दै
   2. हामी छविलाई आवश्यक आकारमा ल्याउँछौं
   3. सबै अनुहारहरू खोज्दै (MTCNN)
   4. हामी सबै अनुहारहरू मूल्याङ्कन गर्छौं (हामी अन्तिम चरणमा फेला परेका अनुहारहरूलाई ब्याच र ResNet34 को अनुमानमा बेर्छौं)
   5. अन्तिम छवि रेन्डर गर्नुहोस्
      1. बाउन्डिङ बक्सहरू कोरौं
      2. मूल्याङ्कन कोर्दै
2. अनुकूलन (मूल) छवि मेटाउँदै
3. मूल्याङ्कन पाइपलाइनबाट आउटपुट बचत गर्दै
4. हामीले कार्यलाई "after_estimate" कतारमा राख्यौं, जुन माथि छलफल गरिएको "attrai-telegram-bot" माइक्रोसर्भिसले सुनेको छ।

Graylog (+ mongoDB + Elasticsearch)

ग्रेलोग केन्द्रीकृत लग व्यवस्थापनको लागि एक समाधान हो। यस परियोजनामा, यो यसको इच्छित उद्देश्यको लागि प्रयोग गरिएको थियो।

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

पहिले मात्र ELK स्ट्याकसँग काम गरेको व्यक्तिको रूपमा, ग्रेलोगसँग काम गर्दा मसँग समग्र सकारात्मक अनुभव थियो। निराशाजनक कुरा भनेको ग्रेलोग वेब इन्टरफेसमा किबाना सुविधाहरूमा उत्कृष्टता हो।

खरगोश MQ

खरगोश MQ AMQP प्रोटोकलमा आधारित सन्देश ब्रोकर हो।

यस परियोजनामा ​​यो रूपमा प्रयोग गरिएको थियो सबैभन्दा स्थिर र समय-परीक्षण सेलरीका लागि ब्रोकर र टिकाऊ मोडमा काम गरे।

Redis

Redis एक NoSQL DBMS हो जसले मुख्य-मान डेटा संरचनाहरूसँग काम गर्दछ

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

उदाहरण को लागी, Redis "telegram_user_id => लाममा सक्रिय कार्यहरूको संख्या" को एक ह्याशम्याप भण्डार गर्दछ, जसले तपाईंलाई एक प्रयोगकर्ताबाट अनुरोधहरूको संख्यालाई निश्चित मानमा सीमित गर्न अनुमति दिन्छ र यसरी, DoS आक्रमणहरू रोक्न अनुमति दिन्छ।

सफल छवि प्रशोधनको प्रक्रियालाई औपचारिक गरौं

1. प्रयोगकर्ताले टेलिग्राम बोटमा छवि पठाउँदछ
2. "attrai-telegram-bot" ले Telegram API बाट सन्देश प्राप्त गर्दछ र यसलाई पार्स गर्दछ
3. छविको साथ कार्य एसिन्क्रोनस लाम "to_estimate" मा थपिएको छ।
4. प्रयोगकर्ताले योजनाबद्ध मूल्याङ्कन समयको साथ सन्देश प्राप्त गर्दछ
5. "attrai-estimator" ले "to_estimate" कतारबाट कार्य लिन्छ, पाइपलाइन मार्फत अनुमानहरू चलाउँछ र कार्यलाई "after_estimate" कतारमा उत्पादन गर्छ।
6. "attrai-telegram-bot" ले "after_estimate" कतार सुन्दै, प्रयोगकर्तालाई नतिजा पठाउँछ

DevOps

अन्तमा, वास्तुकलाको समीक्षा गरेपछि, तपाईं समान रोचक भागमा जान सक्नुहुन्छ - DevOps

डकर झुण्ड

 

डकर झुण्ड  — एक क्लस्टरिङ प्रणाली, जसको कार्यक्षमता डकर इन्जिन भित्र लागू हुन्छ र बक्स बाहिर उपलब्ध छ।

"स्वार्म" को प्रयोग गरेर, हाम्रो क्लस्टरका सबै नोडहरूलाई २ प्रकारमा विभाजन गर्न सकिन्छ - कार्यकर्ता र प्रबन्धक। पहिलो प्रकारका मेसिनहरूमा, कन्टेनरहरूको समूह (स्ट्याकहरू) तैनाथ गरिन्छ, दोस्रो प्रकारका मेसिनहरू स्केलिंग, सन्तुलन र अन्य सुन्दर सुविधाहरू। प्रबन्धकहरू पनि पूर्वनिर्धारित रूपमा कामदारहरू हुन्।

एक नेता प्रबन्धक र तीन कार्यकर्ता संग क्लस्टर

न्यूनतम सम्भावित क्लस्टर साइज १ नोड हो; एउटै मेसिनले एकैसाथ नेता प्रबन्धक र कार्यकर्ताको रूपमा काम गर्नेछ। परियोजनाको आकार र त्रुटि सहिष्णुताको लागि न्यूनतम आवश्यकताहरूको आधारमा, यो दृष्टिकोण प्रयोग गर्ने निर्णय गरियो।

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

डकर स्ट्याक

झुण्ड मोडमा, उहाँ स्ट्याकहरू (डकर सेवाहरूको सेट) तैनाती गर्न जिम्मेवार हुनुहुन्छ। डकर स्ट्याक

यसले डकर-कम्पोज कन्फिगहरू समर्थन गर्दछ, तपाईंलाई थप रूपमा डिप्लोय प्यारामिटरहरू प्रयोग गर्न अनुमति दिन्छ।  

उदाहरणका लागि, यी प्यारामिटरहरू प्रयोग गरेर, प्रत्येक मूल्याङ्कन माइक्रोसर्भिस इन्स्ट्यान्सका लागि स्रोतहरू सीमित थिए (हामी N उदाहरणहरूको लागि N कोरहरू आवंटित गर्छौं, माइक्रोसर्भिसमा नै हामी PyTorch द्वारा प्रयोग गरिएको कोरहरूको सङ्ख्या एकमा सीमित गर्छौं)

attrai_estimator:
  image: 'erqups/attrai_estimator:1.2'
  deploy:
    replicas: 4
    resources:
      limits:
        cpus: '4'
    restart_policy:
      condition: on-failure
      …

यो नोट गर्न महत्त्वपूर्ण छ कि Redis, RabbitMQ र Graylog राज्य सेवाहरू हुन् र तिनीहरूलाई "attrai-estimator" को रूपमा सजिलै मापन गर्न सकिँदैन।

प्रश्नको पूर्वचित्रण गर्दै - किन कुबर्नेट्स होइन?

यस्तो देखिन्छ कि साना र मध्यम आकारका परियोजनाहरूमा Kubernetes प्रयोग गर्नु एक ओभरहेड हो; सबै आवश्यक कार्यक्षमताहरू Docker Swarm बाट प्राप्त गर्न सकिन्छ, जुन कन्टेनर अर्केस्ट्रेटरको लागि धेरै प्रयोगकर्ता-अनुकूल छ र प्रवेशमा कम अवरोध पनि छ।

आधारभूत संरचना

यो सबै निम्न विशेषताहरु संग VDS मा तैनात गरिएको थियो:

• CPU: 4 कोर Intel® Xeon® Gold 5120 CPU @ 2.20GHz
• राम: 8 जीबी
• SSD: 160GB

स्थानीय लोड परीक्षण पछि, यस्तो देखिन्छ कि प्रयोगकर्ताहरूको एक गम्भीर आगमन संग, यो मेसिन पर्याप्त हुनेछ।

तर, तैनाती पछि तुरुन्तै, मैले CIS मा सबैभन्दा लोकप्रिय छविबोर्डहरू मध्ये एकको लिङ्क पोस्ट गरें (हो, त्यो उही), जस पछि मानिसहरू चासो राखे र केही घण्टामा सेवाले सफलतापूर्वक दसौं हजार छविहरू प्रशोधन गर्यो। एकै समयमा, शिखर क्षणहरूमा, CPU र RAM स्रोतहरू आधा पनि प्रयोग गरिएन।

केहि थप ग्राफिक्स

दिनमा निर्भर गर्दै, तैनाती पछि अद्वितीय प्रयोगकर्ता र मूल्याङ्कन अनुरोधहरूको संख्या

मूल्याङ्कन पाइपलाइन अनुमान समय वितरण

निष्कर्ष

संक्षेपमा, म भन्न सक्छु कि वास्तुकला र कन्टेनरहरूको आर्केस्ट्रेशनको दृष्टिकोणले आफैलाई पूर्णतया न्यायोचित बनायो - शिखर क्षणहरूमा पनि प्रशोधन समयमा कुनै थोपा वा सगिंग थिएन। 

मलाई लाग्छ कि साना र मध्यम आकारका परियोजनाहरूले उनीहरूको प्रक्रियामा CPU मा न्यूरल नेटवर्कहरूको वास्तविक-समय अनुमान प्रयोग गर्दछ सफलतापूर्वक यस लेखमा वर्णन गरिएका अभ्यासहरू अपनाउन सक्छ।

म थप्छु कि सुरुमा लेख लामो थियो, तर लामो पढाइ पोस्ट नगर्नको लागि, मैले यस लेखमा केही बुँदाहरू हटाउने निर्णय गरे - हामी भविष्यका प्रकाशनहरूमा तिनीहरूलाई फर्काउनेछौं।

तपाईले टेलिग्राममा बोट पोक गर्न सक्नुहुन्छ - @AttaraiBot, यसले कम्तिमा २०२० को शरद ऋतुको अन्त्यसम्म काम गर्नेछ। मलाई तपाईलाई सम्झाउन दिनुहोस् कि कुनै प्रयोगकर्ता डेटा भण्डार गरिएको छैन - न मूल छविहरू, न मूल्याङ्कन पाइपलाइनको नतिजाहरू - सबै प्रक्रिया पछि ध्वस्त हुन्छ।

स्रोत: www.habr.com