Ynlieding
Hallo!
Yn dit artikel sil ik myn ûnderfining diele mei it bouwen fan in mikroservicearsjitektuer foar in projekt mei help fan neurale netwurken.
Litte wy prate oer de arsjitektuereasken, sjoch nei ferskate strukturele diagrammen, analysearje elk fan 'e komponinten fan' e ôfmakke arsjitektuer, en evaluearje ek de technyske metriken fan 'e oplossing.
Genietsje lêze!
In pear wurden oer it probleem en syn oplossing
It wichtichste idee is om de oantreklikens fan in persoan te evaluearjen op in tsienpuntskaal basearre op in foto.
Yn dit artikel sille wy fuortgean fan it beskriuwen fan sawol de brûkte neurale netwurken as it proses fan gegevenstarieding en training. Yn ien fan 'e folgjende publikaasjes sille wy lykwols perfoarst weromgean nei it analysearjen fan' e beoardielingspipeline op in djipgeand nivo.
No sille wy troch de evaluaasjepipeline gean op it boppeste nivo, en sille rjochtsje op 'e ynteraksje fan mikrotsjinsten yn' e kontekst fan 'e algemiene projektarsjitektuer.
By it wurkjen oan 'e pipeline foar beoardieling fan oantreklikens waard de taak ferdield yn de folgjende komponinten:
- Selektearje gesichten yn foto's
- Rating fan elke persoan
- Meitsje it resultaat
De earste wurdt oplost troch de krêften fan pre-trained . Foar de twadde waard in konvolúsjoneel neural netwurk trainearre op PyTorch, mei help fan - fan it lykwicht "kwaliteit / snelheid fan konklúzje op 'e CPU"
Funksjoneel diagram fan 'e evaluaasjepipeline
Analyse fan projekt arsjitektuer easken
Yn 'e libbenssyklus projekt stadia fan wurk oan de arsjitektuer en automatisearring fan model ynset binne faak ûnder de meast tiidslinend en boarne-konsumint.
Libbenssyklus fan in ML-projekt
Dit projekt is gjin útsûndering - it beslút waard makke om de beoardielingspipeline yn te wikkeljen yn in online tsjinst, dy't ús yn 'e arsjitektuer ûnderdompelje moast. De folgjende basis easken waarden identifisearre:
- Unified log opslach - alle tsjinsten moatte skriuwe logs op ien plak, se moatte wêze handich om te analysearjen
- Mooglikheid fan horizontale skaalfergrutting fan 'e beoardielingstsjinst - as de meast wierskynlike Bottleneck
- Deselde hoemannichte prosessorboarnen moatte wurde tawiisd om elke ôfbylding te evaluearjen om útfallers te foarkommen yn 'e ferdieling fan tiid foar konklúzjes
- Snelle (wer) ynset fan sawol spesifike tsjinsten as de stapel as gehiel
- De mooglikheid om, as nedich, mienskiplike objekten te brûken yn ferskate tsjinsten
arsjitektuer
Nei it analysearjen fan de easken waard it dúdlik dat de arsjitektuer fan mikrotsjinsten hast perfekt past.
Om ûnnedige hoofdpijn kwyt te reitsjen, waard de Telegram API keazen as frontend.
Lit ús earst sjen nei it strukturele diagram fan 'e klear arsjitektuer, gean dan nei in beskriuwing fan elk fan' e komponinten, en ek formalisearje it proses fan suksesfolle ôfbyldingsferwurking.
Struktureel diagram fan 'e ôfmakke arsjitektuer
Litte wy yn mear detail prate oer elk fan 'e komponinten fan' e diagram, dy't se ienige ferantwurdlikens oantsjutte yn it proses fan ôfbylding evaluaasje.
Microservice "attrai-telegram-bot"
Dizze mikrotsjinst omfettet alle ynteraksjes mei de Telegram API. D'r binne 2 haadsenario's: wurkje mei in oanpaste ôfbylding en wurkje mei it resultaat fan in beoardielingspipeline. Litte wy beide senario's yn algemiene termen sjen.
By it ûntfangen fan in oanpast berjocht mei in ôfbylding:
- Filtraasje wurdt útfierd, besteande út de folgjende kontrôles:
- Beskikberens fan optimale ôfbylding grutte
- Oantal brûkersôfbyldings al yn wachtrige
- By it trochjaan fan de earste filtering, wurdt de ôfbylding bewarre yn it dockervolumint
- In taak wurdt produsearre yn 'e wachtrige "to_estimate", dy't ûnder oaren it paad omfettet nei de ôfbylding yn ús folume
- As de boppesteande stappen mei súkses foltôge binne, sil de brûker in berjocht krije mei de ûngefearde ôfbyldingsferwurkingstiid, dy't wurdt berekkene op basis fan it oantal taken yn 'e wachtrige. As der in flater optreedt, wurdt de brûker eksplisyt op 'e hichte brocht troch in berjocht te stjoeren mei ynformaasje oer wat miskien misgien is.
Ek harket dizze mikrotsjinst, lykas in sellerijwurker, nei de wachtrige "after_estimate", dy't bedoeld is foar taken dy't troch de evaluaasjepipeline binne trochjûn.
By it ûntfangen fan in nije taak fan "after_estimate":
- As de ôfbylding mei súkses wurdt ferwurke, stjoere wy it resultaat nei de brûker; sa net, melde wy oer in flater.
- It fuortsmiten fan it byld dat is it resultaat fan de evaluaasje pipeline
Evaluaasje mikroservice "attrai-estimator"
Dizze mikroservice is in sellerijarbeider en omfettet alles yn ferbân mei de pipeline foar ôfbyldingevaluaasje. D'r is hjir mar ien wurkjend algoritme - litte wy it analysearje.
By it ûntfangen fan in nije taak fan "to_estimate":
- Litte wy de ôfbylding troch de evaluaasjepipeline rinne:
- It laden fan de ôfbylding yn it ûnthâld
- Wy bringe it byld nei de fereaske grutte
- Alle gesichten fine (MTCNN)
- Wy evaluearje alle gesichten (wy ferpakke de gesichten fûn yn 'e lêste stap yn in batch en konkludearje ResNet34)
- Renderje de lêste ôfbylding
- Lit ús tekenje de grinzen doazen
- Tekenje de wurdearrings
- In oanpaste (orizjinele) ôfbylding wiskje
- Bewarje de útfier fan 'e evaluaasjepipeline
- Wy sette de taak yn 'e wachtrige "after_estimate", dy't wurdt harke troch de hjirboppe besprutsen mikroservice "attrai-telegram-bot".
Graylog (+ mongoDB + Elasticsearch)
is in oplossing foar sintralisearre logbehear. Yn dit projekt waard it brûkt foar it bedoelde doel.
De kar foel op him, en net op de gewoane stack, fanwege it gemak fan wurkjen mei it út Python. Alles wat jo hoege te dwaan om oan te melden by Graylog is de GELFTCPHandler tafoegje fan it pakket nei de rest fan 'e rootlogger-hannelers fan ús python-mikroservice.
As ien dy't earder allinich wurke hie mei de ELK-stapel, hie ik in algemien positive ûnderfining by it wurkjen mei Graylog. It iennichste ding dat deprimearret is de superioriteit yn Kibana-funksjes oer de Graylog-webynterface.
Konyn MQ
is in berjochtmakelaar basearre op it AMQP-protokol.
Yn dit projekt waard it brûkt as makelder foar Selderij en wurke yn duorsume modus.
Redis
is in NoSQL DBMS dat wurket mei kaai-wearde gegevens struktueren
Soms is d'r needsaak om mienskiplike objekten te brûken dy't bepaalde gegevensstruktueren yn ferskate Python-mikrotsjinsten ymplementearje.
Bygelyks, Redis bewarret in hashmap fan 'e foarm "telegram_user_id => oantal aktive taken yn' e wachtrige," wêrtroch jo it oantal oanfragen fan ien brûker kinne beheine ta in bepaalde wearde en dêrmei DoS-oanfallen foarkomme.
Litte wy it proses fan suksesfolle ôfbyldingsferwurking formalisearje
- De brûker stjoert in ôfbylding nei de Telegram-bot
- "attrai-telegram-bot" ûntfangt in berjocht fan 'e Telegram API en parseart it
- De taak mei de ôfbylding wurdt tafoege oan de asynchrone wachtrige "to_estimate"
- De brûker krijt in berjocht mei de plande evaluaasjetiid
- "attrai-estimator" nimt in taak út 'e "to_estimate"-wachtrige, rint de skatten troch de pipeline en produseart de taak yn 'e "after_estimate"-wachtrige
- "attrai-telegram-bot" harket nei de "after_estimate" wachtrige, stjoert it resultaat nei de brûker
DevOps
As lêste, nei it besjen fan 'e arsjitektuer, kinne jo trochgean nei it like ynteressante diel - DevOps
Docker swarm
- in klustersysteem, wêrfan de funksjonaliteit wurdt ymplementearre yn 'e Docker Engine en is beskikber út' e doaze.
Mei in "swerm" kinne alle knopen yn ús kluster wurde ferdield yn 2 soarten - arbeider en manager. Op masines fan it earste type wurde groepen fan konteners (stapels) ynset, masines fan it twadde type binne ferantwurdlik foar skaalfergrutting, balansearjen en . Managers binne ek standert arbeiders.
Kluster mei ien liederskip en trije arbeiders
De minimale mooglike klustergrutte is 1 knooppunt; ien masine sil tagelyk fungearje as in liederbehearder en in arbeider. Op grûn fan de grutte fan it projekt en de minimale easken foar fouttolerânsje is besletten om dizze oanpak te brûken.
Foarútsjen sil ik sizze dat der sûnt de earste produksjeferliening, dy't heal juny wie, gjin problemen west hawwe ferbûn mei dizze klusterorganisaasje (mar dit betsjut net dat sa'n organisaasje op ien of oare manier akseptabel is yn elke medium-grut projekten, dy't ûnderwurpen binne oan easken foar fouttolerânsje).
Docker Stack
Yn swarmmodus is hy ferantwurdlik foar it ynsetten fan stapels (sets fan dockertsjinsten)
It stipet docker-compose-konfiguraasjes, wêrtroch jo ekstra ynsetparameters kinne brûke.
Bygelyks, mei it brûken fan dizze parameters, waarden de boarnen foar elk fan 'e evaluaasje-mikroservice-eksimplaren beheind (wy tawize N kearnen foar N eksimplaren, yn 'e mikrotsjinst sels beheine wy it oantal kearnen brûkt troch PyTorch ta ien)
attrai_estimator:
image: 'erqups/attrai_estimator:1.2'
deploy:
replicas: 4
resources:
limits:
cpus: '4'
restart_policy:
condition: on-failure
…It is wichtich om te notearjen dat Redis, RabbitMQ en Graylog steatlike tsjinsten binne en se kinne net sa maklik wurde skaleare as "attrai-estimator"
Foareshadoding de fraach - wêrom net Kubernetes?
It liket derop dat it brûken fan Kubernetes yn lytse en middelgrutte projekten in overhead is; alle nedige funksjonaliteit kin wurde krigen fan Docker Swarm, dy't frij brûkerfreonlik is foar in kontenerorkestrator en ek in lege barriêre foar yngong hat.
Ynfrastruktuer
Dit alles waard ynset op VDS mei de folgjende skaaimerken:
- CPU: 4-core Intel® Xeon® Gold 5120 CPU @ 2.20GHz
- RAM: 8 GB
- SSD: 160GB
Nei lokale load testen, it like dat mei in serieuze ynstream fan brûkers, dizze masine soe wêze genôch.
Mar, fuort nei de ynset, pleatste ik in keppeling nei ien fan 'e populêrste imageboards yn' e CIS (yup, dyselde), wêrnei't minsken ynteressearre waarden en yn in pear oeren de tsjinst tsientûzenen ôfbyldings mei súkses ferwurke. Tagelyk, op peak mominten, waarden CPU- en RAM-boarnen net iens heal brûkt.
Wat mear grafiken
Oantal unike brûkers en evaluaasjeoanfragen sûnt ynset, ôfhinklik fan de dei
Evaluaasje pipeline inference tiid ferdieling
befinings
Om gearfetsje, kin ik sizze dat de arsjitektuer en oanpak fan orkestraasje fan konteners harsels folslein rjochtfeardige - sels op peak mominten wiene d'r gjin drippen of sakjen yn 'e ferwurkingstiid.
Ik tink dat lytse en middelgrutte projekten dy't real-time konklúzje fan neurale netwurken op 'e CPU yn har proses brûke kinne de praktiken dy't beskreaun binne yn dit artikel mei súkses oannimme.
Ik sil tafoegje dat it artikel yn 't earstoan langer wie, mar om gjin longread te pleatsen, besleat ik guon punten yn dit artikel weg te litten - wy komme der op werom yn takomstige publikaasjes.
Jo kinne de bot op Telegram stekke - @AttraiBot, it sil op syn minst oant it ein fan 'e hjerst 2020 wurkje. Lit my jo herinnerje dat gjin brûkersgegevens wurde opslein - noch de orizjinele ôfbyldings, noch de resultaten fan 'e evaluaasjepipeline - alles wurdt nei ferwurking sloopt.
Boarne: www.habr.com