Teenuse arhitektuuri üldülevaade, et hinnata välist ilmet põhinevalt närvivõrkudel

Sissejuhatus

Tere!

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

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

Head lugemist!

Mõned sõnad ülesandest ja selle lahendusest

Peamine idee on hinnata inimese atraktiivsust fotode põhjal kümne punkti süsteemis.

Selles artiklis ei käsitle me ei kasutatavaid tehisnärvivõrke ega andmete ettevalmistamise ja treenimise protsessi. Küll aga naaseme ühes järgnevates publikatsioonides süvitsi pipeline'i analüüsi juurde.

Praegu läbime pipeline'i ülevaate, keskendudes mikroteenuste omavahelisele suhtlemisele projekti üldises arhitektuuris. 

Atraktiivsuse hindamise pipeline'i töötamisel oli ülesanne dekomponeeritud järgmistesse osadesse:

1. Nägude eristamine fotodel
2. Iga näo hindamine
3. Tulemuse renderdamine

Esimene probleem lahendatakse eelõpetatud MTCNN. Teise jaoks treiti konvolutsiooniline närvivõrk PyTorchis, kasutades backbone'ina ResNet34 – tasakaalu «kvaliteet / CPU-lt innfereerimise kiirus»

Töötluse hindamise funktsionaalne diagramm

Nõuete analüüs projekti arhitektuurile

Elutsükli ML projekti etapid arhitektuuri ja mudeli juurutamise automatiseerimise osas on sageli ühed kõige aeganõudvamad ning ressursimahukad.

ML projekti elutsükkel

See projekt ei ole erand – otsustati, et hindamise töövoog pakitakse veebiteenuseks, mille jaoks tuli süveneda arhitektuuri. Määratleti järgmised põhiv nõuded:

1. Ühtne logide salvestamine – kõik teenused peavad kirjutama logid ühte kohta, neid peab olema mugav analüüsida
2. Hindamisteenuse horisontaalne skaleeritavus – kui tõenäolisem Bottleneck
3. Iga pildi hindamiseks tuleb eraldada sama palju CPU ressursse – et vältida infereerimise aja jaotuses kõrvalekaldeid
4. Kiire (taas)juurutamine nii konkreetsete teenuste kui ka kogu stäki jaoks
5. Võimalus kasutada vajadusel erinevates teenustes ühiseid objekte

Architecture

Pärast nõuete analüüsi jäi selgeks, et mikroteenus arhitektuur sobitub praktiliselt ideaalselt.

Liigne peavalu vältimiseks valiti frontendiks Telegram API.

Alustuseks vaatame valminud arhitektuuri struktuuridiagrammi, seejärel liigume edasi iga komponendi kirjeldamise juurde ja formaliseerime eduka pildi töötlemise protsessi.

Valminud arhitektuuri struktuuridiagramm

Räägime lähemalt iga diagrammi komponendi kohta, määratleme nende üksiku vastutuse pildi hindamise protsessis.

Mikroslužba «attrai-telegram-bot»

See mikroslužba kapseldab kõik suhtlused Telegram API-ga. Tõstame esile 2 peamist stsenaariumi - töötamine kasutaja pildiga ja töötamine hindamise pipelini tulemusega. Vaatame mõlemat stsenaariumi üldiselt.

Kasutaja pildi saatmise korral:

1. Teostatakse filtreerimine, mis koosneb järgmistest kontrollidest:
   • Pildi optimaalse suuruse olemasolu
   • Kasutaja piltide arv, mis juba järjekorras on
2. Esialgse filtreerimise läbimise korral salvestatakse pilt docker mahutisse
3. Ootele ‘to_estimate’ lisatakse ülesanne, milles on muu hulgas pildi tee, mis asub meie mahutis
4. Kui ülaltoodud etapid on edukalt läbitud, saab kasutaja teadet pildi töötlemise umbkaudse aja kohta, mis arvutatakse järjekorras olevate ülesannete arvu põhjal. Vigade korral teavitame kasutajat selgelt – saatmise teel teate, milles on kirjas, mis võis valesti minna.

Samuti kuulab see mikroteenus, nagu celery töötaja, järjekorda ‘after_estimate’, mis on mõeldud hindamisprotsessist läbinud ülesannetele.

Uue ülesande saamisel ‘after_estimate’:

1. Kui pilt on edukalt töödeldud, saadame tulemuse kasutajale, kui mitte – teavitame veast
2. Kustutame pildi, mis on hindamisprotsessi tulemus

Hindamis mikroteenus ‘attrai-estimator’

See mikroteenus on celery töötaja ja sisaldab endas kõike, mis on seotud pildi hindamise protsessiga. Siin on töö meetod ühekordne – tutvustame seda.

Uue ülesande saamisel ‘to_estimate’:

1. Käime pildi läbi hindamisprotsessi:
   1. Laadime pildi mällu
   2. Kohandame pildi soovitud suurusele
   3. Otsime kõik näod (MTCNN)
   4. Hindame kõiki nägusid (pakkime selle punktis leitud näod ja teeme ResNet34-ga järeldused)
   5. Renderdame lõplikku pilti
      1. Joonistame välja piirjooned
      2. Joonistame hinnangud
2. Kustutame kasutaja (algse) pildi
3. Salvestame hindamise väljundi
4. Paneme ülesande järjekorda "after_estimate", millele kuulab eeltoodud mikroteenus "attrai-telegram-bot"

Graylog (+ mongoDB + Elasticsearch)

Graylog on lahendus logide keskse haldamise jaoks. Antud projektis kasutati seda tema otseseks otstarbeks.

Valik langes just tema kasuks, mitte tuttava ELK stäki, mugavuse tõttu töötamisel Pythonis. Kõik, mis on vajalik Graylogis logimiseks, on GELFTCPHandleri lisamine paketi graypy juurde meie Python mikroteenuse teistele juur logijatele.

Mina, kui inimene, kes on varem töötanud vaid ELK stäkiga, sain Graylogiga töötamisel positiivse kogemuse. Ainus, mis pettumust valmistab, on Kibana funktsioonide üleolek Graylogi veebiliidese ees.

RabbitMQ

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

Selles projektis kasutati seda kõige stabiilsema ja aja jooksul tõestatud vahendina Celery jaoks ning see töötas durable-režiimis.

Redis

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

Mõnikord on vajalik kasutada erinevates python-mikroteenustes ühiseid objekte, mis rakendavad mõningaid andmestruktuure.

Näiteks Redis salvestab hashmap'i kujul „telegram_user_id => aktiivsete ülesannete arv järjekorras”, mis võimaldab piirata ühe kasutaja päringute arvu kindla väärtusega ja seeläbi vältida DoS-rünnakuid.

Formaliseerime pildi eduka töötlemise protsessi

1. Kasutaja saadab pildi Telegrami boti
2. «attrai-telegram-bot» saab sõnumi Telegram API-st ja analüüsib seda
3. Pilt lisatakse asünkroonsesse järjekorda «to_estimate»
4. Kasutaja saab sõnumi kavandatud hindamise ajast
5. «attrai-estimator» võtab ülesande järjekorrast «to_estimate», käivitab selle hindamispipeline'i ja edastab ü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, saab liikuda mitte vähem huvitavasse ossa — DevOps

Docker Swarm

Docker Swarm  — klastri süsteem, mille funktsionaalsus on sisse ehitatud Docker Engine'i ja saadaval välja pakitud.

Kasutades „parve”, saab meie klastri kõik sõlmed jagada kaheks tüübiks – worker ja manager. Esimese tüübi masinatel käivitatakse konteinerigruppide (stekkide) rippmenüüd, teise tüübi masinad vastutavad skaleerimise, tasakaalustamise ja teiste ägedate funktsioonide. Managers on vaikimisi ka worker'id.

Klastril on üks leader manager ja kolm worker'it

Klastri minimaalne suurus on 1 sõlm, ainus masin täidab samaaegselt nii leader manager'i kui ka worker'i ülesandeid. Projekti suurusest ja minimaalsetest nõuetest sõltuva töökindluse osas tehti otsus kasutada just sellist lähenemist.

Kiirelt öeldes, alates esimesest tootmisest, mis toimus juuni keskpaiku, ei olnud mingeid probleeme seoses selle klastri korraldusega (kuid see ei tähenda, et selline korraldus oleks mingil kujul lubatav keskmise suurusega projektides, millele kehtivad töökindluse nõuded).

Docker Stack

Režiimis «roja» vastutab stekkide (docker teenuste komplekti) juurutamise eest docker stack

See toetab docker-compose konfiguratsioone, võimaldades lisaks kasutada juurutamisparameetreid.  

Näiteks piiratud ressursside määramine iga mikroteenuse instantsi jaoks (jagame N instantsi jaoks N protsessorituuma, mikroteenuses piirame PyTorch'iga 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 pole sama lihtne kui «attrai-estimatoril»

Eelmise küsimuse eeldamine – miks mitte Kubernetes?

Tundub, et Kubernetes'e kasutamine väikestes ja keskmise suurusega projektides on üleliigne, kogu vajalik funktsionaalsus on võimalik saada Docker Swarm'ilt, mis on konteinerite orkestreerimiseks üsna kasutajasõbralik ja mille sisseastumispiir on madal.

Infrastruktuur

Kõik see juurutati VDS-il järgmiste omadustega:

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

Pärast kohalikku koormustestimist näis, et tõsise kasutajate voolu korral jääb sellest masinast napilt puudu.

Kuid kohe pärast juurutamist jagasin linki ühe populaarseima pildi jagamise platvormi kohta (jah, just selle), pärast mida hakkasid inimesed huvituma ja mõne tunni jooksul suutis teenus edukalt töödelda kümneid tuhandeid pilte. Samuti ei olnud pikki koormusi CPU ja RAM ressursid isegi pooledki kasutuses.

Veidi graafikat

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

Hindamise toru töötlusaegade jaotumine

Järeldused

Kokkuvõtteks võin öelda, et arhitektuur ja konteinerite orkestreerimise lähenemine õigustasid end täielikult — isegi tipptundidel ei olnud langusi ega aeglaseid töötlemise hetki. 

Arvan, et väikese ja keskmise suurusega projektid, mis kasutavad oma protsessis reaalaja närvivõrkude järeldust CPU-l, saavad edukalt omaks võtta artiklis kirjeldatud praktikaid.

Lisan, et algselt oli artikkel pikem, kuid et mitte postitada pikka lugemist, otsustasin mõned aspektid selles artiklis välja jätta — naaseme nende juurde järgmistes publikatsioonides.

Boti saab proovida Telegramis — @AttraiBot, see töötab vähemalt 2020. aasta sügiseni. Tuletan meelde — mingeid kasutajaandmeid ei salvestata — ei algseid pilte, ega ka tulemusi hinnangupipeline'ist — kõik kustutatakse pärast töötlemist.

Allikas: habr.com