Plus
Hello!
In questu articulu, sparteraghju a mo sperienza di custruisce una architettura di microserviziu per un prughjettu cù e rete neurali.
Parlemu di i bisogni di l'architettura, fighjemu diversi diagrammi strutturali, analizà ognuna di i cumpunenti di l'architettura finita, è ancu evaluà e metriche tecniche di a suluzione.
Enjoy reading!
Uni pochi di parolle nantu à u prublema è a so suluzione
L'idea principale hè di valutà l'attrattiva di una persona nantu à una scala di dece punti basatu nantu à una foto.
In questu articulu avemu da alluntanassi da a descrizzione di e rete neurali utilizati è u prucessu di preparazione di dati è furmazione. Tuttavia, in una di e publicazioni seguenti, torneremu definitivamente à analizà u pipeline di valutazione à un livellu in profondità.
Avà andemu à traversu u pipeline di valutazione à u livellu più altu, è fucalizza nantu à l'interazzione di i microservizi in u cuntestu di l'architettura generale di u prugettu.
Quandu u travagliu nantu à u pipeline di valutazione di l'attrattiva, u compitu hè statu scompostu in i seguenti cumpunenti:
- Selezzione di facci in e foto
- Valutazione di ogni persona
- Rende u risultatu
U primu hè risolta da e forze di pre-furmati . Per u sicondu, una rete neurale cunvoluzionale hè stata furmatu nantu à PyTorch, utilizendu - da u bilanciu "qualità / velocità di inferenza nantu à u CPU"
Schema funziunale di u pipeline di valutazione
Analisi di i bisogni di l'architettura di u prugettu
In u ciclu di vita e tappe di u prughjettu di u travagliu nantu à l'architettura è l'automatizazione di a implementazione di mudelli sò spessu trà i più tempu è risorse.
Ciclu di vita di un prughjettu ML
Stu prughjettu ùn hè micca eccezzioni - a decisione hè stata presa per imbulighjà u pipeline di valutazione in un serviziu in linea, chì necessitava di immersi in l'architettura. I seguenti requisiti basi sò stati identificati:
- Almacenamiento unificatu di logu - tutti i servizii anu da scrive logs in un locu, devenu esse convenientu per analizà
- Possibilità di scaling horizontale di u serviziu di valutazione - cum'è u Bottleneck più prubabile
- A listessa quantità di risorse di processore deve esse attribuita per evaluà ogni imaghjina per evità outliers in a distribuzione di u tempu per l'inferenza.
- (ri)implementazione rapida di i servizii specifichi è di a pila in generale
- A capacità, se ne necessariu, di utilizà l'uggetti cumuni in diversi servizii
architettura
Dopu l'analisi di e esigenze, hè diventatu evidenti chì l'architettura di u microserviziu si adatta quasi perfettamente.
Per caccià i mal di testa inutili, l'API di Telegram hè stata scelta cum'è frontend.
Prima, fighjemu u schema strutturale di l'architettura finita, dopu passà à una descrizzione di ognuna di i cumpunenti, è ancu formalizà u prucessu di trasfurmazioni di l'imaghjini successu.
Schema strutturale di l'architettura finita
Parlemu in più dettaglii di ognunu di i cumpunenti di u diagramma, denotendu a sola Responsabilità in u prucessu di valutazione di l'imaghjini.
Microserviziu "attrai-telegram-bot"
Stu microserviziu incapsula tutte l'interazzione cù l'API Telegram. Ci sò 2 scenarii principali: travaglià cù una maghjina persunalizata è travaglià cù u risultatu di un pipeline di valutazione. Fighjemu i dui scenarii in termini generale.
Quandu riceve un missaghju persunalizatu cù una maghjina:
- A filtrazione hè realizata, cumpostu di i seguenti cuntrolli:
- Disponibilità di a dimensione ottima di l'imagine
- Numeru d'imaghjini d'utilizatori digià in fila
- Quandu passa u filtru iniziale, l'imaghjini hè salvatu in u voluminu docker
- Un compitu hè pruduciutu in a fila "to_estimate", chì include, frà altre cose, u percorsu à l'imaghjini situatu in u nostru voluminu.
- Se i passi sopra sò cumpletati cù successu, l'utilizatore riceverà un missaghju cù u tempu apprussimativu di trasfurmazioni di l'imaghjini, chì hè calculatu basatu annantu à u numeru di tarei in a fila. Se si verifica un errore, l'utilizatore serà esplicitamente notificatu mandendu un missaghju cù l'infurmazioni nantu à ciò chì puderia esse sbagliatu.
Inoltre, stu microserviziu, cum'è un travagliu di l'api, sente à a fila "after_estimate", chì hè destinata à i travaglii chì anu passatu per u pipeline di valutazione.
Quandu riceve un novu compitu da "after_estimate":
- Se l'imaghjini hè trattatu bè, mandemu u risultatu à l'utilizatore; se no, avvisemu un errore.
- Eliminazione di l'imaghjini chì hè u risultatu di u pipeline di valutazione
Microserviziu di valutazione "attrai-estimator"
Stu microserviziu hè un travagliu di l'api è incapsula tuttu ciò chì hè ligatu à u pipeline di valutazione di l'imaghjini. Ci hè solu un algoritmu di travagliu quì - analizemu.
Quandu riceve un novu compitu da "to_estimate":
- Passemu l'imaghjini attraversu u pipeline di valutazione:
- Caricà l'imaghjini in memoria
- Purtemu l'imaghjini à a dimensione necessaria
- Truvà tutte e facce (MTCNN)
- Evaluemu tutte e facce (invecemu e facce truvate in l'ultimu passu in un batch è inferisce ResNet34)
- Rende l'immagine finale
- Disegnu i caselle di delimitazione
- Disegnu i valutazioni
- Eliminazione di una maghjina persunalizata (uriginale).
- Salvà l'output da u pipeline di valutazione
- Pudemu u compitu in a fila "after_estimate", chì hè intesu da u microserviziu "attrai-telegram-bot" discutitu sopra.
Graylog (+ mongoDB + Elasticsearch)
hè una suluzione per a gestione di log centralizata. In questu prughjettu, hè stata utilizata per u so propiu scopu.
A scelta hè cascata nantu à ellu, è micca nantu à u solitu stack, per via di a cunvenzione di travaglià cun ellu da Python. Tuttu ciò chì duvete fà per logu à Graylog hè di aghjunghje u GELFTCPHandler da u pacchettu à u restu di i gestori di root logger di u nostru microserviziu python.
Cum'è qualchissia chì avia travagliatu prima solu cù a pila ELK, aghju avutu una sperienza positiva generale mentre travagliava cù Graylog. L'unicu ciò chì hè deprimente hè a superiorità in e funzioni di Kibana nantu à l'interfaccia web Graylog.
Rabbit MQ
hè un broker di messagiu basatu annantu à u protocolu AMQP.
In questu prughjettu hè stata utilizata cum'è broker per Celery è hà travagliatu in modu durable.
Redis
hè un DBMS NoSQL chì travaglia cù strutture di dati chjave-valore
A volte ci hè bisognu di utilizà l'uggetti cumuni chì implementanu certe strutture di dati in diversi microservizi Python.
Per esempiu, Redis guarda un hashmap di a forma "telegram_user_id => nùmeru di attività attive in a fila", chì permette di limità u nùmeru di richieste da un utilizatore à un certu valore è, cusì, impediscenu l'attacchi DoS.
Furmalizemu u prucessu di trattamentu di l'imaghjini successu
- L'utilizatore manda una maghjina à u bot Telegram
- "attrai-telegram-bot" riceve un missaghju da l'API di Telegram è l'analiza
- U compitu cù l'imaghjini hè aghjuntu à a fila asincrona "to_estimate"
- L'utilizatore riceve un missaghju cù u tempu di valutazione pianificatu
- "attrai-estimator" piglia un compitu da a fila "to_estimate", esegue l'estimazioni attraversu u pipeline è pruduce u compitu in a fila "after_estimate"
- "attrai-telegram-bot" ascoltendu a fila "after_estimate", manda u risultatu à l'utilizatore
DevOps
Infine, dopu avè rivista l'architettura, pudete passà à a parte ugualmente interessante - DevOps
Sciame Docker
- un sistema di clustering, a so funziunalità hè implementata in Docker Engine è dispunibule fora di a scatula.
Utilizendu un "swarm", tutti i nodi in u nostru cluster pò esse divisu in 2 tipi - travagliadori è manager. Nant'à e macchine di u primu tipu, i gruppi di cuntenituri (pile) sò disposti, e macchine di u sicondu tipu sò rispunsevuli di scala, equilibriu è . I gestori sò ancu travagliadori per difettu.
Cluster cun un capu capu è trè travagliadori
A dimensione minima di u cluster pussibule hè 1 node; una sola macchina agirà simultaneamente cum'è un capu manager è un travagliadore. Basatu nantu à a dimensione di u prugettu è i requisiti minimi per a tolleranza di difetti, hè statu decisu di utilizà stu approcciu.
In u futuru, diceraghju chì da a prima consegna di produzzione, chì era à a mità di ghjugnu, ùn ci sò micca stati prublemi assuciati cù questa urganizazione di cluster (ma questu ùn significa micca chì una tale urganizazione hè in ogni modu accettabile in ogni mediu-grande). prughjetti, chì sò sottumessi à esigenze di tolleranza di colpa).
Docker Stack
In u modu swarm, hè rispunsevule per implementà pile (set di servizii docker)
Supporta e cunfigurazioni di docker-compose, chì vi permettenu di utilizà ancu i parametri di implementazione.
Per esempiu, utilizendu sti paràmetri, i risorse per ognuna di l'istanze di microserviziu di valutazione eranu limitati (allemu N core per N istanze, in u microserviziu stessu limitemu u numeru di core utilizati da PyTorch à unu)
attrai_estimator:
image: 'erqups/attrai_estimator:1.2'
deploy:
replicas: 4
resources:
limits:
cpus: '4'
restart_policy:
condition: on-failure
…Hè impurtante di nutà chì Redis, RabbitMQ è Graylog sò servizii stateful è ùn ponu micca scalate cum'è "attrai-estimator"
Foreshadowing the question - perchè micca Kubernetes?
Sembra chì l'usu di Kubernetes in prughjetti chjuchi è mediani hè un overhead; tutte e funziunalità necessarie ponu esse ottenute da Docker Swarm, chì hè abbastanza amichevule per un orchestratore di cuntainer è hà ancu una bassa barriera à l'ingressu.
Infrastruttura
Tuttu chistu hè statu implementatu in VDS cù e seguenti caratteristiche:
- CPU: 4 core Intel® Xeon® Gold 5120 CPU @ 2.20 GHz
- RAM: 8 GB
- SSD: 160 GB
Dopu a prova di carica lucale, pareva chì cù un afflussu seriu di utilizatori, sta macchina seria abbastanza.
Ma, subitu dopu à l'implementazione, aghju publicatu un ligame à unu di l'imaghjini più populari in u CIS (sì, quellu stessu), dopu chì a ghjente hè stata interessata è in uni pochi d'ora u serviziu hà trattatu successu decine di millaie d'imaghjini. À u listessu tempu, in i mumenti di punta, i risorse di CPU è RAM ùn eranu mancu a mità aduprate.
Qualchì più gràficu
Numeru di utilizatori unichi è richieste di valutazione da a implementazione, secondu u ghjornu
Distribuzione di u tempu di inferenza di pipeline di valutazione
scuperti
Per sintetizà, possu dì chì l'architettura è l'approcciu di l'orchestrazione di i cuntenituri si justificàvanu cumplettamente - ancu in i mumenti di punta ùn ci era micca gocce o sagging in u tempu di trasfurmazioni.
Pensu chì i prughjetti chjuchi è mediani chì utilizanu inferenza in tempu reale di e rete neurali nantu à u CPU in u so prucessu ponu aduttà cù successu e pratiche descritte in questu articulu.
Aghju aghjustatu chì inizialmente l'articulu era più longu, ma per ùn publicà una longa lettura, aghju decisu di omette alcuni punti in questu articulu - avemu da vultà à elli in publicazioni future.
Pudete chjappà u bot in Telegram - @AttraiBot, funziona almenu finu à a fine di u vaghjimu 2020. Permettemu di ricurdà chì nisuna dati di l'utilizatori sò almacenati - nè l'imaghjini originali, nè i risultati di u pipeline di valutazione - tuttu hè demolitu dopu a trasfurmazioni.
Source: www.habr.com