Улазак
Здраво!
У овом чланку ћу поделити своје искуство изградње микросервисне архитектуре за пројекат који користи неуронске мреже.
Хајде да разговарамо о захтевима архитектуре, погледамо различите структурне дијаграме, анализирамо сваку од компоненти готове архитектуре, а такође проценимо техничке метрике решења.
Уживајте у читању!
Неколико речи о проблему и његовом решењу
Главна идеја је да се на основу фотографије процени привлачност особе на скали од десет тачака.
У овом чланку ћемо се удаљити од описивања како неуронских мрежа које се користе, тако и процеса припреме података и обуке. Међутим, у једној од следећих публикација, дефинитивно ћемо се вратити на детаљну анализу процеса процене.
Сада ћемо проћи кроз цевовод евалуације на највишем нивоу и фокусираћемо се на интеракцију микросервиса у контексту укупне архитектуре пројекта.
Приликом рада на цевоводу за процену атрактивности, задатак је декомпонован на следеће компоненте:
- Избор лица на фотографијама
- Оцена сваке особе
- Рендер резултат
Први решавају снаге унапред обучених . За друго, конволуциона неуронска мрежа је обучена на ПиТорцх-у, користећи – из равнотеже „квалитет / брзина закључивања на ЦПУ-у“
Функционални дијаграм цевовода евалуације
Анализа захтева архитектуре пројекта
У животном циклусу пројектне фазе рада на архитектури и аутоматизацији имплементације модела често су међу најзахтјевнијим и ресурсима.
Животни циклус МЛ пројекта
Овај пројекат није изузетак – донета је одлука да се цевовод за процену умота у онлајн сервис, што је захтевало да се удубимо у архитектуру. Идентификовани су следећи основни захтеви:
- Јединствено складиштење дневника – све услуге треба да пишу дневнике на једном месту, требало би да буду згодне за анализу
- Могућност хоризонталног скалирања услуге процене - као највероватније уско грло
- Иста количина ресурса процесора треба да се додели за процену сваке слике како би се избегли одступници у расподели времена за закључивање
- Брзо (поновно) распоређивање како одређених услуга, тако и читавог стека
- Могућност, ако је потребно, коришћења заједничких објеката у различитим сервисима
архитектура
Након анализе захтева, постало је очигледно да се микросервисна архитектура готово савршено уклапа.
Да бисмо се решили непотребних главобоља, Телеграм АПИ је изабран као фронтенд.
Прво, погледајмо структурни дијаграм готове архитектуре, затим пређимо на опис сваке од компоненти, а такође формализујемо процес успешне обраде слике.
Структурни дијаграм готове архитектуре
Хајде да разговарамо детаљније о свакој од компоненти дијаграма, означавајући их као појединачну одговорност у процесу евалуације слике.
Микросервис „аттраи-телеграм-бот”
Овај микросервис обухвата све интеракције са Телеграм АПИ-јем. Постоје 2 главна сценарија: рад са прилагођеном сликом и рад са резултатом процене. Погледајмо оба сценарија уопштено.
Када примите прилагођену поруку са сликом:
- Филтрација се врши, која се састоји од следећих провера:
- Доступност оптималне величине слике
- Број корисничких слика које су већ у реду
- Када прође почетно филтрирање, слика се чува у доцкер волумену
- Задатак се производи у реду „то_естимате“, који укључује, између осталог, путању до слике која се налази у нашем волумену
- Ако су горе наведени кораци успешно обављени, корисник ће добити поруку са приближним временом обраде слике, које се израчунава на основу броја задатака у реду. Ако дође до грешке, корисник ће бити експлицитно обавештен слањем поруке са информацијама о томе шта је можда пошло наопако.
Такође, овај микросервис, попут целер радника, слуша „афтер_естимате“ ред, који је намењен задацима који су прошли кроз цевовод за евалуацију.
Када добијете нови задатак од „афтер_естимате“:
- Ако је слика успешно обрађена, резултат шаљемо кориснику, ако није, обавештавамо о грешци.
- Уклањање слике која је резултат цевовода евалуације
Микросервис евалуације „аттраи-естиматор“
Овај микросервис је целер радник и обухвата све што је у вези са цевоводом за процену слике. Овде постоји само један радни алгоритам - хајде да га анализирамо.
Када добијете нови задатак од „то_естимате“:
- Хајде да прођемо слику кроз цевовод за евалуацију:
- Учитавање слике у меморију
- Доводимо слику до потребне величине
- Проналажење свих лица (МТЦНН)
- Процењујемо сва лица (умотавамо лица пронађена у последњем кораку у групу и закључујемо РесНет34)
- Израдите коначну слику
- Хајде да нацртамо граничне кутије
- Цртање оцена
- Брисање прилагођене (оригиналне) слике
- Чување излаза из цевовода за евалуацију
- Стављамо задатак у „афтер_естимате“ ред, који слуша микросервис „аттраи-телеграм-бот“ о коме смо горе говорили.
Граилог (+ монгоДБ + Еластицсеарцх)
је решење за централизовано управљање дневником. У овом пројекту је коришћен за своју намену.
Избор је пао на њега, а не на ону уобичајену стек, због погодности рада са њим из Питхон-а. Све што треба да урадите да бисте се пријавили на Граилог је да додате ГЕЛФТЦПХандлер из пакета до остатка руковаоца роот логера нашег питхон микросервиса.
Као неко ко је раније радио само са ЕЛК стеком, имао сам свеукупно позитивно искуство док сам радио са Граилог-ом. Једина ствар која је депресивна је супериорност Кибана функција над Граилог веб интерфејсом.
РаббитМК
је посредник порука заснован на АМКП протоколу.
У овом пројекту је коришћен као брокер за Целери и радио у трајном режиму.
Редис
је НоСКЛ ДБМС који ради са структурама података кључ/вредност
Понекад постоји потреба да се користе уобичајени објекти који имплементирају одређене структуре података у различитим Питхон микросервисима.
На пример, Редис складишти хасхмап у облику „телеграм_усер_ид => број активних задатака у реду“, који вам омогућава да ограничите број захтева од једног корисника на одређену вредност и на тај начин спречите ДоС нападе.
Хајде да формализујемо процес успешне обраде слике
- Корисник шаље слику Телеграм боту
- „аттраи-телеграм-бот“ прима поруку од Телеграм АПИ-ја и анализира је
- Задатак са сликом се додаје у асинхрони ред „то_естимате“
- Корисник добија поруку са планираним временом евалуације
- „аттраи-естиматор“ узима задатак из реда „то_естимате“, покреће процене кроз цевовод и производи задатак у „афтер_естимате“ ред
- "аттраи-телеграм-бот" слуша "афтер_естимате" ред, шаље резултат кориснику
ДевОпс
Коначно, након прегледа архитектуре, можете прећи на подједнако занимљив део - ДевОпс
Доцкер Сварм
— систем кластеризације, чија је функционалност имплементирана унутар Доцкер Енгине-а и доступна је ван кутије.
Користећи „рој“, сви чворови у нашем кластеру могу се поделити на 2 типа – радник и менаџер. На машинама првог типа постављају се групе контејнера (слагања), машине другог типа су одговорне за скалирање, балансирање и . Менаџери су такође радници подразумевано.
Кластер са једним лидером менаџером и три радника
Минимална могућа величина кластера је 1 чвор, једна машина ће истовремено деловати као менаџер и радник. На основу величине пројекта и минималних захтева за толеранцију грешака, одлучено је да се користи овај приступ.
Гледајући унапред, рећи ћу да од прве испоруке производње, која је била средином јуна, није било никаквих проблема везаних за ову кластерску организацију (али то не значи да је таква организација на било који начин прихватљива у било којој средње великој пројекти, који подлежу захтевима толеранције грешака).
Доцкер Стацк
У режиму роја, он је одговоран за распоређивање стекова (скупова доцкер услуга)
Подржава конфигурације за доцкер-цомпосе, омогућавајући вам да додатно користите опције постављања.
На пример, коришћењем ових параметара, ресурси за сваку инстанцу микросервиса за евалуацију су били ограничени (додељујемо Н језгара за Н инстанци, у самој микросервиси ограничавамо број језгара које ПиТорцх користи на један)
attrai_estimator:
image: 'erqups/attrai_estimator:1.2'
deploy:
replicas: 4
resources:
limits:
cpus: '4'
restart_policy:
condition: on-failure
…Важно је напоменути да су Редис, РаббитМК и Граилог сервиси са стањем и не могу се скалирати тако лако као „аттраи-естиматор“
Наговјештавајући питање - зашто не Кубернетес?
Чини се да је коришћење Кубернетеса у малим и средњим пројектима прекомерно, све потребне функционалности се могу добити од Доцкер Сварм-а, који је прилично једноставан за употребу за оркестратора контејнера и такође има ниску баријеру за улазак.
Инфраструктура
Све ово је постављено на ВДС са следећим карактеристикама:
- ЦПУ: 4 језгра Интел® Ксеон® Голд 5120 ЦПУ на 2.20 ГХз
- РАМ: КСНУМКС МБ
- ССД: 160 ГБ
Након локалног тестирања оптерећења, чинило се да би уз озбиљан прилив корисника ова машина била довољна.
Али, одмах након постављања, поставио сам линк до једног од најпопуларнијих имиџбоарда у ЗНД (да, тог истог), након чега су се људи заинтересовали и сервис је за неколико сати успешно обрадио десетине хиљада слика. Истовремено, у тренуцима врхунца, ЦПУ и РАМ ресурси нису искоришћени ни напола.
Још неке графике
Број јединствених корисника и захтева за процену од примене, у зависности од дана
Расподела времена за закључивање цевовода за евалуацију
Налази
Да резимирам, могу рећи да су се архитектура и приступ оркестрацији контејнера у потпуности оправдали - чак ни у тренуцима врхунца није било падова или пропадања у времену обраде.
Мислим да мали и средњи пројекти који у свом процесу користе закључивање неуронских мрежа на ЦПУ у реалном времену могу успешно усвојити праксе описане у овом чланку.
Додаћу да је у почетку чланак био дужи, али да не бих дуго читао, одлучио сам да изоставим неке тачке у овом чланку - на њих ћемо се вратити у будућим публикацијама.
Бота можете убацити на Телеграм - @АттраиБот, радиће најмање до краја јесени 2020. Дозволите ми да вас подсетим да се не чувају никакви кориснички подаци – ни оригиналне слике, ни резултати процене – све се руши након обраде.
Извор: ввв.хабр.цом
