Belépés
Hi!
Ebben a cikkben megosztom tapasztalataimat egy neurális hálózatokat használó projekt mikroszolgáltatási architektúrájának felépítéséről.
Beszéljünk az architektúra követelményeiről, nézzünk meg különféle szerkezeti diagramokat, elemezzük a kész architektúra egyes összetevőit, és értékeljük a megoldás műszaki mérőszámait is.
Élvezd az olvasást!
Néhány szó a problémáról és annak megoldásáról
A fő gondolat az, hogy egy fénykép alapján értékeljük egy személy vonzerejét egy tízfokú skálán.
Ebben a cikkben eltávolodunk a használt neurális hálózatok és az adatok előkészítésének és betanításának folyamatától. A következő kiadványok egyikében azonban mindenképpen visszatérünk az értékelési folyamat mélyreható elemzéséhez.
Most a legfelső szintű értékelési folyamaton megyünk keresztül, és a mikroszolgáltatások interakciójára fogunk összpontosítani a teljes projektarchitektúra összefüggésében.
A vonzerőértékelési folyamat során a feladatot a következő összetevőkre bontották:
- Arcok kiválasztása a fényképeken
- Minden személy értékelése
- Rendelje meg az eredményt
Az elsőt az előre kiképzett erők oldják meg . A másodikhoz egy konvolúciós neurális hálózatot tanítottak meg PyTorch-on, a segítségével – a „CPU-n a következtetés minősége/sebessége” mérlegből
Az értékelési folyamat diagramja
Projektarchitektúra követelményeinek elemzése
Az életciklusban A modelltelepítés architektúrájával és automatizálásával kapcsolatos munka projektszakaszai gyakran a legidő- és erőforrás-igényesebbek közé tartoznak.
Egy ML projekt életciklusa
Ez a projekt sem kivétel – az a döntés született, hogy az értékelési folyamatot egy online szolgáltatásba csomagoljuk, amihez el kellett merülnünk az architektúrában. A következő alapvető követelményeket határozták meg:
- Egységes naplótárolás – minden szolgáltatásnak egy helyen kell naplót írnia, kényelmesen elemezhetőnek kell lennie
- Az értékelési szolgáltatás horizontális skálázásának lehetősége - mint a legvalószínűbb szűk keresztmetszet
- Ugyanannyi processzorerőforrást kell lefoglalni minden egyes kép kiértékeléséhez, hogy elkerüljük a következtetések levonási idejének eloszlását.
- Az egyes szolgáltatások és a verem egészének gyors (újra)telepítése
- Az a képesség, hogy szükség esetén közös objektumokat használjunk különböző szolgáltatásokban
építészet
A követelmények elemzése után nyilvánvalóvá vált, hogy a mikroszolgáltatási architektúra szinte tökéletesen illeszkedik.
A felesleges fejfájások elkerülése érdekében a Telegram API-t választották frontendnek.
Először nézzük meg a kész architektúra szerkezeti diagramját, majd térjünk át az egyes komponensek leírására, és formalizáljuk a sikeres képfeldolgozás folyamatát is.
Az elkészült építészet szerkezeti diagramja
Beszéljünk részletesebben a diagram egyes összetevőiről, jelölve őket Egyedülálló felelősség a képértékelés folyamatában.
Mikroszolgáltatás „attrai-telegram-bot”
Ez a mikroszolgáltatás magába foglalja a Telegram API-val való összes interakciót. Két fő forgatókönyv létezik: egyéni képfájllal és egy értékelési folyamat eredményével való munka. Nézzük mindkét forgatókönyvet általánosságban.
Ha egyéni üzenetet kap képpel:
- A szűrés a következő ellenőrzésekből áll:
- Optimális képméret elérhetősége
- A már sorban álló felhasználói képek száma
- A kezdeti szűrés átadásakor a kép a docker kötetbe kerül mentésre
- A „to_estimate” sorban egy feladat jön létre, amely többek között tartalmazza a kötetünkben található kép elérési útját
- A fenti lépések sikeres végrehajtása esetén a felhasználó üzenetet kap a hozzávetőleges képfeldolgozási idővel, amelyet a sorban lévő feladatok száma alapján számítanak ki. Ha hiba történik, a felhasználó kifejezetten értesítést kap egy üzenet elküldésével arról, hogy mi lehetett a hiba.
Ezenkívül ez a mikroszolgáltatás, mint egy zeller, figyel az „after_estimate” sorra, amely az értékelési folyamaton áthaladt feladatokhoz készült.
Amikor új feladatot kap az „af_estimate”-től:
- Sikeres képfeldolgozás esetén az eredményt elküldjük a felhasználónak, ha nem, hibajelzést küldünk.
- A kiértékelési folyamat eredményeként létrejött kép eltávolítása
Értékelési mikroszolgáltatás „attrai-estimator”
Ez a mikroszolgáltatás egy zellermunkás, és mindent magába foglal, ami a képértékelési folyamattal kapcsolatos. Itt csak egy működő algoritmus van – elemezzük azt.
Amikor új feladatot kap a „to_estimate”-től:
- Futtassuk át a képet az értékelési folyamaton:
- A kép betöltése a memóriába
- A képet a kívánt méretre hozzuk
- Minden arc megkeresése (MTCNN)
- Minden arcot kiértékelünk (az utolsó lépésben talált arcokat egy kötegbe csomagoljuk, és következtetjük a ResNet34-et)
- Renderelje le a végső képet
- Rajzoljuk meg a határolókereteket
- Az értékelések megrajzolása
- Egyéni (eredeti) kép törlése
- Az értékelési folyamat kimenetének mentése
- A feladatot az „after_estimate” sorba tesszük, amit a fent tárgyalt „attrai-telegram-bot” mikroszolgáltatás hallgat meg.
Graylog (+ mongoDB + Elasticsearch)
megoldás a központosított naplókezelésre. Ebben a projektben a rendeltetésének megfelelően használták.
A választás rá esett, és nem a szokásosra verem, a Pythonból való munkavégzés kényelme miatt. A Graylogba való bejelentkezéshez mindössze annyit kell tennie, hogy hozzáadja a GELFTCPHandlert a csomagból python mikroszolgáltatásunk többi root logger kezelőjének.
Mint valaki, aki korábban csak az ELK veremével dolgozott, összességében pozitív tapasztalatokat szereztem a Grayloggal való munka során. Az egyetlen lehangoló dolog a Kibana szolgáltatásainak felsőbbrendűsége a Graylog webes felülettel szemben.
Nyúl MQ
az AMQP protokollon alapuló üzenetközvetítő.
Ebben a projektben úgy használták bróker a Celery számára, és tartós üzemmódban dolgozott.
Feleinek
egy NoSQL DBMS, amely kulcsérték adatstruktúrákkal működik
Néha szükség van olyan közös objektumok használatára, amelyek bizonyos adatstruktúrákat valósítanak meg a különböző Python mikroszolgáltatásokban.
Például a Redis egy „telegram_user_id => aktív feladatok száma a sorban” formátumú hashmapot tárolja, amely lehetővé teszi egy felhasználótól érkező kérések számának egy bizonyos értékre való korlátozását, és ezáltal megakadályozza a DoS támadásokat.
Formalizáljuk a sikeres képfeldolgozás folyamatát
- A felhasználó képet küld a Telegram botnak
- Az "attrai-telegram-bot" üzenetet kap a Telegram API-tól, és elemzi azt
- A képpel ellátott feladat hozzáadódik a „to_estimate” aszinkron sorhoz
- A felhasználó üzenetet kap a tervezett értékelési időről
- Az „attrai-estimator” kivesz egy feladatot a „to_estimate” sorból, végigfutja a becsléseket a folyamaton, és a feladatot az „after_estimate” sorba állítja
- Az "attrai-telegram-bot" figyeli az "after_estimate" sort, elküldi az eredményt a felhasználónak
DevOps
Végül az architektúra áttekintése után továbbléphet a szintén érdekes részre - a DevOps-ra
Docker Raj
— egy klaszterrendszer, amelynek funkcionalitása a Docker Engine-en belül van megvalósítva, és már a dobozból is elérhető.
Egy „raj” segítségével a klaszterünk összes csomópontja 2 típusra osztható – dolgozó és menedzser. Az első típusú gépeken konténercsoportokat (stack) helyeznek el, a második típusú gépek felelősek a méretezésért, kiegyensúlyozásért és . A menedzserek is alapértelmezés szerint dolgozók.
Klaszter egy vezető menedzserrel és három dolgozóval
A minimális lehetséges fürtméret 1 csomópont; egyetlen gép egyszerre fog vezető menedzserként és dolgozóként is működni. A projekt mérete és a hibatűrés minimális követelményei alapján úgy döntöttek, hogy ezt a megközelítést alkalmazzák.
A jövőre nézve elmondom, hogy az első gyártási átadás óta, ami június közepén volt, nem volt probléma ezzel a klaszterszervezettel (de ez nem jelenti azt, hogy egy ilyen szervezet bármilyen közepesen-nagyon elfogadható lenne projektek, amelyekre hibatűrési követelmények vonatkoznak).
Docker Stack
Swarm módban ő felelős a veremek telepítéséért (docker szolgáltatáskészletek)
Támogatja a docker-compose konfigurációkat, lehetővé téve a telepítési lehetőségek további használatát.
Ezekkel a paraméterekkel például az egyes kiértékelő mikroszolgáltatás-példányok erőforrásai korlátozottak voltak (N példányhoz N magot osztunk ki, magában a mikroszolgáltatásban a PyTorch által használt magok számát egyre korlátozzuk)
attrai_estimator:
image: 'erqups/attrai_estimator:1.2'
deploy:
replicas: 4
resources:
limits:
cpus: '4'
restart_policy:
condition: on-failure
…Fontos megjegyezni, hogy a Redis, a RabbitMQ és a Graylog állapotalapú szolgáltatások, és nem skálázhatók olyan egyszerűen, mint az „attrai-estimator”
Előre vetítve a kérdést – miért nem Kubernetes?
Úgy tűnik, hogy a Kubernetes használata kis- és közepes méretű projektekben többletköltség, minden szükséges funkcionalitás beszerezhető a Docker Swarmból, amely meglehetősen felhasználóbarát egy konténerhangszerelőnek, és alacsony belépési korláttal is rendelkezik.
Infrastruktúra
Mindezt VDS-en telepítették a következő jellemzőkkel:
- CPU: 4 magos Intel® Xeon® Gold 5120 CPU @ 2.20 GHz
- RAM: 8 GB
- SSD: 160 GB
A helyi terhelési tesztek után úgy tűnt, hogy komoly felhasználóáradattal ez a gép is elég lesz.
Ám közvetlenül a telepítés után közzétettem egy linket a FÁK egyik legnépszerűbb imageboardjára (ja, ugyanarra), ami után az emberek érdeklődni kezdtek, és néhány óra alatt a szolgáltatás több tízezer képet sikeresen feldolgozott. Ugyanakkor a csúcsidőszakokban a CPU és a RAM erőforrások felére sem kerültek felhasználásra.
Még néhány grafika
Egyedi felhasználók és értékelési kérelmek száma a telepítés óta, a naptól függően
Kiértékelési csővezeték következtetés időeloszlása
Álláspontja
Összefoglalva elmondhatom, hogy a konténerek architektúrája és hangszerelési megközelítése teljesen igazolta magát – még a csúcsidőszakokban sem volt feldolgozási idő csökkenése vagy megereszkedése.
Úgy gondolom, hogy azok a kis- és közepes méretű projektek, amelyek folyamatukban a neurális hálózatok valós idejű következtetését használják a CPU-n, sikeresen alkalmazhatják az ebben a cikkben leírt gyakorlatokat.
Hozzáteszem, hogy kezdetben a cikk hosszabb volt, de azért, hogy ne tegyek fel hosszú olvasmányt, úgy döntöttem, hogy kihagyok néhány pontot ebből a cikkből – ezekre a későbbi publikációkban visszatérünk.
A botot a Telegramon piszkálhatod - @AttraiBot, legalább 2020 ősz végéig működik. Hadd emlékeztesselek arra, hogy a felhasználói adatok nem kerülnek tárolásra - sem az eredeti képek, sem a kiértékelési folyamat eredményei - a feldolgozás után mindent lerombolnak.
Forrás: will.com