ProHoster >> Blog >> Administrimi >> Kampion përmbledhës i arkitekturës së shërbimit për vlerësimin e pamjes mbi baza të rrjeteve neuronale

Kampion përmbledhës i arkitekturës së shërbimit për vlerësimin e pamjes mbi baza të rrjeteve neuronale

Kampion përmbledhës i arkitekturës së shërbimit për vlerësimin e pamjes mbi baza të rrjeteve neuronale

Hyrje

Përshëndetje!

Në këtë artikull do të ndaj përvojën time në ndërtimin e një arkitekture mikroshërbimesh për një projekt që përdor rrjete nervore.

Do të flasim për kërkesat e arkitekturës, do të shohim diagrame të ndryshme strukturore, do të analizojmë secilin nga komponentët e arkitekturës së gatshme dhe do të vlerësojmë metrikat teknike të zgjidhjes.

Lexim të këndshëm!

Disa fjalë për detyrën dhe zgjidhjen e saj

Ideja kryesore – tĂ« ofrohet njĂ« vlerĂ«sim pĂ«r tĂ«rheqjen e njĂ« personi nĂ« njĂ« shkallĂ« nga 1 nĂ« 10 bazuar nĂ« fotografi.

Në këtë artikull do të shmangim përshkrimin e rrjeteve nervore të përdorura, si dhe procesin e përgatitjes së të dhënave dhe mësimit. Megjithatë, në një nga botimet e ardhshme, ne do të rikthehemi në analizën e pipeline-it të vlerësimit në një nivel më të thellë.

Aktualisht ne do të kalojmë nëpër pipeline-in e vlerësimit, duke u fokusuar në ndërveprimin e mikroshërbimeve në kontekstin e arkitekturës së përgjithshme të projektit. 

Kur punonim mbi pipeline-in e vlerësimit të tërheqjes, detyra u dekompozua në komponentët e mëposhtëm:

  1. Identifikimi i fytyrave në foto
  2. Vlerësimi i çdo fytyre
  3. Renderimi i rezultatit

E para zgjidhet nga njĂ« model i trajnuar mĂ« parĂ« MTCNN. PĂ«r tĂ« dytĂ«n, njĂ« rrjet nervor konvolucional u trajnuar nĂ« PyTorch, si backbone u pĂ«rdor ResNet34 – nga balanca "cilĂ«si / shpejtĂ«sia e inferencĂ«s nĂ« CPU"

Kampion përmbledhës i arkitekturës së shërbimit për vlerësimin e pamjes mbi baza të rrjeteve neuronale

Diagrami funksional i pipeline-it të vlerësimit

Analiza e kërkesave për arkitekturën e projektit

Në ciklin e jetës ML etapat e punës mbi arkitekturën dhe automatizimin e shpërndarjes së modelit, shpeshherë janë disa nga ato më të kushtueshme në kohë dhe burime.

Kampion përmbledhës i arkitekturës së shërbimit për vlerësimin e pamjes mbi baza të rrjeteve neuronale

Cikli i jetës së projektit ML

Ky projekt nuk Ă«shtĂ« pĂ«rjashtim – u mor vendimi pĂ«r tĂ« mbĂ«shtjellĂ« pipeline-in e vlerĂ«simit nĂ« njĂ« shĂ«rbim online, pĂ«r kĂ«tĂ« ishte e nevojshme tĂ« thellohej nĂ« arkitekturĂ«. U pĂ«rcaktuan kĂ«rkesat bazĂ« tĂ« mĂ«poshtme:

  1. NjĂ« magazinĂ« e vetme log-esh – tĂ« gjitha shĂ«rbimet duhet tĂ« shkruajnĂ« log-Ă«t nĂ« njĂ« vend, ato duhet tĂ« jenĂ« lehtĂ«sisht tĂ« analizueshme
  2. MundĂ«sia e shkallĂ«zimit horizontal tĂ« shĂ«rbimit tĂ« vlerĂ«simit — si Bottleneck mĂ« i mundshĂ«m
  3. PĂ«r çdo imazh duhet tĂ« caktuar njĂ« sasi e barabartĂ« burimesh tĂ« procesorit — pĂ«r tĂ« shmangur devijimet nĂ« shpĂ«rndarjen e kohĂ«s pĂ«r inferencĂ«
  4. Ripërhapje e shpejtë (ri) e shërbimeve specifike, si dhe e stakës në tërësi
  5. Mundësia për të përdorur objekte të përbashkëta në shërbime të ndryshme, nëse është e nevojshme.

Arkitektura

Pas analizimit të kërkesave, u bë e qartë se arkitektura mikroshërbimore përshtatet pothuajse perfekt.

Për të shmangur dhimbjet e panevojshme, u zgjodh Telegram API si frontend.

Faza e parë është shqyrtimi i diagramës strukturore të arkitekturës përfundimtare, më pas do të kalojmë në përshkrimin e secilit komponent dhe do të formulojmë procesin e përpunimit të suksesshëm të imazheve.

Kampion përmbledhës i arkitekturës së shërbimit për vlerësimin e pamjes mbi baza të rrjeteve neuronale

Diagrami struktural i arkitekturës përfundimtare

Të flasim më në detaje mbi secilin nga komponentët e diagramës, duke ndarë përgjegjësinë e tyre të vetme në procesin e vlerësimit të imazhit.

Mikrosherbimi «attrai-telegram-bot»

Ky mikroshĂ«rbim inkapsulon tĂ« gjitha ndĂ«rveprimet me Telegram API. Mund tĂ« dallojmĂ« dy skenarĂ« kryesorĂ« – punimi me imazhin e pĂ«rdoruesit dhe punimi me rezultatin e procesit tĂ« vlerĂ«simit. Do tĂ« shqyrtojmĂ« tĂ« dyja skenarĂ«t nĂ« pĂ«rmbledhje.

Kur merrni një mesazh të përdoruesit me një imazh:

  1. Kryhet filtrimi, i cili përfshin këto kontrollime:
    • Prania e madhĂ«sisĂ« optimale tĂ« imazhit
    • Numri i imazheve tĂ« pĂ«rdoruesit qĂ« tashmĂ« janĂ« nĂ« radhĂ«
  2. Gjatë kalimit të filtër primar, imazhi ruhet në docker volume
  3. NĂ« radhĂ«n “to_estimate” prodhohet njĂ« detyrĂ«, ku, ndĂ«r tĂ« tjera, pĂ«rfshihet rruga deri te imazhi, qĂ« ndodhet nĂ« volume tonĂ«
  4. Nëse hapat e mësipërm përfundojnë me sukses - përdoruesi do të marrë një mesazh me kohën e përafërt të përpunimit të imazhit, e cila llogaritet në bazë të numrit të detyrave në radhë. Në rast gabimi, përdoruesi do të njoftohet qartë - duke dërguar një mesazh me informacionin se çfarë mund të ketë shkuar keq.

Gjithashtu, ky mikroshĂ«rbim, si punĂ«tor celere, dĂ«gjon radhĂ«n “after_estimate”, e cila Ă«shtĂ« e destinuar pĂ«r detyrat qĂ« kanĂ« kaluar pĂ«rmes pipeline-it tĂ« vlerĂ«simit.

Kur marrim njĂ« detyrĂ« tĂ« re nga “after_estimate”:

  1. Nëse imazhi është përpunuar me sukses - i dërgojmë rezultatin përdoruesit, në të kundërt - njoftojmë për gabimin
  2. Fshijmë imazhin, që është rezultati i pipeline-it të vlerësimit

MikroshĂ«rbimi i vlerĂ«simit “attrai-estimator”

Ky mikroshërbim është punëtor celere dhe inkapsulon gjithçka që lidhet me pipeline-in e vlerësimit të imazhit. Algoritmi i punës këtu është një - do ta shqyrtojmë atë.

Kur marrim njĂ« detyrĂ« tĂ« re nga “to_estimate”:

  1. Kaluajmë imazhin përmes pipeline-it të vlerësimit:
    1. Ngarkohet imazhi në memorje
    2. Rregullojmë imazhin në madhësinë e duhur
    3. Gjejmë të gjitha fytyrat (MTCNN)
    4. Vlerësojmë të gjitha fytyrat (mbështjellim fytyrat e gjetura më parë në një grup dhe bëjmë inferencën me ResNet34)
    5. Renderojmë imazhin përfundimtar
      1. Vizatojmë kutitë ndihmëse
      2. Vizatojmë vlerësimet
  2. Fshijmë imazhin origjinal nga përdoruesi
  3. Ruajmë daljen nga pipeline-i i vlerësimit
  4. Vendosim detyrën në radhë "after_estimate", e cila dëgjohet nga mikroshërbisi i përmendur më sipër "attrai-telegram-bot"

Graylog (+ mongoDB + Elasticsearch)

Graylog është një zgjidhje për menaxhimin qendror të log-eve. Në këtë projekt, ai është përdorur sipas qëllimeve të tij të drejta.

Zgjedhja ra pikërisht mbi të, dhe jo mbi stakun e njohur për të gjithë ELK për shkak të lehtësisë së punës me të nga Python. Gjithçka që duhet bërë për logimin në Graylog është të shtoni GELFTCPHandler nga paketa graypy në handler-at tjerë root logger të mikroshërbisit tonë python.

Unë, si një person që më parë ka punuar vetëm me stakun ELK, në përgjithësi kam pasur një përvojë pozitive gjatë punës me Graylog. E vetmja gjë që më shqetëson është superioriteti i karakteristikave të Kibana-s ndaj ndërfaqes së web-it të Graylog.

RabbitMQ

RabbitMQ — Ă«shtĂ« njĂ« broker mesazhesh i bazuar nĂ« protokollin AMQP.

Në këtë projekt, ai u përdor si brokeri më stabil dhe i provuar me kohën për Celery dhe punoi në modalitetin durable.

Redis

Redis — Ă«shtĂ« njĂ« DBMS NoSQL qĂ« punon me struktura tĂ« dhĂ«nash tĂ« tipit "çelĂ«s — vlerĂ«".

Ndonjëherë lind nevoja për të përdorur objekte të zakonshme në mikroshërbime të ndryshme Python, të cilat implementojnë disa struktura të dhënash.

Për shembull, në Redis ruhet një hashmap i tipit "telegram_user_id => numri i task-eve aktive në radhë", çka lejon kufizimin e numrit të kërkesave nga një përdorues në një vlerë të caktuar dhe, në këtë mënyrë, parandalon sulmet DoS.

Formulojmë procesin e trajtimit të suksesshëm të imazhit

  1. Përdoruesi dërgon një imazh në botin Telegram
  2. "attrai-telegram-bot" merr mesazhin nga API i Telegram dhe e analizojnë atë
  3. Tasku me imazhin shtohet në radhën asinkrone "to_estimate"
  4. Përdoruesi merr një mesazh me kohën e parashikuar për vlerësim
  5. "attrai-estimator" merr taskun nga radhë "to_estimate", e kalon atë përmes tubit të vlerësimit dhe e prodhon taskun në radhën "after_estimate"
  6. "attrai-telegram-bot", që dëgjon radhën "after_estimate", i dërgon rezultatin përdoruesit

DevOps

Finally, after reviewing the architecture, we can move on to the no less interesting part — DevOps

Docker Swarm

 

Kampion përmbledhës i arkitekturës së shërbimit për vlerësimin e pamjes mbi baza të rrjeteve neuronale

Docker Swarm  — a clustering system whose functionality is implemented within the Docker Engine and available out of the box.

Using the ‘swarm’, all nodes in our cluster can be divided into 2 types – worker and manager. Containers (stacks) are deployed on machines of the first type, while machines of the second type are responsible for scaling, balancing, and other cool features. Managers are, by default, also workers.

Kampion përmbledhës i arkitekturës së shërbimit për vlerësimin e pamjes mbi baza të rrjeteve neuronale

A cluster with one leader manager and three workers

The minimum possible size of a cluster is 1 node, with a single machine acting as both the leader manager and worker. Based on the project size and minimal fault tolerance requirements, it was decided to use this approach.

To get ahead of myself, I’ll say that since the first production deployment in mid-June, there have been no issues related to this cluster organization (but this doesn’t mean that such an organization is acceptable in any medium-large projects that have reliability requirements).

Docker Stack

Në modin «swarm», për shpërndarjen e stekëve (grupeve të shërbimeve docker) është përgjegjës docker stack

Ai mbështet konfigurimet docker-compose, duke lejuar përdorimin e parametrave të shpërndarjes.  

Për shembull, me këta parametra janë kufizuar burimet për çdo instancë të mikroshërbimit të vlerësimit (i alokoni N instancave N bërthama, në mikroshërbim kufizojmë numrin e bërthamave, që përdoret nga PyTorch, në një)

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


ËshtĂ« e rĂ«ndĂ«sishme tĂ« theksohet se Redis, RabbitMQ dhe Graylog janĂ« shĂ«rbime stateful dhe nuk Ă«shtĂ« kaq e lehtĂ« t’i shkallĂ«zosh si «attrai-estimator»

Për të parashikuar pyetjen - pse jo Kubernetes?

Duket se përdorimi i Kubernetes në projekte të vogla dhe mesme është një overhead, të gjithë funksionalitetin e nevojshëm mund ta merrni nga Docker Swarm, i cili është mjaft miqësor për përdoruesit në menaxhimin e kontejnerëve, si dhe ka një prag të ulët hyrjeje.

Infrastruktura

Kjo e gjithë është vendosur në VDS me këto karakteristika:

  • CPU: 4 bĂ«rthama IntelÂź XeonÂź Gold 5120 CPU @ 2.20GHz
  • RAM: 8 GB
  • SSD: 160 GB

Pas testimit local të ngarkesës, dukej se nëse ka një fluks të konsiderueshëm përdoruesish, kjo makinë do të ishte e mjaftueshme.

Por, menjëherë pas deploy-it, postova një lidhje në një nga bordet më të njohura të imazheve në CE (po, atë vetë), dhe pas kësaj njerëzit u interesuan dhe brenda disa orësh, shërbimi përfundoi me sukses përpunimin e dhjetëra mijëra imazheve. Në momentet kulmore, burimet e CPU dhe RAM nuk u përdorën as gjysmë.

Kampion përmbledhës i arkitekturës së shërbimit për vlerësimin e pamjes mbi baza të rrjeteve neuronale
Kampion përmbledhës i arkitekturës së shërbimit për vlerësimin e pamjes mbi baza të rrjeteve neuronale

Pak më shumë grafikë

Numri i përdoruesve unik dhe kërkesat për vlerësim, nga momenti i deploy-it, në varësi të ditës

Kampion përmbledhës i arkitekturës së shërbimit për vlerësimin e pamjes mbi baza të rrjeteve neuronale

Shpërndarja e kohës së inferencës së rafteve të vlerësimit

Kampion përmbledhës i arkitekturës së shërbimit për vlerësimin e pamjes mbi baza të rrjeteve neuronale

PĂ«rfundimet

PĂ«rmbledhĂ«sisht, mund tĂ« them se arkitektura dhe qasja pĂ«r orkestrimin e kontejnerĂ«ve u vĂ«rtetuan plotĂ«sisht – edhe nĂ« momentet kulmore nuk kishte rĂ«nie apo ngadalĂ«sim nĂ« kohĂ«n e pĂ«rpunimit. 

Mendoj se projektet e vogla dhe të mesme, që përdorin inferencë në kohë reale me rrjete neuronale në CPU, mund të adoptojnë me sukses praktikat e përshkruara në këtë artikull.

Do tĂ« shtoj se fillimisht artikulli ishte mĂ« i gjatĂ«, por qĂ« tĂ« mos postoj njĂ« tekst tĂ« gjatĂ«, vendosa tĂ« shkep disa pika nĂ« kĂ«tĂ« artikull — do t'i kthehemi nĂ« publikimet e ardhshme.

Mund ta provosh botin nĂ« Telegram — @AttraiBot, do tĂ« funksionojĂ« sĂ« paku deri nĂ« fund tĂ« vjeshtĂ«s 2020. KujtojmĂ« — nuk ruhen tĂ« dhĂ«na tĂ« pĂ«rdoruesve — as imazhet origjinale, as rezultatet e procesit tĂ« vlerĂ«simit — gjithçka zhduket pas pĂ«rpunimit.

Burimi: habr.com

Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« đŸ”„ Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« | ProHoster