Üldine ülevaade teenuste arhitektuurist närvivõrkudel põhineva välimuse hindamiseks

Kanne

Tere!

Selles artiklis jagan oma kogemusi närvivõrke kasutava projekti jaoks mikroteenuse arhitektuuri loomisel.

Räägime arhitektuurinõuetest, vaatame erinevaid struktuuriskeeme, analüüsime igat valminud arhitektuuri komponenti ning hindame ka lahenduse tehnilisi mõõdikuid.

Nautige lugemist!

Paar sõna probleemist ja selle lahendusest

Põhiidee on hinnata foto põhjal inimese atraktiivsust kümnepallisel skaalal.

Selles artiklis loobume nii kasutatavate närvivõrkude kui ka andmete ettevalmistamise ja treenimise protsessi kirjeldamisest. Kuid ühes järgmistest väljaannetest tuleme kindlasti tagasi hindamistorustiku põhjaliku analüüsi juurde.

Nüüd läbime hindamisprotsessi tipptasemel ja keskendume mikroteenuste koostoimele projekti üldise arhitektuuri kontekstis. 

Atraktiivsuse hindamise torustiku kallal töötades jaotati ülesanne järgmisteks komponentideks:

1. Fotodel nägude valimine
2. Iga inimese hinnang
3. Renderdage tulemus

Esimene lahendatakse eelkoolitatud jõududega MTCNN. Teiseks treeniti PyTorchis konvolutsioonilist närvivõrku, kasutades ResNet34 - tasakaalust "CPU järelduste kvaliteet / kiirus"

Hindamiskonveieri funktsionaalne skeem

Projekti arhitektuuri nõuete analüüs

Elutsüklis ML mudeli juurutamise arhitektuuri ja automatiseerimise projektietapid on sageli kõige aeganõudvamad ja ressursimahukamad.

ML-projekti elutsükkel

See projekt pole erand – otsustati pakkida hindamiskonveier võrguteenuseks, mis nõudis arhitektuurisse sukeldumist. Määrati kindlaks järgmised põhinõuded:

1. Ühtne logihoidla – kõik teenused peaksid kirjutama logid ühte kohta, neid peaks olema mugav analüüsida
2. Hindamisteenuse horisontaalse skaleerimise võimalus – kui kõige tõenäolisem pudelikael
3. Iga pildi hindamiseks tuleks eraldada sama palju protsessoriressursse, et vältida kõrvalekaldeid järelduste tegemise aja jaotuses
4. Nii konkreetsete teenuste kui ka virna kui terviku kiire (ümber)juurutamine
5. Võimalus vajadusel kasutada erinevates teenustes levinud objekte

arhitektuur

Pärast nõuete analüüsimist sai selgeks, et mikroteenuse arhitektuur sobib peaaegu ideaalselt.

Asjatutest peavaludest vabanemiseks valiti kasutajaliideseks Telegrami API.

Kõigepealt vaatame valmis arhitektuuri struktuuriskeemi, seejärel liigume edasi iga komponendi kirjelduse juurde ja vormistame ka eduka pilditöötluse protsessi.

Valmis arhitektuuri ehitusskeem

Räägime üksikasjalikumalt diagrammi igast komponendist, märkides neile ühe vastutuse pildi hindamise protsessis.

Mikroteenus “attrai-telegram-bot”

See mikroteenus kapseldab kõik koostoimed Telegram API-ga. On kaks peamist stsenaariumi: kohandatud pildiga töötamine ja hindamiskonveieri tulemusega töötamine. Vaatame mõlemat stsenaariumi üldiselt.

Kui saate kohandatud pildiga sõnumi:

1. Filtreerimine viiakse läbi, mis koosneb järgmistest kontrollidest:
   • Optimaalse pildisuuruse olemasolu
   • Juba järjekorras olevate kasutajapiltide arv
2. Esialgse filtreerimise läbimisel salvestatakse pilt dockeri helitugevusse
3. Järjekorda "to_estimate" luuakse ülesanne, mis sisaldab muuhulgas teed meie köites asuva pildi juurde
4. Kui ülaltoodud sammud on edukalt sooritatud, saab kasutaja teate ligikaudse pilditöötluse aja järgi, mis arvutatakse järjekorras olevate ülesannete arvu alusel. Kui ilmneb tõrge, teavitatakse kasutajat selgesõnaliselt, saates sõnumi, mis sisaldab teavet selle kohta, mis võis valesti minna.

Samuti kuulab see mikroteenus sarnaselt selleritöölisele “after_estimate” järjekorda, mis on mõeldud hindamiskonveieri läbinud ülesannete jaoks.

Kui saate "after_estimate"-lt uue ülesande:

1. Kui pildi töötlemine õnnestub, saadame tulemuse kasutajale, kui mitte, siis teavitame veast.
2. Hindamiskonveieri tulemuseks oleva kujutise eemaldamine

Hindamise mikroteenus "attrai-estimator"

See mikroteenus on selleri töötaja ja sisaldab kõike, mis on seotud pildi hindamise torujuhtmega. Siin on ainult üks tööalgoritm – analüüsime seda.

Uue ülesande saamisel "to_estimate":

1. Käivitame pildi läbi hindamiskonveieri:
   1. Pildi mällu laadimine
   2. Toome pildi vajaliku suuruseni
   3. Kõigi nägude otsimine (MTCNN)
   4. Hindame kõiki nägusid (viimases etapis leitud näod koondame partii ja järeldame ResNet34)
   5. Renderdage lõplik pilt
      1. Joonistame piirdekastid
      2. Reitingute joonistamine
2. Kohandatud (algse) pildi kustutamine
3. Väljundi salvestamine hindamiskonveierist
4. Panime ülesande “after_estimate” järjekorda, mida kuulab ülalpool käsitletud “attrai-telegram-bot” mikroteenus.

Graylog (+ mongoDB + Elasticsearch)

Hallpall on tsentraliseeritud logihalduse lahendus. Selles projektis kasutati seda sihtotstarbeliselt.

Valik langes talle, mitte tavapärasele ELK pinu, kuna sellega on mugav Pythonist töötada. Graylogi sisselogimiseks pole vaja teha muud, kui lisada paketist GELFTCPHandler hallikas meie pythoni mikroteenuse ülejäänud juurlogija käitlejatele.

Varem ainult ELK-stackiga töötanud inimesena sain Graylogiga töötades üldiselt positiivse kogemuse. Ainus, mis masendav, on Kibana funktsioonide paremus Graylogi veebiliidese ees.

JänesMQ

JänesMQ on AMQP protokollil põhinev sõnumivahendaja.

Selles projektis kasutati seda kui kõige stabiilsem ja ajaproovitud selleri maakler ja töötas vastupidavas režiimis.

Redis

Redis on NoSQL DBMS, mis töötab võtmeväärtuste andmestruktuuridega

Mõnikord on vajadus kasutada tavalisi objekte, mis rakendavad teatud andmestruktuure erinevates Pythoni mikroteenustes.

Näiteks salvestab Redis räsikaardi kujul “telegrammi_kasutaja_id => aktiivsete ülesannete arv järjekorras”, mis võimaldab piirata ühe kasutaja päringute arvu teatud väärtuseni ja seeläbi vältida DoS-rünnakuid.

Vormistame eduka pilditöötluse protsessi

1. Kasutaja saadab pildi Telegrami robotile
2. "attrai-telegram-bot" saab sõnumi Telegram API-lt ja analüüsib seda
3. Pildiga ülesanne lisatakse asünkroonsesse järjekorda “to_estimate”
4. Kasutaja saab teate planeeritud hindamisajaga
5. "attrai-estimator" võtab ülesande "to_estimate" järjekorrast, käivitab hinnangud läbi konveieri ja toodab ülesande "after_estimate" järjekorda
6. "attrai-telegram-bot" kuulab "after_estimate" järjekorda, saadab tulemuse kasutajale

DevOps

Lõpuks, pärast arhitektuuri ülevaatamist, võite liikuda sama huvitava osa juurde - DevOps

Dockeri sülem

 

Dockeri sülem  — klasterdamissüsteem, mille funktsionaalsus on realiseeritud Docker Engine'is ja mis on karbist väljas saadaval.

“Sülemi” kasutades saab kõik meie klastri sõlmed jagada kahte tüüpi – töötaja ja juht. Esimest tüüpi masinatel on kasutusel konteinerite rühmad (virnad), teist tüüpi masinad vastutavad skaleerimise, tasakaalustamise ja muid lahedaid funktsioone. Juhid on ka vaikimisi töötajad.

Klaster ühe juhi ja kolme töötajaga

Minimaalne võimalik klastri suurus on 1 sõlm; üks masin toimib samaaegselt nii juhi kui ka töötajana. Lähtudes projekti mahust ja tõrketaluvuse miinimumnõuetest, otsustati kasutada seda lähenemist.

Tulevikku vaadates ütlen, et alates esimesest tootmise tarnimisest, mis oli juuni keskel, pole selle klastriorganisatsiooniga seotud probleeme olnud (aga see ei tähenda, et selline organisatsioon oleks kuidagi vastuvõetav üheski keskmises-suures). projektid, mille suhtes kehtivad tõrketaluvuse nõuded).

Docker Stack

Sülemisrežiimis vastutab ta virnade (dokiteenuste komplektide) juurutamise eest. dokkide virn

See toetab dokkide koostamise konfiguratsioone, võimaldades teil lisaks kasutada juurutamisvalikuid.  

Näiteks neid parameetreid kasutades olid ressursid iga hindamise mikroteenuse eksemplari jaoks piiratud (eraldame N tuuma N eksemplari jaoks, mikroteenuses endas piirame PyTorchi poolt kasutatavate tuumade arvu ühega)

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

Oluline on märkida, et Redis, RabbitMQ ja Graylog on olekupõhised teenused ja neid ei saa nii lihtsalt skaleerida kui "attrai-estimatorit".

Eelnev küsimus – miks mitte Kubernetes?

Tundub, et Kubernetese kasutamine väikestes ja keskmistes projektides on kulukas, kogu vajaliku funktsionaalsuse saab Docker Swarmist, mis on konteinerorkestri jaoks üsna kasutajasõbralik ja millel on ka madal sisenemisbarjäär.

Infrastruktuur

Kõik see võeti kasutusele VDS-is järgmiste omadustega:

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

Pärast kohalikku koormustestimist tundus, et tõsise kasutajate juurdevoolu korral sellest masinast piisab.

Kuid kohe pärast juurutamist postitasin lingi SRÜ ühele populaarsemale pilditahvlile (jah, seesama), misjärel tekkis inimestel huvi ja teenus töötles mõne tunniga edukalt kümneid tuhandeid pilte. Samal ajal ei kasutatud tipphetkedel CPU ja RAM-i ressursse pooleldi ära.

Veel natuke graafikat

Unikaalsete kasutajate ja hindamistaotluste arv alates kasutuselevõtust olenevalt päevast

Hindamiskonveieri järelduste ajajaotus

Järeldused

Kokkuvõtteks võin öelda, et arhitektuur ja lähenemine konteinerite orkestreerimisele õigustas end igati – isegi tipphetkedel ei toimunud töötlemisaja langust ega longust. 

Ma arvan, et väikesed ja keskmise suurusega projektid, mis kasutavad oma protsessis protsessori närvivõrkude reaalajas järeldusi, saavad selles artiklis kirjeldatud tavasid edukalt kasutusele võtta.

Lisan, et algselt oli artikkel pikem, kuid selleks, et pikka lugemist mitte postitada, otsustasin mõned punktid sellest artiklist välja jätta - nende juurde tuleme tulevastes väljaannetes tagasi.

Boti saab pista Telegramis - @AttraiBot, see töötab vähemalt 2020. aasta sügise lõpuni. Tuletan meelde, et kasutajaandmeid ei salvestata – ei originaalpilte ega hindamiskonveieri tulemusi – kõik lammutatakse pärast töötlemist.

Allikas: www.habr.com