кіру
Сәлем!
Бұл мақалада мен нейрондық желілерді қолданатын жоба үшін микросервис архитектурасын құру тәжірибеммен бөлісемін.
Сәулет талаптары туралы сөйлесейік, әртүрлі құрылымдық диаграммаларды қарастырайық, дайын архитектураның әрбір құрамдас бөлігін талдаймыз, сонымен қатар шешімнің техникалық көрсеткіштерін бағалайық.
Оқуға ләззат алыңыз!
Мәселе және оның шешімі туралы бірнеше сөз
Негізгі идея - фотосурет негізінде адамның тартымдылығын он балдық шкала бойынша бағалау.
Бұл мақалада біз пайдаланылатын нейрондық желілерді де, деректерді дайындау мен оқыту процесін де сипаттаудан бас тартамыз. Дегенмен, келесі басылымдардың бірінде біз бағалау құбырын терең деңгейде талдауға міндетті түрде ораламыз.
Енді біз жоғары деңгейде бағалау құбырынан өтеміз және жобаның жалпы архитектурасы контекстінде микросервистердің өзара әрекеттесуіне назар аударамыз.
Тартымдылықты бағалау құбырында жұмыс істеу кезінде тапсырма келесі компоненттерге бөлінді:
- Фотосуреттердегі беттерді таңдау
- Әр адамның бағалауы
- Нәтижені көрсетіңіз
Біріншісі алдын ала дайындалған күштермен шешіледі . Екіншісі үшін конволюционды нейрондық желі PyTorch арқылы оқытылды – «процессордағы нәтиженің сапасы / жылдамдығы» теңгерімінен
Бағалау құбырының функционалдық диаграммасы
Жоба архитектурасына қойылатын талаптарды талдау
Өмірлік циклде Модельді орналастырудың архитектурасы мен автоматтандыруы бойынша жұмыстың жобалық кезеңдері көбінесе ең көп уақытты қажет ететін және ресурстарды қажет ететін кезеңдердің бірі болып табылады.
ML жобасының өмірлік циклі
Бұл жоба ерекшелік емес - бағалау құбырын архитектураға енуді қажет ететін онлайн сервиске айналдыру туралы шешім қабылданды. Келесі негізгі талаптар анықталды:
- Бірыңғай журнал қоймасы – барлық қызметтер журналдарды бір жерде жазуы керек, олар талдауға ыңғайлы болуы керек
- Бағалау қызметінің көлденең масштабтау мүмкіндігі – ең ықтимал Төменге ретінде
- Қорытынды жасау уақытын бөлу кезінде шектен тыс мәндерді болдырмау үшін әрбір кескінді бағалау үшін процессор ресурстарының бірдей көлемін бөлу керек.
- Арнайы қызметтерді де, тұтастай стекті де жылдам (қайта) орналастыру
- Қажет болған жағдайда әртүрлі қызметтерде ортақ объектілерді пайдалану мүмкіндігі
сәулет
Талаптарды талдағаннан кейін микросервис архитектурасы дерлік тамаша сәйкес келетіні белгілі болды.
Қажетсіз бас ауруларынан құтылу үшін Telegram API интерфейсі таңдалды.
Алдымен, дайын архитектураның құрылымдық диаграммасын қарастырайық, содан кейін компоненттердің әрқайсысының сипаттамасына көшеміз, сонымен қатар кескінді сәтті өңдеу процесін ресімдейміз.
Дайын архитектураның құрылымдық схемасы
Суретті бағалау процесінде оларды Бірыңғай жауапкершілік деп белгілей отырып, диаграмманың әрбір құрамдас бөлігі туралы толығырақ сөйлесейік.
«attrai-telegram-bot» микросервис
Бұл микросервис Telegram API интерфейсімен барлық өзара әрекеттесуді қамтиды. 2 негізгі сценарий бар: теңшелетін кескінмен жұмыс және бағалау құбырының нәтижесімен жұмыс. Жалпы екі сценарийді де қарастырайық.
Суреті бар теңшелетін хабарды алған кезде:
- Сүзу келесі тексерулерден тұратын орындалады:
- Оңтайлы кескін өлшемінің болуы
- Кезекте тұрған пайдаланушы кескіндерінің саны
- Бастапқы сүзгіден өткен кезде сурет докер көлемінде сақталады
- Тапсырма «бағалау_бағалау» кезегінде жасалады, ол басқа нәрселермен қатар біздің томда орналасқан кескінге жолды қамтиды
- Жоғарыда аталған қадамдар сәтті орындалса, пайдаланушы кезектегі тапсырмалар санына қарай есептелетін кескінді өңдеудің шамамен уақыты бар хабарлама алады. Қате орын алса, пайдаланушы қате болуы мүмкін ақпараты бар хабарламаны жіберу арқылы анық хабарланады.
Сондай-ақ, бұл микросервис, балдыркөк жұмысшысы сияқты, бағалау құбыры арқылы өткен тапсырмаларға арналған «бағалаудан кейінгі» кезекті тыңдайды.
"Кейін_бағалаудан" жаңа тапсырма алған кезде:
- Егер сурет сәтті өңделсе, нәтижені пайдаланушыға жібереміз, егер олай болмаса, қате туралы хабарлаймыз.
- Бағалау құбырының нәтижесі болып табылатын кескінді жою
«attrai-estimator» бағалау микросервисі
Бұл микросервис балдыркөк жұмысшысы болып табылады және кескінді бағалау құбырына қатысты барлық нәрсені қамтиды. Мұнда бір ғана жұмыс алгоритмі бар – оны талдап көрейік.
«Бағалау_бағалауынан» жаңа тапсырма алған кезде:
- Кескінді бағалау құбыры арқылы іске қосайық:
- Кескінді жадқа жүктеу
- Біз суретті қажетті өлшемге келтіреміз
- Барлық беттерді табу (MTCNN)
- Біз барлық беттерді бағалаймыз (соңғы қадамда табылған беттерді пакетке орап, ResNet34 тұжырымын жасаймыз)
- Соңғы кескінді көрсетіңіз
- Шектеу жолақтарын салайық
- Бағалауды құрастыру
- Пайдаланушы (түпнұсқа) кескінді жою
- Бағалау құбырының шығысын сақтау
- Біз тапсырманы жоғарыда талқыланған «attrai-telegram-bot» микросервисі тыңдайтын «кейінгі_бағалау» кезегіне қоямыз.
Graylog (+ mongoDB + Elasticsearch)
орталықтандырылған журналды басқаруға арналған шешім болып табылады. Бұл жобада ол өз мақсатына сай пайдаланылды.
Таңдау әдеттегіге емес, оған түсті стек, онымен Python-дан жұмыс істеу ыңғайлылығына байланысты. Graylog жүйесіне кіру үшін сізге тек пакеттен GELFTCPHandler қосу керек python микросервисіміздің қалған түбірлік тіркеуші өңдеушілеріне.
Бұрын тек ELK стекімен жұмыс істеген адам ретінде мен Graylog-пен жұмыс істеу барысында жалпы оң тәжірибе алдым. Көңілге қалдыратын жалғыз нәрсе - Kibana мүмкіндіктерінің Graylog веб-интерфейсінен артықшылығы.
Қоян MQ
AMQP протоколына негізделген хабарлама брокері.
Бұл жобада ол ретінде пайдаланылды балдыркөк үшін брокер және берік режимде жұмыс істеді.
Редис
кілт-мән деректер құрылымдарымен жұмыс істейтін NoSQL ДҚБЖ болып табылады
Кейде әртүрлі Python микросервистерінде белгілі бір деректер құрылымдарын жүзеге асыратын жалпы нысандарды пайдалану қажеттілігі туындайды.
Мысалы, Redis «telegram_user_id => кезектегі белсенді тапсырмалардың саны» пішіміндегі хэшмапты сақтайды, бұл бір пайдаланушының сұрауларының санын белгілі бір мәнге дейін шектеуге және осылайша DoS шабуылдарына жол бермеуге мүмкіндік береді.
Кескінді сәтті өңдеу процесін ресімдейік
- Пайдаланушы суретті Telegram ботына жібереді
- "attrai-telegram-bot" Telegram API интерфейсінен хабарлама алады және оны талдайды
- Суреті бар тапсырма "to_estimate" асинхронды кезекке қосылады.
- Пайдаланушы жоспарланған бағалау уақыты бар хабарлама алады
- «attrai-estimator» «бағалау_бағалау» кезегінен тапсырма алады, бағалауларды құбыр арқылы жүргізеді және тапсырманы «бағалаудан кейінгі» кезекке шығарады
- "attrai-telegram-bot" "кейінгі_бағалау" кезегін тыңдап, нәтижені пайдаланушыға жібереді
DevOps
Соңында, архитектураны қарап шыққаннан кейін, сіз бірдей қызықты бөлікке - DevOps-ке ауыса аласыз
Докер үйірі
— функционалдығы Docker Engine ішінде жүзеге асырылатын және қораптан тыс қол жетімді кластерлік жүйе.
«Үйірді» пайдаланып, біздің кластердегі барлық түйіндерді екі түрге бөлуге болады - жұмысшы және менеджер. Бірінші типті машиналарда контейнерлер топтары (штабтар) орналастырылады, екінші типтегі машиналар масштабтау, теңгерімдеу және . Менеджерлер де әдепкі бойынша жұмысшылар.
Бір жетекші менеджер және үш жұмысшы бар кластер
Кластердің ең аз мүмкін өлшемі - 1 түйін; бір машина бір уақытта жетекші менеджер мен жұмысшы ретінде әрекет етеді. Жобаның көлеміне және ақауларға төзімділікке қойылатын минималды талаптарға сүйене отырып, осы тәсілді қолдану туралы шешім қабылданды.
Алға қарай, мен маусым айының ортасында болған алғашқы өнім жеткізілімінен бері бұл кластерлік ұйыммен байланысты ешқандай проблемалар болмағанын айтқым келеді (бірақ бұл мұндай ұйым кез келген ортада қолайлы дегенді білдірмейді. ақауларға төзімділік талаптарына жататын жобалар).
Docker стегі
Үйір режимінде ол стектерді (докер қызметтерінің жиынтығы) орналастыруға жауапты.
Ол қолдану параметрлерін қосымша пайдалануға мүмкіндік беретін докер құрастыру конфигурацияларын қолдайды.
Мысалы, осы параметрлерді пайдалана отырып, әрбір бағалау микросервис даналары үшін ресурстар шектеулі болды (біз 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-ті пайдалану үлкен шығындар болып табылатын сияқты; барлық қажетті функционалдылықты Docker Swarm-тен алуға болады, ол контейнерлік оркестр үшін өте ыңғайлы және сонымен қатар кіруге кедергісі төмен.
Инфрақұрылым
Мұның бәрі келесі сипаттамалармен VDS-де орналастырылған:
- Орталық процессор: 4 ядролы Intel® Xeon® Gold 5120 CPU @ 2.20 ГГц
- RAM: 8 ГБ
- SSD: 160 ГБ
Жергілікті жүктемені тестілеуден кейін, пайдаланушылардың елеулі ағыны кезінде бұл машина жеткілікті болатын сияқты.
Бірақ, орналастырудан кейін бірден мен ТМД-дағы ең танымал сурет тақталарының біріне сілтеме жарияладым (иә, дәл сол), содан кейін адамдар қызығушылық танытты және бірнеше сағат ішінде қызмет ондаған мың кескіндерді сәтті өңдеді. Сонымен қатар, ең жоғары сәттерде CPU және RAM ресурстары тіпті жартысы пайдаланылмады.
Тағы бірнеше графика
Бірегей пайдаланушылар саны және күнге байланысты орналастырудан кейінгі бағалау сұраулары
Бағалау құбырының қорытынды уақытын бөлу
қорытындылар
Қорытындылай келе, мен контейнерлерді оркестрлеудің архитектурасы мен тәсілі өзін толығымен ақтады деп айта аламын - тіпті ең жоғары сәттерде өңдеу уақытында ешқандай құлдырау немесе салдар болған жоқ.
Менің ойымша, процесс барысында орталық процессордағы нейрондық желілердің нақты уақыт режиміндегі қорытындысын қолданатын шағын және орта жобалар осы мақалада сипатталған тәжірибелерді сәтті қабылдай алады.
Мен мақаланың бастапқыда ұзағырақ болғанын қосамын, бірақ ұзақ оқылмау үшін мен осы мақаладағы кейбір тармақтарды алып тастауды шештім - біз оларға болашақ басылымдарда қайта ораламыз.
Сіз ботты Telegram - @AttraiBot-та сүзе аласыз, ол кем дегенде 2020 жылдың күзінің соңына дейін жұмыс істейді. Еске сала кетейін, пайдаланушы деректері сақталмайды - түпнұсқа кескіндер де, бағалау құбырының нәтижелері де - өңдеуден кейін бәрі жойылады.
Ақпарат көзі: www.habr.com