Влегување
Здраво!
Во оваа статија ќе го споделам моето искуство за градење микросервисна архитектура за проект со помош на невронски мрежи.
Ајде да зборуваме за барањата за архитектура, да погледнеме различни структурни дијаграми, да ја анализираме секоја од компонентите на завршената архитектура, а исто така да ја процениме техничката метрика на решението.
Уживајте во читањето!
Неколку зборови за проблемот и неговото решение
Главната идеја е да се оцени привлечноста на една личност на скала од десет точки врз основа на фотографија.
Во оваа статија ќе се оддалечиме од опишување и на користените невронски мрежи и на процесот на подготовка и обука на податоци. Сепак, во една од следните публикации, дефинитивно ќе се вратиме на анализа на цевководот за проценка на длабинско ниво.
Сега ќе поминеме низ цевководот за евалуација на највисоко ниво и ќе се фокусираме на интеракцијата на микросервисите во контекст на целокупната архитектура на проектот.
Кога се работеше на цевководот за проценка на атрактивноста, задачата беше разложена на следните компоненти:
- Избор на лица на фотографии
- Оценка на секоја личност
- Преведете го резултатот
Првиот го решаваат силите на претходно обучени . За втората, конволутивна невронска мрежа беше обучена на PyTorch, користејќи – од билансот „квалитет / брзина на заклучување на процесорот“
Функционален дијаграм на цевководот за евалуација
Анализа на барањата за проектна архитектура
Во животниот циклус проектните фази на работа на архитектурата и автоматизацијата на распоредувањето на моделот честопати се едни од оние кои одземаат многу време и одземаат ресурси.
Животен циклус на проект за ML
Овој проект не е исклучок - беше донесена одлука цевководот за проценка да се завитка во онлајн услуга, што бараше да се потопиме во архитектурата. Следниве основни барања беа идентификувани:
- Унифицирано складирање на дневници - сите услуги треба да пишуваат дневници на едно место, тие треба да бидат погодни за анализа
- Можност за хоризонтално скалирање на услугата за оценување - како најверојатна Тесно грло
- Треба да се доделат иста количина на ресурси на процесорот за да се процени секоја слика со цел да се избегнат отстапувања во распределбата на времето за заклучување
- Брзо (повторно) распоредување и на специфични услуги и на стекот како целина
- Способност, доколку е потребно, да се користат заеднички објекти во различни услуги
архитектура
По анализата на барањата, стана очигледно дека микросервисната архитектура се вклопува речиси совршено.
Со цел да се ослободиме од непотребните главоболки, Telegram API беше избран како преден дел.
Прво, да го погледнеме структурниот дијаграм на завршената архитектура, потоа да преминеме на опис на секоја од компонентите, а исто така да го формализираме процесот на успешна обработка на сликата.
Структурен дијаграм на завршената архитектура
Ајде да разговараме подетално за секоја од компонентите на дијаграмот, означувајќи ги Единствена одговорност во процесот на евалуација на сликата.
Микросервис „attrai-telegram-bot“
Овој микросервис ги опфаќа сите интеракции со Telegram API. Постојат 2 главни сценарија: работа со прилагодена слика и работа со резултат од проценка. Да ги погледнеме двете сценарија во општи рамки.
Кога примате приспособена порака со слика:
- Се врши филтрација, која се состои од следните проверки:
- Достапност на оптимална големина на сликата
- Број на кориснички слики веќе во редица
- Кога го поминувате почетното филтрирање, сликата се зачувува во јачината на звукот на докерот
- Во редот „to_estimate“ се создава задача, која меѓу другото ја вклучува и патеката до сликата лоцирана во нашиот волумен
- Доколку горенаведените чекори се успешно завршени, корисникот ќе добие порака со приближното време за обработка на сликата, кое се пресметува врз основа на бројот на задачи во редот. Ако се појави грешка, корисникот ќе биде експлицитно известен со испраќање порака со информации за тоа што можеби тргнало наопаку.
Исто така, овој микросервис, како работник на целер, ја слуша редицата „after_estimate“, која е наменета за задачи што поминале низ цевководот за оценување.
Кога примате нова задача од „after_estimate“:
- Ако сликата е успешно обработена, резултатот го испраќаме до корисникот, ако не, известуваме за грешка.
- Отстранување на сликата што е резултат на цевководот за евалуација
Микросервис за евалуација „attrai-estimator“
Овој микросервис е работник на целер и содржи се што е поврзано со цевководот за евалуација на сликата. Тука има само еден работен алгоритам - ајде да го анализираме.
Кога примате нова задача од „to_estimate“:
- Ајде да ја поминеме сликата низ цевководот за евалуација:
- Вчитување на сликата во меморија
- Ја доведуваме сликата до потребната големина
- Пронаоѓање на сите лица (MTCNN)
- Ги проценуваме сите лица (ги обвиткуваме лицата пронајдени во последниот чекор во серија и заклучуваме ResNet34)
- Рендерирајте ја конечната слика
- Ајде да ги нацртаме граничните полиња
- Цртање на оценките
- Бришење прилагодена (оригинална) слика
- Зачувување на излезот од цевководот за евалуација
- Задачата ја ставаме во редот „after_estimate“, кој го слуша микросервисот „attrai-telegram-bot“ што беше дискутиран погоре.
Graylog (+ mongoDB + Elasticsearch)
е решение за централизирано управување со дневниците. Во овој проект тој беше искористен за намената.
Изборот падна на него, а не на вообичаениот стек, поради практичноста да се работи со него од Python. Сè што треба да направите за да се најавите на Graylog е да го додадете GELFTCPHandler од пакетот на остатокот од ракувачите на root logger на нашиот микросервис за python.
Како некој што претходно работел само со ELK stack, имав севкупно позитивно искуство додека работев со Graylog. Единственото нешто што е депресивно е супериорноста во карактеристиките на Kibana во однос на веб-интерфејсот на Graylog.
Зајакот MQ
е брокер за пораки базиран на протоколот AMQP.
Во овој проект се користеше како брокер за целер и работеше во издржлив режим.
Redis
е NoSQL DBMS што работи со структури на податоци со клучна вредност
Понекогаш има потреба да се користат заеднички објекти кои имплементираат одредени структури на податоци во различни микросервиси на Python.
На пример, Redis складира хашмапа од формата „telegram_user_id => број на активни задачи во редот“, што ви овозможува да го ограничите бројот на барања од еден корисник на одредена вредност и, со тоа, да спречите DoS напади.
Ајде да го формализираме процесот на успешна обработка на слики
- Корисникот испраќа слика до ботот на Telegram
- „attrai-telegram-bot“ добива порака од Telegram API и ја анализира
- Задачата со сликата се додава во асинхроната редица „to_estimate“
- Корисникот добива порака со планираното време за оценување
- „attrai-estimator“ зема задача од редот „to_estimate“, ги извршува проценките низ цевководот и ја произведува задачата во редот „after_estimate“
- „attrai-telegram-bot“ слушајќи ја редицата „after_estimate“, го испраќа резултатот до корисникот
DevOps
Конечно, откако ќе ја разгледате архитектурата, можете да преминете на подеднакво интересниот дел - DevOps
Докер рој
— систем за кластерирање, чија функционалност е имплементирана во Docker Engine и е достапен надвор од кутијата.
Користејќи „рој“, сите јазли во нашиот кластер можат да се поделат на 2 типа - работник и менаџер. На машините од првиот тип, групи на контејнери (купови) се распоредени, машините од вториот тип се одговорни за скалирање, балансирање и . И менаџерите се стандардно работници.
Кластер со еден лидер менаџер и тројца работници
Минималната можна големина на кластерот е 1 јазол; една машина истовремено ќе дејствува како лидер менаџер и работник. Врз основа на големината на проектот и минималните барања за толеранција на грешки, беше одлучено да се користи овој пристап.
Гледајќи напред, ќе кажам дека од првата испорака на производство, која беше во средината на јуни, немаше никакви проблеми поврзани со оваа кластерска организација (но тоа не значи дека таквата организација на кој било начин е прифатлива за која било средно-голема проекти, кои подлежат на барања за толеранција на грешки).
Докер Стак
Во режим на рој, тој е одговорен за распоредување на стекови (множества на докер услуги)
Поддржува конфигурации за докер-компонирање, што ви овозможува дополнително да ги користите опциите за распоредување.
На пример, користејќи ги овие параметри, ресурсите за секој од микросервисните примероци за евалуација беа ограничени (доделуваме 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 @ 2.20 GHz
- RAM меморија: 8 GB
- SSD: 160 GB
По локалното тестирање на оптоварување, се чинеше дека со сериозен прилив на корисници, оваа машина ќе биде доволна.
Но, веднаш по распоредувањето, објавив линк до една од најпопуларните табли за слики во ЗНД (да, истата), по што луѓето се заинтересираа и за неколку часа услугата успешно обработи десетици илјади слики. Во исто време, во моментите на врвот, ресурсите на процесорот и RAM меморијата не беа ни половина искористени.
Уште малку графика
Број на единствени корисници и барања за евалуација од распоредувањето, во зависност од денот
Дистрибуција на време за заклучување на цевководот за евалуација
Наоди
Сумирајќи, можам да кажам дека архитектурата и пристапот кон оркестрација на контејнерите целосно се оправдаа - дури и во моментите на врвот немаше падови или опаѓање во времето на обработка.
Мислам дека малите и средни проекти кои користат заклучоци во реално време на невронските мрежи на процесорот во нивниот процес можат успешно да ги усвојат практиките опишани во овој напис.
Ќе додадам дека првично статијата беше подолга, но за да не објавувам долгогодишна, решив да испуштам некои точки во оваа статија - ќе се вратиме на нив во идните публикации.
Ботот може да го прободите на Telegram - @AttraiBot, ќе работи барем до крајот на есента 2020 година. Дозволете ми да ве потсетам дека не се зачувани никакви кориснички податоци - ниту оригиналните слики, ниту резултатите од цевководот за евалуација - сè се уништува по обработката.
Извор: www.habr.com