ProHoster > Blog > uprava > Opći pregled arhitekture servisa za procjenu izgleda na temelju neuronskih mreža

Opći pregled arhitekture servisa za procjenu izgleda na temelju neuronskih mreža

Opći pregled arhitekture servisa za procjenu izgleda na temelju neuronskih mreža

Ulazak

Pozdrav!

U ovom ću članku podijeliti svoje iskustvo izgradnje mikroservisne arhitekture za projekt koji koristi neuronske mreže.

Razgovarajmo o zahtjevima arhitekture, pogledajmo razne strukturne dijagrame, analizirajmo svaku od komponenti gotove arhitekture i također procijenimo tehničke metrike rješenja.

Uživajte u čitanju!

Nekoliko riječi o problemu i njegovom rješenju

Glavna ideja je procijeniti nečiju privlačnost na ljestvici od deset stupnjeva na temelju fotografije.

U ovom ćemo se članku udaljiti od opisa korištenih neuronskih mreža i procesa pripreme podataka i obuke. Međutim, u jednoj od sljedećih publikacija sigurno ćemo se vratiti dubljoj analizi procesa procjene.

Sada ćemo proći kroz cjevovod evaluacije na najvišoj razini i usredotočit ćemo se na interakciju mikroservisa u kontekstu cjelokupne arhitekture projekta. 

Prilikom rada na cjevovodu za procjenu atraktivnosti, zadatak je rastavljen na sljedeće komponente:

  1. Odabir lica na fotografijama
  2. Ocjena svake osobe
  3. Prikaz rezultata

Prvi se rješava snagama unaprijed obučenih MTCNN. Za drugu, konvolucijska neuronska mreža trenirana je na PyTorchu, koristeći ResNet34 – iz ravnoteže “kvaliteta / brzina zaključivanja na CPU”

Opći pregled arhitekture servisa za procjenu izgleda na temelju neuronskih mreža

Funkcionalni dijagram evaluacijskog cjevovoda

Analiza zahtjeva arhitekture projekta

U životnom ciklusu ML Projektne faze rada na arhitekturi i automatizaciji implementacije modela često su među najdugotrajnijima i najzahtjevnijim.

Opći pregled arhitekture servisa za procjenu izgleda na temelju neuronskih mreža

Životni ciklus ML projekta

Ovaj projekt nije iznimka - donesena je odluka da se cjevovod za ocjenjivanje uklopi u online uslugu, što je zahtijevalo uranjanje u arhitekturu. Identificirani su sljedeći osnovni zahtjevi:

  1. Objedinjena pohrana dnevnika – sve usluge bi trebale pisati zapisnike na jednom mjestu, trebali bi biti praktični za analizu
  2. Mogućnost horizontalnog skaliranja usluge procjene – kao najvjerojatnije usko grlo
  3. Ista količina procesorskih resursa treba biti dodijeljena za procjenu svake slike kako bi se izbjegle odstupanja u distribuciji vremena za zaključivanje
  4. Brza (ponovna) implementacija i specifičnih usluga i skupa u cjelini
  5. Mogućnost, ako je potrebno, korištenja zajedničkih objekata u različitim uslugama

arhitektura

Nakon analize zahtjeva, postalo je očito da arhitektura mikroservisa gotovo savršeno odgovara.

Kako bismo se riješili nepotrebnih glavobolja, kao frontend odabran je Telegram API.

Prvo, pogledajmo strukturni dijagram gotove arhitekture, zatim prijeđimo na opis svake od komponenti, a također formaliziramo proces uspješne obrade slike.

Opći pregled arhitekture servisa za procjenu izgleda na temelju neuronskih mreža

Strukturni dijagram gotove arhitekture

Razgovarajmo detaljnije o svakoj od komponenti dijagrama, označavajući ih Jedinstvenom odgovornošću u procesu procjene slike.

Mikroservis “attrai-telegram-bot”

Ova mikrousluga sažima sve interakcije s Telegram API-jem. Postoje 2 glavna scenarija: rad s prilagođenom slikom i rad s rezultatom niza procjena. Pogledajmo oba scenarija općenito.

Kada primite prilagođenu poruku sa slikom:

  1. Provodi se filtracija koja se sastoji od sljedećih provjera:
    • Dostupnost optimalne veličine slike
    • Broj korisničkih slika koje su već u redu
  2. Kada prođe početno filtriranje, slika se sprema u volumen dockera
  3. Zadatak se proizvodi u redu čekanja "to_estimate", koji uključuje, između ostalog, put do slike koja se nalazi u našem volumenu
  4. Ako su gornji koraci uspješno izvršeni, korisnik će primiti poruku s približnim vremenom obrade slike, koje se izračunava na temelju broja zadataka u redu čekanja. Ako dođe do pogreške, korisnik će biti izričito obaviješten slanjem poruke s informacijama o tome što je moglo poći po zlu.

Također, ovaj mikroservis poput celery worker-a sluša “after_estimate” red čekanja koji je namijenjen zadacima koji su prošli kroz evaluacijski pipeline.

Kada primite novi zadatak od “after_estimate”:

  1. Ako je slika uspješno obrađena, rezultat šaljemo korisniku, ako nije, obavještavamo o pogrešci.
  2. Uklanjanje slike koja je rezultat cjevovoda procjene

Evaluacijski mikroservis “attrai-estimator”

Ova mikrousluga je celery worker i sažima sve što je povezano s cjevovodom za procjenu slike. Ovdje postoji samo jedan radni algoritam - analizirajmo ga.

Kada primite novi zadatak od “to_estimate”:

  1. Pustimo sliku kroz evaluacijski cjevovod:
    1. Učitavanje slike u memoriju
    2. Sliku dovodimo do potrebne veličine
    3. Pronalaženje svih lica (MTCNN)
    4. Procjenjujemo sva lica (zamotavamo lica pronađena u posljednjem koraku u skupinu i zaključujemo ResNet34)
    5. Renderirajte konačnu sliku
      1. Nacrtajmo granične okvire
      2. Izvlačenje ocjena
  2. Brisanje prilagođene (izvorne) slike
  3. Spremanje izlaza iz cjevovoda procjene
  4. Zadatak smo stavili u red čekanja "after_estimate", koji sluša mikroservis "attrai-telegram-bot" o kojem smo govorili gore.

Graylog (+ mongoDB + Elasticsearch)

Siva je rješenje za centralizirano upravljanje zapisima. U ovom projektu korišten je za svoju namjenu.

Izbor je pao na njega, a ne na uobičajenog LOS stog, zbog pogodnosti rada s njim iz Pythona. Sve što trebate učiniti da se prijavite na Graylog je dodati GELFTCPHandler iz paketa sivkast ostalim rukovateljima root loggera našeg python mikroservisa.

Kao netko tko je prije radio samo s ELK stackom, imao sam općenito pozitivno iskustvo tijekom rada s Graylogom. Jedina stvar koja je deprimirajuća je superiornost Kibana značajki u odnosu na Graylog web sučelje.

Zec MQ

Zec MQ je broker poruka temeljen na AMQP protokolu.

U ovom projektu korišten je kao najstabilniji i vremenski testiran broker za Celery i radio je u trajnom načinu rada.

Redis

Redis je NoSQL DBMS koji radi sa strukturama podataka ključ-vrijednost

Ponekad postoji potreba za korištenjem uobičajenih objekata koji implementiraju određene podatkovne strukture u različitim Python mikroservisima.

Na primjer, Redis pohranjuje hashmap u obliku “telegram_user_id => broj aktivnih zadataka u redu čekanja”, što vam omogućuje da ograničite broj zahtjeva od jednog korisnika na određenu vrijednost i na taj način spriječite DoS napade.

Formalizirajmo proces uspješne obrade slike

  1. Korisnik šalje sliku Telegram botu
  2. "attrai-telegram-bot" prima poruku od Telegram API-ja i analizira je
  3. Zadatak sa slikom dodaje se u asinkroni red "to_estimate"
  4. Korisnik dobiva poruku s planiranim vremenom procjene
  5. “attrai-estimator” preuzima zadatak iz reda čekanja “to_estimate”, pokreće procjene kroz cjevovod i proizvodi zadatak u red čekanja “after_estimate”
  6. "attrai-telegram-bot" sluša "after_estimate" red čekanja, šalje rezultat korisniku

DevOps

Na kraju, nakon pregleda arhitekture, možete prijeći na jednako zanimljiv dio - DevOps

Docker Roj

 

Opći pregled arhitekture servisa za procjenu izgleda na temelju neuronskih mreža

Docker Roj  — sustav klasteriranja, čija je funkcionalnost implementirana unutar Docker Enginea i dostupan je odmah nakon instalacije.

Koristeći "roj", svi čvorovi u našem klasteru mogu se podijeliti u 2 tipa - radnik i upravitelj. Na strojevima prvog tipa raspoređene su skupine spremnika (skupovi), strojevi drugog tipa odgovorni su za skaliranje, balansiranje i druge cool značajke. Menadžeri su također standardno radnici.

Opći pregled arhitekture servisa za procjenu izgleda na temelju neuronskih mreža

Klaster s jednim voditeljem i tri radnika

Minimalna moguća veličina klastera je 1 čvor; jedan stroj će istovremeno djelovati kao voditelj i radnik. Na temelju veličine projekta i minimalnih zahtjeva za toleranciju na greške, odlučeno je da se koristi ovaj pristup.

Gledajući unaprijed, reći ću da od prve isporuke proizvodnje, koja je bila sredinom lipnja, nije bilo problema vezanih uz ovu organizaciju klastera (ali to ne znači da je takva organizacija na bilo koji način prihvatljiva u bilo kojem srednjem i velikom projekti koji podliježu zahtjevima tolerancije na greške).

Docker stog

U swarm modu, on je odgovoran za raspoređivanje stekova (setova docker usluga) docker stog

Podržava docker-compose konfiguracije, omogućujući vam da dodatno koristite parametre implementacije.  

Na primjer, korištenjem ovih parametara, resursi za svaku instancu mikroservisa za procjenu bili su ograničeni (dodjeljujemo N jezgri za N instanci, u samoj mikroservisi ograničavamo broj jezgri koje koristi PyTorch na jednu)

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

Važno je napomenuti da su Redis, RabbitMQ i Graylog usluge s praćenjem stanja i ne mogu se mjeriti tako lako kao "attrai-estimator"

Nagovještaj pitanja - zašto ne Kubernetes?

Čini se da je korištenje Kubernetesa u malim i srednjim projektima dodatni trošak; sve potrebne funkcije mogu se dobiti od Docker Swarma, koji je vrlo jednostavan za rukovanje kontejnerskim orkestratorom, a također ima niske barijere za ulazak.

Infrastruktura

Sve je to raspoređeno na VDS sa sljedećim karakteristikama:

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

Nakon testiranja lokalnog opterećenja, činilo se da će uz ozbiljan priljev korisnika ovaj stroj biti dovoljan.

No, odmah nakon implementacije, objavio sam vezu na jednu od najpopularnijih slikovnih ploča u CIS-u (da, tu istu), nakon čega su se ljudi zainteresirali i za nekoliko sati usluga je uspješno obradila desetke tisuća slika. U isto vrijeme, u vršnim trenucima CPU i RAM resursi nisu bili ni dopola iskorišteni.

Opći pregled arhitekture servisa za procjenu izgleda na temelju neuronskih mreža
Opći pregled arhitekture servisa za procjenu izgleda na temelju neuronskih mreža

Još malo grafike

Broj jedinstvenih korisnika i zahtjeva za procjenu od implementacije, ovisno o danu

Opći pregled arhitekture servisa za procjenu izgleda na temelju neuronskih mreža

Distribucija vremena zaključivanja cjevovoda evaluacije

Opći pregled arhitekture servisa za procjenu izgleda na temelju neuronskih mreža

Zaključci

Ukratko, mogu reći da su se arhitektura i pristup orkestraciji kontejnera u potpunosti opravdali - čak ni u vršnim trenucima nije bilo padova ili popuštanja u vremenu obrade. 

Mislim da mali i srednji projekti koji u svom procesu koriste zaključivanje neuronskih mreža u stvarnom vremenu na CPU-u mogu uspješno usvojiti prakse opisane u ovom članku.

Dodat ću da je u početku članak bio duži, ali kako ne bih objavljivao dugo čitanje, odlučio sam izostaviti neke točke u ovom članku - vratit ćemo im se u budućim publikacijama.

Možete bocnuti bot na Telegramu - @AttraiBot, radit će najmanje do kraja jeseni 2020. Dopustite mi da vas podsjetim da se ne pohranjuju nikakvi korisnički podaci - ni izvorne slike, ni rezultati evaluacijskog cjevovoda - sve se ruši nakon obrade.

Izvor: www.habr.com

Dodajte komentar