Toegang
Hey there!
In dit artikel zal ik mijn ervaring delen met het bouwen van een microservice-architectuur voor een project met behulp van neurale netwerken.
Laten we het hebben over de architectuurvereisten, verschillende structurele diagrammen bekijken, elk van de componenten van de voltooide architectuur analyseren en ook de technische statistieken van de oplossing evalueren.
Veel leesplezier!
Een paar woorden over het probleem en de oplossing ervan
Het belangrijkste idee is om de aantrekkelijkheid van een persoon te beoordelen op een schaal van tien punten op basis van een foto.
In dit artikel zullen we afstappen van het beschrijven van zowel de gebruikte neurale netwerken als het proces van datavoorbereiding en -training. In een van de volgende publicaties zullen we echter zeker terugkeren naar een diepgaande analyse van de beoordelingspijplijn.
Nu zullen we de evaluatiepijplijn op het hoogste niveau doorlopen en ons concentreren op de interactie van microservices in de context van de algehele projectarchitectuur.
Bij het werken aan de pijplijn voor het beoordelen van de aantrekkelijkheid werd de taak opgesplitst in de volgende componenten:
- Gezichten in foto's selecteren
- Beoordeling van elke persoon
- Geef het resultaat weer
De eerste wordt opgelost door de krachten van vooraf getrainde krachten . Voor de tweede werd een convolutioneel neuraal netwerk getraind op PyTorch, met behulp van – uit de balans “kwaliteit / snelheid van gevolgtrekking op de CPU”
Functioneel diagram van de evaluatiepijplijn
Analyse van de vereisten voor projectarchitectuur
In de levenscyclus projectfasen van het werk aan de architectuur en automatisering van de implementatie van modellen behoren vaak tot de meest tijdrovende en resource-intensieve fasen.
Levenscyclus van een ML-project
Dit project vormt daarop geen uitzondering: er werd besloten om de beoordelingspijplijn in een online service te verwerken, waarvoor we ons in de architectuur moesten verdiepen. De volgende basisvereisten werden geïdentificeerd:
- Uniforme logopslag – alle services moeten logs op één plek schrijven, ze moeten gemakkelijk te analyseren zijn
- Mogelijkheid tot horizontale schaalvergroting van de assessmentdienst – als meest waarschijnlijke knelpunt
- Dezelfde hoeveelheid processorbronnen moet worden toegewezen om elk beeld te evalueren om uitschieters in de verdeling van de tijd voor gevolgtrekking te voorkomen
- Snelle (her)implementatie van zowel specifieke diensten als de stack als geheel
- De mogelijkheid om, indien nodig, gemeenschappelijke objecten in verschillende services te gebruiken
Architectuur
Na analyse van de vereisten werd het duidelijk dat de microservice-architectuur vrijwel perfect past.
Om onnodige kopzorgen weg te nemen, werd gekozen voor de Telegram API als frontend.
Laten we eerst eens kijken naar het structurele diagram van de voltooide architectuur, dan verder gaan met een beschrijving van elk van de componenten, en ook het proces van succesvolle beeldverwerking formaliseren.
Structureel diagram van de voltooide architectuur
Laten we meer in detail praten over elk van de componenten van het diagram, waarbij we ze de enkele verantwoordelijkheid in het proces van beeldevaluatie aanduiden.
Microservice “attrai-telegram-bot”
Deze microservice omvat alle interacties met de Telegram API. Er zijn 2 hoofdscenario's: werken met een aangepaste afbeelding en werken met het resultaat van een beoordelingspijplijn. Laten we beide scenario’s in algemene termen bekijken.
Wanneer u een aangepast bericht met een afbeelding ontvangt:
- Er wordt een filtratie uitgevoerd, bestaande uit de volgende controles:
- Beschikbaarheid van optimale afbeeldingsgrootte
- Aantal gebruikersafbeeldingen dat al in de wachtrij staat
- Wanneer de initiële filtering wordt doorstaan, wordt de afbeelding opgeslagen in het dockervolume
- Er wordt een taak geproduceerd in de wachtrij "to_ estimate", die onder andere het pad naar de afbeelding in ons volume bevat
- Als de bovenstaande stappen succesvol zijn voltooid, ontvangt de gebruiker een bericht met de geschatte beeldverwerkingstijd, die wordt berekend op basis van het aantal taken in de wachtrij. Als er een fout optreedt, wordt de gebruiker expliciet op de hoogte gebracht door een bericht te sturen met informatie over wat er mogelijk mis is gegaan.
Bovendien luistert deze microservice, net als een selderijwerker, naar de wachtrij ‘after_ estimate’, die bedoeld is voor taken die door de evaluatiepijplijn zijn gegaan.
Wanneer u een nieuwe taak ontvangt van “after_ estimate”:
- Als de afbeelding succesvol is verwerkt, sturen we het resultaat naar de gebruiker; zo niet, dan melden we een fout.
- Het verwijderen van de afbeelding die het resultaat is van de evaluatiepijplijn
Evaluatie microservice “attrai-schatter”
Deze microservice is een selderijwerker en omvat alles wat te maken heeft met de pijplijn voor beeldevaluatie. Er is hier maar één werkend algoritme – laten we het analyseren.
Wanneer u een nieuwe taak ontvangt van “to_ estimate”:
- Laten we de afbeelding door de evaluatiepijplijn laten lopen:
- De afbeelding in het geheugen laden
- Wij brengen de afbeelding op het gewenste formaat
- Alle gezichten zoeken (MTCNN)
- We evalueren alle gezichten (we verpakken de gezichten gevonden in de laatste stap in een batch en leiden ResNet34 af)
- Geef de uiteindelijke afbeelding weer
- Laten we de selectiekaders tekenen
- Het tekenen van de beoordelingen
- Een aangepaste (originele) afbeelding verwijderen
- De uitvoer van de evaluatiepijplijn opslaan
- We plaatsen de taak in de wachtrij ‘after_ estimate’, waarnaar wordt geluisterd door de hierboven besproken microservice ‘attrai-telegram-bot’.
Graylog (+ mongoDB + Elasticsearch)
is een oplossing voor gecentraliseerd logbeheer. In dit project werd het gebruikt waarvoor het bedoeld was.
De keuze viel op hem, en niet op de gebruikelijke stack, vanwege het gemak om ermee vanuit Python te werken. Het enige wat u hoeft te doen om in te loggen bij Graylog is het toevoegen van de GELFTCPHandler uit het pakket aan de rest van de rootlogger-handlers van onze Python-microservice.
Als iemand die voorheen alleen met de ELK-stack had gewerkt, had ik over het algemeen een positieve ervaring tijdens het werken met Graylog. Het enige dat deprimerend is, is de superioriteit van Kibana-functies ten opzichte van de Graylog-webinterface.
RabbitMQ
is een berichtenmakelaar gebaseerd op het AMQP-protocol.
In dit project werd het gebruikt als makelaar voor Celery en werkte in duurzame modus.
Redis
is een NoSQL DBMS dat werkt met sleutelwaardedatastructuren
Soms is het nodig om gemeenschappelijke objecten te gebruiken die bepaalde datastructuren in verschillende Python-microservices implementeren.
Redis slaat bijvoorbeeld een hashmap op in de vorm “telegram_user_id => aantal actieve taken in de wachtrij”, waarmee u het aantal verzoeken van één gebruiker tot een bepaalde waarde kunt beperken en daarmee DoS-aanvallen kunt voorkomen.
Laten we het proces van succesvolle beeldverwerking formaliseren
- De gebruiker stuurt een afbeelding naar de Telegram-bot
- "attrai-telegram-bot" ontvangt een bericht van de Telegram API en parseert het
- De taak met de afbeelding wordt toegevoegd aan de asynchrone wachtrij “to_ estimate”
- De gebruiker ontvangt een bericht met het geplande evaluatietijdstip
- “attrai-estimator” neemt een taak uit de wachtrij “to_schatting”, voert de schattingen door de pijplijn en produceert de taak in de wachtrij “na_schatting”
- "attrai-telegram-bot" luistert naar de wachtrij "after_ estimate" en stuurt het resultaat naar de gebruiker
DevOps
Ten slotte kunt u, na het bekijken van de architectuur, doorgaan naar het even interessante deel: DevOps
Docker Zwerm
— een clusteringsysteem waarvan de functionaliteit is geïmplementeerd in de Docker Engine en out-of-the-box beschikbaar is.
Met behulp van een “zwerm” kunnen alle knooppunten in ons cluster in 2 typen worden verdeeld: werknemer en manager. Op machines van het eerste type worden groepen containers (stacks) ingezet, machines van het tweede type zijn verantwoordelijk voor het schalen, balanceren en . Managers zijn ook per definitie werknemers.
Cluster met één leidersmanager en drie werknemers
De minimaal mogelijke clustergrootte is 1 knooppunt; een enkele machine fungeert tegelijkertijd als leidermanager en als werker. Op basis van de omvang van het project en de minimale eisen aan fouttolerantie werd besloten om deze aanpak te gebruiken.
Vooruitkijkend kan ik zeggen dat er sinds de eerste productieoplevering, medio juni, geen problemen zijn geweest in verband met deze clusterorganisatie (maar dit betekent niet dat een dergelijke organisatie op enigerlei wijze acceptabel is in een middelgroot bedrijf). projecten, waarvoor fouttolerantie-eisen gelden).
Docker-stack
In de zwermmodus is hij verantwoordelijk voor het inzetten van stapels (sets van docker-services)
Het ondersteunt docker-compose-configuraties, waardoor u bovendien implementatieopties kunt gebruiken.
Met behulp van deze parameters waren de bronnen voor elk van de evaluatie-microservice-instanties bijvoorbeeld beperkt (we wijzen N cores toe voor N instances, in de microservice zelf beperken we het aantal cores dat door PyTorch wordt gebruikt tot één)
attrai_estimator:
image: 'erqups/attrai_estimator:1.2'
deploy:
replicas: 4
resources:
limits:
cpus: '4'
restart_policy:
condition: on-failure
…Het is belangrijk op te merken dat Redis, RabbitMQ en Graylog stateful services zijn en niet zo eenvoudig kunnen worden geschaald als “attrai-estimator”
Een voorafschaduwing van de vraag: waarom niet Kubernetes?
Het lijkt erop dat het gebruik van Kubernetes in kleine en middelgrote projecten een overhead is; alle benodigde functionaliteit kan worden verkregen uit Docker Swarm, dat vrij gebruiksvriendelijk is voor een containerorkestrator en bovendien een lage toegangsdrempel kent.
Infrastructuur
Dit alles werd ingezet op VDS met de volgende kenmerken:
- CPU: 4-core Intel® Xeon® Gold 5120 CPU @ 2.20 GHz
- RAM: 8 GB
- SSD: 160GB
Na lokale belastingtests leek het erop dat deze machine bij een serieuze toestroom van gebruikers voldoende zou zijn.
Maar onmiddellijk na de implementatie plaatste ik een link naar een van de populairste imageboards in het CIS (ja, diezelfde), waarna mensen geïnteresseerd raakten en binnen een paar uur verwerkte de service met succes tienduizenden afbeeldingen. Tegelijkertijd werden op piekmomenten de CPU- en RAM-bronnen niet eens voor de helft gebruikt.
Nog wat grafische afbeeldingen
Aantal unieke gebruikers en evaluatieverzoeken sinds de implementatie, afhankelijk van de dag
Evaluatiepijplijn-inferentietijdverdeling
Bevindingen
Samenvattend kan ik zeggen dat de architectuur en de aanpak van de orkestratie van containers zichzelf volledig rechtvaardigden - zelfs op piekmomenten was er geen sprake van dalingen of verzakkingen in de verwerkingstijd.
Ik denk dat kleine en middelgrote projecten die in hun proces gebruik maken van real-time inferentie van neurale netwerken op de CPU, met succes de praktijken kunnen overnemen die in dit artikel worden beschreven.
Ik zal hieraan toevoegen dat het artikel aanvankelijk langer was, maar om geen longread te plaatsen, heb ik besloten enkele punten in dit artikel weg te laten - we komen er in toekomstige publicaties op terug.
Je kunt de bot porren op Telegram - @AttraiBot, hij werkt in ieder geval tot eind herfst 2020. Ik wil u eraan herinneren dat er geen gebruikersgegevens worden opgeslagen - noch de originele afbeeldingen, noch de resultaten van de evaluatiepijplijn - alles wordt na verwerking gesloopt.
Bron: www.habr.com