Začetek
Lep pozdrav!
V tem članku bom delil svoje izkušnje z gradnjo arhitekture mikrostoritev za projekt z uporabo nevronskih mrež.
Pogovorimo se o zahtevah arhitekture, poglejmo različne strukturne diagrame, analizirajmo vsako komponento končne arhitekture in ocenimo tudi tehnične metrike rešitve.
Uživajte v branju!
Nekaj besed o problemu in njegovi rešitvi
Glavna ideja je na podlagi fotografije oceniti privlačnost osebe na desetstopenjski lestvici.
V tem članku se bomo oddaljili od opisa uporabljenih nevronskih mrež in procesa priprave in usposabljanja podatkov. Vsekakor pa se bomo v eni od naslednjih publikacij vrnili k poglobljeni analizi ocenjevalnega cevovoda.
Zdaj bomo šli skozi cevovod vrednotenja na najvišji ravni in se osredotočili na interakcijo mikrostoritev v kontekstu celotne arhitekture projekta.
Pri delu na cevovodu za oceno privlačnosti je bila naloga razdeljena na naslednje komponente:
- Izbiranje obrazov na fotografijah
- Ocena vsake osebe
- Upodobi rezultat
Prvi je rešen s silami predhodno usposobljenih . Za drugo je bila konvolucijska nevronska mreža usposobljena na PyTorchu z uporabo – iz ravnovesja “kakovost / hitrost sklepanja na CPU”
Funkcionalni diagram ocenjevalnega cevovoda
Analiza zahtev arhitekture projekta
V življenjskem ciklu projektne faze dela na arhitekturi in avtomatizaciji uvajanja modela so pogosto med najbolj zamudnimi in potratnimi.
Življenjski cikel projekta ML
Ta projekt ni nobena izjema – sprejeta je bila odločitev, da ocenjevalni cevovod zavijemo v spletno storitev, kar je zahtevalo, da se potopimo v arhitekturo. Ugotovljene so bile naslednje osnovne zahteve:
- Poenoteno shranjevanje dnevnikov – vse storitve bi morale pisati dnevnike na enem mestu, morali bi biti priročni za analizo
- Možnost horizontalnega skaliranja ocenjevalne storitve - kot najverjetnejše ozko grlo
- Enako količino procesorskih virov je treba dodeliti za ovrednotenje vsake slike, da se izognemo odstopanjem v porazdelitvi časa za sklepanje
- Hitra (pre)uvedba tako določenih storitev kot sklada kot celote
- Sposobnost, če je potrebno, uporabe skupnih predmetov v različnih storitvah
arhitektura
Po analizi zahtev je postalo očitno, da se mikrostoritvena arhitektura skoraj popolnoma prilega.
Da bi se znebili nepotrebnih preglavic, smo za frontend izbrali Telegram API.
Najprej si oglejmo strukturni diagram končne arhitekture, nato preidimo na opis vsake komponente in tudi formaliziramo postopek uspešne obdelave slike.
Strukturni diagram končane arhitekture
Pogovorimo se podrobneje o vsaki od komponent diagrama in jih označimo kot Enotno odgovornost v procesu vrednotenja slike.
Mikrostoritev »attrai-telegram-bot«
Ta mikrostoritev zajema vse interakcije z API-jem Telegram. Obstajata dva glavna scenarija: delo s sliko po meri in delo z rezultatom cevovoda ocenjevanja. Poglejmo oba scenarija na splošno.
Ko prejmete sporočilo po meri s sliko:
- Izvede se filtracija, ki vključuje naslednje preglede:
- Razpoložljivost optimalne velikosti slike
- Število uporabniških slik, ki so že v čakalni vrsti
- Ko opravi začetno filtriranje, se slika shrani v nosilec dockerja
- V čakalni vrsti »to_estimate« se ustvari naloga, ki med drugim vključuje pot do slike, ki se nahaja v našem nosilcu
- Če so zgornji koraki uspešno opravljeni, bo uporabnik prejel sporočilo s približnim časom obdelave slike, ki se izračuna glede na število opravil v čakalni vrsti. Če pride do napake, bo uporabnik izrecno obveščen s sporočilom o tem, kaj bi lahko šlo narobe.
Prav tako ta mikrostoritev, kot celery worker, posluša čakalno vrsto “after_estimate”, ki je namenjena nalogam, ki so šle skozi ocenjevalni cevovod.
Ko prejmete novo nalogo od »after_estimate«:
- Če je slika uspešno obdelana, rezultat pošljemo uporabniku, v nasprotnem primeru obvestimo o napaki.
- Odstranjevanje slike, ki je rezultat ocenjevalnega cevovoda
Ocenjevalna mikrostoritev »attrai-estimator«
Ta mikrostoritev je celery worker in zajema vse, kar je povezano s cevovodom za vrednotenje slike. Tukaj je samo en delujoč algoritem - analizirajmo ga.
Ko prejmete novo nalogo od »to_estimate«:
- Poženimo sliko skozi ocenjevalni cevovod:
- Nalaganje slike v pomnilnik
- Sliko pripeljemo do želene velikosti
- Iskanje vseh obrazov (MTCNN)
- Ocenimo vse obraze (obraze, najdene v zadnjem koraku, zavijemo v skupino in sklepamo ResNet34)
- Upodobite končno sliko
- Narišimo mejne okvirje
- Žrebanje ocen
- Brisanje prilagojene (izvirne) slike
- Shranjevanje izhoda iz ocenjevalnega cevovoda
- Nalogo postavimo v čakalno vrsto »after_estimate«, ki jo posluša zgoraj obravnavana mikrostoritev »attrai-telegram-bot«.
Graylog (+ mongoDB + Elasticsearch)
je rešitev za centralizirano upravljanje dnevnikov. V tem projektu je bil uporabljen za predvideni namen.
Izbira je padla nanj in ne na običajnega stack, zaradi priročnosti dela z njim iz Pythona. Vse, kar morate storiti, da se prijavite v Graylog, je dodati GELFTCPHandler iz paketa preostalim obdelovalcem korenskega zapisovalnika naše mikrostoritve python.
Kot nekdo, ki je prej delal samo s skladom ELK, sem imel med delom z Graylogom na splošno pozitivno izkušnjo. Edina stvar, ki je depresivna, je superiornost funkcij Kibane nad spletnim vmesnikom Graylog.
RabbitMQ
je posrednik sporočil, ki temelji na protokolu AMQP.
V tem projektu je bil uporabljen kot posrednik za Celery in je deloval v trajnem načinu.
Redis
je NoSQL DBMS, ki deluje s podatkovnimi strukturami ključ-vrednost
Včasih je treba uporabiti skupne objekte, ki izvajajo določene podatkovne strukture v različnih mikrostoritvah Python.
Redis na primer shrani hashmap v obliki “telegram_user_id => število aktivnih nalog v čakalni vrsti,” kar vam omogoča, da omejite število zahtev enega uporabnika na določeno vrednost in s tem preprečite napade DoS.
Formalizirajmo proces uspešne obdelave slike
- Uporabnik pošlje sliko Telegram botu
- "attrai-telegram-bot" prejme sporočilo od Telegram API-ja in ga razčleni
- Naloga s sliko je dodana v asinhrono čakalno vrsto »to_estimate«
- Uporabnik prejme sporočilo s predvidenim časom ocenjevanja
- »attrai-estimator« vzame nalogo iz čakalne vrste »to_estimate«, požene ocene skozi cevovod in izdela nalogo v čakalno vrsto »after_estimate«.
- "attrai-telegram-bot" posluša čakalno vrsto "after_estimate", pošlje rezultat uporabniku
DevOps
Končno, po pregledu arhitekture, lahko preidete na prav tako zanimiv del - DevOps
Docker roj
— sistem združevanja v gruče, katerega funkcionalnost je implementirana znotraj Docker Engine in je na voljo takoj po izdelavi.
Z uporabo "roja" lahko vsa vozlišča v naši gruči razdelimo na 2 tipa - delavca in upravitelja. Na strojih prve vrste so nameščene skupine vsebnikov (skladi), stroji druge vrste pa so odgovorni za skaliranje, uravnoteženje in . Tudi menedžerji so privzeto delavci.
Grozd z enim vodilnim managerjem in tremi delavci
Najmanjša možna velikost gruče je 1 vozlišče; en stroj bo istočasno deloval kot vodilni upravitelj in delavec. Na podlagi velikosti projekta in minimalnih zahtev za toleranco napak je bila odločena uporaba tega pristopa.
Če pogledam naprej, bom rekel, da od prve dobave proizvodnje, ki je bila sredi junija, ni bilo nobenih težav, povezanih s to organizacijo grozda (vendar to ne pomeni, da je taka organizacija kakor koli sprejemljiva v katerem koli srednje velikem projekti, za katere veljajo zahteve glede tolerance napak).
Docker Stack
V načinu roja je odgovoren za uvajanje skladov (naborov priklopnih storitev)
Podpira konfiguracije docker-compose, kar vam omogoča dodatno uporabo možnosti uvajanja.
Z uporabo teh parametrov so bili na primer omejeni viri za vsako od primerkov ocenjevalne mikrostoritve (dodelimo N jeder za N primerkov, v sami mikrostoritvi omejimo število jeder, ki jih uporablja PyTorch, na eno)
attrai_estimator:
image: 'erqups/attrai_estimator:1.2'
deploy:
replicas: 4
resources:
limits:
cpus: '4'
restart_policy:
condition: on-failure
…Pomembno je omeniti, da so Redis, RabbitMQ in Graylog storitve s spremljanjem stanja in jih ni mogoče skalirati tako enostavno kot »attrai-estimator«
Napovedovanje vprašanja - zakaj ne Kubernetes?
Zdi se, da je uporaba Kubernetesa v majhnih in srednje velikih projektih prevelika; vso potrebno funkcionalnost je mogoče pridobiti iz Docker Swarma, ki je precej uporabniku prijazen za vsebniški orkestrator in ima tudi nizko vstopno oviro.
Infrastruktura
Vse to je bilo nameščeno na VDS z naslednjimi značilnostmi:
- CPU: 4-jedrni procesor Intel® Xeon® Gold 5120 @ 2.20 GHz
- RAM: 8 GB
- SSD: 160 GB
Po lokalnem obremenitvenem testiranju se je zdelo, da bo ob resnem navalu uporabnikov ta stroj zadostoval.
Toda takoj po uvedbi sem objavil povezavo do ene najbolj priljubljenih slikovnih plošč v CIS (ja, ta ista), po kateri so se ljudje začeli zanimati in v nekaj urah je storitev uspešno obdelala več deset tisoč slik. Hkrati v konicah viri CPE in RAM niso bili niti polovično porabljeni.
Še nekaj grafike
Število edinstvenih uporabnikov in zahtev za vrednotenje od uvedbe, odvisno od dneva
Razporeditev časa sklepanja evalvacijskega cevovoda
Ugotovitve
Če povzamem, lahko rečem, da sta se arhitektura in pristop k orkestraciji vsebnikov popolnoma upravičila - tudi v najvišjih trenutkih ni bilo padcev ali padcev v času obdelave.
Mislim, da lahko majhni in srednje veliki projekti, ki v svojem procesu uporabljajo realnočasovno sklepanje nevronskih mrež na CPE, uspešno sprejmejo prakse, opisane v tem članku.
Dodal bom, da je bil članek na začetku daljši, a da ne bi objavil dolgega branja, sem se odločil, da izpustim nekatere točke v tem članku - k njim se bomo vrnili v prihodnjih publikacijah.
Bota lahko pikaš na Telegram - @AttraiBot, deloval bo vsaj do konca jeseni 2020. Naj vas spomnim, da se ne shranjujejo nobeni uporabniški podatki - niti izvirne slike, niti rezultati ocenjevalnega cevovoda - vse se po obdelavi poruši.
Vir: www.habr.com