Ülevaade teenuse arhitektuurist välimuse hindamiseks närvivõrkude põhjal

Sissejuhatus

Tere!

Selles artiklis jagan kogemusi mikroteenuste arhitektuuri loomisel projektile, mis kasutab närvivõrke.

Räägime arhitektuuri nõuetest, vaatame erinevaid struktuuri diagramme, analüüsime iga valmis arhitektuuri komponenti ning hindame lahenduse tehnilisi näitajaid.

Head lugemist!

Mõned sõnad ülesandest ja selle lahendusest

Peamine mõte on hinnata inimese atraktiivsust kümnepallisel skaalal fotode põhjal.

Selles artiklis kõrvale jätame kirjeldused nii kasutatavatest närvivõrkudest kui ka andmete ettevalmistamise ja õpetamise protsessist. Siiski, ühes järgmises publikatsioonis, naaseme kindlasti süvaprobleemide analüüsi juurde.

Praegu vaatleme ülemise taseme lõikes hindamispipeline'i, keskendudes mikroteenuste koostoimele projekti üldises arhitektuuris. 

Atraktiivsuse hindamisprotsessis jagunes ülesanne järgmisteks osadeks:

1. Näolist tuvastamist piltidel
2. Iga näo hindamine
3. Tulemuse renderdamine

Esimene probleem lahendatakse eelnevalt treenitud MTCNN. Teise jaoks treeniti konvolutsiooniline närvivõrk PyTorch'is, kus backbone'ina kasutati ResNet34 – kaalu tasakaalu „kvaliteet / CPU infereerimise kiirus"

Hindamispipeline'i funktsionaalne diagramm

Projekti arhitektuurinõuete analüüs

Elu tsüklis ML projekti arhitektuuri ja mudeli juurutamise automatiseerimise etapid on sageli ajaliselt ja ressursiliselt kõige kulukamad.

ML projekti elu tsükkel

See projekt ei ole erand - otsustati mähkida hindamispipeline veebiteenusesse, milleks tuli süveneda arhitektuuri. Määrati järgmised põhinõuded:

1. Üksne logide salvestamine - kõik teenused peavad kirjutama logid ühte kohta, et neid oleks mugav analüüsida
2. Hindamisteenuse horisontaalne skaleerimise võimalus - kuna see on tõenäoliselt pudelikael
3. Iga pildi hindamiseks tuleb eraldada sama palju protsessori ressursse - vältimaks ajakulu jaotuses erandeid
4. Kiire (taas)juurutamine nii konkreetsete teenuste kui ka kogu stack'i jaoks
5. Võimalus, vajadusel, kasutada erinevates teenustes ühiseid objekte

Arhitektuur

Pärast nõuete analüüsi sai selgeks, et mikroteenuste arhitektuur sobib praktiliselt ideaalselt.

Liigne peavalu vältimiseks valiti front-endina Telegram API.

Alustame valmis arhitektuuri struktuuridiagrammi vaatamisega, seejärel liikumme iga komponendi kirjeldamise juurde ning formaliseerime eduka pildi töötlemise protsessi.

Valmis arhitektuuri struktuuridiagramm

Arutame iga diagrammi komponendi üle, tuvastame nende ühe vastutuse pildi hindamise protsessis.

Mikroteenus „attrai-telegram-bot“

See mikroteenus kapseldab kõik interaktsioonid Telegram API-ga. Võime eristada kahte peamist stsenaariumi: töötamine kasutaja pildiga ja töötamine hindamise töötluse tulemusega. Vaatame mõlemat stsenaariumi üldiselt.

Kasutaja sõnumi pildi saamisel:

1. Toimub filtreerimine, mis koosneb järgmistest kontrollidest:
   • Pildi optimaalse suuruse olemasolu
   • Kasutaja piltide arv, mis juba järjekorras on
2. Kui esialgne filtreerimine on läbitud, salvestatakse pilt docker volüümisse
3. Järjekorda “to_estimate” produtseeritakse ülesanne, milles muu hulgas sisaldub tee pildini, mis asub meie volüümis
4. Kui ülaltoodud etapid on edukalt läbitud, saab kasutaja sõnumi pildi töötlemise umbkaudse aja kohta, mis arvutatakse järjekorras olevate ülesannete arvu alusel. Vea korral teavitatakse kasutajat selgelt - saadetakse sõnum, kus on teave selle kohta, mis oleks võinud valesti minna.

Samuti kuulab see mikroteenus, nagu celery worker, järjekorda „after_estimate“, mis on mõeldud hindamise töötluse läbinud ülesannetele.

Uue ülesande saamisel järjekorrast “after_estimate”:

1. Kui pilt on edukalt töödeldud, saadame tulemuse kasutajale, kui ei - teavitame veast
2. Kustutame pildi, mis on hindamise töötluse tulemus

Hindamisteenus „attrai-estimator“

See mikroteenus on celery worker ja kapseldab kõik, mis on seotud pildihindamise töötlusega. Siin on tööprotsess üks - vaatame seda.

Uue ülesande saamisel järjekorrast “to_estimate”:

1. Lastakse pilt läbi hindamisprotsessi:
   1. Laadime pildi mälu
   2. Kohandame pildi soovitud suurusele
   3. Leiame kõik näod (MTCNN)
   4. Hindame kõiki nägusid (ümbritseme eelnevalt leitud näod partii formaadis ja teeme inferentsi ResNet34 abil)
   5. Renderdame lõpppildi
      1. Joonistame välja piirjooned
      2. Joonistame välja hinnangud
2. Kustutame kasutaja (algse) pildi
3. Salvestame hindamise väljundi
4. Paneme ülesande järjekorda „after_estimate“, mida kuulab ülalmainitud mikroteenus „attrai-telegram-bot“

Graylog (+ mongoDB + Elasticsearch)

Graylog — on lahendus logide tsentraalseks haldamiseks. Selles projektis kasutati seda oma otstarbele vastavalt.

Valiku põhjuseks oli just see, mitte tuntud ELK stack, kuna sellega töötamine Pythonis on mugav. Kõik, mis on vajalik Graylogi logimiseks, on lisada GELFTCPHandler pakist graypy muude meie python-mikrosüsteemi juurlogeri haldurite hulka.

Mina, inimesena, kes on varem töötanud ainult ELK stackiga, sain Graylogiga töötamisest kokkuvõttes positiivse kogemuse. Ainus, mis häirib, on Kibana funktsioonide ülekaal Graylogi veebiliidese ees.

RabbitMQ

RabbitMQ — on AMQP protokollil põhinev sõnumite vahetus süsteem.

Selles projektis kasutati seda kui kõige stabiilsemat ja aja jooksul testitud vahetussüsteemi Celery jaoks ja see töötas durable režiimis.

Redis

Redis — on NoSQL andmebaas, mis töötab „võti — väärtus“ andmestruktuuridega.

Tuleb kohati kasutada erinevates python-mikrosüsteemides ühiseid objekte, mis rakendavad mõningaid andmestruktuure.

Näiteks, Redis sisaldab hashmapi kujul „telegram_user_id => aktiivsete ülesannete arv järjekorras“, mis võimaldab piirata teatud väärtusega ühe kasutaja päringute arvu, vältides seeläbi DoS-rünnakuid.

Formuleerime ära töötava pildi töötlemise protsessi

1. Kasutaja saadab pildi Telegrami botile
2. „attrai-telegram-bot“ saab sõnumi Telegrami API-lt ja tõlgendab selle
3. Ülesanne pildiga lisatakse asünkroonsesse järjekorda „to_estimate“
4. Kasutaja saab sõnumi planeeritud hindamise ajaga
5. „attrai-estimator“ võtab ülesande järjekorrast „to_estimate“, edastab selle hindamisprotsessi läbi ja toodab ülesande järjekorda „after_estimate“
6. „attrai-telegram-bot“, mis kuulab järjekorda „after_estimate“, saadab tulemuse kasutajale

DevOps

Lõpuks, pärast arhitektuuri ülevaatamist, võime minna mitte vähem huvitavasse ossa — DevOps

Docker Swarm

Docker Swarm  — klasteriseerimisüsteem, mille funktsioon on rakendatud Docker Engine'i sees ja on tootes saadaval.

Roya abil saab meie klastris kõik sõlmed jagada kahe tüübi vahel – worker ja manager. Esimese tüübi masinatel käivitatakse konteinerigruppide (stekid) komplekte, teise tüübi masinad vastutavad skaleerimise, tasakaalustamise ja teiste ägedate funktsioonide eest.Mängijad on vaikimisi ka töötajad.

Klaster, kus on üks juhtiv manager ja kolm töötajat.

Minimaalne klasteri suurus on 1 sõlm, ainus masin töötab samal ajal juhtiva manageri ja töötajana. Projekti suurusest ja minimaalsetest nõudmistest talitlushäirete osas lähtuvalt on otsustatud kasutada just seda lähenemist.

Eelnevalt öeldes, alates esimesest tootmispaigaldusest, mis toimus juuni keskel, ei ole olnud selle klasteri korraldusega seotud probleeme (kuid see ei tähenda, et selline korraldus oleks lubatav igasugustes keskmise ja suurte projektide puhul, millega kaasnevad talitlushäirete nõuded).

Docker Stack

Roya režiimis vastutab stekide (docker teenuste komplektide) käivitamise eest docker stack

See toetab docker-compose konfigureeringuid, võimaldades lisaks kasutada deploy parameetreid.  

Näiteks nende parameetrite abil piirati ressursside jagamist iga üksiku mikroteenuse hindamiseks (jagame N instantsile N tuuma, mikroteenuses piirame PyTorchi 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 stateful teenused ning nende skaleerimine ei ole nii lihtne nagu 'attrai-estimator'.

Eelnevalt küsimusele – miks mitte Kubernetes?

Tundub, et Kubernetes'e kasutamine väikeste ja keskmise suurusega projektide puhul on üleliigne, kogu vajalik funktsionaalsus on saadaval Docker Swarmis, mis on üsna kasutajasõbralik konteinerite koordineerija ja mille sisenemislävi on madal.

Infrastruktuur

Kõik see paigaldati VDS-ile, millel on järgmised omadused:

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

Pärast kohalikku koormustestimist tundus, et tõsise külastajate voolu korral on sellist masinat napilt piisavalt.

Kuid kohe pärast kasutuselevõttu postitasin lingi ühele Venemaa ja naaberriikide populaarseimale pildifoorumile (jah, sellele samale), pärast mida hakkasid inimesed huvi tundma ja mõne tunni jooksul töötas teenus edukalt läbi kümneid tuhandeid pilte. Samal ajal ei kasutanud CPU ja RAM ressursid isegi pooli oma võimetest tipptundidel.

Veidi graafikat

Unikaalsete kasutajate ja hindamispäringute arv kasutuselevõtu hetkest alates, sõltuvalt päevast

Hindamisprotsessi infereerimise ajajaotus

Järeldused

Kokkuvõtlikult võin öelda, et arhitektuur ja konteinerite orkestreerimise lähenemine on end täielikult õigustanud — isegi tipptundidel ei olnud viivitusi ega aeglustumist töötlemise ajas. 

Arvan, et väikeste ja keskmise suurusega projektid, mis kasutavad oma protsessis reaalajas närvivõrkude infereerimist CPU-l, võivad edukalt üle võtta artiklis kirjeldatud tavasid.

Lisaks lisan, et algselt oli artikkel pikem, kuid et mitte postitada liiga mahukat sisu, otsustasin mõned punktid siin artiklis vahele jätta — tuleme nende juurde tagasi järgmistes väljaannetes.

Boti saab katsetada Telegramis — @AttraiBot, see töötab vähemalt kuni 2020. aasta sügise lõpuni. Tuletan meelde — mingeid kasutajaandmeid ei salvestata — ei algseid pilte ega hindamisprotsessi tulemusi — kõik kustutatakse pärast töötlemist.

Allikas: habr.com