ProHoster > blog > Utawala > Muhtasari wa jumla wa usanifu wa huduma kwa tathmini ya mwonekano kulingana na mitandao ya neva

Muhtasari wa jumla wa usanifu wa huduma kwa tathmini ya mwonekano kulingana na mitandao ya neva

Muhtasari wa jumla wa usanifu wa huduma kwa tathmini ya mwonekano kulingana na mitandao ya neva

Entry

Hi!

Katika makala hii nitashiriki uzoefu wangu wa kujenga usanifu wa microservice kwa mradi kwa kutumia mitandao ya neural.

Hebu tuzungumze juu ya mahitaji ya usanifu, angalia michoro mbalimbali za miundo, kuchambua kila vipengele vya usanifu wa kumaliza, na pia tathmini metrics ya kiufundi ya suluhisho.

Furahia kusoma!

Maneno machache kuhusu tatizo na ufumbuzi wake

Wazo kuu ni kutathmini mvuto wa mtu kwa kiwango cha alama kumi kulingana na picha.

Katika makala haya tutaondoka katika kuelezea mitandao ya neural inayotumika na mchakato wa utayarishaji na mafunzo ya data. Hata hivyo, katika mojawapo ya machapisho yafuatayo, kwa hakika tutarudi kuchambua bomba la tathmini kwa kiwango cha kina.

Sasa tutapitia bomba la tathmini katika ngazi ya juu, na tutazingatia mwingiliano wa microservices katika mazingira ya usanifu wa jumla wa mradi. 

Wakati wa kufanya kazi kwenye bomba la tathmini ya kuvutia, kazi hiyo iligawanywa katika vipengele vifuatavyo:

  1. Kuchagua nyuso katika picha
  2. Ukadiriaji wa kila mtu
  3. Toa matokeo

Ya kwanza inatatuliwa na nguvu za mafunzo ya awali MTCNN. Kwa pili, mtandao wa neural wa kubadilika ulifunzwa kwenye PyTorch, kwa kutumia ResNet34 - kutoka kwa usawa "ubora / kasi ya uelekezaji kwenye CPU"

Muhtasari wa jumla wa usanifu wa huduma kwa tathmini ya mwonekano kulingana na mitandao ya neva

Mchoro wa kazi wa bomba la tathmini

Uchambuzi wa mahitaji ya usanifu wa mradi

Katika mzunguko wa maisha ML hatua za mradi wa kazi juu ya usanifu na automatisering ya kupelekwa kwa mfano mara nyingi ni kati ya muda mwingi na utumiaji wa rasilimali.

Muhtasari wa jumla wa usanifu wa huduma kwa tathmini ya mwonekano kulingana na mitandao ya neva

Mzunguko wa maisha wa mradi wa ML

Mradi huu sio ubaguzi - uamuzi ulifanywa wa kufunga bomba la tathmini katika huduma ya mtandaoni, ambayo ilihitaji kuzama katika usanifu. Mahitaji ya msingi yafuatayo yalitambuliwa:

  1. Hifadhi ya logi ya umoja - huduma zote zinapaswa kuandika kumbukumbu katika sehemu moja, zinapaswa kuwa rahisi kuchambua
  2. Uwezekano wa kuongeza usawa wa huduma ya tathmini - kama Bottleneck inayowezekana zaidi
  3. Kiasi sawa cha rasilimali za kichakataji kinapaswa kutengwa kutathmini kila picha ili kuepusha wauzaji wa nje katika usambazaji wa wakati wa makisio.
  4. Usambazaji wa haraka (re) wa huduma zote mahususi na mrundikano kwa ujumla
  5. Uwezo, ikiwa ni lazima, kutumia vitu vya kawaida katika huduma tofauti

usanifu

Baada ya kuchambua mahitaji, ikawa dhahiri kwamba usanifu wa microservice unafaa karibu kabisa.

Ili kuondoa maumivu ya kichwa yasiyo ya lazima, API ya Telegraph ilichaguliwa kama sehemu ya mbele.

Kwanza, hebu tuangalie mchoro wa muundo wa usanifu wa kumaliza, kisha uende kwenye maelezo ya kila moja ya vipengele, na pia urasimishe mchakato wa usindikaji mafanikio wa picha.

Muhtasari wa jumla wa usanifu wa huduma kwa tathmini ya mwonekano kulingana na mitandao ya neva

Mchoro wa muundo wa usanifu wa kumaliza

Wacha tuzungumze kwa undani zaidi juu ya kila sehemu ya mchoro, tukiwaonyesha Wajibu Mmoja katika mchakato wa tathmini ya picha.

Huduma ndogo ya "attrai-telegram-bot"

Huduma hii ndogo hujumuisha mwingiliano wote na API ya Telegraph. Kuna hali 2 kuu: kufanya kazi na picha maalum na kufanya kazi na matokeo ya bomba la tathmini. Wacha tuangalie hali zote mbili kwa jumla.

Unapopokea ujumbe maalum na picha:

  1. Uchujaji unafanywa, unaojumuisha ukaguzi ufuatao:
    • Upatikanaji wa saizi bora ya picha
    • Idadi ya picha za watumiaji ambazo tayari ziko kwenye foleni
  2. Wakati wa kupitisha uchujaji wa awali, picha imehifadhiwa kwa kiasi cha docker
  3. Kazi inatolewa katika foleni ya "ku_kadiria", ambayo inajumuisha, kati ya mambo mengine, njia ya picha iliyo katika kiasi chetu.
  4. Ikiwa hatua zilizo hapo juu zimekamilika kwa ufanisi, mtumiaji atapokea ujumbe na muda wa takriban wa usindikaji wa picha, ambao huhesabiwa kulingana na idadi ya kazi kwenye foleni. Hitilafu ikitokea, mtumiaji ataarifiwa kwa uwazi kwa kutuma ujumbe wenye taarifa kuhusu kile ambacho huenda kilienda vibaya.

Pia, huduma hii ndogo, kama mfanyakazi wa celery, husikiliza foleni ya "after_estimate", ambayo inakusudiwa kwa kazi ambazo zimepitia bomba la tathmini.

Wakati wa kupokea kazi mpya kutoka kwa "after_estimate":

  1. Ikiwa picha itachakatwa kwa ufanisi, tunatuma matokeo kwa mtumiaji; ikiwa sivyo, tunaarifu kuhusu hitilafu.
  2. Kuondoa picha ambayo ni matokeo ya bomba la tathmini

Tathmini huduma ndogo ya "attrai-estimator"

Huduma hii ndogo ni mfanyakazi wa celery na hujumuisha kila kitu kinachohusiana na bomba la kutathmini picha. Kuna algorithm moja tu ya kufanya kazi hapa - wacha tuichambue.

Unapopokea kazi mpya kutoka kwa "to_estimate":

  1. Wacha tuendeshe picha kupitia bomba la tathmini:
    1. Inapakia picha kwenye kumbukumbu
    2. Tunaleta picha kwa ukubwa unaohitajika
    3. Inatafuta nyuso zote (MTCNN)
    4. Tunatathmini nyuso zote (tunafunga nyuso zilizopatikana katika hatua ya mwisho kuwa kundi na marejeleo ResNet34)
    5. Toa picha ya mwisho
      1. Wacha tuchore masanduku ya kufunga
      2. Kuchora makadirio
  2. Inafuta picha maalum (asili).
  3. Kuokoa matokeo kutoka kwa bomba la tathmini
  4. Tunaweka kazi hiyo kwenye foleni ya "baada_ya_kadiria", ambayo inasikilizwa na huduma ndogo ya "attrai-telegram-bot" iliyojadiliwa hapo juu.

Graylog (+ mongoDB + Elasticsearch)

Kijivu ni suluhisho la usimamizi wa kumbukumbu wa kati. Katika mradi huu, ilitumika kwa madhumuni yaliyokusudiwa.

Chaguo likaanguka juu yake, na sio kwa kawaida ELK stack, kwa sababu ya urahisi wa kufanya kazi nayo kutoka Python. Unachohitaji kufanya ili kuingia kwenye Graylog ni kuongeza GELFTCPHndler kutoka kwa kifurushi kijivu kwa washikaji wengine wa vigogo wa python microservice yetu.

Kama mtu ambaye hapo awali alikuwa amefanya kazi na safu ya ELK, nilikuwa na uzoefu mzuri wakati nikifanya kazi na Graylog. Kitu pekee ambacho kinasikitisha ni ubora wa vipengele vya Kibana juu ya kiolesura cha wavuti cha Graylog.

SunguraMQ

SunguraMQ ni wakala wa ujumbe kulingana na itifaki ya AMQP.

Katika mradi huu ilitumika kama imara zaidi na iliyojaribiwa kwa wakati wakala wa Celery na kufanya kazi katika hali ya kudumu.

Rejea

Rejea ni DBMS ya NoSQL ambayo inafanya kazi na miundo ya data ya thamani-msingi

Wakati mwingine kuna haja ya kutumia vitu vya kawaida vinavyotekeleza miundo fulani ya data katika microservices tofauti za Python.

Kwa mfano, Redis huhifadhi ramani ya reli ya fomu ya “telegram_user_id => idadi ya kazi zinazoendelea kwenye foleni,” ambayo inakuruhusu kuweka kikomo idadi ya maombi kutoka kwa mtumiaji mmoja hadi thamani fulani na, hivyo, kuzuia mashambulizi ya DoS.

Hebu turasimishe mchakato wa usindikaji wa picha uliofanikiwa

  1. Mtumiaji hutuma picha kwenye bot ya Telegraph
  2. "attrai-telegram-bot" hupokea ujumbe kutoka kwa API ya Telegramu na kuuchanganua
  3. Kazi iliyo na picha imeongezwa kwenye foleni isiyolingana "to_estimate"
  4. Mtumiaji hupokea ujumbe na muda uliopangwa wa tathmini
  5. "attrai-estimator" huchukua jukumu kutoka kwa foleni ya "ku_kadiria", huendesha makadirio kupitia bomba na kutoa kazi kwenye foleni ya "baada_ya_makadirio".
  6. "attrai-telegram-bot" ikisikiliza foleni ya "after_estimate", hutuma matokeo kwa mtumiaji.

DevOps

Hatimaye, baada ya kukagua usanifu, unaweza kuendelea na sehemu ya kuvutia sawa - DevOps

Pumba la Docker

 

Muhtasari wa jumla wa usanifu wa huduma kwa tathmini ya mwonekano kulingana na mitandao ya neva

Pumba la Docker  - mfumo wa nguzo, utendakazi ambao unatekelezwa ndani ya Injini ya Docker na unapatikana nje ya boksi.

Kwa kutumia "pumba", nodes zote katika kundi letu zinaweza kugawanywa katika aina 2 - mfanyakazi na meneja. Kwenye mashine za aina ya kwanza, vikundi vya kontena (lundi) hutumwa, mashine za aina ya pili zina jukumu la kuongeza, kusawazisha na. vipengele vingine vya kupendeza. Wasimamizi pia ni wafanyikazi kwa chaguo-msingi.

Muhtasari wa jumla wa usanifu wa huduma kwa tathmini ya mwonekano kulingana na mitandao ya neva

Nguzo yenye meneja kiongozi mmoja na wafanyakazi watatu

Ukubwa wa chini unaowezekana wa nguzo ni nodi 1; mashine moja itafanya wakati huo huo kama meneja kiongozi na mfanyakazi. Kulingana na ukubwa wa mradi na mahitaji ya chini ya uvumilivu wa makosa, iliamuliwa kutumia njia hii.

Kuangalia mbele, nitasema kwamba tangu utoaji wa kwanza wa uzalishaji, ambao ulikuwa katikati ya Juni, hakujawa na matatizo yoyote yanayohusiana na shirika hili la nguzo (lakini hii haimaanishi kuwa shirika kama hilo linakubalika kwa njia yoyote katika kiwango chochote cha kati. miradi ambayo iko chini ya mahitaji ya uvumilivu wa makosa).

Mkusanyiko wa Docker

Katika hali ya kundi, ana jukumu la kupeleka safu (seti za huduma za docker) kizimbani

Inaauni usanidi wa kutunga docker, hukuruhusu kutumia chaguzi za kupeleka.  

Kwa mfano, kwa kutumia vigezo hivi, nyenzo za kila moja ya matukio ya huduma ndogo za tathmini zilikuwa na kikomo (tunatenga cores N kwa matukio ya N, katika huduma ndogo yenyewe tunaweka kikomo idadi ya cores zinazotumiwa na PyTorch hadi moja)

attrai_estimator:
  image: 'erqups/attrai_estimator:1.2'
  deploy:
    replicas: 4
    resources:
      limits:
        cpus: '4'
    restart_policy:
      condition: on-failure
      …

Ni muhimu kutambua kwamba Redis, RabbitMQ na Graylog ni huduma za hali na haziwezi kupunguzwa kwa urahisi kama "attrai-estimator"

Kuonyesha swali - kwa nini sio Kubernetes?

Inaonekana kwamba kutumia Kubernetes katika miradi midogo na ya kati ni kazi ya ziada; utendakazi wote muhimu unaweza kupatikana kutoka kwa Docker Swarm, ambayo ni rahisi kwa mtumiaji kwa orchestrator ya chombo na pia ina kizuizi cha chini cha kuingia.

Miundombinu

Yote hii iliwekwa kwenye VDS na sifa zifuatazo:

  • CPU: 4 core Intel® Xeon® Gold 5120 CPU @ 2.20GHz
  • RAM: 8 GB
  • SSD: GB 160

Baada ya kupima mzigo wa ndani, ilionekana kuwa na ongezeko kubwa la watumiaji, mashine hii itakuwa ya kutosha.

Lakini, mara tu baada ya kupelekwa, nilichapisha kiunga cha moja ya ubao wa picha maarufu zaidi katika CIS (yup, hiyo hiyo), baada ya hapo watu walipendezwa na katika masaa machache huduma ilifanikiwa kusindika makumi ya maelfu ya picha. Wakati huo huo, wakati wa kilele, rasilimali za CPU na RAM hazikutumiwa hata nusu.

Muhtasari wa jumla wa usanifu wa huduma kwa tathmini ya mwonekano kulingana na mitandao ya neva
Muhtasari wa jumla wa usanifu wa huduma kwa tathmini ya mwonekano kulingana na mitandao ya neva

Baadhi ya michoro zaidi

Idadi ya watumiaji mahususi na maombi ya tathmini tangu kutumwa, kulingana na siku

Muhtasari wa jumla wa usanifu wa huduma kwa tathmini ya mwonekano kulingana na mitandao ya neva

Tathmini ya usambazaji wa muda wa marejeleo ya bomba

Muhtasari wa jumla wa usanifu wa huduma kwa tathmini ya mwonekano kulingana na mitandao ya neva

Matokeo

Kwa muhtasari, naweza kusema kwamba usanifu na mbinu ya upangaji wa vyombo ilijihalalisha - hata wakati wa kilele hakukuwa na matone au kushuka kwa wakati wa usindikaji. 

Nadhani miradi midogo na ya wastani inayotumia uelekezaji wa wakati halisi wa mitandao ya neva kwenye CPU katika mchakato wake inaweza kupitisha mazoea yaliyofafanuliwa katika makala haya.

Nitaongeza kuwa hapo awali nakala hiyo ilikuwa ndefu, lakini ili nisichapishe usomaji wa muda mrefu, niliamua kuacha baadhi ya vidokezo katika nakala hii - tutarudi kwao katika machapisho yajayo.

Unaweza kupiga kijibu kwenye Telegraph - @AttraiBot, itafanya kazi angalau hadi mwisho wa vuli 2020. Napenda kukukumbusha kwamba hakuna data ya mtumiaji iliyohifadhiwa - wala picha za awali, wala matokeo ya bomba la tathmini - kila kitu kinaharibiwa baada ya usindikaji.

Chanzo: mapenzi.com

Kuongeza maoni