Vstup
Ahoj!
V tomto článku sa podelím o svoje skúsenosti s budovaním architektúry mikroslužieb pre projekt využívajúci neurónové siete.
Poďme sa porozprávať o požiadavkách na architektúru, pozrieť sa na rôzne štrukturálne schémy, analyzovať každý z komponentov hotovej architektúry a tiež zhodnotiť technické metriky riešenia.
Užite si čítanie!
Pár slov o probléme a jeho riešení
Hlavnou myšlienkou je zhodnotiť atraktivitu človeka na desaťbodovej škále na základe fotografie.
V tomto článku sa vzdialime od opisu ako použitých neurónových sietí, tak aj procesu prípravy a tréningu dát. V niektorej z nasledujúcich publikácií sa však určite vrátime k hĺbkovej analýze procesu hodnotenia.
Teraz prejdeme procesom hodnotenia na najvyššej úrovni a zameriame sa na interakciu mikroslužieb v kontexte celkovej architektúry projektu.
Pri práci na procese hodnotenia atraktivity bola úloha rozložená do nasledujúcich komponentov:
- Výber tvárí na fotografiách
- Hodnotenie každej osoby
- Vykreslite výsledok
Prvý je riešený silami vopred trénovaných . Po druhé, konvolučná neurónová sieť bola trénovaná na PyTorch pomocou – z rovnováhy „kvalita / rýchlosť odvodenia na CPU“
Funkčná schéma hodnotiaceho potrubia
Analýza požiadaviek na architektúru projektu
V životnom cykle fázy projektu práce na architektúre a automatizácii nasadzovania modelov často patria medzi časovo a zdrojovo najnáročnejšie.
Životný cyklus projektu ML
Tento projekt nie je výnimkou – bolo rozhodnuté zabaliť proces hodnotenia do online služby, čo si vyžadovalo ponoriť sa do architektúry. Boli identifikované tieto základné požiadavky:
- Jednotné ukladanie protokolov – všetky služby by mali zapisovať protokoly na jednom mieste, mali by sa dať pohodlne analyzovať
- Možnosť horizontálneho škálovania hodnotiacej služby - ako najpravdepodobnejšie úzke miesto
- Na vyhodnotenie každého obrázka by sa malo prideliť rovnaké množstvo zdrojov procesora, aby sa predišlo odľahlým hodnotám v distribúcii času na odvodenie.
- Rýchle (opätovné) nasadenie špecifických služieb aj zásobníka ako celku
- Schopnosť v prípade potreby používať spoločné objekty v rôznych službách
architektúra
Po analýze požiadaviek sa ukázalo, že architektúra mikroslužieb takmer dokonale zapadá.
Aby sme sa zbavili zbytočných bolestí hlavy, ako frontend bolo zvolené Telegram API.
Najprv sa pozrime na štrukturálny diagram hotovej architektúry, potom prejdeme k popisu každého z komponentov a tiež formalizujeme proces úspešného spracovania obrazu.
Štrukturálny diagram hotovej architektúry
Povedzme si podrobnejšie o každej zo zložiek diagramu a označme ich Single Responsibility v procese hodnotenia obrazu.
Mikroslužba „attrai-telegram-bot“
Táto mikroslužba zahŕňa všetky interakcie s Telegram API. Existujú 2 hlavné scenáre: práca s vlastným obrázkom a práca s výsledkom procesu hodnotenia. Pozrime sa na oba scenáre všeobecne.
Pri prijímaní vlastnej správy s obrázkom:
- Vykonáva sa filtrácia, ktorá pozostáva z týchto kontrol:
- Dostupnosť optimálnej veľkosti obrazu
- Počet obrázkov používateľov už vo fronte
- Pri prechode úvodným filtrovaním sa obrázok uloží do zväzku ukotvenia
- Vo fronte „to_estimate“ sa vytvorí úloha, ktorá okrem iného obsahuje cestu k obrázku nachádzajúcemu sa v našom zväzku
- Ak sú vyššie uvedené kroky úspešne dokončené, používateľ dostane správu s približným časom spracovania obrazu, ktorý sa vypočíta na základe počtu úloh vo fronte. Ak sa vyskytne chyba, používateľ bude výslovne upozornený odoslaním správy s informáciou o tom, čo sa mohlo pokaziť.
Aj táto mikroslužba, podobne ako zeler robotník, počúva frontu „after_estimate“, ktorá je určená pre úlohy, ktoré prešli procesom hodnotenia.
Pri prijatí novej úlohy z „after_estimate“:
- Ak je obrázok úspešne spracovaný, pošleme výsledok používateľovi, ak nie, upozorníme na chybu.
- Odstránenie obrázka, ktorý je výsledkom procesu hodnotenia
Hodnotiaca mikroslužba „attrai-estimator“
Táto mikroslužba pracuje so zelerom a zahŕňa všetko, čo súvisí s procesom vyhodnocovania obrázkov. Je tu len jeden funkčný algoritmus – poďme ho analyzovať.
Pri prijímaní novej úlohy od „to_estimate“:
- Spustite obrázok cez hodnotiaci kanál:
- Načítanie obrázka do pamäte
- Obrázok privedieme na požadovanú veľkosť
- Hľadanie všetkých tvárí (MTCNN)
- Vyhodnotíme všetky tváre (tváre nájdené v poslednom kroku zabalíme do dávky a odvodíme ResNet34)
- Vykreslite konečný obrázok
- Nakreslíme ohraničujúce rámčeky
- Kreslenie hodnotení
- Odstránenie vlastného (pôvodného) obrázka
- Uloženie výstupu z procesu hodnotenia
- Úlohu sme zaradili do frontu „after_estimate“, ktorý počúva vyššie uvedená mikroslužba „attrai-telegram-bot“.
Graylog (+ mongoDB + Elasticsearch)
je riešením pre centralizovanú správu protokolov. V tomto projekte bol použitý na zamýšľaný účel.
Voľba padla na neho, a nie na obyčajnú stack, kvôli pohodlnosti práce s ním z Pythonu. Všetko, čo musíte urobiť, aby ste sa prihlásili do Graylogu, je pridať GELFTCPHandler z balíka k zvyšku koreňových loggerov našej mikroslužby python.
Ako niekto, kto predtým pracoval iba s ELK stackom, som mal celkovo pozitívnu skúsenosť pri práci s Graylogom. Jediná vec, ktorá je deprimujúca, je nadradenosť funkcií Kibana nad webovým rozhraním Graylog.
RabbitMQ
je sprostredkovateľ správ založený na protokole AMQP.
V tomto projekte bol použitý ako maklér pre Zeler a pracoval v trvanlivom režime.
Redis
je NoSQL DBMS, ktorý pracuje s dátovými štruktúrami kľúč-hodnota
Niekedy je potrebné použiť bežné objekty, ktoré implementujú určité dátové štruktúry v rôznych mikroslužbách Pythonu.
Napríklad Redis ukladá hashmapu v tvare „telegram_user_id => počet aktívnych úloh vo fronte“, čo vám umožňuje obmedziť počet požiadaviek od jedného používateľa na určitú hodnotu, a tým zabrániť DoS útokom.
Poďme formalizovať proces úspešného spracovania obrazu
- Používateľ odošle obrázok robotovi Telegram
- „attrai-telegram-bot“ prijme správu z Telegram API a analyzuje ju
- Úloha s obrázkom sa pridá do asynchrónneho frontu „to_estimate“
- Používateľ dostane správu s plánovaným časom hodnotenia
- „attrai-estimator“ prevezme úlohu z frontu „to_estimate“, spustí odhady cez kanál a vytvorí úlohu do frontu „after_estimate“
- „attrai-telegram-bot“ počúvajúci front „after_estimate“ odošle výsledok používateľovi
DevOps
Nakoniec, po preskúmaní architektúry, môžete prejsť k nemenej zaujímavej časti – DevOps
Dockerov roj
— klastrovací systém, ktorého funkčnosť je implementovaná vo vnútri Docker Engine a je k dispozícii hneď po vybalení.
Pomocou „roja“ možno všetky uzly v našom klastri rozdeliť na 2 typy – pracovník a manažér. Na strojoch prvého typu sú nasadené skupiny kontajnerov (stohy), stroje druhého typu sú zodpovedné za škálovanie, vyvažovanie a . Manažéri sú tiež štandardne pracovníci.
Klaster s jedným vedúcim manažérom a tromi pracovníkmi
Minimálna možná veľkosť klastra je 1 uzol; jeden stroj bude súčasne pôsobiť ako vedúci manažér a pracovník. Na základe veľkosti projektu a minimálnych požiadaviek na odolnosť voči chybám bolo rozhodnuté použiť tento prístup.
Pri pohľade do budúcnosti poviem, že od prvej produkčnej dodávky, ktorá bola v polovici júna, sa nevyskytli žiadne problémy spojené s touto klastrovou organizáciou (to však neznamená, že takáto organizácia je akýmkoľvek spôsobom akceptovateľná v akejkoľvek stredne veľkej projekty, ktoré podliehajú požiadavkám na odolnosť proti chybám).
Docker Stack
V režime swarm je zodpovedný za nasadenie zásobníkov (súborov dockerových služieb)
Podporuje konfigurácie skladania dockerov, čo vám umožňuje dodatočne použiť možnosti nasadenia.
Napríklad pomocou týchto parametrov boli zdroje pre každú inštanciu vyhodnocovacej mikroslužby obmedzené (N jadier prideľujeme N inštanciám, v samotnej mikroslužbe obmedzíme počet jadier používaných PyTorchom na jedno)
attrai_estimator:
image: 'erqups/attrai_estimator:1.2'
deploy:
replicas: 4
resources:
limits:
cpus: '4'
restart_policy:
condition: on-failure
…Je dôležité poznamenať, že Redis, RabbitMQ a Graylog sú stavové služby a nemožno ich škálovať tak ľahko ako „attrai-estimator“
Predznamenáva otázku – prečo nie Kubernetes?
Zdá sa, že používanie Kubernetes v malých a stredne veľkých projektoch je réžia; všetky potrebné funkcie je možné získať z Docker Swarm, ktorý je pre kontajnerový orchestrátor celkom užívateľsky prívetivý a má tiež nízku bariéru vstupu.
Infraštruktúra
Toto všetko bolo nasadené na VDS s nasledujúcimi charakteristikami:
- CPU: 4-jadrový procesor Intel® Xeon® Gold 5120 @ 2.20 GHz
- RAM: 8 GB
- SSD: 160 GB
Po lokálnom záťažovom testovaní sa zdalo, že pri poriadnom návale používateľov bude tento stroj stačiť.
Hneď po nasadení som však zverejnil odkaz na jeden z najpopulárnejších obrázkových tabúľ v CIS (jupí, ten istý), po ktorom sa ľudia začali zaujímať a za pár hodín služba úspešne spracovala desaťtisíce obrázkov. Zároveň v špičkách neboli zdroje CPU a RAM využité ani na polovicu.
Ešte nejaká grafika
Počet jedinečných používateľov a žiadostí o hodnotenie od nasadenia v závislosti od dňa
Časová distribúcia inferencie hodnotiaceho potrubia
Závery
Aby som to zhrnul, môžem povedať, že architektúra a prístup k orchestrácii kontajnerov sa plne ospravedlňovali - ani v špičkách nedošlo k žiadnym poklesom alebo prepadom v čase spracovania.
Myslím si, že malé a stredné projekty, ktoré vo svojom procese využívajú inferenciu neurónových sietí na CPU v reálnom čase, môžu úspešne prijať postupy opísané v tomto článku.
Dodávam, že pôvodne bol článok dlhší, ale aby som nepridával dlhé čítanie, rozhodol som sa niektoré body v tomto článku vynechať - vrátime sa k nim v budúcich publikáciách.
Bota môžete popichať na Telegrame - @AttraiBot, bude fungovať minimálne do konca jesene 2020. Pripomínam, že sa neukladajú žiadne používateľské dáta – ani pôvodné obrázky, ani výsledky hodnotiaceho potrubia – všetko sa po spracovaní zdemoluje.
Zdroj: hab.com