Vstup
Ahoj!
V tomto článku se podělím o své zkušenosti s budováním architektury mikroslužeb pro projekt využívající neuronové sítě.
Promluvme si o požadavcích na architekturu, podívejme se na různá strukturální schémata, analyzujme každý z komponent hotové architektury a také zhodnoťme technické metriky řešení.
Užijte si čtení!
Pár slov o problému a jeho řešení
Hlavní myšlenkou je vyhodnotit atraktivitu člověka na desetibodové škále na základě fotografie.
V tomto článku se vzdáme popisu jak používaných neuronových sítí, tak procesu přípravy a trénování dat. V některé z následujících publikací se však určitě vrátíme k podrobné analýze procesu hodnocení.
Nyní projdeme procesem hodnocení na nejvyšší úrovni a zaměříme se na interakci mikroslužeb v kontextu celkové architektury projektu.
Při práci na kanálu hodnocení atraktivity byl úkol rozložen do následujících složek:
- Výběr tváří na fotografiích
- Hodnocení každého člověka
- Vykreslete výsledek
První je řešena silami předem vycvičených . Za druhé byla konvoluční neuronová síť trénována na PyTorch pomocí – z rovnováhy „kvalita / rychlost odvození na CPU“
Funkční schéma vyhodnocovacího potrubí
Analýza požadavků na architekturu projektu
V životním cyklu fáze projektu, práce na architektuře a automatizaci nasazení modelu patří často k časově nejnáročnějším a nejnáročnějším na zdroje.
Životní cyklus projektu ML
Tento projekt není výjimkou – bylo rozhodnuto zabalit proces hodnocení do online služby, což vyžadovalo ponořit se do architektury. Byly stanoveny následující základní požadavky:
- Jednotné úložiště logů – všechny služby by měly zapisovat logy na jednom místě, měly by být pohodlné pro analýzu
- Možnost horizontálního škálování hodnotící služby - jako nejpravděpodobnější Úzké místo
- Pro vyhodnocení každého obrázku by mělo být přiděleno stejné množství procesorových zdrojů, aby se předešlo odlehlým hodnotám v rozložení času pro odvození
- Rychlé (znovu) nasazení jak konkrétních služeb, tak zásobníku jako celku
- Schopnost v případě potřeby používat společné objekty v různých službách
architektura
Po analýze požadavků se ukázalo, že architektura mikroslužeb téměř dokonale zapadá.
Abychom se zbavili zbytečných bolestí hlavy, bylo jako frontend zvoleno Telegram API.
Nejprve se podívejme na strukturální schéma hotové architektury, poté přejdeme k popisu každé z komponent a také formalizujeme proces úspěšného zpracování obrazu.
Strukturální schéma hotové architektury
Promluvme si podrobněji o každé ze složek diagramu a označme je Single Responsibility v procesu hodnocení obrazu.
Mikroslužba „attrai-telegram-bot“
Tato mikroslužba zapouzdřuje všechny interakce s Telegram API. Existují 2 hlavní scénáře: práce s vlastním obrázkem a práce s výsledkem hodnotícího kanálu. Podívejme se na oba scénáře obecně.
Při přijímání vlastní zprávy s obrázkem:
- Provádí se filtrace, která se skládá z následujících kontrol:
- Dostupnost optimální velikosti obrazu
- Počet uživatelských obrázků již ve frontě
- Při absolvování počátečního filtrování se obrázek uloží do svazku ukotvitelného panelu
- Ve frontě „to_estimate“ je vytvořen úkol, který mimo jiné obsahuje cestu k obrázku umístěnému v našem svazku
- Pokud jsou výše uvedené kroky úspěšně dokončeny, uživatel obdrží zprávu s přibližnou dobou zpracování obrazu, která se počítá na základě počtu úloh ve frontě. Pokud dojde k chybě, bude uživatel výslovně upozorněn zasláním zprávy s informací o tom, co se mohlo pokazit.
Také tato mikroslužba, stejně jako dělník celeru, naslouchá frontě „after_estimate“, která je určena pro úkoly, které prošly procesem hodnocení.
Při příjmu nového úkolu z „after_estimate“:
- V případě úspěšného zpracování obrázku odešleme výsledek uživateli, pokud ne, upozorníme na chybu.
- Odstranění obrázku, který je výsledkem procesu hodnocení
Hodnotící mikroslužba „attrai-estimator“
Tato mikroslužba je celer worker a zapouzdřuje vše, co souvisí s procesem hodnocení obrazu. Je zde pouze jeden funkční algoritmus – pojďme ho analyzovat.
Při příjmu nového úkolu od „to_estimate“:
- Proveďme obrázek hodnotícím kanálem:
- Načítání obrázku do paměti
- Obrázek přivedeme na požadovanou velikost
- Hledání všech tváří (MTCNN)
- Vyhodnotíme všechny tváře (obličeje nalezené v posledním kroku zabalíme do dávky a odvodíme ResNet34)
- Vykreslete konečný obrázek
- Nakreslíme ohraničující rámečky
- Kreslení hodnocení
- Smazání vlastního (původního) obrázku
- Uložení výstupu z kanálu hodnocení
- Úkol jsme zařadili do fronty „after_estimate“, kterou poslouchá výše zmíněná mikroslužba „attrai-telegram-bot“.
Graylog (+ mongoDB + Elasticsearch)
je řešení pro centralizovanou správu protokolů. V tomto projektu byl použit k zamýšlenému účelu.
Volba padla na něj, a ne na tu obvyklou zásobníku, kvůli pohodlí práce s ním z Pythonu. Vše, co musíte udělat pro přihlášení do Graylog, je přidat GELFTCPHandler z balíčku na zbytek obslužných programů root logger naší mikroslužby python.
Jako někdo, kdo dříve pracoval pouze se stackem ELK, jsem měl při práci s Graylogem celkově pozitivní zkušenost. Jediná věc, která je depresivní, je převaha funkcí Kibana nad webovým rozhraním Graylog.
RabbitMQ
je zprostředkovatel zpráv založený na protokolu AMQP.
V tomto projektu byl použit jako broker pro celer a pracoval v trvanlivém režimu.
Redestilát
je NoSQL DBMS, který pracuje s datovými strukturami klíč-hodnota
Někdy je potřeba použít běžné objekty, které implementují určité datové struktury v různých mikroslužbách Pythonu.
Redis například ukládá hashmapu ve tvaru „telegram_user_id => počet aktivních úloh ve frontě“, což vám umožňuje omezit počet požadavků od jednoho uživatele na určitou hodnotu, a tím zabránit DoS útokům.
Pojďme formalizovat proces úspěšného zpracování obrazu
- Uživatel odešle obrázek robotovi Telegram
- "attrai-telegram-bot" přijme zprávu z Telegram API a analyzuje ji
- Úloha s obrázkem je přidána do asynchronní fronty „to_estimate“
- Uživatel obdrží zprávu s plánovaným časem vyhodnocení
- „attrai-estimator“ převezme úlohu z fronty „to_estimate“, spustí odhady v potrubí a vytvoří úlohu do fronty „after_estimate“
- „attrai-telegram-bot“ naslouchající frontě „after_estimate“ odešle výsledek uživateli
devops
Nakonec, po prostudování architektury, můžete přejít k neméně zajímavé části – DevOps
Docker roj
— klastrovací systém, jehož funkčnost je implementována uvnitř Docker Engine a je k dispozici ihned po vybalení.
Pomocí „roje“ lze všechny uzly v našem clusteru rozdělit na 2 typy – pracovník a manažer. Na strojích prvního typu jsou nasazeny skupiny kontejnerů (stohy), stroje druhého typu zodpovídají za škálování, vyvažování a . Manažeři jsou ve výchozím nastavení také pracovníci.
Cluster s jedním vedoucím manažerem a třemi pracovníky
Minimální možná velikost clusteru je 1 uzel; jeden stroj bude současně fungovat jako vedoucí manažer a pracovník. Na základě velikosti projektu a minimálních požadavků na odolnost proti chybám bylo rozhodnuto použít tento přístup.
Výhledově řeknu, že od první produkční dodávky, která byla v polovině června, nebyly s touto klastrovou organizací spojeny žádné problémy (to ale neznamená, že taková organizace je v nějakém středně velkém projekty, které podléhají požadavkům na odolnost proti chybám).
Docker Stack
V režimu swarm je zodpovědný za rozmístění stacků (sad dockerových služeb)
Podporuje konfigurace docker-compose, což vám umožňuje dodatečně používat parametry nasazení.
Například pomocí těchto parametrů byly omezeny zdroje pro každou z instancí vyhodnocovací mikroslužby (alokujeme N jader pro N instancí, v samotné mikroslužbě omezíme počet jader používaných PyTorchem 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é poznamenat, že Redis, RabbitMQ a Graylog jsou stavové služby a nelze je škálovat tak snadno jako „attrai-estimator“
Předznamenává otázku – proč ne Kubernetes?
Zdá se, že používání Kubernetes v malých a středně velkých projektech je režie, všechny potřebné funkce lze získat z Docker Swarm, který je pro orchestrátor kontejnerů uživatelsky docela přívětivý a má také nízkou bariéru vstupu.
infrastruktura
To vše bylo nasazeno na VDS s následujícími vlastnostmi:
- CPU: 4jádrový procesor Intel® Xeon® Gold 5120 @ 2.20 GHz
- RAM: 8 GB
- SSD: 160 GB
Po lokálním zátěžovém testování se zdálo, že při pořádném návalu uživatelů bude tento stroj stačit.
Ale hned po nasazení jsem zveřejnil odkaz na jeden z nejpopulárnějších imageboardů v CIS (jupí, ten stejný), načež se lidé začali zajímat a za pár hodin služba úspěšně zpracovala desítky tisíc obrázků. Ve špičkách přitom nebyly zdroje CPU a RAM využity ani z poloviny.
Ještě nějaká grafika
Počet unikátních uživatelů a požadavků na hodnocení od nasazení v závislosti na dni
Časové rozložení odvození hodnocení potrubí
Závěry
Abych to shrnul, mohu říci, že architektura a přístup k orchestraci kontejnerů se plně osvědčily - ani ve špičkách nedocházelo k žádným propadům nebo propadům v době zpracování.
Domnívám se, že malé a střední projekty, které ve svém procesu využívají odvozování neuronových sítí na CPU v reálném čase, mohou úspěšně převzít postupy popsané v tomto článku.
Dodávám, že původně byl článek delší, ale abych nepřidával dlouhé čtení, rozhodl jsem se některé body v tomto článku vynechat – vrátíme se k nim v budoucích publikacích.
Bota můžete šťourat na Telegramu - @AttraiBot, bude fungovat minimálně do konce podzimu 2020. Připomínám, že se neukládají žádná uživatelská data – ani původní snímky, ani výsledky hodnotícího potrubí – vše je po zpracování zdemolováno.
Zdroj: www.habr.com