Pangkalahatang pangkalahatang-ideya ng arkitektura ng serbisyo para sa pagtatasa ng hitsura batay sa mga neural network

Pagpasok

Привет!

Sa artikulong ito ibabahagi ko ang aking karanasan sa pagbuo ng isang microservice architecture para sa isang proyekto gamit ang mga neural network.

Pag-usapan natin ang mga kinakailangan sa arkitektura, tingnan ang iba't ibang mga diagram ng istruktura, pag-aralan ang bawat isa sa mga bahagi ng natapos na arkitektura, at suriin din ang mga teknikal na sukatan ng solusyon.

Tangkilikin ang pagbabasa!

Ilang salita tungkol sa problema at solusyon nito

Ang pangunahing ideya ay suriin ang pagiging kaakit-akit ng isang tao sa isang sampung puntong sukat batay sa isang larawan.

Sa artikulong ito ay lalayo tayo sa paglalarawan ng parehong mga neural network na ginamit at ang proseso ng paghahanda at pagsasanay ng data. Gayunpaman, sa isa sa mga sumusunod na publikasyon, tiyak na babalik tayo sa pagsusuri sa pipeline ng pagtatasa sa isang malalim na antas.

Ngayon ay dadaan tayo sa pipeline ng pagsusuri sa pinakamataas na antas, at tututuon ang pakikipag-ugnayan ng mga microservice sa konteksto ng pangkalahatang arkitektura ng proyekto. 

Kapag nagtatrabaho sa pipeline ng pagtatasa ng pagiging kaakit-akit, ang gawain ay nabulok sa mga sumusunod na bahagi:

1. Pagpili ng mga mukha sa mga larawan
2. Rating ng bawat tao
3. I-render ang resulta

Ang una ay nalutas sa pamamagitan ng mga puwersa ng pre-trained MTCNN. Para sa pangalawa, ang isang convolutional neural network ay sinanay sa PyTorch, gamit ResNet34 – mula sa balanseng "kalidad / bilis ng hinuha sa CPU"

Functional na diagram ng pipeline ng pagsusuri

Pagsusuri ng mga kinakailangan sa arkitektura ng proyekto

Sa ikot ng buhay ML Ang mga yugto ng proyekto ng trabaho sa arkitektura at pag-automate ng pag-deploy ng modelo ay kadalasang kabilang sa pinakamatagal at nakakaubos ng mapagkukunan.

Life cycle ng isang ML project

Ang proyektong ito ay walang pagbubukod - ang desisyon ay ginawa upang i-wrap ang pipeline ng pagtatasa sa isang online na serbisyo, na nangangailangan ng paglubog sa ating sarili sa arkitektura. Natukoy ang mga sumusunod na pangunahing kinakailangan:

1. Pinag-isang imbakan ng log - lahat ng mga serbisyo ay dapat magsulat ng mga log sa isang lugar, dapat silang maginhawa upang pag-aralan
2. Posibilidad ng pahalang na pag-scale ng serbisyo sa pagtatasa - bilang ang pinaka-malamang na Bottleneck
3. Ang parehong halaga ng mga mapagkukunan ng processor ay dapat ilaan upang suriin ang bawat imahe upang maiwasan ang mga outlier sa pamamahagi ng oras para sa hinuha.
4. Mabilis (muling) deployment ng parehong partikular na serbisyo at ang stack sa kabuuan
5. Ang kakayahan, kung kinakailangan, na gumamit ng mga karaniwang bagay sa iba't ibang serbisyo

arkitektura

Matapos suriin ang mga kinakailangan, naging malinaw na ang arkitektura ng microservice ay halos ganap na akma.

Upang maalis ang hindi kinakailangang pananakit ng ulo, pinili ang Telegram API bilang frontend.

Una, tingnan natin ang structural diagram ng natapos na arkitektura, pagkatapos ay lumipat sa isang paglalarawan ng bawat isa sa mga bahagi, at gawing pormal din ang proseso ng matagumpay na pagproseso ng imahe.

Structural diagram ng tapos na arkitektura

Pag-usapan natin nang mas detalyado ang tungkol sa bawat isa sa mga bahagi ng diagram, na nagsasaad ng mga ito na Nag-iisang Pananagutan sa proseso ng pagsusuri ng imahe.

Microservice "attrai-telegram-bot"

Isinasama ng microservice na ito ang lahat ng pakikipag-ugnayan sa Telegram API. Mayroong 2 pangunahing senaryo: nagtatrabaho sa isang custom na imahe at nagtatrabaho sa resulta ng isang pipeline ng pagtatasa. Tingnan natin ang parehong mga sitwasyon sa mga pangkalahatang tuntunin.

Kapag tumatanggap ng custom na mensahe na may larawan:

1. Isinasagawa ang pagsasala, na binubuo ng mga sumusunod na pagsusuri:
   • Availability ng pinakamainam na laki ng imahe
   • Bilang ng mga larawan ng user na nasa pila na
2. Kapag pumasa sa paunang pag-filter, ang imahe ay nai-save sa dami ng docker
3. Ang isang gawain ay ginawa sa queue na "to_estimate", na kinabibilangan, bukod sa iba pang mga bagay, ang path patungo sa imahe na matatagpuan sa aming volume
4. Kung matagumpay na nakumpleto ang mga hakbang sa itaas, makakatanggap ang user ng mensahe na may tinatayang oras ng pagproseso ng imahe, na kinakalkula batay sa bilang ng mga gawain sa pila. Kung may nangyaring error, tahasang aabisuhan ang user sa pamamagitan ng pagpapadala ng mensahe na may impormasyon tungkol sa kung ano ang maaaring nagkamali.

Gayundin, ang microservice na ito, tulad ng isang celery worker, ay nakikinig sa queue na "after_estimate", na nilayon para sa mga gawaing dumaan sa pipeline ng pagsusuri.

Kapag tumatanggap ng bagong gawain mula sa "after_estimate":

1. Kung matagumpay na naproseso ang larawan, ipinapadala namin ang resulta sa user; kung hindi, aabisuhan namin ang tungkol sa isang error.
2. Pag-alis ng larawan na resulta ng pipeline ng pagsusuri

Pagsusuri ng microservice "attrai-estimator"

Ang microservice na ito ay isang celery worker at isinasama ang lahat ng nauugnay sa pipeline ng pagsusuri ng imahe. Mayroon lamang isang gumaganang algorithm dito - pag-aralan natin ito.

Kapag tumatanggap ng bagong gawain mula sa "to_estimate":

1. Patakbuhin natin ang imahe sa pamamagitan ng pipeline ng pagsusuri:
   1. Nilo-load ang imahe sa memorya
   2. Dinadala namin ang imahe sa kinakailangang laki
   3. Paghahanap sa lahat ng mukha (MTCNN)
   4. Sinusuri namin ang lahat ng mga mukha (binalot namin ang mga mukha na natagpuan sa huling hakbang sa isang batch at hinuha ang ResNet34)
   5. I-render ang huling larawan
      1. Iguhit natin ang mga nakatali na kahon
      2. Pagguhit ng mga rating
2. Pagtanggal ng custom (orihinal) na larawan
3. Sine-save ang output mula sa pipeline ng pagsusuri
4. Inilalagay namin ang gawain sa queue na "after_estimate", na pinakikinggan ng microservice na "attrai-telegram-bot" na tinalakay sa itaas.

Graylog (+ mongoDB + Elasticsearch)

graylog ay isang solusyon para sa sentralisadong pamamahala ng log. Sa proyektong ito, ginamit ito para sa layunin nito.

Ang pagpili ay nahulog sa kanya, at hindi sa karaniwan ELK stack, dahil sa kaginhawaan ng pagtatrabaho dito mula sa Python. Ang kailangan mo lang gawin para mag-log in sa Graylog ay idagdag ang GELFTCPHandler mula sa package kulay abo sa iba pang mga tagapangasiwa ng root logger ng aming microservice ng python.

Bilang isang tao na dati ay nagtrabaho lamang sa ELK stack, nagkaroon ako ng pangkalahatang positibong karanasan habang nagtatrabaho sa Graylog. Ang tanging bagay na nakapanlulumo ay ang higit na kahusayan sa mga tampok ng Kibana sa interface ng web ng Graylog.

Kuneho MQ

Kuneho MQ ay isang message broker batay sa AMQP protocol.

Sa proyektong ito ito ay ginamit bilang ang pinaka-matatag at nasubok sa oras broker para sa Celery at nagtrabaho sa matibay na mode.

Redis

Redis ay isang NoSQL DBMS na gumagana sa mga istruktura ng data ng key-value

Minsan may pangangailangang gumamit ng mga karaniwang bagay na nagpapatupad ng ilang partikular na istruktura ng data sa iba't ibang microservice ng Python.

Halimbawa, nag-iimbak ang Redis ng hashmap ng form na "telegram_user_id => bilang ng mga aktibong gawain sa pila," na nagbibigay-daan sa iyong limitahan ang bilang ng mga kahilingan mula sa isang user sa isang tiyak na halaga at, sa gayon, maiwasan ang mga pag-atake ng DoS.

I-formalize natin ang proseso ng matagumpay na pagpoproseso ng imahe

1. Nagpapadala ang user ng larawan sa Telegram bot
2. Ang "attrai-telegram-bot" ay tumatanggap ng mensahe mula sa Telegram API at na-parse ito
3. Ang gawain na may larawan ay idinagdag sa asynchronous na pila na "to_estimate"
4. Makakatanggap ang user ng mensahe na may nakaplanong oras ng pagtatasa
5. Ang "attrai-estimator" ay kumukuha ng isang gawain mula sa queue na "to_estimate", pinapatakbo ang mga pagtatantya sa pipeline at ginagawa ang gawain sa queue na "after_estimate"
6. Ang "attrai-telegram-bot" na nakikinig sa "after_estimate" na pila, ay nagpapadala ng resulta sa user

DevOps

Sa wakas, pagkatapos suriin ang arkitektura, maaari kang magpatuloy sa parehong kawili-wiling bahagi - DevOps

Docker kuyog

 

Docker kuyog  — isang clustering system, ang functionality na ipinapatupad sa loob ng Docker Engine at available sa labas ng kahon.

Gamit ang isang "kawan", ang lahat ng mga node sa aming cluster ay maaaring hatiin sa 2 uri - manggagawa at tagapamahala. Sa mga makina ng unang uri, ang mga grupo ng mga lalagyan (stack) ay inilalagay, ang mga makina ng pangalawang uri ay may pananagutan para sa pag-scale, pagbabalanse at iba pang mga cool na tampok. Ang mga manager ay mga manggagawa rin bilang default.

Cluster na may isang pinunong tagapamahala at tatlong manggagawa

Ang pinakamababang posibleng laki ng cluster ay 1 node; ang isang makina ay sabay-sabay na gaganap bilang isang pinunong tagapamahala at isang manggagawa. Batay sa laki ng proyekto at mga minimum na kinakailangan para sa fault tolerance, napagpasyahan na gamitin ang diskarteng ito.

Sa hinaharap, sasabihin ko na mula noong unang paghahatid ng produksyon, na noong kalagitnaan ng Hunyo, walang mga problemang nauugnay sa cluster na organisasyong ito (ngunit hindi ito nangangahulugan na ang naturang organisasyon ay sa anumang paraan ay katanggap-tanggap sa anumang medium-large mga proyekto, na napapailalim sa mga kinakailangan sa fault tolerance).

Docker Stack

Sa swarm mode, responsable siya sa pag-deploy ng mga stack (mga hanay ng mga serbisyo ng docker) docker stack

Sinusuportahan nito ang mga docker-compose config, na nagbibigay-daan sa iyo na dagdagan ang paggamit ng mga opsyon sa pag-deploy.  

Halimbawa, gamit ang mga parameter na ito, limitado ang mga mapagkukunan para sa bawat isa sa mga evaluation microservice instance (naglalaan kami ng N core para sa N instance, sa microservice mismo nililimitahan namin ang bilang ng mga core na ginagamit ng PyTorch sa isa)

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

Mahalagang tandaan na ang Redis, RabbitMQ at Graylog ay mga stateful na serbisyo at hindi sila masusukat nang kasingdali ng "attrai-estimator"

Foreshadowing ang tanong - bakit hindi Kubernetes?

Tila ang paggamit ng Kubernetes sa maliliit at katamtamang laki ng mga proyekto ay isang overhead; ang lahat ng kinakailangang pag-andar ay maaaring makuha mula sa Docker Swarm, na medyo user-friendly para sa isang container orchestrator at mayroon ding mababang hadlang sa pagpasok.

Infrastructure

Ang lahat ng ito ay na-deploy sa VDS na may mga sumusunod na katangian:

• CPU: 4 core Intel® Xeon® Gold 5120 CPU @ 2.20GHz
• RAM: 8 GB
• SSD: 160GB

Pagkatapos ng lokal na pagsubok sa pag-load, tila sa isang seryosong pagdagsa ng mga gumagamit, magiging sapat na ang makinang ito.

Ngunit, kaagad pagkatapos ng pag-deploy, nag-post ako ng isang link sa isa sa mga pinakasikat na imageboard sa CIS (yup, ang parehong iyon), pagkatapos ay naging interesado ang mga tao at sa loob ng ilang oras ang serbisyo ay matagumpay na naproseso ang libu-libong mga imahe. Kasabay nito, sa mga peak na sandali, ang mga mapagkukunan ng CPU at RAM ay hindi kahit kalahati ang ginamit.

Ilan pang graphics

Bilang ng mga natatanging user at mga kahilingan sa pagsusuri mula noong deployment, depende sa araw

Pagsusuri ng pipeline inference time distribution

Natuklasan

Upang buod, maaari kong sabihin na ang arkitektura at diskarte sa orkestrasyon ng mga lalagyan ay ganap na nabigyang-katwiran ang kanilang mga sarili - kahit na sa mga peak na sandali ay walang mga patak o sagging sa oras ng pagproseso. 

Sa tingin ko, ang mga maliliit at katamtamang laki ng mga proyekto na gumagamit ng real-time na inference ng mga neural network sa CPU sa kanilang proseso ay maaaring matagumpay na gamitin ang mga kasanayang inilarawan sa artikulong ito.

Idaragdag ko na sa una ang artikulo ay mas mahaba, ngunit upang hindi mag-post ng isang mahabang pagbasa, nagpasya akong alisin ang ilang mga punto sa artikulong ito - babalikan namin ang mga ito sa hinaharap na mga publikasyon.

Maaari mong sundutin ang bot sa Telegram - @AttraiBot, gagana ito ng hindi bababa sa katapusan ng taglagas 2020. Hayaan akong ipaalala sa iyo na walang data ng user ang nakaimbak - ni ang mga orihinal na larawan, o ang mga resulta ng pipeline ng pagsusuri - lahat ay na-demolish pagkatapos ng pagproseso.

Pinagmulan: www.habr.com