Færslu
РџСЂРІРμы!
Í þessari grein mun ég deila reynslu minni af því að byggja upp örþjónustuarkitektúr fyrir verkefni sem notar taugakerfi.
Við skulum tala um kröfur um arkitektúr, skoða ýmsar byggingarskýringar, greina hvern hluta fullunnar byggingarlistar og einnig meta tæknilega mælikvarða lausnarinnar.
Gleðilegt lestur!
Nokkur orð um vandamálið og lausn þess
Meginhugmyndin er að meta aðdráttarafl einstaklings á tíu punkta kvarða út frá mynd.
Í þessari grein munum við hverfa frá því að lýsa bæði tauganetunum sem notuð eru og ferlinu við undirbúning og þjálfun gagna. Hins vegar, í einni af eftirfarandi ritum, munum við örugglega snúa aftur til að greina matsleiðsluna á ítarlegu stigi.
Nú munum við fara í gegnum matsleiðsluna á efsta stigi og einbeita okkur að samspili örþjónustu í samhengi við heildarverkefnisarkitektúr.
Þegar unnið var að aðdráttarmatsleiðslunni var verkefninu skipt niður í eftirfarandi þætti:
- Velja andlit á myndum
- Einkunn hvers og eins
- Skildu niðurstöðuna
Fyrsta er leyst af krafti forþjálfaðra . Í öðru lagi var snúningstauganet þjálfað á PyTorch með því að nota - frá jafnvæginu "gæði / ályktunarhraði á CPU"
Virk skýringarmynd af matsleiðslunni
Greining á kröfum um byggingarlist verks
Í lífshlaupinu Verkefnastig vinnu við arkitektúr og sjálfvirkni módeldreifingar eru oft með þeim tíma- og auðlindafreku.
Lífsferill ML verkefnis
Þetta verkefni er engin undantekning - sú ákvörðun var tekin að pakka matsleiðslunni inn í netþjónustu, sem krafðist þess að sökkva okkur niður í arkitektúrinn. Eftirfarandi grunnkröfur komu fram:
- Sameinuð annálgeymsla – allar þjónustur ættu að skrifa logs á einum stað, þær ættu að vera þægilegar að greina
- Möguleiki á láréttri stærðargráðu matsþjónustunnar - sem líklegasti flöskuhálsinn
- Úthluta ætti sama magni af örgjörvatilföngum til að meta hverja mynd til að forðast frávik í dreifingu tíma til ályktunar
- Hröð (endur)dreifing bæði sértækrar þjónustu og staflasins í heild
- Hæfni, ef nauðsyn krefur, til að nota algenga hluti í mismunandi þjónustu
arkitektúr
Eftir að hafa greint kröfurnar kom í ljós að örþjónustuarkitektúrinn passar nánast fullkomlega.
Til að losna við óþarfa höfuðverk var Telegram API valið sem framhlið.
Í fyrsta lagi skulum við skoða burðarmyndina af fullunnum arkitektúr, fara síðan yfir í lýsingu á hverjum íhlutum og einnig formfesta ferlið við árangursríka myndvinnslu.
Byggingarmynd af fullunnum arkitektúr
Við skulum tala nánar um hvern hluta skýringarmyndarinnar og tákna þá eina ábyrgð í ferli myndmats.
Örþjónusta „attrai-telegram-bot“
Þessi örþjónusta umlykur öll samskipti við Telegram API. Það eru 2 meginsviðsmyndir: að vinna með sérsniðna mynd og vinna með niðurstöður matsleiðslu. Við skulum skoða báðar aðstæður almennt.
Þegar þú færð sérsniðin skilaboð með mynd:
- Síun fer fram sem samanstendur af eftirfarandi eftirliti:
- Framboð á bestu myndastærð
- Fjöldi notendamynda þegar í biðröð
- Þegar upphafssíunin er liðin er myndin vistuð í hólfinu
- Verkefni er framleitt í biðröðinni „að meta“, sem inniheldur meðal annars slóðina að myndinni sem er í bindinu okkar
- Ef ofangreindum skrefum er lokið fær notandinn skilaboð með áætluðum myndvinnslutíma, sem er reiknaður út frá fjölda verkefna í biðröðinni. Ef villa kemur upp verður notandanum beint tilkynnt með því að senda skilaboð með upplýsingum um hvað gæti hafa farið úrskeiðis.
Einnig hlustar þessi örþjónusta, eins og sellerístarfsmaður, á „after_estimate“ biðröðina, sem er ætluð fyrir verkefni sem hafa farið í gegnum matsleiðsluna.
Þegar þú færð nýtt verkefni frá „after_estimate“:
- Ef vinnsla myndarinnar gengur vel sendum við niðurstöðuna til notandans; ef ekki, látum við vita um villu.
- Fjarlægir myndina sem er afleiðing matsleiðslunnar
Mat örþjónustu „attrai-estimator“
Þessi örþjónusta er sellerístarfsmaður og umlykur allt sem tengist myndmatsleiðslunni. Það er aðeins eitt virkt reiknirit hér - við skulum greina það.
Þegar þú færð nýtt verkefni frá „to_estimate“:
- Við skulum keyra myndina í gegnum matsleiðsluna:
- Hleður myndinni inn í minnið
- Við færum myndina í nauðsynlega stærð
- Að finna öll andlit (MTCNN)
- Við metum öll andlit (við vöfum andlitin sem fundust í síðasta skrefi í lotu og ályktum ResNet34)
- Gerðu lokamyndina
- Við skulum teikna afmarkandi reiti
- Að draga einkunnir
- Eyðir sérsniðinni (upprunalegri) mynd
- Vistar úttakið úr matsleiðslunni
- Við settum verkefnið í „after_estimate“ biðröðina, sem „attrai-telegram-bot“ örþjónustan sem fjallað er um hér að ofan hlustar á.
Graylog (+ mongoDB + Elasticsearch)
er lausn fyrir miðstýrða annálastjórnun. Í þessu verkefni var það notað í tilætluðum tilgangi.
Valið féll á hann, en ekki hinn venjulega stafla, vegna þæginda við að vinna með það frá Python. Allt sem þú þarft að gera til að skrá þig inn á Graylog er að bæta við GELFTCPHandler úr pakkanum við restina af rótarskrárstjórum python örþjónustunnar okkar.
Sem einhver sem hafði áður aðeins unnið með ELK stafla, hafði ég almennt jákvæða reynslu þegar ég vann með Graylog. Það eina sem er niðurdrepandi eru yfirburðir Kibana eiginleikanna yfir Graylog vefviðmótinu.
Kanína MQ
er skilaboðamiðlari byggður á AMQP samskiptareglum.
Í þessu verkefni var það notað sem miðlari fyrir sellerí og vann í varanlegum ham.
Redis
er NoSQL DBMS sem vinnur með lykilgildi gagnaskipulag
Stundum er þörf á að nota algenga hluti sem innleiða ákveðna gagnauppbyggingu í mismunandi Python örþjónustum.
Til dæmis geymir Redis hashmap af forminu „telegram_user_id => fjöldi virkra verkefna í biðröðinni,“ sem gerir þér kleift að takmarka fjölda beiðna frá einum notanda við ákveðið gildi og þar með koma í veg fyrir DoS árásir.
Við skulum formfesta ferlið við árangursríka myndvinnslu
- Notandinn sendir mynd til Telegram bot
- "attrai-telegram-bot" fær skilaboð frá Telegram API og flokkar þau
- Verkefninu með myndinni er bætt við ósamstilltu biðröðina „to_estimate“
- Notandi fær skilaboð með fyrirhuguðum matstíma
- „attrai-estimator“ tekur verkefni úr „to_estimate“ biðröðinni, keyrir áætlunina í gegnum leiðsluna og framleiðir verkefnið í „after_estimate“ biðröðina
- "attrai-telegram-bot" hlustar á "after_estimate" biðröðina, sendir niðurstöðuna til notandans
DevOps
Að lokum, eftir að hafa farið yfir arkitektúrinn, geturðu haldið áfram í jafn áhugaverða hlutann - DevOps
Docker Sveimur
— klasakerfi, virkni þess er útfærð inni í Docker Engine og er fáanleg strax í kassanum.
Með því að nota „sveim“ er hægt að skipta öllum hnútum í klasanum okkar í 2 tegundir - starfsmann og stjórnanda. Á vélum af fyrri gerðinni eru hópar af gámum (stafla), vélar af annarri gerð sjá um mælikvarða, jafnvægi og . Stjórnendur eru líka starfsmenn sjálfgefið.
Klasa með einum leiðtogastjóra og þremur starfsmönnum
Lágmarks klasastærð er 1 hnút; ein vél mun samtímis starfa sem leiðtogastjóri og starfsmaður. Miðað við stærð verksins og lágmarkskröfur um bilanaþol var ákveðið að nota þessa leið.
Þegar ég horfi fram á veginn segi ég að frá fyrstu framleiðsluafhendingu, sem var um miðjan júní, hafa engin vandamál verið tengd þessari klasastofnun (en það þýðir ekki að slík stofnun sé á nokkurn hátt ásættanleg í hvaða meðalstóru verkefni, sem eru háð kröfum um bilanaþol).
Docker Stack
Í kvikham er hann ábyrgur fyrir að dreifa stafla (sett af hafnarþjónustu)
Það styður docker-compose stillingar, sem gerir þér kleift að nota dreifingarvalkosti til viðbótar.
Til dæmis, með því að nota þessar færibreytur, voru tilföngin fyrir hvert matsörþjónustutilvik takmörkuð (við úthlutum N kjarna fyrir N tilvik, í örþjónustunni sjálfri takmörkum við fjölda kjarna sem PyTorch notar við einn)
attrai_estimator:
image: 'erqups/attrai_estimator:1.2'
deploy:
replicas: 4
resources:
limits:
cpus: '4'
restart_policy:
condition: on-failure
…Það er mikilvægt að hafa í huga að Redis, RabbitMQ og Graylog eru opinberar þjónustur og ekki er hægt að skala þær eins auðveldlega og „attrai-estimator“
Fyrirboði spurningarinnar - hvers vegna ekki Kubernetes?
Svo virðist sem notkun Kubernetes í litlum og meðalstórum verkefnum sé kostnaður; alla nauðsynlega virkni er hægt að fá frá Docker Swarm, sem er frekar notendavænt fyrir gámasveitarmann og hefur einnig litla aðgangshindrun.
Infrastructure
Allt þetta var sent á VDS með eftirfarandi eiginleikum:
- Örgjörvi: 4 kjarna Intel® Xeon® Gold 5120 örgjörvi @ 2.20GHz
- RAM: 8 GB
- SSD: 160GB
Eftir staðbundnar álagsprófanir virtist sem með alvarlegu innstreymi notenda myndi þessi vél duga.
En strax eftir dreifinguna birti ég hlekk á eitt vinsælasta myndaspjaldið í CIS (jamm, það sama), eftir það fékk fólk áhuga og á nokkrum klukkustundum tókst þjónustan að vinna úr tugþúsundum mynda. Á sama tíma, á hámarksstundum, voru örgjörvi og vinnsluminni ekki einu sinni hálfnotuð.
Smá grafík í viðbót
Fjöldi einstakra notenda og matsbeiðna frá dreifingu, fer eftir degi
Ályktunartíma dreifingar matsleiðslu
Niðurstöður
Til að draga saman get ég sagt að arkitektúrinn og nálgunin við skipulagningu gáma réttlættu sig að fullu - jafnvel á álagstímum var ekkert fall eða hnignun í vinnslutíma.
Ég held að lítil og meðalstór verkefni sem nota rauntímaályktun um taugakerfi á örgjörvanum í ferli sínu geti með góðum árangri tekið upp þær aðferðir sem lýst er í þessari grein.
Ég bæti því við að upphaflega var greinin lengri, en til að birta ekki langlestur ákvað ég að sleppa nokkrum atriðum í þessari grein - við munum koma aftur að þeim í framtíðarútgáfum.
Þú getur potað í botninn á Telegram - @AttraiBot, það mun virka að minnsta kosti til loka haustsins 2020. Ég minni á að engin notendagögn eru geymd - hvorki upprunalegu myndirnar, né niðurstöður matsleiðslunnar - allt er rifið að vinnslu lokinni.
Heimild: www.habr.com