Merkintä
Hi!
Tässä artikkelissa jaan kokemukseni mikropalveluarkkitehtuurin rakentamisesta neuroverkkoja käyttävään projektiin.
Puhutaan arkkitehtuurivaatimuksista, tarkastellaan erilaisia rakennekaavioita, analysoidaan jokaista valmiin arkkitehtuurin komponenttia ja arvioidaan myös ratkaisun teknisiä mittareita.
Nauti lukemisesta!
Muutama sana ongelmasta ja sen ratkaisusta
Pääideana on arvioida henkilön houkuttelevuutta valokuvan perusteella kymmenen pisteen asteikolla.
Tässä artikkelissa siirrymme kuvailematta sekä käytettyjä hermoverkkoja että tietojen valmistelu- ja koulutusprosessia. Kuitenkin jossakin seuraavista julkaisuista palaamme ehdottomasti arviointiprosessin syvälliseen analysointiin.
Nyt käymme läpi arviointiputken huipputasolla ja keskitymme mikropalvelujen vuorovaikutukseen projektin kokonaisarkkitehtuurin kontekstissa.
Kun työskenneltiin houkuttelevuuden arviointiprosessin parissa, tehtävä jaettiin seuraaviin osiin:
- Valokuvien kasvojen valitseminen
- Jokaisen henkilön arvio
- Renderöi tulos
Ensimmäinen ratkaistaan esikoulutettujen voimien avulla . Toisessa tapauksessa konvoluutiohermoverkkoa koulutettiin PyTorchilla käyttämällä - tasapainosta "prosessorin päättelyn laatu / nopeus"
Arviointiputken toimintakaavio
Hankkeen arkkitehtuurin vaatimusten analyysi
Elämänkierrossa mallin käyttöönoton arkkitehtuurin ja automatisoinnin projektivaiheet ovat usein aikaa ja resursseja vievimpiä.
ML-projektin elinkaari
Tämä projekti ei ole poikkeus - arviointiputki päätettiin kääriä verkkopalveluksi, mikä vaati arkkitehtuuriin uppoamista. Seuraavat perusvaatimukset tunnistettiin:
- Yhtenäinen lokitallennus – kaikkien palveluiden tulee kirjoittaa lokit yhteen paikkaan, niitä tulee olla kätevä analysoida
- Arviointipalvelun horisontaalisen skaalausmahdollisuus - todennäköisimpänä pullonkaulana
- Jokaisen kuvan arvioimiseen tulisi varata sama määrä prosessoriresursseja, jotta vältytään poikkeavuuksista päättelyn ajan jakautumisessa
- Sekä tiettyjen palveluiden että koko pinon nopea (uudelleen)käyttöönotto
- Mahdollisuus käyttää tarvittaessa yhteisiä objekteja eri palveluissa
Arkkitehtuuri
Vaatimusten analysoinnin jälkeen kävi selväksi, että mikropalveluarkkitehtuuri sopii lähes täydellisesti.
Tarpeettoman päänsäryn poistamiseksi käyttöliittymäksi valittiin Telegram API.
Katsotaanpa ensin valmiin arkkitehtuurin rakennekaaviota, siirrytään sitten kunkin komponentin kuvaukseen ja virallistetaan myös onnistuneen kuvankäsittelyn prosessi.
Valmiin arkkitehtuurin rakennekaavio
Puhutaanpa yksityiskohtaisemmin kustakin kaavion komponentista, mikä merkitsee niitä yksittäisenä vastuuna kuvan arviointiprosessissa.
Mikropalvelu "attrai-telegram-bot"
Tämä mikropalvelu kapseloi kaikki vuorovaikutukset Telegram API:n kanssa. Pääskenaarioita on kaksi: mukautetun kuvan käyttäminen ja arviointiprosessin tulosten käsittely. Katsotaanpa molempia skenaarioita yleisellä tasolla.
Kun vastaanotat mukautetun kuvan sisältävän viestin:
- Suodatus suoritetaan, ja se koostuu seuraavista tarkistuksista:
- Optimaalisen kuvakoon saatavuus
- Jonossa olevien käyttäjäkuvien määrä
- Kun ensimmäinen suodatus läpäisee, kuva tallennetaan telakointiasemaan
- "to_estimate" -jonoon tuotetaan tehtävä, joka sisältää muun muassa polun taltiossamme olevaan kuvaan
- Jos yllä olevat vaiheet suoritetaan onnistuneesti, käyttäjä saa viestin, jossa on likimääräinen kuvankäsittelyaika, joka lasketaan jonossa olevien tehtävien lukumäärän perusteella. Jos tapahtuu virhe, käyttäjä saa nimenomaisen ilmoituksen lähettämällä viestin, jossa kerrotaan, mikä on voinut mennä pieleen.
Lisäksi tämä mikropalvelu, kuten sellerityöntekijä, kuuntelee "after_estimate" -jonoa, joka on tarkoitettu arviointiputken läpi kulkeneille tehtäville.
Kun vastaanotat uuden tehtävän "jälkiarviolta":
- Jos kuvan käsittely onnistuu, lähetämme tuloksen käyttäjälle, jos ei, ilmoitamme virheestä.
- Arviointiliukuhihnan tuloksena olevan kuvan poistaminen
Arviointimikropalvelu "attrai-estimator"
Tämä mikropalvelu on sellerityöntekijä ja tiivistää kaiken kuvan arviointiprosessiin liittyvän. Tässä on vain yksi toimiva algoritmi – analysoidaan se.
Kun vastaanotat uuden tehtävän kohteesta "to_estimate":
- Suoritetaan kuva arviointiputken läpi:
- Ladataan kuvaa muistiin
- Tuomme kuvan haluttuun kokoon
- Etsitään kaikki kasvot (MTCNN)
- Arvioimme kaikki kasvot (käärimme viimeisessä vaiheessa löydetyt kasvot eräksi ja päättelemme ResNet34:n)
- Renderöi lopullinen kuva
- Piirretään rajoitusruudut
- Arvioiden piirtäminen
- Muokatun (alkuperäisen) kuvan poistaminen
- Tulosteen tallentaminen arviointiputkesta
- Laitoimme tehtävän “after_estimate”-jonoon, jota kuuntelee yllä käsitelty “attrai-telegram-bot”-mikropalvelu.
Graylog (+ mongoDB + Elasticsearch)
on ratkaisu keskitettyyn lokinhallintaan. Tässä projektissa sitä käytettiin aiottuun tarkoitukseen.
Valinta osui häneen, ei tavalliseen pino, koska sen kanssa on helppo työskennellä Pythonista. Sinun tarvitsee vain kirjautua Graylogiin lisäämällä GELFTCPHandler paketista muille python-mikropalvelumme root logger -käsittelijöille.
Koska olen aiemmin työskennellyt vain ELK-pinon parissa, minulla oli kaiken kaikkiaan positiivinen kokemus työskennellessäni Graylogin kanssa. Ainoa masentava asia on Kibanan ominaisuuksien ylivoima Graylog-verkkokäyttöliittymään verrattuna.
RabbitMQ
on AMQP-protokollaan perustuva viestinvälittäjä.
Tässä projektissa sitä käytettiin mm välittäjänä sellerille ja työskenteli kestävässä tilassa.
Redis
on NoSQL DBMS, joka toimii avainarvotietorakenteiden kanssa
Joskus on tarpeen käyttää yleisiä objekteja, jotka toteuttavat tiettyjä tietorakenteita eri Python-mikropalveluissa.
Esimerkiksi Redis tallentaa hashmapin muodossa "telegram_user_id => aktiivisten tehtävien määrä jonossa", jonka avulla voit rajoittaa yhden käyttäjän pyyntöjen määrää tiettyyn arvoon ja siten estää DoS-hyökkäykset.
Virallistetaan onnistuneen kuvankäsittelyn prosessi
- Käyttäjä lähettää kuvan Telegram-botille
- "attrai-telegram-bot" vastaanottaa viestin Telegram API:lta ja jäsentää sen
- Kuvan sisältävä tehtävä lisätään asynkroniseen jonoon "to_estimate"
- Käyttäjä saa viestin, jossa on suunniteltu arviointiaika
- "attrai-estimator" ottaa tehtävän "to_estimate"-jonosta, suorittaa arviot liukuhihnan läpi ja tuottaa tehtävän "after_estimate"-jonoon.
- "attrai-telegram-bot" kuuntelee "after_estimate"-jonoa, lähettää tuloksen käyttäjälle
DevOps
Lopuksi arkkitehtuurin tarkastelun jälkeen voit siirtyä yhtä mielenkiintoiseen osaan - DevOpsiin
Docker-parvi
— klusterointijärjestelmä, jonka toiminnallisuus on toteutettu Docker Enginen sisällä ja joka on saatavana suoraan pakkauksesta.
"Parven" avulla kaikki klusterin solmut voidaan jakaa kahteen tyyppiin - työntekijä ja johtaja. Ensimmäisen tyypin koneissa käytetään konttiryhmiä (pinoja), toisen tyypin koneet vastaavat mittakaavasta, tasapainottamisesta ja . Esimiehet ovat myös oletuksena työntekijöitä.
Klusteri, jossa on yksi johtajajohtaja ja kolme työntekijää
Pienin mahdollinen klusterin koko on 1 solmu; yksi kone toimii samanaikaisesti johtajana ja työntekijänä. Projektin koon ja vikasietoisuuden vähimmäisvaatimusten perusteella päätettiin käyttää tätä lähestymistapaa.
Tulevaisuudessa sanon, että ensimmäisestä tuotantotoimituksesta, joka oli kesäkuun puolivälissä, tähän klusteriorganisaatioon ei ole liittynyt ongelmia (mutta tämä ei tarkoita, että tällainen organisaatio olisi millään tavalla hyväksyttävä missään keskisuuressa hankkeisiin, joihin sovelletaan vikasietovaatimuksia).
Docker Stack
Swarm-tilassa hän on vastuussa pinojen (telakkapalveluiden) käyttöönotosta.
Se tukee telakointiaseman kokoonpanomäärityksiä, jolloin voit käyttää lisäksi käyttöönottoparametreja.
Esimerkiksi näitä parametreja käyttämällä resurssit jokaiselle arviointimikropalveluinstanssille olivat rajalliset (varaamme N ydintä N instanssille, itse mikropalvelussa rajoitamme PyTorchin käyttämien ytimien määrän yhteen)
attrai_estimator:
image: 'erqups/attrai_estimator:1.2'
deploy:
replicas: 4
resources:
limits:
cpus: '4'
restart_policy:
condition: on-failure
…On tärkeää huomata, että Redis, RabbitMQ ja Graylog ovat tilallisia palveluita, eikä niitä voida skaalata yhtä helposti kuin "attrai-estimator".
Ennakoiva kysymys - miksi ei Kubernetes?
Näyttää siltä, että Kubernetesin käyttö pienissä ja keskisuurissa projekteissa on ylimääräistä, kaikki tarvittavat toiminnot saadaan Docker Swarmista, joka on konttiorkesterille varsin käyttäjäystävällinen ja jolla on myös alhainen sisäänpääsyeste.
infrastruktuuri
Kaikki tämä otettiin käyttöön VDS:ssä seuraavilla ominaisuuksilla:
- CPU: 4-ytiminen Intel® Xeon® Gold 5120 -suoritin @ 2.20 GHz
- RAM: 8 GB
- SSD: 160 Gt
Paikallisen kuormitustestauksen jälkeen näytti siltä, että tämä kone riittäisi suurella käyttäjävirralla.
Mutta heti käyttöönoton jälkeen laitoin linkin yhdelle IVY:n suosituimmista kuvatauluista (jep, tuohon samaan), minkä jälkeen ihmiset kiinnostuivat ja palvelu käsitteli muutamassa tunnissa onnistuneesti kymmeniätuhansia kuvia. Samaan aikaan huippuhetkillä suoritin- ja RAM-resursseja ei käytetty puoliksikaan.
Vielä vähän grafiikkaa
Yksittäisten käyttäjien ja arviointipyyntöjen määrä käyttöönoton jälkeen päivästä riippuen
Arviointiputken päättelyn aikajakauma
Tulokset
Yhteenvetona voin todeta, että konttien arkkitehtuuri ja lähestymistapa orkestrointiin oikeuttivat täysin itsensä - ruuhka-aikoinakaan ei tapahtunut laskua tai roikkumista käsittelyajassa.
Uskon, että pienet ja keskisuuret projektit, jotka käyttävät prosessissaan reaaliaikaista neuroverkkojen päättelyä CPU:ssa, voivat onnistuneesti omaksua tässä artikkelissa kuvatut käytännöt.
Lisään, että alun perin artikkeli oli pidempi, mutta jotta en kirjoittaisi pitkää lukua, päätin jättää joitakin kohtia pois tästä artikkelista - palaamme niihin tulevissa julkaisuissa.
Botin voi tökätä Telegramissa - @AttraiBot, se toimii ainakin syksyn 2020 loppuun asti. Muistutan, että mitään käyttäjätietoja ei tallenneta - ei alkuperäisiä kuvia eikä arviointiputken tuloksia - kaikki puretaan käsittelyn jälkeen.
Lähde: will.com