Նեյրոնային ցանցերի վրա հիմնված արտաքին տեսքի գնահատման ծառայության ճարտարապետության ընդհանուր ակնարկ

Մուտք

Hi!

Այս հոդվածում ես կկիսվեմ նեյրոնային ցանցերի օգտագործմամբ նախագծի համար միկրոսերվիսային ճարտարապետություն կառուցելու իմ փորձով:

Եկեք խոսենք ճարտարապետության պահանջների մասին, նայենք տարբեր կառուցվածքային դիագրամներին, վերլուծենք պատրաստի ճարտարապետության բաղադրիչներից յուրաքանչյուրը, ինչպես նաև գնահատենք լուծման տեխնիկական չափորոշիչները:

Վայելեք ընթերցանությունը:

Մի քանի խոսք խնդրի և դրա լուծման մասին

Հիմնական գաղափարը լուսանկարի հիման վրա տասը բալանոց սանդղակով գնահատել մարդու գրավչությունը։

Այս հոդվածում մենք կհեռանանք ինչպես օգտագործվող նեյրոնային ցանցերի, այնպես էլ տվյալների պատրաստման և վերապատրաստման գործընթացի նկարագրությունից: Այնուամենայնիվ, հաջորդ հրապարակումներից մեկում մենք անպայման կվերադառնանք գնահատման խողովակաշարը խորը մակարդակով վերլուծելուն:

Այժմ մենք կանցնենք գնահատման խողովակաշարով ամենաբարձր մակարդակով և կկենտրոնանանք միկրոծառայությունների փոխազդեցության վրա՝ ծրագրի ընդհանուր ճարտարապետության համատեքստում: 

Գրավչության գնահատման խողովակաշարի վրա աշխատելիս խնդիրը բաժանվել է հետևյալ բաղադրիչների.

1. Լուսանկարներում դեմքերի ընտրություն
2. Յուրաքանչյուր անձի վարկանիշը
3. Ներկայացրե՛ք արդյունքը

Առաջինը լուծվում է նախապես պատրաստված ուժերով MTCNN. Երկրորդի համար PyTorch-ի վրա ուսուցանվել է կոնվոլյուցիոն նեյրոնային ցանց՝ օգտագործելով ResNet34 – «CPU-ի վրա եզրակացության որակ/արագություն» հաշվեկշռից

Գնահատման խողովակաշարի ֆունկցիոնալ դիագրամ

Ծրագրի ճարտարապետության պահանջների վերլուծություն

Կյանքի ցիկլում ML Մոդելի տեղակայման ճարտարապետության և ավտոմատացման նախագծային փուլերը հաճախ առավել ժամանակատար և ռեսուրսներ են խլում:

ML նախագծի կյանքի ցիկլը

Այս նախագիծը բացառություն չէ. որոշվեց գնահատման խողովակաշարը փաթեթավորել առցանց ծառայության մեջ, որը պահանջում էր խորասուզվել ճարտարապետության մեջ: Բացահայտվել են հետևյալ հիմնական պահանջները.

1. Մատյանների միասնական պահեստավորում. բոլոր ծառայությունները պետք է գրեն տեղեկամատյանները մեկ տեղում, դրանք պետք է հարմար լինեն վերլուծելու համար
2. Գնահատման ծառայության հորիզոնական մասշտաբի հնարավորությունը` որպես ամենահավանական խցան
3. Պրոցեսորային ռեսուրսների նույն քանակությունը պետք է հատկացվի յուրաքանչյուր պատկերը գնահատելու համար, որպեսզի խուսափենք եզրահանգումների ժամանակի բաշխման մեջ:
4. Թե՛ հատուկ ծառայությունների, թե՛ ամբողջ փաթեթի արագ (վեր) տեղակայումը
5. Անհրաժեշտության դեպքում տարբեր ծառայություններում ընդհանուր օբյեկտներ օգտագործելու ունակություն

ճարտարապետություն

Պահանջները վերլուծելուց հետո ակնհայտ դարձավ, որ միկրոսերվիսային ճարտարապետությունը գրեթե լիովին համապատասխանում է:

Ավելորդ գլխացավերից ազատվելու համար որպես ֆրոնտենդ ընտրվել է Telegram API-ն։

Նախ, եկեք նայենք պատրաստի ճարտարապետության կառուցվածքային դիագրամին, այնուհետև անցնենք բաղադրիչներից յուրաքանչյուրի նկարագրությանը, ինչպես նաև ձևակերպենք պատկերի հաջող մշակման գործընթացը:

Ավարտված ճարտարապետության կառուցվածքային դիագրամ

Եկեք ավելի մանրամասն խոսենք գծապատկերի յուրաքանչյուր բաղադրիչի մասին՝ նշելով դրանք միայնակ պատասխանատվություն պատկերի գնահատման գործընթացում։

Microservice «attrai-telegram-bot»

Այս միկրոսերվիսը ներառում է բոլոր փոխազդեցությունները Telegram API-ի հետ: Գոյություն ունի 2 հիմնական սցենար՝ աշխատել անհատական ​​պատկերով և աշխատել գնահատման խողովակաշարի արդյունքի հետ: Եկեք նայենք երկու սցենարներին ընդհանուր առումներով:

Պատկերով հատուկ հաղորդագրություն ստանալիս՝

1. Զտումը կատարվում է, որը բաղկացած է հետևյալ ստուգումներից.
   • Պատկերի օպտիմալ չափի առկայությունը
   • Օգտատիրոջ պատկերների թիվն արդեն հերթագրված է
2. Նախնական զտումն անցնելիս պատկերը պահվում է դոկերի ծավալում
3. «to_estimate» հերթում արտադրվում է առաջադրանք, որը ներառում է, ի թիվս այլ բաների, դեպի մեր ծավալում գտնվող պատկերի ուղին
4. Եթե ​​վերը նշված քայլերը հաջողությամբ ավարտվեն, օգտվողը կստանա հաղորդագրություն պատկերի մշակման մոտավոր ժամանակով, որը հաշվարկվում է հերթում առաջադրանքների քանակի հիման վրա: Եթե ​​սխալ առաջանա, օգտատերը հստակ կտեղեկացվի՝ ուղարկելով հաղորդագրություն՝ տեղեկությամբ, թե ինչի մասին կարող է սխալ լինել:

Նաև այս միկրոսերվիսը, ինչպես նեխուրի աշխատողը, լսում է «after_estimate» հերթը, որը նախատեսված է գնահատման խողովակաշարով անցած առաջադրանքների համար։

«after_estimate»-ից նոր առաջադրանք ստանալիս.

1. Եթե ​​պատկերը հաջողությամբ մշակվում է, մենք արդյունքն ուղարկում ենք օգտատիրոջը, եթե ոչ, մենք ծանուցում ենք սխալի մասին:
2. Գնահատման խողովակաշարի արդյունք հանդիսացող պատկերի հեռացում

Գնահատման միկրոսերվիս «attrai-estimator»

Այս միկրոսերվիսը նեխուրի աշխատող է և ընդգրկում է պատկերների գնահատման խողովակաշարի հետ կապված ամեն ինչ: Այստեղ կա միայն մեկ աշխատանքային ալգորիթմ. եկեք վերլուծենք այն:

«to_estimate»-ից նոր առաջադրանք ստանալիս.

1. Եկեք պատկերն անցկացնենք գնահատման խողովակաշարով.
   1. Պատկերի բեռնում հիշողության մեջ
   2. Պատկերը բերում ենք անհրաժեշտ չափի
   3. Գտնել բոլոր դեմքերը (MTCNN)
   4. Մենք գնահատում ենք բոլոր դեմքերը (վերջին քայլում հայտնաբերված դեմքերը փաթաթում ենք խմբաքանակի մեջ և եզրակացնում ResNet34)
   5. Ներկայացրեք վերջնական պատկերը
      1. Եկեք գծենք սահմանող տուփերը
      2. Վարկանիշների նկարում
2. Պատվերով (բնօրինակ) պատկերի ջնջում
3. Արդյունքների պահպանում գնահատման խողովակաշարից
4. Մենք առաջադրանքը դնում ենք «after_estimate» հերթում, որը լսում է վերը քննարկված «attrai-telegram-bot» միկրոծառայությունը։

Graylog (+ mongoDB + Elasticsearch)

Գրեյլոգ լոգերի կենտրոնացված կառավարման լուծում է: Այս նախագծում այն ​​օգտագործվել է իր նպատակային նպատակի համար:

Ընտրությունն ընկավ նրա վրա, այլ ոչ թե սովորականի ELK stack, շնորհիվ Python-ից դրա հետ աշխատելու հարմարության: Գրեյլոգ մուտք գործելու համար անհրաժեշտ է միայն փաթեթից ավելացնել GELFTCPHandler-ը մոխրագույն մեր python microservice-ի մնացած root լոգերի մշակողներին:

Որպես մեկը, ով նախկինում աշխատել է միայն ELK stack-ի հետ, ես ընդհանուր դրական փորձ ունեցա Graylog-ի հետ աշխատելիս: Միակ բանը, որ վհատեցնում է, Kibana-ի հատկանիշների առավելությունն է Graylog վեբ ինտերֆեյսի նկատմամբ:

Rabbit MQ

Rabbit MQ AMQP արձանագրության վրա հիմնված հաղորդագրությունների բրոքեր է:

Այս նախագծում այն ​​օգտագործվել է որպես ամենակայունը և ժամանակի փորձարկվածը բրոքեր Նեխուրի համար և աշխատել երկարակյաց ռեժիմով:

Redis

Redis NoSQL DBMS է, որն աշխատում է առանցքային արժեքի տվյալների կառուցվածքների հետ

Երբեմն անհրաժեշտություն է առաջանում օգտագործել ընդհանուր օբյեկտներ, որոնք իրականացնում են տվյալների որոշակի կառուցվածքներ Python-ի տարբեր միկրոծառայություններում:

Օրինակ, Redis-ը պահում է «telegram_user_id => շարք ակտիվ առաջադրանքների հերթում» ձևի հաշքապը, որը թույլ է տալիս սահմանափակել մեկ օգտագործողի հարցումների քանակը որոշակի արժեքով և դրանով իսկ կանխել DoS հարձակումները:

Եկեք պաշտոնականացնենք պատկերի հաջող մշակման գործընթացը

1. Օգտատերը պատկեր է ուղարկում Telegram բոտին
2. «attrai-telegram-bot»-ը հաղորդագրություն է ստանում Telegram API-ից և վերլուծում այն
3. Պատկերով առաջադրանքն ավելացվում է «to_estimate» ասինխրոն հերթում
4. Օգտագործողը ստանում է հաղորդագրություն պլանավորված գնահատման ժամանակով
5. «attrai-estimator»-ը առաջադրանք է վերցնում «to_estimate» հերթից, կատարում է գնահատումները խողովակաշարով և առաջադրանքը արտադրում «after_estimate» հերթում:
6. «attrai-telegram-bot»-ը, լսելով «after_estimate» հերթը, արդյունքն ուղարկում է օգտատիրոջը

DevOps

Վերջապես, ճարտարապետությունը վերանայելուց հետո կարող եք անցնել նույնքան հետաքրքիր հատվածին՝ DevOps-ին

Docker ամբոխ

 

Docker ամբոխ  — կլաստերավորման համակարգ, որի ֆունկցիոնալությունը ներդրված է Docker Engine-ի ներսում և հասանելի է տուփից դուրս:

Օգտագործելով «երամ»՝ մեր կլաստերի բոլոր հանգույցները կարելի է բաժանել 2 տեսակի՝ աշխատող և կառավարիչ: Առաջին տիպի մեքենաների վրա տեղակայվում են բեռնարկղերի խմբեր (կույտեր), երկրորդ տիպի մեքենաները պատասխանատու են մասշտաբման, հավասարակշռման և. այլ հետաքրքիր հատկություններ. Կառավարիչները նույնպես լռելյայն աշխատողներ են:

Կլաստեր մեկ առաջնորդ ղեկավարի և երեք աշխատողի հետ

Կլաստերի նվազագույն հնարավոր չափը 1 հանգույց է, մեկ մեքենա միաժամանակ հանդես կգա որպես առաջատար կառավարիչ և աշխատող: Ելնելով նախագծի չափից և սխալների հանդուրժողականության նվազագույն պահանջներից՝ որոշվեց կիրառել այս մոտեցումը:

Նայելով առաջ՝ ես կասեմ, որ արտադրության առաջին առաքումից ի վեր, որը տեղի ունեցավ հունիսի կեսերին, այս կլաստերային կազմակերպության հետ կապված որևէ խնդիր չի եղել (բայց դա չի նշանակում, որ նման կազմակերպությունը որևէ կերպ ընդունելի է ցանկացած միջին և խոշոր չափերի համար։ նախագծեր, որոնք ենթակա են սխալների հանդուրժողականության պահանջներին):

Docker Stack

Swarm ռեժիմում նա պատասխանատու է կույտերի տեղակայման համար (դոկերի ծառայությունների հավաքածուներ) docker stack

Այն աջակցում է docker-compose կոնֆիգուրացիաներին՝ թույլ տալով լրացուցիչ օգտագործել տեղակայման տարբերակները:  

Օրինակ, օգտագործելով այս պարամետրերը, յուրաքանչյուր գնահատման միկրոծառայության դեպքի համար ռեսուրսները սահմանափակ էին (մենք N միջուկներ ենք հատկացնում N օրինակների համար, իսկ միկրոսերվիսում մենք սահմանափակում ենք PyTorch-ի կողմից օգտագործվող միջուկների թիվը մեկով):

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

Կարևոր է նշել, որ Redis-ը, RabbitMQ-ն և Graylog-ը պետական ​​ծառայություններ են, և դրանք չեն կարող չափավորվել այնքան հեշտությամբ, որքան «attrai-estimator»-ը:

Նախագուշակելով հարցը՝ ինչու ոչ Kubernetes-ը:

Թվում է, թե Kubernetes-ի օգտագործումը փոքր և միջին նախագծերում գերբեռնվածություն է, բոլոր անհրաժեշտ գործառույթները կարելի է ձեռք բերել Docker Swarm-ից, որը բավականին հարմար է կոնտեյներային նվագախմբի համար և ունի նաև մուտքի ցածր խոչընդոտ:

Ենթակառուցվածքի

Այս ամենը տեղադրվել է VDS-ի վրա հետևյալ բնութագրերով.

• Պրոցեսոր՝ 4 միջուկ Intel® Xeon® Gold 5120 CPU @ 2.20 ԳՀց
• RAM: 8 ԳԲ
• SSD՝ 160 ԳԲ

Տեղական բեռնվածության փորձարկումից հետո թվում էր, որ օգտագործողների լուրջ հոսքի դեպքում այս մեքենան բավական կլինի:

Բայց տեղակայումից անմիջապես հետո ես տեղադրեցի ԱՊՀ-ի ամենահայտնի պատկերատախտակներից մեկի հղումը (այո, նույնը), որից հետո մարդիկ սկսեցին հետաքրքրվել և մի քանի ժամում ծառայությունը հաջողությամբ մշակեց տասնյակ հազարավոր պատկերներ: Միևնույն ժամանակ, պիկ պահերին CPU-ի և RAM-ի ռեսուրսները նույնիսկ կիսով չափ չէին օգտագործվում:

Եվս մի քանի գրաֆիկա

Եզակի օգտագործողների թիվը և գնահատման հարցումները տեղակայումից ի վեր՝ կախված օրվանից

Գնահատման խողովակաշարի եզրակացության ժամանակի բաշխում

Արդյունքները

Ամփոփելու համար կարող եմ ասել, որ կոնտեյներների նվագախմբավորման ճարտարապետությունն ու մոտեցումը լիովին արդարացնում էին իրենց. 

Կարծում եմ, որ փոքր և միջին նախագծերը, որոնք իրենց գործընթացում օգտագործում են նեյրոնային ցանցերի իրական ժամանակում եզրակացություն CPU-ի վրա, կարող են հաջողությամբ ընդունել այս հոդվածում նկարագրված պրակտիկան:

Ավելացնեմ, որ ի սկզբանե հոդվածն ավելի երկար էր, բայց երկարատև չհրապարակելու համար որոշեցի բաց թողնել այս հոդվածում որոշ կետեր. մենք կանդրադառնանք դրանց հետագա հրապարակումներում:

Դուք կարող եք բոտը տեղադրել Telegram-ում՝ @AttraiBot, այն կաշխատի առնվազն մինչև 2020 թվականի աշնան վերջ։ Հիշեցնեմ, որ օգտատիրոջ ոչ մի տվյալ չի պահվում՝ ոչ բնօրինակ պատկերները, ոչ էլ գնահատման խողովակաշարի արդյունքները, մշակումից հետո ամեն ինչ քանդվում է։

Source: www.habr.com