Opšti pregled arhitekture servisa za procjenu izgleda zasnovanog na neuronskim mrežama

ulazak

Zdravo!

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

Hajde da razgovaramo o zahtevima arhitekture, pogledamo različite strukturne dijagrame, analiziramo svaku od komponenti gotove arhitekture, a takođe procenimo tehničke metrike rešenja.

Uživajte u čitanju!

Nekoliko riječi o problemu i njegovom rješenju

Glavna ideja je procijeniti privlačnost osobe na skali od deset bodova na osnovu fotografije.

U ovom članku ćemo se odmaknuti od opisa korištenih neuronskih mreža i procesa pripreme podataka i obuke. Međutim, u jednoj od sljedećih publikacija, definitivno ćemo se vratiti na detaljnu analizu procesa procjene.

Sada ćemo proći kroz proces evaluacije na najvišem nivou i fokusiraćemo se na interakciju mikroservisa u kontekstu ukupne arhitekture projekta. 

Prilikom rada na cevovodu za procenu atraktivnosti, zadatak je razložen na sledeće komponente:

1. Odabir lica na fotografijama
2. Ocjena svake osobe
3. Renderirajte rezultat

Prvu rješavaju snage unaprijed obučenih MTCNN. Za drugu, konvoluciona neuronska mreža je obučena na PyTorchu, koristeći ResNet34 – iz ravnoteže “kvalitet/brzina zaključivanja na CPU-u”

Funkcionalni dijagram cjevovoda evaluacije

Analiza zahtjeva arhitekture projekta

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

Životni ciklus ML projekta

Ovaj projekat nije izuzetak - doneta je odluka da se proces procene umota u onlajn servis, što je zahtevalo da se uživimo u arhitekturu. Identificirani su sljedeći osnovni zahtjevi:

1. Jedinstvena pohrana dnevnika – svi servisi bi trebali pisati dnevnike na jednom mjestu, trebali bi biti zgodni za analizu
2. Mogućnost horizontalnog skaliranja usluge procjene - kao najvjerovatnije usko grlo
3. Ista količina resursa procesora treba biti dodijeljena za evaluaciju svake slike kako bi se izbjegle odstupanja u raspodjeli vremena za zaključivanje
4. Brza (ponovna) implementacija i određenih usluga i čitavog steka
5. Mogućnost, ako je potrebno, korištenja zajedničkih objekata u različitim servisima

arhitektura

Nakon analize zahtjeva, postalo je očigledno da se mikroservisna arhitektura gotovo savršeno uklapa.

Kako bismo se riješili nepotrebnih glavobolja, kao frontend je odabran 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.

Strukturni dijagram gotove arhitekture

Razgovarajmo detaljnije o svakoj od komponenti dijagrama, označavajući ih kao jedinstvenu odgovornost u procesu evaluacije slike.

Mikroservis “attrai-telegram-bot”

Ovaj mikroservis obuhvata sve interakcije sa Telegram API-jem. Postoje 2 glavna scenarija: rad sa prilagođenom slikom i rad sa rezultatom procene. Pogledajmo oba scenarija općenito.

Kada primite prilagođenu poruku sa slikom:

1. Vrši se filtriranje koje se sastoji od sljedećih provjera:
   • Dostupnost optimalne veličine slike
   • Broj korisničkih slika koje su već u redu čekanja
2. Kada prođe početno filtriranje, slika se pohranjuje u docker volumen
3. Zadatak se proizvodi u redu "to_estimate", koji uključuje, između ostalog, putanju do slike koja se nalazi u našem volumenu
4. Ako su gore navedeni koraci uspješno obavljeni, korisnik će dobiti poruku s približnim vremenom obrade slike koje se izračunava na osnovu broja zadataka u redu čekanja. Ako dođe do greške, korisnik će biti izričito obaviješten slanjem poruke s informacijama o tome šta je moglo poći po zlu.

Također, ovaj mikroservis, poput celery radnika, sluša "after_estimate" red, koji je namijenjen za zadatke koji su prošli kroz cjevovod evaluacije.

Kada primite novi zadatak od “after_estimate”:

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

Mikroservis evaluacije “attrai-estimator”

Ovaj mikroservis je celer radnik i obuhvata sve što je povezano sa cevovodom za evaluaciju slike. Ovdje postoji samo jedan algoritam koji radi – hajde da ga analiziramo.

Kada primite novi zadatak od “to_estimate”:

1. Pokrenimo sliku kroz cevovod za evaluaciju:
   1. Učitavanje slike u memoriju
   2. Dovodimo sliku do željene veličine
   3. Pronalaženje svih lica (MTCNN)
   4. Procjenjujemo sva lica (umotavamo lica pronađena u posljednjem koraku u skup i zaključujemo ResNet34)
   5. Renderirajte konačnu sliku
      1. Nacrtajmo granične okvire
      2. Crtanje rejtinga
2. Brisanje prilagođene (originalne) slike
3. Spremanje izlaza iz cjevovoda evaluacije
4. Stavljamo zadatak u "after_estimate" red, koji sluša mikroservis "attrai-telegram-bot" o kojem smo gore govorili.

Graylog (+ mongoDB + Elasticsearch)

Greylog je rješenje za centralizirano upravljanje dnevnikom. U ovom projektu je korišten za svoju namjenu.

Izbor je pao na njega, a ne na onu uobičajenu ELK stek, zbog pogodnosti rada s njim iz Pythona. Sve što treba da uradite da biste se prijavili na Graylog je da dodate GELFTCPHandler iz paketa sivo na ostatak rukovatelja root logera našeg python mikroservisa.

Kao neko ko je ranije radio samo sa ELK stekom, imao sam sveukupno pozitivno iskustvo dok sam radio sa Graylog-om. Jedina stvar koja je depresivna je superiornost Kibana funkcija nad Graylog web interfejsom.

Rabbit MQ

Rabbit MQ je posrednik poruka baziran na AMQP protokolu.

U ovom projektu korišten je kao najstabilniji i vremenski testiran broker za Celery i radio u trajnom modu.

Redis

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

Ponekad postoji potreba za korištenjem zajedničkih objekata koji implementiraju određene strukture podataka u različitim Python mikroservisima.

Na primjer, Redis pohranjuje hashmap oblika "telegram_user_id => broj aktivnih zadataka u redu", koji vam omogućava da ograničite broj zahtjeva od jednog korisnika na određenu vrijednost i na taj način spriječite DoS napade.

Hajde da formalizujemo proces uspeš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 se dodaje u asinhroni red čekanja "to_estimate"
4. Korisnik dobija poruku sa planiranim vremenom evaluacije
5. “attrai-estimator” uzima zadatak iz reda “to_estimate”, pokreće procjene kroz cjevovod i proizvodi zadatak u redu “after_estimate”
6. "attrai-telegram-bot" sluša "after_estimate" red, šalje rezultat korisniku

DevOps

Konačno, nakon pregleda arhitekture, možete prijeći na jednako zanimljiv dio - DevOps

Docker roj

 

Docker roj  — sistem klasteriranja, čija je funkcionalnost implementirana unutar Docker Engine-a i dostupna je izvan kutije.

Koristeći „roj“, svi čvorovi u našem klasteru mogu se podijeliti u 2 tipa – radnik i menadžer. Na mašinama prvog tipa postavljaju se grupe kontejnera (slopova), mašine drugog tipa su odgovorne za skaliranje, balansiranje i druge cool karakteristike. Menadžeri su također radnici po defaultu.

Klaster sa jednim vodećim menadžerom i tri radnika

Minimalna moguća veličina klastera je 1 čvor; jedna mašina će istovremeno delovati kao vodeći menadžer i radnik. Na osnovu veličine projekta i minimalnih zahtjeva za toleranciju grešaka, 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 nikakvih problema vezanih za ovu klastersku organizaciju (ali to ne znači da je takva organizacija na bilo koji način prihvatljiva u bilo kojoj srednje velikoj projekti koji podliježu zahtjevima tolerancije grešaka).

Docker Stack

U načinu rada roja, on je odgovoran za raspoređivanje stekova (skupova docker usluga) docker stack

Podržava docker-compose konfiguracije, omogućavajući vam da dodatno koristite opcije postavljanja.  

Na primjer, korištenjem ovih parametara, resursi za svaku od mikroservisnih instanci evaluacije bili su ograničeni (dodjeljujemo N jezgri za N instanci, u samoj mikroservisi ograničavamo broj jezgara koje PyTorch koristi 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 servisi sa stanjem i ne mogu se skalirati tako lako kao "attrai-estimator"

Nagovještavajući pitanje - zašto ne Kubernetes?

Čini se da korištenje Kubernetesa u malim i srednjim projektima predstavlja preveliki trošak; sve potrebne funkcionalnosti mogu se dobiti od Docker Swarma, koji je prilično jednostavan za korištenje za orkestratore kontejnera i također ima nisku barijeru za ulazak.

Infrastruktura

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

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

Nakon lokalnog testiranja opterećenja, činilo se da bi uz ozbiljan priliv korisnika ova mašina bila dovoljna.

Ali, odmah nakon postavljanja, postavio sam link na jedan od najpopularnijih imageboarda u CIS-u (da, taj isti), nakon čega su se ljudi zainteresirali i servis je za nekoliko sati uspješno obradio desetine hiljada slika. Istovremeno, u trenucima vrhunca, CPU i RAM resursi nisu bili ni napola iskorišteni.

Još malo grafike

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

Vremenska distribucija zaključivanja cevovoda evaluacije

nalazi

Sumirajući, mogu reći da su se arhitektura i pristup orkestraciji kontejnera u potpunosti opravdali – čak ni u trenucima špica nije bilo padova ili propadanja u vremenu obrade. 

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

Dodać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 - na njih ćemo se vratiti u budućim publikacijama.

Bota možete ubaciti na Telegram - @AttraiBot, radit će barem do kraja jeseni 2020. Da vas podsjetim da se ne pohranjuju nikakvi korisnički podaci – ni originalne slike, ni rezultati procjene – sve se ruši nakon obrade.

izvor: www.habr.com