Iscrizione
Hi!
In questo articolo condividerò la mia esperienza nella creazione di un'architettura di microservizi per un progetto utilizzando reti neurali.
Parliamo dei requisiti dell'architettura, esaminiamo i vari diagrammi strutturali, analizziamo ciascuno dei componenti dell'architettura finita e valutiamo anche le metriche tecniche della soluzione.
Buona lettura!
Qualche parola sul problema e sulla sua soluzione
L’idea principale è valutare l’attrattiva di una persona su una scala di dieci punti basata su una foto.
In questo articolo ci allontaneremo dalla descrizione sia delle reti neurali utilizzate sia del processo di preparazione e addestramento dei dati. Tuttavia, in una delle prossime pubblicazioni, torneremo sicuramente ad analizzare in modo approfondito la pipeline della valutazione.
Ora esamineremo la pipeline di valutazione al livello più alto e ci concentreremo sull'interazione dei microservizi nel contesto dell'architettura complessiva del progetto.
Quando si lavora sulla pipeline di valutazione dell'attrattiva, l'attività è stata scomposta nei seguenti componenti:
- Selezione dei volti nelle foto
- Valutazione di ogni persona
- Rendi il risultato
Il primo è risolto dalle forze pre-addestrate . Per il secondo, è stata addestrata una rete neurale convoluzionale su PyTorch, utilizzando – dal bilancio “qualità/velocità di inferenza sulla CPU”
Diagramma funzionale della pipeline di valutazione
Analisi dei requisiti dell'architettura del progetto
Nel ciclo di vita le fasi di lavoro del progetto sull'architettura e sull'automazione della distribuzione del modello sono spesso tra le più dispendiose in termini di tempo e risorse.
Ciclo di vita di un progetto ML
Questo progetto non fa eccezione: è stata presa la decisione di racchiudere la pipeline di valutazione in un servizio online, che ha richiesto di immergerci nell'architettura. Sono stati individuati i seguenti requisiti fondamentali:
- Archiviazione unificata dei log: tutti i servizi dovrebbero scrivere i log in un unico posto e dovrebbero essere facili da analizzare
- Possibilità di ridimensionamento orizzontale del servizio di valutazione - come il collo di bottiglia più probabile
- La stessa quantità di risorse del processore dovrebbe essere allocata per valutare ciascuna immagine al fine di evitare valori anomali nella distribuzione del tempo per l'inferenza
- (ri)distribuzione rapida sia di servizi specifici che dello stack nel suo insieme
- La capacità, se necessario, di utilizzare oggetti comuni in diversi servizi
Architettura
Dopo aver analizzato i requisiti, è risultato evidente che l’architettura dei microservizi si adatta quasi perfettamente.
Per eliminare inutili grattacapi, come frontend è stata scelta l'API di Telegram.
Per prima cosa, diamo un'occhiata al diagramma strutturale dell'architettura finita, quindi passiamo alla descrizione di ciascuno dei componenti e formalizziamo anche il processo di elaborazione delle immagini di successo.
Schema strutturale dell'architettura finita
Parliamo più in dettaglio di ciascuno dei componenti del diagramma, denotandoli Unica Responsabilità nel processo di valutazione dell'immagine.
Microservizio “attrai-telegram-bot”
Questo microservizio incapsula tutte le interazioni con l'API di Telegram. Esistono due scenari principali: lavorare con un'immagine personalizzata e lavorare con il risultato di una pipeline di valutazione. Consideriamo entrambi gli scenari in termini generali.
Quando ricevi un messaggio personalizzato con un'immagine:
- Viene eseguita la filtrazione, consistente nei seguenti controlli:
- Disponibilità di dimensioni immagine ottimali
- Numero di immagini utente già in coda
- Quando si supera il filtraggio iniziale, l'immagine viene salvata nel volume della finestra mobile
- Nella coda "to_estimate" viene prodotta un'attività che include, tra le altre cose, il percorso dell'immagine situata nel nostro volume
- Se i passaggi precedenti vengono completati correttamente, l'utente riceverà un messaggio con il tempo approssimativo di elaborazione dell'immagine, calcolato in base al numero di attività in coda. Se si verifica un errore, l'utente verrà avvisato esplicitamente inviando un messaggio con informazioni su cosa potrebbe essere andato storto.
Inoltre, questo microservizio, come un sedano, ascolta la coda "after_estimate", destinata alle attività che sono passate attraverso la pipeline di valutazione.
Quando si riceve una nuova attività da "after_estimate":
- Se l'immagine viene elaborata con successo, inviamo il risultato all'utente; in caso contrario, avvisiamo un errore.
- Rimozione dell'immagine che è il risultato della pipeline di valutazione
Microservizio di valutazione “attrai-estimator”
Questo microservizio è un celery work e incapsula tutto ciò che riguarda la pipeline di valutazione dell'immagine. C’è solo un algoritmo funzionante qui: analizziamolo.
Quando si riceve una nuova attività da "to_estimate":
- Eseguiamo l'immagine attraverso la pipeline di valutazione:
- Caricamento dell'immagine in memoria
- Portiamo l'immagine alla dimensione richiesta
- Trovare tutti i volti (MTCNN)
- Valutiamo tutte le facce (racchiudiamo le facce trovate nell'ultimo passaggio in un batch e inferenza ResNet34)
- Renderizza l'immagine finale
- Disegniamo i riquadri di delimitazione
- Disegnare le valutazioni
- Eliminazione di un'immagine personalizzata (originale).
- Salvataggio dell'output dalla pipeline di valutazione
- Inseriamo l'attività nella coda "after_estimate", che viene ascoltata dal microservizio "attrai-telegram-bot" discusso sopra.
Graylog (+ mongoDB + Elasticsearch)
è una soluzione per la gestione centralizzata dei log. In questo progetto è stato utilizzato per lo scopo previsto.
La scelta è caduta su di lui, e non sul solito stack, grazie alla comodità di lavorarci da Python. Tutto quello che devi fare per accedere a Graylog è aggiungere GELFTCPHandler dal pacchetto al resto dei gestori di root logger del nostro microservizio Python.
Essendo qualcuno che in precedenza aveva lavorato solo con lo stack ELK, ho avuto un'esperienza complessivamente positiva mentre lavoravo con Graylog. L'unica cosa deprimente è la superiorità delle funzionalità di Kibana rispetto all'interfaccia web di Graylog.
RabbitMQ
è un broker di messaggi basato sul protocollo AMQP.
In questo progetto è stato utilizzato come broker per Celery e ha lavorato in modalità durevole.
Redis
è un DBMS NoSQL che funziona con strutture di dati chiave-valore
A volte è necessario utilizzare oggetti comuni che implementano determinate strutture dati in diversi microservizi Python.
Ad esempio, Redis memorizza una hashmap nel formato "telegram_user_id => numero di attività attive in coda", che consente di limitare il numero di richieste di un utente a un determinato valore e, quindi, prevenire attacchi DoS.
Formalizziamo il processo di elaborazione delle immagini di successo
- L'utente invia un'immagine al bot di Telegram
- "attrai-telegram-bot" riceve un messaggio dall'API di Telegram e lo analizza
- L'attività con l'immagine viene aggiunta alla coda asincrona “to_estimate”
- L'utente riceve un messaggio con il tempo di valutazione pianificato
- “attrai-estimator” prende un'attività dalla coda “to_estimate”, esegue le stime attraverso la pipeline e produce l'attività nella coda “after_estimate”
- "attrai-telegram-bot" ascoltando la coda "after_estimate", invia il risultato all'utente
DevOps
Infine, dopo aver esaminato l'architettura, puoi passare alla parte altrettanto interessante: DevOps
Sciame portuale
— un sistema di clustering, la cui funzionalità è implementata all'interno del Docker Engine ed è disponibile immediatamente.
Utilizzando uno "sciame", tutti i nodi nel nostro cluster possono essere divisi in 2 tipi: lavoratore e manager. Sulle macchine del primo tipo vengono distribuiti gruppi di contenitori (stack), le macchine del secondo tipo sono responsabili del ridimensionamento, del bilanciamento e . I manager sono anche lavoratori per impostazione predefinita.
Cluster con un manager leader e tre lavoratori
La dimensione minima possibile del cluster è 1 nodo; una singola macchina fungerà contemporaneamente da leader manager e lavoratore. In base alle dimensioni del progetto e ai requisiti minimi di tolleranza agli errori, si è deciso di utilizzare questo approccio.
Guardando al futuro dirò che sin dalla prima consegna produttiva, avvenuta a metà giugno, non si sono verificati problemi legati a questa organizzazione a cluster (ma questo non vuol dire che tale organizzazione sia in alcun modo accettabile in realtà medio-grandi) progetti soggetti a requisiti di tolleranza agli errori).
Pila Docker
In modalità sciame, è responsabile della distribuzione degli stack (insiemi di servizi docker)
Supporta le configurazioni docker-compose, consentendoti di utilizzare anche le opzioni di distribuzione.
Ad esempio, utilizzando questi parametri, le risorse per ciascuna delle istanze del microservizio di valutazione erano limitate (assegniamo N core per N istanze, nel microservizio stesso limitiamo a uno il numero di core utilizzati da PyTorch)
attrai_estimator:
image: 'erqups/attrai_estimator:1.2'
deploy:
replicas: 4
resources:
limits:
cpus: '4'
restart_policy:
condition: on-failure
…È importante notare che Redis, RabbitMQ e Graylog sono servizi con stato e non possono essere scalati così facilmente come “attrai-estimator”
Prefigurando la domanda: perché non Kubernetes?
Sembra che l'utilizzo di Kubernetes in progetti di piccole e medie dimensioni sia un sovraccarico; tutte le funzionalità necessarie possono essere ottenute da Docker Swarm, che è abbastanza facile da usare per un orchestratore di container e ha anche una bassa barriera all'ingresso.
infrastruttura
Il tutto è stato implementato su VDS con le seguenti caratteristiche:
- CPU: CPU Intel® Xeon® Gold 4 a 5120 core a 2.20 GHz
- RAM: 8 GB
- Unità SSD: 160GB
Dopo i test di carico locale, sembrava che con un serio afflusso di utenti questa macchina sarebbe stata sufficiente.
Ma, subito dopo l'implementazione, ho pubblicato un collegamento a una delle imageboard più popolari nella CSI (sì, proprio quella), dopo di che le persone si sono interessate e in poche ore il servizio ha elaborato con successo decine di migliaia di immagini. Allo stesso tempo, nei momenti di punta, le risorse CPU e RAM non venivano utilizzate nemmeno la metà.
Ancora qualche grafica
Numero di utenti univoci e richieste di valutazione dalla distribuzione, a seconda del giorno
Distribuzione temporale di inferenza della pipeline di valutazione
risultati
Riassumendo, posso dire che l'architettura e l'approccio all'orchestrazione dei contenitori si sono pienamente giustificati: anche nei momenti di punta non si sono verificati cali o cali nei tempi di elaborazione.
Penso che i progetti di piccole e medie dimensioni che utilizzano l'inferenza in tempo reale delle reti neurali sulla CPU nel loro processo possano adottare con successo le pratiche descritte in questo articolo.
Aggiungo che inizialmente l'articolo era più lungo, ma per non pubblicare una lettura lunga, ho deciso di omettere alcuni punti di questo articolo: li ritorneremo nelle prossime pubblicazioni.
Puoi fare un poke al bot su Telegram - @AttraiBot, funzionerà almeno fino alla fine dell'autunno 2020. Lascia che ti ricordi che nessun dato utente viene memorizzato, né le immagini originali, né i risultati della pipeline di valutazione: tutto viene demolito dopo l'elaborazione.
Fonte: habr.com