eniro
Saluton!
En ĉi tiu artikolo mi dividos mian sperton pri konstruado de mikroserva arkitekturo por projekto uzanta neŭrajn retojn.
Ni parolu pri la arkitekturaj postuloj, rigardu diversajn strukturajn diagramojn, analizu ĉiun el la komponantoj de la finita arkitekturo kaj ankaŭ taksu la teknikajn metrikojn de la solvo.
Ĝuu legi!
Kelkajn vortojn pri la problemo kaj ĝia solvo
La ĉefa ideo estas taksi la allogecon de homo sur dek-punkta skalo bazita sur foto.
En ĉi tiu artikolo ni malproksimiĝos de priskribado de la neŭralaj retoj uzataj kaj la procezo de preparado kaj trejnado de datumoj. Tamen, en unu el la sekvaj publikaĵoj, ni certe revenos al analizo de la taksa dukto je profunda nivelo.
Nun ni trairos la taksan dukton ĉe la plej alta nivelo, kaj fokusiĝos pri la interago de mikroservoj en la kunteksto de la ĝenerala projektarkitekturo.
Dum laborado pri la allogeca taksado-dukto, la tasko estis malkomponita en la sekvajn komponentojn:
- Elektante vizaĝojn en fotoj
- Taksado de ĉiu persono
- Redonu la rezulton
La unua estas solvita de la fortoj de pre-trejnitaj . Por la dua, konvolucia neŭrala reto estis trejnita sur PyTorch, uzante - de la ekvilibro "kvalito / rapido de inferenco sur la CPU"
Funkcia diagramo de la taksa dukto
Analizo de projektaj arkitekturpostuloj
En la vivociklo projektostadioj de laboro pri la arkitekturo kaj aŭtomatigo de modeldeplojo ofte estas inter la plej tempopostulaj kaj rimed-konsumantaj.
Vivciklo de ML-projekto
Ĉi tiu projekto ne estas escepto - la decido estis farita envolvi la taksan dukton en interretan servon, kio postulis mergi nin en la arkitekturo. La sekvaj bazaj postuloj estis identigitaj:
- Unuigita protokolo-stokado - ĉiuj servoj devus skribi protokolojn en unu loko, ili devus esti oportune analizi
- Eblo de horizontala skalo de la taksa servo - kiel la plej verŝajna Bottleck
- La sama kvanto de procesorresursoj devus esti asignita por taksi ĉiun bildon por eviti eksteraĵojn en la distribuado de tempo por inferenco.
- Rapida (re)deplojo de kaj specifaj servoj kaj la stako entute
- La kapablo, se necese, uzi komunajn objektojn en malsamaj servoj
arkitekturo
Post analizo de la postuloj, evidentiĝis, ke la mikroserva arkitekturo preskaŭ perfekte taŭgas.
Por forigi nenecesajn kapdolorojn, la Telegram API estis elektita kiel la fasado.
Unue, ni rigardu la strukturan diagramon de la finita arkitekturo, poste transiru al priskribo de ĉiu el la komponantoj, kaj ankaŭ formaligu la procezon de sukcesa bildprilaborado.
Struktura diagramo de la finita arkitekturo
Ni parolu pli detale pri ĉiu el la komponantoj de la diagramo, indikante ilin Ununura Respondeco en la procezo de bilda taksado.
Mikroservo "attrai-telegram-bot"
Ĉi tiu mikroservo enkapsuligas ĉiujn interagojn kun la Telegram-API. Estas 2 ĉefaj scenaroj: labori kun kutima bildo kaj labori kun la rezulto de taksa dukto. Ni rigardu ambaŭ scenarojn ĝenerale.
Kiam vi ricevas propran mesaĝon kun bildo:
- Filtrado estas farita, konsistante el la sekvaj kontroloj:
- Havebleco de optimuma grandeco de bildo
- Nombro de uzantbildoj jam en vico
- Pasinte la komencan filtradon, la bildo estas konservita en la docker-volumo
- Tasko estas produktita en la vico "to_estimate", kiu inkluzivas interalie la vojon al la bildo situanta en nia volumo.
- Se la supraj paŝoj estas plenumitaj sukcese, la uzanto ricevos mesaĝon kun la proksimuma bilda prilaborado, kiu estas kalkulita surbaze de la nombro da taskoj en la vosto. Se okazas eraro, la uzanto estos eksplicite sciigita sendante mesaĝon kun informoj pri kio eble misfunkciis.
Ankaŭ ĉi tiu mikroservo, kiel celeria laboristo, aŭskultas la atendovicon "post_takso", kiu estas destinita por taskoj, kiuj trapasis la taksaddukton.
Kiam vi ricevas novan taskon de "after_estimate":
- Se la bildo estas procesita sukcese, ni sendas la rezulton al la uzanto; se ne, ni sciigas pri eraro.
- Forigante la bildon kiu estas la rezulto de la taksa dukto
Mikroservo de taksado "attrai-estimator"
Ĉi tiu mikroservo estas celeria laboristo kaj enkapsuligas ĉion rilate al la bilda taksa dukto. Estas nur unu funkcianta algoritmo ĉi tie - ni analizu ĝin.
Kiam vi ricevas novan taskon de "to_estimate":
- Ni rulu la bildon tra la taksa dukto:
- Ŝargante la bildon en memoron
- Ni alportas la bildon al la bezonata grandeco
- Trovante ĉiujn vizaĝojn (MTCNN)
- Ni taksas ĉiujn vizaĝojn (ni envolvas la vizaĝojn trovitajn en la lasta paŝo en aron kaj inferencon ResNet34)
- Redonu la finan bildon
- Ni desegnu la limskatolojn
- Desegni la taksojn
- Forigo de kutima (originala) bildo
- Konservado de la eligo de la taksa dukto
- Ni metas la taskon en la vicon "post_taksado", kiun aŭskultas la mikroservo "attrai-telegram-bot" diskutita supre.
Graylog (+ mongoDB + Elasticsearch)
estas solvo por centralizita logadministrado. En ĉi tiu projekto, ĝi estis uzata por sia celita celo.
La elekto falis sur li, kaj ne sur la kutima stack, pro la oportuno labori kun ĝi de Python. Ĉio, kion vi devas fari por ensaluti al Graylog, estas aldoni la GELFTCPHandler el la pakaĵo al la resto de la radikregistriloj pritraktiloj de nia python-mikroservo.
Kiel iu, kiu antaŭe nur laboris kun la ELK-stako, mi havis ĝeneralan pozitivan sperton laborante kun Graylog. La nura afero, kiu estas deprimanta, estas la supereco en Kibana-funkcioj super la Graylog-interfaco.
KunikloMQ
estas mesaĝmakleristo bazita sur la AMQP-protokolo.
En ĉi tiu projekto ĝi estis uzata kiel makleristo por Celery kaj laboris en daŭrema reĝimo.
Redis
estas NoSQL-DBMS kiu funkcias kun ŝlosilvaloraj datumstrukturoj
Kelkfoje necesas uzi komunajn objektojn, kiuj efektivigas certajn datumstrukturojn en malsamaj Python-mikroservoj.
Ekzemple, Redis stokas hashmapon de la formo "telegram_user_id => nombro da aktivaj taskoj en la vosto", kiu permesas vin limigi la nombron da petoj de unu uzanto al certa valoro kaj, tiel, malhelpi DoS-atakojn.
Ni formaligu la procezon de sukcesa bildprilaborado
- La uzanto sendas bildon al la Telegram-bot
- "attrai-telegram-bot" ricevas mesaĝon de la Telegram-API kaj analizas ĝin
- La tasko kun la bildo estas aldonita al la nesinkrona vico "to_estimate"
- La uzanto ricevas mesaĝon kun la planita taksa tempo
- "attrai-estimator" prenas taskon de la "to_estimate" atendovico, prizorgas la taksojn tra la dukto kaj produktas la taskon en la "after_estimate" atendovico
- "attrai-telegram-bot" aŭskultante la vicon "post_taksado", sendas la rezulton al la uzanto
DevOps
Fine, post revizii la arkitekturon, vi povas pluiri al la same interesa parto - DevOps
Docker Svarmo
— clustering-sistemo, kies funkcieco estas efektivigita ene de la Docker Engine kaj disponeblas el la skatolo.
Uzante "svarmon", ĉiuj nodoj en nia areto povas esti dividitaj en 2 tipojn - laboristo kaj administranto. Sur maŝinoj de la unua tipo, grupoj de ujoj (stakoj) estas deplojitaj, maŝinoj de la dua tipo respondecas pri skalado, ekvilibro kaj . Manaĝeroj ankaŭ estas laboristoj defaŭlte.
Areto kun unu ĉefmanaĝero kaj tri laboristoj
La minimuma ebla aretgrandeco estas 1 nodo; ununura maŝino samtempe funkcios kiel ĉefmanaĝero kaj laboristo. Surbaze de la grandeco de la projekto kaj la minimumaj postuloj por kulp-toleremo, oni decidis uzi ĉi tiun aliron.
Antaŭenrigardante, mi diros, ke ekde la unua produktada livero, kiu okazis meze de junio, ne estis problemoj asociitaj kun ĉi tiu cluster-organizo (sed tio ne signifas, ke tia organizo estas iel akceptebla en iu ajn mezgranda. projektoj, kiuj estas submetitaj al faŭltoleremo postuloj).
Docker Stako
En svarma reĝimo, li respondecas pri deplojado de stakoj (aroj de dockerservoj)
Ĝi subtenas docker-komponajn agordojn, permesante vin aldone uzi deplojajn opciojn.
Ekzemple, uzante ĉi tiujn parametrojn, la rimedoj por ĉiu el la taksaj mikroservoj estis limigitaj (ni asignas N kernojn por N okazoj, en la mikroservo mem ni limigas la nombron da kernoj uzataj de PyTorch al unu)
attrai_estimator:
image: 'erqups/attrai_estimator:1.2'
deploy:
replicas: 4
resources:
limits:
cpus: '4'
restart_policy:
condition: on-failure
…Gravas noti, ke Redis, RabbitMQ kaj Graylog estas ŝtataj servoj kaj ili ne povas esti skalaj same facile kiel "attrai-taksisto"
Antaŭsignante la demandon - kial ne Kubernetes?
Ŝajnas, ke uzi Kubernetes en malgrandaj kaj mezgrandaj projektoj estas supera kosto; ĉiuj necesaj funkcioj povas esti akiritaj de Docker Swarm, kiu estas sufiĉe afabla por ujo-orkestro kaj ankaŭ havas malaltan barieron al eniro.
Infrastrukturo
Ĉio ĉi estis deplojita sur VDS kun la sekvaj karakterizaĵoj:
- CPU: 4-kerna Intel® Xeon® Gold 5120 CPU @ 2.20GHz
- RAM: 8 GB
- SSD: 160 GB
Post loka ŝarĝtestado, ŝajnis, ke kun serioza enfluo de uzantoj, ĉi tiu maŝino sufiĉus.
Sed, tuj post la deplojo, mi afiŝis ligilon al unu el la plej popularaj bildtabuloj en la CIS (jes, tiu sama), post kiu homoj interesiĝis kaj en kelkaj horoj la servo sukcese prilaboris dekojn da miloj da bildoj. Samtempe, en pintaj momentoj, CPU kaj RAM-resursoj eĉ ne estis duone uzataj.
Kelkaj pliaj grafikaĵoj
Nombro de unikaj uzantoj kaj taksaj petoj ekde deplojo, depende de la tago
Taksada dukto inferenca tempodistribuo
trovoj
Por resumi, mi povas diri, ke la arkitekturo kaj aliro al orkestrado de ujoj plene pravigis sin - eĉ en pintaj momentoj ne estis gutoj aŭ malfortiĝo en pretiga tempo.
Mi pensas, ke malgrandaj kaj mezgrandaj projektoj, kiuj uzas realtempan inferencon de neŭralaj retoj sur la CPU en sia procezo, povas sukcese adopti la praktikojn priskribitajn en ĉi tiu artikolo.
Mi aldonos, ke komence la artikolo estis pli longa, sed por ne afiŝi longan legadon, mi decidis preterlasi kelkajn punktojn en ĉi tiu artikolo - ni revenos al ili en estontaj eldonaĵoj.
Vi povas piki la bot sur Telegram - @AttraiBot, ĝi funkcios almenaŭ ĝis la fino de aŭtuno 2020. Mi memorigu vin, ke neniuj uzantdatenoj estas stokitaj - nek la originalaj bildoj, nek la rezultoj de la taksa dukto - ĉio estas malkonstruita post prilaborado.
fonto: www.habr.com