Įrašas
Sveiki!
Šiame straipsnyje pasidalinsiu savo patirtimi kuriant mikro paslaugų architektūrą projektui naudojant neuroninius tinklus.
Pakalbėkime apie architektūros reikalavimus, pažiūrėkime į įvairias konstrukcines diagramas, išanalizuosime kiekvieną iš baigtos architektūros komponentų, taip pat įvertinsime techninius sprendimo metrikus.
Mėgaukitės skaitymu!
Keletas žodžių apie problemą ir jos sprendimą
Pagrindinė mintis – pagal nuotrauką įvertinti žmogaus patrauklumą dešimties balų skalėje.
Šiame straipsnyje mes nutolsime nuo naudojamų neuroninių tinklų ir duomenų rengimo bei mokymo proceso aprašymo. Tačiau viename iš šių leidinių tikrai grįšime prie nuodugnios vertinimo sistemos analizės.
Dabar mes eisime per vertinimo procesą aukščiausiu lygiu ir sutelksime dėmesį į mikropaslaugų sąveiką visos projekto architektūros kontekste.
Dirbant su patrauklumo vertinimo vamzdynu, užduotis buvo suskaidyta į šiuos komponentus:
- Veidų pasirinkimas nuotraukose
- Kiekvieno žmogaus įvertinimas
- Pateikite rezultatą
Pirmasis išsprendžiamas iš anksto apmokytų jėgų . Antruoju atveju konvoliucinis neuroninis tinklas buvo apmokytas PyTorch, naudojant – iš balanso „procesoriaus išvados kokybė / greitis“
Vertinimo dujotiekio funkcinė schema
Projekto architektūros reikalavimų analizė
Gyvenimo cikle Projekto architektūros ir modelio diegimo automatizavimo etapai dažnai yra vieni daugiausiai laiko ir išteklių reikalaujančių.
ML projekto gyvavimo ciklas
Šis projektas nėra išimtis – vertinimo vamzdyną buvo nuspręsta įvynioti į internetinę paslaugą, todėl reikėjo pasinerti į architektūrą. Buvo nustatyti šie pagrindiniai reikalavimai:
- Vieninga žurnalų saugykla – visos tarnybos turėtų rašyti žurnalus vienoje vietoje, juos būtų patogu analizuoti
- Vertinimo paslaugos horizontalaus mastelio keitimo galimybė – kaip labiausiai tikėtina kliūtis
- Kiekvienam vaizdui įvertinti turėtų būti skirta tiek pat procesoriaus išteklių, kad būtų išvengta išvadų paskirstymo laiko.
- Greitas (pakartotinis) tiek konkrečių paslaugų, tiek viso rinkinio diegimas
- Galimybė, jei reikia, naudoti bendrus objektus įvairiose paslaugose
Architektūra
Išanalizavus reikalavimus tapo akivaizdu, kad mikroserviso architektūra dera beveik tobulai.
Siekiant atsikratyti nereikalingų galvos skausmų, prieiga buvo pasirinkta Telegram API.
Pirmiausia pažvelkime į baigtos architektūros struktūrinę schemą, tada pereikime prie kiekvieno komponento aprašymo, taip pat įforminkime sėkmingo vaizdo apdorojimo procesą.
Pagamintos architektūros struktūrinė schema
Pakalbėkime išsamiau apie kiekvieną diagramos komponentą, pažymėdami juos „Single Responsibility“ vaizdo vertinimo procese.
Mikropaslauga „attrai-telegram-bot“
Ši mikropaslauga apima visas sąveikas su Telegram API. Yra 2 pagrindiniai scenarijai: darbas su tinkintu vaizdu ir darbas su vertinimo dujotiekio rezultatu. Pažvelkime į abu scenarijus bendrai.
Kai gaunate pasirinktinį pranešimą su vaizdu:
- Atliekamas filtravimas, kurį sudaro šie patikrinimai:
- Optimalaus vaizdo dydžio prieinamumas
- Eilėje jau esančių naudotojų vaizdų skaičius
- Kai praeina pradinis filtravimas, vaizdas išsaugomas doko tūryje
- Eilėje „to_estimate“ sukuriama užduotis, kuri, be kita ko, apima kelią į vaizdą, esantį mūsų tome
- Jei aukščiau nurodyti veiksmai bus atlikti sėkmingai, vartotojas gaus pranešimą su apytiksliu vaizdo apdorojimo laiku, kuris apskaičiuojamas pagal užduočių skaičių eilėje. Jei įvyks klaida, vartotojas bus aiškiai informuotas išsiųsdamas pranešimą su informacija apie tai, kas galėjo nutikti.
Taip pat ši mikropaslauga, kaip ir salierų darbuotojas, išklauso eilę „after_estimate“, kuri skirta užduotims, kurios buvo perėjusios vertinimo konvejeriu.
Kai gaunate naują užduotį iš „af_estimate“:
- Jei vaizdas apdorojamas sėkmingai, rezultatą išsiunčiame vartotojui, jei ne, pranešame apie klaidą.
- Vaizdo, kuris yra įvertinimo dujotiekio rezultatas, pašalinimas
Vertinimo mikropaslauga „attrai-estimator“
Ši mikropaslauga yra „salierų“ darbuotoja ir apima viską, kas susiję su vaizdo įvertinimo vamzdynu. Čia yra tik vienas veikiantis algoritmas – paanalizuokime jį.
Kai gaunate naują užduotį iš „to_estimate“:
- Paleiskite vaizdą per vertinimo dujotiekį:
- Vaizdo įkėlimas į atmintį
- Atvaizduojame reikiamo dydžio paveikslėlį
- Visų veidų paieška (MTCNN)
- Įvertiname visus veidus (paskutiniame žingsnyje rastus veidus sujungiame į paketą ir darome išvadą, kad ResNet34)
- Pateikite galutinį vaizdą
- Nubrėžkime ribojančius langelius
- Reitingų braižymas
- Pasirinktinio (originalaus) vaizdo ištrynimas
- Išsaugoma vertinimo dujotiekio išvestis
- Užduotį dedame į eilę „after_estimate“, kurios klausosi aukščiau aptarta „attrai-telegram-bot“ mikropaslauga.
Graylog (+ mongoDB + Elasticsearch)
yra centralizuoto žurnalų valdymo sprendimas. Šiame projekte jis buvo naudojamas pagal paskirtį.
Pasirinkimas teko jam, o ne įprastam stack, nes patogu dirbti su juo iš Python. Viskas, ką jums reikia padaryti norint prisijungti prie „Graylog“, yra pridėti GELFTCPHandler iš paketo likusiems mūsų python mikroserviso šaknų registravimo tvarkytojams.
Kaip žmogus, anksčiau dirbęs tik su ELK stacku, dirbdamas su „Graylog“ paprastai turėjau teigiamos patirties. Vienintelis slegiantis dalykas yra „Kibana“ funkcijų pranašumas prieš „Graylog“ žiniatinklio sąsają.
TriušisMQ
yra pranešimų tarpininkas, pagrįstas AMQP protokolu.
Šiame projekte jis buvo naudojamas kaip Salierų brokeris ir dirbo ilgalaikiu režimu.
Redis
yra NoSQL DBVS, kuri veikia su raktinių verčių duomenų struktūromis
Kartais reikia naudoti bendrus objektus, kurie įgyvendina tam tikras duomenų struktūras skirtingose Python mikropaslaugos.
Pavyzdžiui, „Redis“ saugo „telegram_user_id => aktyvių užduočių skaičius eilėje“ maišos diagramą, kuri leidžia apriboti vieno vartotojo užklausų skaičių iki tam tikros vertės ir taip užkirsti kelią DoS atakoms.
Įforminkime sėkmingo vaizdo apdorojimo procesą
- Vartotojas siunčia vaizdą į „Telegram“ robotą
- „attrai-telegram-bot“ gauna pranešimą iš Telegram API ir jį analizuoja
- Užduotis su vaizdu įtraukiama į asinchroninę eilę „to_estimate“
- Vartotojas gauna pranešimą su planuojamu vertinimo laiku
- „attrai-estimator“ paima užduotį iš „to_estimate“ eilės, vykdo įvertinimus konvejeriu ir pateikia užduotį į eilę „after_estimate“
- „attrai-telegram-bot“ klausydamas „after_estimate“ eilės, siunčia rezultatą vartotojui
DevOps
Galiausiai, peržiūrėjus architektūrą, galima pereiti prie ne mažiau įdomios dalies – DevOps
Dockerio spiečius
— grupavimo sistema, kurios funkcionalumas įdiegtas „Docker Engine“ viduje ir pasiekiamas jau iš karto.
Naudojant „spiečius“, visus mūsų klasterio mazgus galima suskirstyti į 2 tipus – darbuotoją ir vadovą. Pirmojo tipo mašinose yra dislokuojamos konteinerių grupės (riedžiai), antrojo tipo mašinos yra atsakingos už mastelio keitimą, balansavimą ir . Vadovai taip pat pagal nutylėjimą yra darbuotojai.
Klasteris su vienu vadovu ir trimis darbuotojais
Mažiausias galimas klasterio dydis yra 1 mazgas; viena mašina vienu metu veiks kaip lyderio vadovas ir darbuotojas. Atsižvelgiant į projekto dydį ir minimalius gedimų tolerancijos reikalavimus, buvo nuspręsta taikyti šį metodą.
Žvelgdamas į ateitį, pasakysiu, kad nuo pat pirmojo produkcijos pristatymo, kuris buvo birželio viduryje, su šia klasterio organizacija nebuvo jokių problemų (tačiau tai nereiškia, kad tokia organizacija yra priimtina bet kokioje vidutinio ar didelio dydžio projektams, kuriems taikomi atsparumo gedimams reikalavimai).
Docker Stack
Spiečio režimu jis yra atsakingas už kaminų (dokerių paslaugų rinkinių) išdėstymą.
Jis palaiko dokerio kūrimo konfigūracijas, leidžiančias papildomai naudoti diegimo parinktis.
Pavyzdžiui, naudojant šiuos parametrus, kiekvieno įvertinimo mikroserviso egzemplioriaus ištekliai buvo riboti (N egzempliorių skiriame N branduolių, pačioje mikropaslaugoje apribojame PyTorch naudojamų branduolių skaičių iki vieno)
attrai_estimator:
image: 'erqups/attrai_estimator:1.2'
deploy:
replicas: 4
resources:
limits:
cpus: '4'
restart_policy:
condition: on-failure
…Svarbu pažymėti, kad „Redis“, „RabbitMQ“ ir „Graylog“ yra būseną palaikančios paslaugos ir jų negalima taip lengvai pakeisti kaip „attrai-estimator“.
Užbėgdamas už akių klausimui – kodėl gi ne Kubernetes?
Panašu, kad Kubernetes naudojimas mažuose ir vidutiniuose projektuose yra papildomas kaštas, visas reikiamas funkcijas galima gauti iš Docker Swarm, kuris yra gana patogus konteinerių orkestrui ir taip pat turi nedidelį įėjimo barjerą.
Infrastruktūra
Visa tai buvo įdiegta VDS su šiomis savybėmis:
- CPU: 4 branduolių Intel® Xeon® Gold 5120 CPU @ 2.20 GHz
- RAM: 8 GB
- SSD: 160 GB
Po vietinio apkrovos testavimo atrodė, kad esant rimtam vartotojų antplūdžiui, šios mašinos užteks.
Tačiau iškart po įdiegimo paskelbiau nuorodą į vieną populiariausių vaizdo lentų NVS (yup, tą pačią), po kurios žmonės susidomėjo ir per kelias valandas paslauga sėkmingai apdorojo dešimtis tūkstančių vaizdų. Tuo pačiu metu piko metu procesoriaus ir RAM ištekliai nebuvo naudojami net iki pusės.
Dar šiek tiek grafikos
Unikalių naudotojų ir vertinimo užklausų skaičius nuo diegimo, atsižvelgiant į dieną
Vertinimo dujotiekio išvadų laiko pasiskirstymas
išvados
Apibendrindamas galiu pasakyti, kad architektūra ir požiūris į konteinerių orkestravimą visiškai pasiteisino – net ir piko momentais apdorojimo laikas nenutrūko.
Manau, kad maži ir vidutinio dydžio projektai, kurie savo procese naudoja procesoriaus neuroninių tinklų išvadas realiuoju laiku, gali sėkmingai pritaikyti šiame straipsnyje aprašytą praktiką.
Pridursiu, kad iš pradžių straipsnis buvo ilgesnis, bet kad nerašyčiau ilgo skaitymo, nusprendžiau praleisti kai kuriuos šio straipsnio punktus – prie jų grįšime kituose leidiniuose.
Botą galite įkišti į „Telegram“ - @AttraiBot, jis veiks bent iki 2020 m. rudens pabaigos. Priminsiu, kad jokie vartotojo duomenys nesaugomi – nei originalūs vaizdai, nei vertinimo vamzdyno rezultatai – po apdorojimo viskas griaunama.
Šaltinis: www.habr.com