Hyrje
đ„Si tĂ« arrish nĂ« qiell dhe tĂ« bĂ«hesh pilot | ProHoster
Në këtë artikull do të ndaj përvojën time në ndërtimin e një arkitekture mikro-shërbimesh për një projekt që përdor rrjete nervore.
Do të flasim rreth kërkesave të arkitekturës, do të shohim diagramet e ndryshme strukturore, do të shqyrtojmë çdo komponent të arkitekturës së gatshme dhe do të vlerësojmë metrikat teknike të zgjidhjes.
Lexim të këndshëm!
Për disa fjalë rreth detyrës dhe zgjidhjes së saj
Ideja kryesore është që, në bazë të fotove, të japim një vlerësim të atraktivitetit të personit në një shkallë nga 1 në 10.
Në këtë artikull ne do të largohemi nga përshkrimi i rrjeteve nervore që përdoren dhe procesit të përgatitjes së të dhënave dhe trajnimit. Megjithatë, në një nga publikimet e ardhshme, ne do të kthehemi me siguri në shqyrtimin e pipeline-it të vlerësimit në një nivel më të thellë.
Tani ne do tĂ« kalojmĂ« nĂ« mĂ«nyrĂ« tĂ« pĂ«rgjithshme pĂ«rmes pipeline-it tĂ« vlerĂ«simit, duke pĂ«rqendruar vĂ«mendjen nĂ« ndĂ«rveprimin e mikro-shĂ«rbimeve nĂ« kontekstin e arkitekturĂ«s sĂ« pĂ«rgjithshme tĂ« projektit.Â
Gjatë punës mbi pipeline-in e vlerësimit të atraktivitetit, detyra u dekompozua në përbërësit në vijim:
- Identifikimi i fytyrave në foto
- Vlerësimi i secilës nga fytyrat
- Renderimi i rezultatit
E para zgjidhet me ndihmĂ«n e . PĂ«r tĂ« dytĂ«n, njĂ« rrjet nervor konvulucional u trajnuar nĂ« PyTorch, duke pĂ«rdorur si backbone â nga balanca "cilĂ«si / shpejtĂ«si inferencĂ«s nĂ« CPU"
Diagrami funksional i pipeline-it të vlerësimit
Analiza e kërkesave për arkitekturën e projektit
Në ciklin e jetës e projektit, etapet e punës mbi arkitekturën dhe automatizimin e vendosjes së modelit janë shpesh nga më të shtrenjtat në kohë dhe burime.
Cikli i jetës së projektit ML
Ky projekt nuk Ă«shtĂ« pĂ«rjashtim â u vendos qĂ« pipeline-i i vlerĂ«simit tĂ« paketojĂ« si njĂ« shĂ«rbim online, pĂ«r kĂ«tĂ« ishte e nevojshme tĂ« thellohemi nĂ« arkitekturĂ«. KĂ«to ishin disa kĂ«rkesa bazĂ« tĂ« identifikuara:
- NjĂ« repository tĂ« vetme pĂ«r log-e â tĂ« gjithĂ« shĂ«rbimet duhet tĂ« shkruajnĂ« log-e nĂ« njĂ« vend, dhe tĂ« jetĂ« e lehtĂ« pĂ«r t'i analizuar ato
- MundĂ«sia e shkallĂ«zimit horizontal tĂ« shĂ«rbimit tĂ« vlerĂ«simit â si ngushticĂ« mĂ« e mundshme
- PĂ«r çdo imazh duhet tĂ« ndahen tĂ« njĂ«jtat burime tĂ« procesorit â pĂ«r tĂ« shmangur shpĂ«rthimet nĂ« shpĂ«rndarjen e kohĂ«s pĂ«r inferencĂ«n
- Zhvillim të shpejtë (përsëritje) si të shërbimeve specifike ashtu edhe të stack-ut në tërësi
- Mundësia, nëse është e nevojshme, për të përdorur objekte të përbashkëta në shërbime të ndryshme
Arkitektura
Pas analizimit të kërkesave, bëhet e qartë se arkitektura mikroshërbimeve përshtatet praktikisht perfekt.
Për të eliminuar ndonjë dhimbje të panevojshme, u zgjodh Telegram API si frontend.
Fillimisht, le të shqyrtojmë diagramin strukturore të arkitekturës përfundimtare, pastaj do të kalojmë në përshkrimin e secilit nga komponentët, si dhe do të formalisht procesin e përpunimit të suksesshëm të imazhit.
Diagrami strukturore i arkitekturës përfundimtare
Të flasim më në detaje për secilin nga komponentët e diagramit, të shënojmë përgjegjësinë e tyre të Vetme në procesin e vlerësimit të imazhit.
Mikrosherbimi «attrai-telegram-bot»
Ky mikrosherbim inkapsulon të gjitha ndërveprimet me Telegram API. Mund të veçojmë 2 skenarë kryesorë - puna me imazhin e përdoruesit dhe puna me rezultatin e pipeline-it të vlerësimit. Të dy scenarët do t'i shqyrtojmë në mënyrë të përgjithshme.
Kur merret një mesazh nga përdoruesi me imazhin:
- Kryhet filtrimi, që përfshin verifikimet e mëposhtme:
- Prania e madhësisë optimale të imazhit
- Numri i imazheve të përdoruesit, që tashmë janë në radhë
- Pas kalimit të filtrimit fillestar, imazhi ruhet në volumet docker
- NjĂ« detyrĂ« e prodhuar dĂ«rgohet nĂ« radha âto_estimateâ, e cila pĂ«rfshin, midis tĂ« tjerash, rrugĂ«n pĂ«r nĂ« imazhin qĂ« ndodhet nĂ« volumet tonĂ«
- Nëse etapet e lartpërmendura kalohen me sukses - përdoruesi do të marrë një mesazh me një kohë të përafërt për përpunimin e imazhit, e cila llogaritet mbi numrin e detyrave në radhë. Në rast gabimi, përdoruesi do të informohet qartë për këtë - duke dërguar një mesazh me informacion se çfarë mund të ketë shkuar keq.
Gjithashtu, ky mikrosherbim, si punonjĂ«s celery, dĂ«gjon radhĂ«n âafter_estimateâ, e cila Ă«shtĂ« e destinuar pĂ«r detyrat qĂ« kanĂ« kaluar pĂ«rmes pipeline-it tĂ« vlerĂ«simit.
Kur merret njĂ« detyrĂ« e re nga âafter_estimateâ:
- NĂ«se imazhi Ă«shtĂ« pĂ«rpunuar me sukses â dĂ«rgojmĂ« rezultatin pĂ«rdoruesit, nĂ«se jo â e njoftojmĂ« pĂ«r gabimin
- Fshijmë imazhin, që është rezultati i pipeline-it të vlerësimit
Mikrosherbimi i vlerësimit «attrai-estimator»
Ky mikrosherbim është një punonjës celery dhe inkapsulon gjithçka që lidhet me pipeline-in e vlerësimit të imazhit. Algoritmi i punës këtu është i vetmi - do ta shqyrtojmë atë.
Kur merret njĂ« detyrĂ« e re nga âto_estimateâ:
- Përshkruajmë imazhin përmes pipeline-it të vlerësimit:
- Ngarko imazhin në memorje
- Bring the image to the desired size
- Find all faces (MTCNN)
- Evaluate all faces (wrap faces found in the previous step into a batch and infer using ResNet34)
- Render the final image
- Draw bounding boxes
- Draw evaluations
- Delete the userâs (original) image
- Save the output from the evaluation pipeline
- Place the task in the âafter_estimateâ queue, which is listened to by the previously discussed microservice âattrai-telegram-botâ
Graylog (+ mongoDB + Elasticsearch)
â is a solution for centralized log management. In this project, it was used for its intended purpose.
The choice fell specifically on it, rather than the familiar stack, due to the convenience of working with it from Python. All that is needed to log in Graylog is to add GELFTCPHandler from the to other root logger handlers of our python microservice.
As someone who has previously only worked with the ELK stack, I generally had a positive experience working with Graylog. The only downside is Kibanaâs superior features compared to Graylogâs web interface.
RabbitMQ
â is a message broker based on the AMQP protocol.
In this project, it was used as broker for Celery and operated in durable mode.
Redis
â is a NoSQL DBMS that works with key-value data structures.
Sometimes it's necessary to use common objects in different python microservices that implement some data structures.
For example, Redis stores a hashmap like âtelegram_user_id => number of active tasks in the queueâ, which allows limiting the number of requests from a single user to a certain value, thereby preventing DoS attacks.
Formalize the process of successful image processing
- The user sends an image to the Telegram bot
- âattrai-telegram-botâ receives a message from the Telegram API and parses it
- The task with the image is added to the asynchronous queue âto_estimateâ
- The user receives a message with the planned estimation time
- âattrai-estimatorâ takes the task from the âto_estimateâ queue, runs it through the evaluation pipeline, and produces a task in the âafter_estimateâ queue
- âattrai-telegram-botâ, listening to the âafter_estimateâ queue, sends the result to the user
DevOps
Finally, after reviewing the architecture, we can move on to the equally interesting part â DevOps
Docker Swarm
Â
 â njĂ« sistem klasterizimi, funksionaliteti i tĂ« cilit Ă«shtĂ« realizuar brenda Docker Engine dhe Ă«shtĂ« i aksesueshĂ«m nga kutia.
Me ndihmĂ«n e «rojeve», tĂ« gjithĂ« nodet e klasterit tonĂ« mund tĂ« ndahen nĂ« 2 lloje â punonjĂ«s dhe menaxher. NĂ« pajisjet e llojit tĂ« parĂ« krijohen grupe kontejnerĂ«sh (stacks), pajisjet e llojit tĂ« dytĂ« janĂ« pĂ«rgjegjĂ«se pĂ«r shkallĂ«zimin, balancimin dhe . MenaxherĂ«t pĂ«r default janĂ« gjithashtu punonjĂ«s.
Një klaster me një menaxher lider dhe tre punonjës
Madhësia minimale e mundshme e klasterit është 1 nod, pajisja e vetme do të veprojë njëkohësisht si menaxher lider dhe punonjës. Duke u bazuar në madhësinë e projektit dhe kërkesat minimale për qëndrueshmëri, u mor vendimi për të përdorur këtë qasje.
Duke e kaluar përpara, do të them se që nga shpërndarja e parë në prodhim, e cila ndodhi në mes të qershorit, nuk ka pasur probleme të lidhura me organizimin e këtij klasteri (por kjo nuk do të thotë se një organizim i tillë është i pranueshëm në ndonjë projekt të mesëm ose të madh që ka kërkesa për qëndrueshmëri).
Docker Stack
Në modin e «rojeve» për shpërndarjen e stacks (grupimi i shërbimeve docker) është përgjegjës
Ai mbĂ«shtet konfigurime docker-compose, duke lejuar pĂ«rdorimin e parametrave tĂ« deploy-it pĂ«r mĂ« tepĂ«r. Â
Për shembull, me ndihmën e këtyre parametrave u kufizuan burimet për secilën nga instancat e mikroshërbimit të vlerësimit (ndajmë N qarqe për N instanca, në vetë mikroshërbimin kufizojmë numrin e qarqeve të përdorura nga PyTorch në një)
attrai_estimator:
image: 'erqups/attrai_estimator:1.2'
deploy:
replicas: 4
resources:
limits:
cpus: '4'
restart_policy:
condition: on-failure
âŠĂshtĂ« e rĂ«ndĂ«sishme tĂ« theksohet se Redis, RabbitMQ dhe Graylog janĂ« shĂ«rbime stateful dhe nuk Ă«shtĂ« aq e lehtĂ« t'i shkallĂ«zojmĂ« ato si «attrai-estimator»
Duke parashikuar pyetjenâpse jo Kubernetes?
Duket se përdorimi i Kubernetes në projekte të vogla dhe të mesme është një overhed, të gjitha funksionalitetet e nevojshme mund të merren nga Docker Swarm, i cili është mjaft miqësor me përdoruesit si një orkestrator kontejnerësh, si dhe ka një prag të ulët hyrës.
Infrastruktura
Të gjitha këto u zhvilluan në VDS me karakteristika të mëposhtme:
- CPU: 4 bërthama IntelŸ XeonŸ Gold 5120 CPU @ 2.20GHz
- RAM: 8 GB
- SSD: 160 GB
Pas testeve lokale të ngarkesës, dukej se gjatë një fluksi të rëndë përdoruesish, kjo pajisje do të ishte në kufi.
Por vetëm pas implementimit, kam postuar një lidhje në një nga board-et më të njohura të imazheve në CIS (po, atë të famshmen), pas së cilës njerëzit u interesuan dhe brenda disa orëve shërbimi përpunoi me sukses dhjetëra mijëra imazhe. Në momentet kulmore, burimet CPU dhe RAM nuk u shfrytëzuan as në gjysmën e kapacitetit.
Pak më shumë grafikë
Numri i përdoruesve unikë dhe kërkesave për vlerësim, që nga momenti i implementimit, varion sipas ditës
Distribucioni i kohës së inferencës së pipeline-it të vlerësimit
PĂ«rfundimet
NĂ« pĂ«rmbledhje, mund tĂ« them se arkitektura dhe qasja pĂ«r orkestrimin e kontejnerĂ«ve e justifikuan vetveten plotĂ«sisht â edhe nĂ« momentet kulmore nuk kishte rĂ«nie dhe vonesa nĂ« kohĂ«n e pĂ«rpunimit.Â
Mendoj që projektet e vogla dhe të mesme, që përdorin inferencën në kohë reale të rrjeteve neuronale në CPU, mund të përfitojnë suksesshëm nga praktikat e përshkruara në këtë artikull.
Do tĂ« shtoja se fillimisht artikulli ishte mĂ« i gjatĂ«, por, pĂ«r tĂ« mos postuar njĂ« dokument tĂ« gjatĂ«, vendosa tĂ« lĂ« disa pika jashtĂ« â do tĂ« kthehemi te to nĂ« publikime tĂ« ardhshme.
Mund ta provoni botin nĂ« Telegram â @AttraiBot, do tĂ« funksionojĂ«, tĂ« paktĂ«n, deri nĂ« fund tĂ« vjeshtĂ«s sĂ« vitit 2020. Kujtoj â nuk ruhet asnjĂ« tĂ« dhĂ«nĂ« personale â as imazhet origjinale, as rezultatet e pipeline-it tĂ« vlerĂ«simit â gjithçka fshihet pas pĂ«rpunimit.
Burimi: habr.com
