Entry
Привет!
In hierdie artikel sal ek my ervaring deel van die bou van 'n mikrodiensargitektuur vir 'n projek wat neurale netwerke gebruik.
Kom ons praat oor die argitektuurvereistes, kyk na verskeie struktuurdiagramme, ontleed elk van die komponente van die voltooide argitektuur, en evalueer ook die tegniese maatstawwe van die oplossing.
Geniet dit om te lees!
'n Paar woorde oor die probleem en die oplossing daarvan
Die hoofgedagte is om 'n persoon se aantreklikheid op 'n tienpuntskaal op grond van 'n foto te evalueer.
In hierdie artikel sal ons wegbeweeg van die beskrywing van beide die neurale netwerke wat gebruik word en die proses van data voorbereiding en opleiding. In een van die volgende publikasies sal ons egter beslis terugkeer na die ontleding van die assesseringspyplyn op 'n in-diepte vlak.
Nou gaan ons deur die evalueringspyplyn op die topvlak, en sal fokus op die interaksie van mikrodienste in die konteks van die algehele projekargitektuur.
Wanneer aan die aantreklikheidsbepalingspyplyn gewerk is, is die taak in die volgende komponente opgedeel:
- Kies gesigte in foto's
- Gradering van elke persoon
- Gee die resultaat
Die eerste word opgelos deur die kragte van vooraf-opgeleide . Vir die tweede is 'n konvolusionele neurale netwerk opgelei op PyTorch, met behulp van - van die balans "kwaliteit / spoed van afleiding op die SVE"
Funksionele diagram van die evalueringspyplyn
Ontleding van projek argitektuur vereistes
In die lewensiklus projekstadia van werk oor die argitektuur en outomatisering van modelontplooiing is dikwels van die tydrowendste en hulpbronrowendste.
Lewensiklus van 'n ML-projek
Hierdie projek is geen uitsondering nie - die besluit is geneem om die assesseringspyplyn in 'n aanlyndiens te omskep, wat vereis het om onsself in die argitektuur te verdiep. Die volgende basiese vereistes is geïdentifiseer:
- Eenvormige logberging – alle dienste moet logs op een plek skryf, dit moet gerieflik wees om te ontleed
- Moontlikheid van horisontale skaal van die assesseringsdiens - as die mees waarskynlike Bottelnek
- Dieselfde hoeveelheid verwerkerhulpbronne moet toegewys word om elke beeld te evalueer om uitskieters in die verspreiding van tyd vir afleiding te vermy
- Vinnige (her)ontplooiing van beide spesifieke dienste en die stapel as 'n geheel
- Die vermoë om, indien nodig, algemene voorwerpe in verskillende dienste te gebruik
Argitektuur
Nadat die vereistes ontleed is, het dit duidelik geword dat die mikrodiensargitektuur amper perfek pas.
Om van onnodige hoofpyn ontslae te raak, is die Telegram API as die frontend gekies.
Kom ons kyk eers na die struktuurdiagram van die voltooide argitektuur, gaan dan na 'n beskrywing van elk van die komponente, en formaliseer ook die proses van suksesvolle beeldverwerking.
Struktuurdiagram van die voltooide argitektuur
Kom ons praat in meer besonderhede oor elk van die komponente van die diagram, en dui hulle op Enkele Verantwoordelikheid in die proses van beeldevaluering.
Mikrodiens "attrai-telegram-bot"
Hierdie mikrodiens omsluit alle interaksies met die Telegram API. Daar is 2 hoofscenario's: werk met 'n pasgemaakte beeld en werk met die resultaat van 'n assesseringspyplyn. Kom ons kyk na albei scenario's in algemene terme.
Wanneer 'n pasgemaakte boodskap met 'n prent ontvang word:
- Filtrering word uitgevoer, wat bestaan uit die volgende kontrole:
- Beskikbaarheid van optimale beeldgrootte
- Aantal gebruikerbeelde wat reeds in die tou is
- Wanneer die aanvanklike filter geslaag word, word die prent in die dokvolume gestoor
- 'n Taak word in die "to_estimate"-ry geproduseer, wat onder andere die pad na die beeld in ons volume insluit
- As bogenoemde stappe suksesvol voltooi is, sal die gebruiker 'n boodskap ontvang met die benaderde beeldverwerkingstyd, wat bereken word op grond van die aantal take in die tou. As 'n fout voorkom, sal die gebruiker uitdruklik in kennis gestel word deur 'n boodskap te stuur met inligting oor wat dalk verkeerd geloop het.
Ook luister hierdie mikrodiens, soos 'n selderywerker, na die "na_skatting"-tou, wat bedoel is vir take wat deur die evalueringspyplyn gegaan het.
Wanneer 'n nuwe taak van "after_estimate" ontvang word:
- As die prent suksesvol verwerk is, stuur ons die resultaat aan die gebruiker indien nie, stel ons in kennis van 'n fout.
- Verwyder die beeld wat die resultaat van die evalueringspyplyn is
Evaluering mikrodiens "attrai-estimator"
Hierdie mikrodiens is 'n selderywerker en omsluit alles wat met die beeldevalueringspyplyn verband hou. Daar is net een werkende algoritme hier - kom ons ontleed dit.
Wanneer 'n nuwe taak van "to_estimate" ontvang word:
- Kom ons loop die prent deur die evalueringspyplyn:
- Laai die prent in die geheue
- Ons bring die beeld na die verlangde grootte
- Vind alle gesigte (MTCNN)
- Ons evalueer alle gesigte (ons draai die gesigte wat in die laaste stap gevind is in 'n bondel en lei ResNet34 af)
- Gee die finale prent weer
- Kom ons teken die grenskassies
- Teken die graderings
- Vee 'n pasgemaakte (oorspronklike) prent uit
- Stoor die uitset van die evalueringspyplyn
- Ons plaas die taak in die "na_skatting" tou, waarna geluister word deur die "attrai-telegram-bot" mikrodiens hierbo bespreek.
Greylog (+ mongoDB + Elasticsearch)
is 'n oplossing vir gesentraliseerde logbestuur. In hierdie projek is dit vir sy beoogde doel gebruik.
Die keuse het op hom geval, en nie op die gewone een nie stapel, as gevolg van die gerief om daarmee vanaf Python te werk. Al wat jy hoef te doen om by Graylog aan te meld, is om die GELFTCPHandler uit die pakket by te voeg aan die res van die wortellogger-hanteerders van ons python-mikrodiens.
As iemand wat voorheen net met die ELK-stapel gewerk het, het ek 'n algehele positiewe ervaring gehad terwyl ek met Graylog gewerk het. Die enigste ding wat neerdrukkend is, is die meerderwaardigheid in Kibana-kenmerke bo die Graylog-webkoppelvlak.
Konyn MQ
is 'n boodskap makelaar gebaseer op die AMQP protokol.
In hierdie projek is dit gebruik as makelaar vir Seldery en het in duursame modus gewerk.
Redis
is 'n NoSQL DBMS wat met sleutel-waarde datastrukture werk
Soms is daar 'n behoefte om algemene voorwerpe te gebruik wat sekere datastrukture in verskillende Python-mikrodienste implementeer.
Byvoorbeeld, Redis stoor 'n hashmap van die vorm "telegram_user_id => aantal aktiewe take in die tou," wat jou toelaat om die aantal versoeke van een gebruiker tot 'n sekere waarde te beperk en sodoende DoS-aanvalle te voorkom.
Kom ons formaliseer die proses van suksesvolle beeldverwerking
- Die gebruiker stuur 'n prent na die Telegram-bot
- "attrai-telegram-bot" ontvang 'n boodskap van die Telegram API en ontleed dit
- Die taak met die prent word by die asynchrone tou gevoeg "to_estimate"
- Die gebruiker ontvang 'n boodskap met die beplande assesseringstyd
- "attrai-estimator" neem 'n taak uit die "to_estimate" tou, loop die skattings deur die pyplyn en produseer die taak in die "na_estimate" tou
- "attrai-telegram-bot" luister na die "after_estimate" tou, stuur die resultaat na die gebruiker
DevOps
Uiteindelik, nadat u die argitektuur hersien het, kan u voortgaan na die ewe interessante deel - DevOps
Docker -swerm
- 'n groeperingstelsel, waarvan die funksionaliteit binne die Docker Engine geïmplementeer is en uit die boks beskikbaar is.
Deur 'n “swerm” te gebruik, kan alle nodusse in ons groepering in 2 tipes verdeel word – werker en bestuurder. Op masjiene van die eerste tipe word groepe houers (stapels) ontplooi, masjiene van die tweede tipe is verantwoordelik vir skaal, balansering en . Bestuurders is ook by verstek werkers.
Groepering met een leierbestuurder en drie werkers
Die minimum moontlike groepgrootte is 1 nodus 'n enkele masjien sal gelyktydig as leierbestuurder en werker optree. Op grond van die grootte van die projek en die minimum vereistes vir foutverdraagsaamheid, is besluit om hierdie benadering te gebruik.
As ek vorentoe kyk, sal ek sê dat daar sedert die eerste produksielewering, wat middel Junie was, geen probleme met hierdie klusterorganisasie geassosieer het nie (maar dit beteken nie dat so 'n organisasie enigsins aanvaarbaar is in enige medium-groot projekte, wat onderhewig is aan vereistes vir foutverdraagsaamheid).
Docker Stack
In swermmodus is hy verantwoordelik vir die ontplooiing van stapels (stelle docker-dienste)
Dit ondersteun docker-compose-konfigurasies, waardeur u ook ontplooi-opsies kan gebruik.
Byvoorbeeld, deur hierdie parameters te gebruik, was die hulpbronne vir elk van die evalueringsmikrodiensgevalle beperk (ons ken N kerne toe vir N instansies, in die mikrodiens self beperk ons die aantal kerne wat deur PyTorch gebruik word tot een)
attrai_estimator:
image: 'erqups/attrai_estimator:1.2'
deploy:
replicas: 4
resources:
limits:
cpus: '4'
restart_policy:
condition: on-failure
…Dit is belangrik om daarop te let dat Redis, RabbitMQ en Graylog staatkundige dienste is en dat hulle nie so maklik as "attrai-estimator" geskaal kan word nie.
Voorspel die vraag - hoekom nie Kubernetes nie?
Dit blyk dat die gebruik van Kubernetes in klein en medium-grootte projekte 'n oorhoofse koste is wat al die nodige funksionaliteit verkry kan word van Docker Swarm, wat redelik gebruikersvriendelik is vir 'n houer-orkeseerder en ook 'n lae toegangsgrens het.
Infrastruktuur
Dit alles is op VDS ontplooi met die volgende kenmerke:
- SVE: 4-kern Intel® Xeon® Gold 5120 SVE @ 2.20GHz
- RAM: 8 GB
- SSD: 160 GB
Na plaaslike vragtoetsing het dit gelyk of met 'n ernstige toestroming van gebruikers, hierdie masjien genoeg sou wees.
Maar, onmiddellik na die ontplooiing, het ek 'n skakel geplaas na een van die gewildste beeldborde in die GOS (yup, daardie selfde een), waarna mense begin belangstel het en binne 'n paar uur het die diens tienduisende beelde suksesvol verwerk. Terselfdertyd, op spitsoomblikke, is SVE- en RAM-hulpbronne nie eens half gebruik nie.
Nog 'n paar grafika
Aantal unieke gebruikers en evalueringsversoeke sedert ontplooiing, afhangend van die dag
Evaluering pyplyn afleiding tyd verspreiding
Bevindinge
Om op te som, kan ek sê dat die argitektuur en benadering tot orkestrasie van houers hulself ten volle geregverdig het – selfs op spitsoomblikke was daar geen druppels of insakking in verwerkingstyd nie.
Ek dink dat klein en mediumgrootte projekte wat intydse afleiding van neurale netwerke op die SVE in hul proses gebruik, die praktyke wat in hierdie artikel beskryf word, suksesvol kan aanneem.
Ek sal byvoeg dat die artikel aanvanklik langer was, maar om nie 'n langlesing te plaas nie, het ek besluit om 'n paar punte in hierdie artikel weg te laat - ons sal daarna terugkeer in toekomstige publikasies.
Jy kan die bot op Telegram steek - @AttraiBot, dit sal ten minste tot die einde van herfs 2020 werk. Laat ek jou daaraan herinner dat geen gebruikerdata gestoor word nie - nóg die oorspronklike beelde, nóg die resultate van die evalueringspyplyn - alles word afgebreek na verwerking.
Bron: will.com
