Hyrje
Привет!
Në këtë artikull unë do të ndaj përvojën time të ndërtimit të një arkitekture mikroservice për një projekt duke përdorur rrjetet nervore.
Le të flasim për kërkesat e arkitekturës, të shohim diagrame të ndryshme strukturore, të analizojmë secilin prej përbërësve të arkitekturës së përfunduar dhe gjithashtu të vlerësojmë metrikat teknike të zgjidhjes.
Gëzoni leximin!
Disa fjalë për problemin dhe zgjidhjen e tij
Ideja kryesore është të vlerësohet atraktiviteti i një personi në një shkallë prej dhjetë pikësh bazuar në një foto.
Në këtë artikull ne do të largohemi nga përshkrimi i rrjeteve nervore të përdorura dhe procesi i përgatitjes dhe trajnimit të të dhënave. Megjithatë, në një nga botimet e mëposhtme, ne patjetër do t'i rikthehemi analizimit të tubacionit të vlerësimit në një nivel të thellë.
Tani do të kalojmë përmes tubacionit të vlerësimit në nivelin më të lartë dhe do të fokusohemi në ndërveprimin e mikroshërbimeve në kontekstin e arkitekturës së përgjithshme të projektit.
Gjatë punës në tubacionin e vlerësimit të atraktivitetit, detyra u zbërthye në komponentët e mëposhtëm:
- Përzgjedhja e fytyrave në foto
- Vlerësimi i çdo personi
- Jepni rezultatin
E para zgjidhet nga forcat e para-stërvitur . Për të dytën, një rrjet nervor konvolucionist u trajnua në PyTorch, duke përdorur - nga bilanci "cilësia / shpejtësia e përfundimit në CPU"
Diagrami funksional i tubacionit të vlerësimit
Analiza e kërkesave të arkitekturës së projektit
Në ciklin jetësor Fazat e projektit të punës në arkitekturën dhe automatizimin e vendosjes së modelit janë shpesh ndër ato që kërkojnë kohë dhe konsumojnë burime.
Cikli jetësor i një projekti ML
Ky projekt nuk bën përjashtim - u vendos që tubacioni i vlerësimit të mbështillet në një shërbim online, i cili kërkonte zhytjen në arkitekturë. U identifikuan kërkesat themelore të mëposhtme:
- Ruajtja e unifikuar e regjistrave - të gjitha shërbimet duhet të shkruajnë regjistrat në një vend, ato duhet të jenë të përshtatshme për t'u analizuar
- Mundësia e shkallëzimit horizontal të shërbimit të vlerësimit - si Gryka më e mundshme
- E njëjta sasi e burimeve të procesorit duhet të ndahet për të vlerësuar çdo imazh, në mënyrë që të shmangen dallimet në shpërndarjen e kohës për konkluzione.
- Shpërndarja e shpejtë (ri) si e shërbimeve specifike ashtu edhe e stakut në tërësi
- Aftësia, nëse është e nevojshme, për të përdorur objekte të përbashkëta në shërbime të ndryshme
Arkitekturë
Pas analizimit të kërkesave, u bë e qartë se arkitektura e mikroshërbimit përshtatet pothuajse në mënyrë të përsosur.
Për të hequr qafe dhimbje koke të panevojshme, Telegram API u zgjodh si frontend.
Së pari, le të shohim diagramin strukturor të arkitekturës së përfunduar, pastaj të kalojmë në një përshkrim të secilit prej komponentëve, dhe gjithashtu të zyrtarizojmë procesin e përpunimit të suksesshëm të imazhit.
Diagrami strukturor i arkitekturës së përfunduar
Le të flasim më në detaje për secilin nga komponentët e diagramit, duke i treguar ato Përgjegjësi të vetme në procesin e vlerësimit të imazhit.
Microservice “attrai-telegram-bot”
Ky mikroshërbim përfshin të gjitha ndërveprimet me API-në e Telegramit. Ekzistojnë 2 skenarë kryesorë: puna me një imazh të personalizuar dhe puna me rezultatin e një tubacioni vlerësimi. Le t'i shohim të dy skenarët në terma të përgjithshëm.
Kur merrni një mesazh të personalizuar me një imazh:
- Filtrimi kryhet, i cili përbëhet nga kontrollet e mëposhtme:
- Disponueshmëria e madhësisë optimale të imazhit
- Numri i imazheve të përdoruesve tashmë në radhë
- Kur kalon filtrimin fillestar, imazhi ruhet në volumin e dokerit
- Një detyrë prodhohet në radhën "to_estimate", e cila përfshin, ndër të tjera, rrugën drejt imazhit të vendosur në vëllimin tonë
- Nëse hapat e mësipërm përfundojnë me sukses, përdoruesi do të marrë një mesazh me kohën e përafërt të përpunimit të imazhit, e cila llogaritet në bazë të numrit të detyrave në radhë. Nëse ndodh një gabim, përdoruesi do të njoftohet në mënyrë eksplicite duke dërguar një mesazh me informacion se çfarë mund të ketë shkuar keq.
Gjithashtu, ky mikroshërbim, si një punëtor selino, dëgjon radhën "after_estimate", e cila është menduar për detyrat që kanë kaluar në tubacionin e vlerësimit.
Kur merrni një detyrë të re nga "after_estimate":
- Nëse imazhi përpunohet me sukses, ne ia dërgojmë rezultatin përdoruesit; nëse jo, njoftojmë për një gabim.
- Heqja e imazhit që është rezultat i tubacionit të vlerësimit
Mikroshërbimi i vlerësimit "attrai-estimator"
Ky mikroshërbim është një punëtor selino dhe përfshin gjithçka që lidhet me tubacionin e vlerësimit të imazhit. Ekziston vetëm një algoritëm i punës këtu - le ta analizojmë atë.
Kur merrni një detyrë të re nga "to_estimate":
- Le ta kalojmë imazhin përmes tubacionit të vlerësimit:
- Duke ngarkuar imazhin në memorie
- Ne e sjellim imazhin në madhësinë e kërkuar
- Gjetja e të gjitha fytyrave (MTCNN)
- Ne vlerësojmë të gjitha fytyrat (ne i mbështjellim fytyrat e gjetura në hapin e fundit në një grup dhe nxjerrim përfundimin ResNet34)
- Paraqitni imazhin përfundimtar
- Le të vizatojmë kutitë kufizuese
- Vizatimi i vlerësimeve
- Fshirja e një imazhi të personalizuar (origjinal).
- Ruajtja e prodhimit nga tubacioni i vlerësimit
- Ne e vendosim detyrën në radhën "after_estimate", e cila dëgjohet nga mikroshërbimi "attrai-telegram-bot" i diskutuar më sipër.
Graylog (+ mongoDB + Elasticsearch)
është një zgjidhje për menaxhimin e centralizuar të regjistrave. Në këtë projekt, ai u përdor për qëllimin e tij të synuar.
Zgjedhja ra mbi të, dhe jo mbi atë të zakonshmen stack, për shkak të komoditetit të punës me të nga Python. Gjithçka që duhet të bëni për të hyrë në Graylog është të shtoni GELFTCPHandler nga paketa për pjesën tjetër të mbajtësve të logger-it rrënjë të mikroshërbimit tonë python.
Si dikush që më parë kishte punuar vetëm me grupin ELK, pata një përvojë të përgjithshme pozitive gjatë punës me Graylog. E vetmja gjë që është dëshpëruese është epërsia në veçoritë e Kibana ndaj ndërfaqes së internetit Graylog.
LepuriMQ
është një ndërmjetës mesazhesh i bazuar në protokollin AMQP.
Në këtë projekt u përdor si ndërmjetës për Selino dhe ka punuar në mënyrë të qëndrueshme.
Redis
është një DBMS NoSQL që punon me strukturat e të dhënave me vlerë kyçe
Ndonjëherë ekziston nevoja për të përdorur objekte të zakonshme që zbatojnë struktura të caktuara të dhënash në mikroshërbime të ndryshme Python.
Për shembull, Redis ruan një hartë të formës "telegram_user_id => numri i detyrave aktive në radhë", i cili ju lejon të kufizoni numrin e kërkesave nga një përdorues në një vlerë të caktuar dhe, në këtë mënyrë, të parandaloni sulmet DoS.
Le të zyrtarizojmë procesin e përpunimit të suksesshëm të imazhit
- Përdoruesi dërgon një imazh në bot Telegram
- "attrai-telegram-bot" merr një mesazh nga Telegram API dhe e analizon atë
- Detyra me imazhin shtohet në radhën asinkrone "to_estimate"
- Përdoruesi merr një mesazh me kohën e planifikuar të vlerësimit
- "attrai-estimator" merr një detyrë nga radha "to_estimate", ekzekuton vlerësimet përmes tubacionit dhe prodhon detyrën në radhën "after_estimate".
- "attrai-telegram-bot" duke dëgjuar radhën "after_estimate", ia dërgon rezultatin përdoruesit
DevOps
Më në fund, pas rishikimit të arkitekturës, mund të kaloni në pjesën po aq interesante - DevOps
Grumbulli i dokerëve
— një sistem grupimi, funksionaliteti i të cilit zbatohet brenda Docker Engine dhe është i disponueshëm jashtë kutisë.
Duke përdorur një "swarm", të gjitha nyjet në grupin tonë mund të ndahen në 2 lloje - punëtor dhe menaxher. Në makinat e tipit të parë vendosen grupe kontejnerësh (pirgje), makinat e tipit të dytë janë përgjegjës për shkallëzimin, balancimin dhe . Menaxherët janë gjithashtu punëtorë si parazgjedhje.
Grupi me një menaxher udhëheqës dhe tre punëtorë
Madhësia minimale e mundshme e grupit është 1 nyje; një makinë e vetme do të veprojë njëkohësisht si menaxher udhëheqës dhe punëtor. Bazuar në madhësinë e projektit dhe kërkesat minimale për tolerancën e gabimeve, u vendos që të përdoret kjo qasje.
Duke parë përpara, do të them se që nga dorëzimi i parë i prodhimit, i cili ishte në mes të qershorit, nuk ka pasur probleme të lidhura me këtë organizim grupor (por kjo nuk do të thotë se një organizim i tillë është në asnjë mënyrë i pranueshëm në çdo të mesme-të madhe projektet, të cilat i nënshtrohen kërkesave për tolerancën e gabimeve).
Docker Stack
Në modalitetin swarm, ai është përgjegjës për vendosjen e pirgjeve (grupe shërbimesh docker)
Ai mbështet konfigurimin e docker-compose, duke ju lejuar të përdorni shtesë opsionet e vendosjes.
Për shembull, duke përdorur këto parametra, burimet për secilin prej instancave të mikroshërbimit të vlerësimit ishin të kufizuara (ne ndajmë N bërthama për N shembuj, në vetë mikroshërbimin kufizojmë numrin e bërthamave 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 shtetërore dhe ato nuk mund të shkallëzohen aq lehtë sa "attrai-estimator"
Parashikimi i pyetjes - pse jo Kubernetes?
Duket se përdorimi i Kubernetes në projekte të vogla dhe të mesme është një kosto e lartë; të gjithë funksionalitetin e nevojshëm mund të merren nga Docker Swarm, i cili është mjaft i përshtatshëm për një orkestrim konteinerësh dhe gjithashtu ka një pengesë të ulët për hyrjen.
Infrastrukturë
E gjithë kjo u vendos në VDS me karakteristikat e mëposhtme:
- CPU: 4 bërthama Intel® Xeon® Gold 5120 CPU @ 2.20 GHz
- RAM: 8 GB
- SSD: 160 GB
Pas testimit të ngarkesës lokale, dukej se me një fluks serioz përdoruesish, kjo makinë do të mjaftonte.
Por, menjëherë pas vendosjes, unë postova një lidhje me një nga tabelat më të njohura të imazheve në CIS (po, e njëjta), pas së cilës njerëzit u interesuan dhe në pak orë shërbimi përpunoi me sukses dhjetëra mijëra imazhe. Në të njëjtën kohë, në momentet e pikut, burimet e CPU dhe RAM nuk u përdorën as gjysma.
Disa grafika të tjera
Numri i përdoruesve unikë dhe kërkesat e vlerësimit që nga vendosja, në varësi të ditës
Shpërndarja e kohës së konkluzionit të tubacionit të vlerësimit
Gjetjet
Për ta përmbledhur, mund të them se arkitektura dhe qasja ndaj orkestrimit të kontejnerëve e justifikuan plotësisht veten e tyre - edhe në momentet e pikut nuk kishte rënie apo ulje në kohën e përpunimit.
Unë mendoj se projektet e vogla dhe të mesme që përdorin konkluzionet në kohë reale të rrjeteve nervore në CPU në procesin e tyre mund të adoptojnë me sukses praktikat e përshkruara në këtë artikull.
Do të shtoj që fillimisht artikulli ishte më i gjatë, por për të mos postuar një kohë të gjatë, vendosa të heq disa pika në këtë artikull - do t'u kthehemi atyre në botimet e ardhshme.
Mund ta futni robotin në Telegram - @AttraiBot, do të funksionojë të paktën deri në fund të vjeshtës 2020. Më lejoni t'ju kujtoj se asnjë e dhënë e përdoruesit nuk ruhet - as imazhet origjinale, as rezultatet e tubacionit të vlerësimit - gjithçka shkatërrohet pas përpunimit.
Burimi: www.habr.com