Общ преглед на архитектурата на услугата за оценка на външния вид на базата на невронни мрежи

Влизане

Привет!

В тази статия ще споделя моя опит в изграждането на архитектура на микросервизи за проект, използващ невронни мрежи.

Нека да поговорим за изискванията към архитектурата, да разгледаме различни структурни диаграми, да анализираме всеки от компонентите на завършената архитектура и също да оценим техническите показатели на решението.

Насладете се на четенето

Няколко думи за проблема и неговото решение

Основната идея е да се оцени привлекателността на човек по десетобална скала въз основа на снимка.

В тази статия ще се отдалечим от описанието както на използваните невронни мрежи, така и на процеса на подготовка и обучение на данни. Въпреки това, в една от следващите публикации определено ще се върнем към анализирането на конвейера за оценка на задълбочено ниво.

Сега ще преминем през тръбопровода за оценка на най-високо ниво и ще се фокусираме върху взаимодействието на микроуслугите в контекста на цялостната архитектура на проекта. 

При работата по тръбопровода за оценка на привлекателността задачата беше разложена на следните компоненти:

1. Избиране на лица в снимки
2. Рейтинг на всеки човек
3. Изобразете резултата

Първият се решава от силите на предварително обучени MTCNN. За втория, конволюционна невронна мрежа беше обучена на PyTorch, използвайки ResNet34 – от баланса „качество / скорост на извод на процесора“

Функционална схема на тръбопровода за оценка

Анализ на изискванията към архитектурата на проекта

В жизнения цикъл ML проектните етапи на работа по архитектурата и автоматизацията на внедряването на модела често са сред най-отнемащите време и ресурси.

Жизнен цикъл на ML проект

Този проект не е изключение - беше взето решение да се обвие тръбопроводът за оценка в онлайн услуга, което изискваше да се потопим в архитектурата. Бяха идентифицирани следните основни изисквания:

1. Унифицирано съхранение на журнали – всички услуги трябва да пишат журнали на едно място, те трябва да са удобни за анализ
2. Възможност за хоризонтално мащабиране на услугата за оценка - като най-вероятната пречка
3. Същото количество процесорни ресурси трябва да бъде разпределено за оценка на всяко изображение, за да се избегнат отклонения в разпределението на времето за извод
4. Бързо (пре)разгръщане както на конкретни услуги, така и на стека като цяло
5. Възможността, ако е необходимо, да се използват общи обекти в различни услуги

архитектура

След анализ на изискванията стана очевидно, че архитектурата на микросервизите пасва почти идеално.

За да се отървем от ненужните главоболия, за интерфейс беше избран Telegram API.

Първо, нека да разгледаме структурната диаграма на готовата архитектура, след това да преминем към описание на всеки от компонентите и също да формализираме процеса на успешна обработка на изображения.

Структурна схема на готовата архитектура

Нека поговорим по-подробно за всеки от компонентите на диаграмата, като ги обозначим като Единична отговорност в процеса на оценка на изображението.

Микроуслуга „attrai-telegram-bot“

Тази микроуслуга капсулира всички взаимодействия с API на Telegram. Има 2 основни сценария: работа с персонализирано изображение и работа с резултата от конвейера за оценка. Нека да разгледаме двата сценария в общи линии.

При получаване на персонализирано съобщение с изображение:

1. Извършва се филтриране, състоящо се от следните проверки:
   • Наличие на оптимален размер на изображението
   • Брой потребителски изображения, които вече са в опашката
2. При преминаване на първоначалното филтриране изображението се записва в обема на докера
3. Създава се задача в опашката „to_estimate“, която включва, наред с други неща, пътя до изображението, намиращо се в нашия том
4. Ако горните стъпки са изпълнени успешно, потребителят ще получи съобщение с приблизителното време за обработка на изображението, което се изчислява въз основа на броя задачи в опашката. Ако възникне грешка, потребителят ще бъде изрично уведомен чрез изпращане на съобщение с информация какво може да се е объркало.

Също така, тази микроуслуга, подобно на celery worker, слуша опашката „after_estimate“, която е предназначена за задачи, които са преминали през конвейера за оценка.

При получаване на нова задача от „after_estimate“:

1. Ако изображението е обработено успешно, изпращаме резултата на потребителя, ако не, уведомяваме за грешка.
2. Премахване на изображението, което е резултат от конвейера за оценка

Микроуслуга за оценка „attrai-estimator“

Тази микроуслуга е celery worker и капсулира всичко, свързано с тръбопровода за оценка на изображението. Тук има само един работещ алгоритъм – нека го анализираме.

При получаване на нова задача от „to_estimate“:

1. Нека прекараме изображението през конвейера за оценка:
   1. Зареждане на изображението в паметта
   2. Довеждаме изображението до необходимия размер
   3. Намиране на всички лица (MTCNN)
   4. Ние оценяваме всички лица (увиваме лицата, открити в последната стъпка, в партида и правим изводи ResNet34)
   5. Изобразете крайното изображение
      1. Нека начертаем ограничителните полета
      2. Теглене на оценките
2. Изтриване на персонализирано (оригинално) изображение
3. Запазване на изхода от конвейера за оценка
4. Поставяме задачата в опашката „after_estimate“, която се слуша от микроуслугата „attrai-telegram-bot“, обсъдена по-горе.

Graylog (+ mongoDB + Elasticsearch)

Грейлог е решение за централизирано управление на регистрационни файлове. В този проект той е използван по предназначение.

Изборът падна върху него, а не върху обичайния ELK стек, поради удобството на работа с него от Python. Всичко, което трябва да направите, за да влезете в Graylog, е да добавите GELFTCPHandler от пакета сивкав към останалите манипулатори на root logger на нашата микроуслуга на python.

Като човек, който преди това е работил само със стека ELK, имах като цяло положителен опит, докато работех с Graylog. Единственото нещо, което е депресиращо, е превъзходството на функциите на Kibana над уеб интерфейса на Graylog.

RabbitMQ

RabbitMQ е брокер на съобщения, базиран на протокола AMQP.

В този проект беше използван като най-стабилните и изпитани във времето брокер за Celery и работеше в издръжлив режим.

Redis

Redis е NoSQL СУБД, която работи със структури от данни ключ-стойност

Понякога има нужда да се използват общи обекти, които имплементират определени структури от данни в различни микроуслуги на Python.

Например, Redis съхранява hashmap под формата „telegram_user_id => брой активни задачи в опашката“, което ви позволява да ограничите броя на заявките от един потребител до определена стойност и по този начин да предотвратите DoS атаки.

Нека формализираме процеса на успешна обработка на изображения

1. Потребителят изпраща изображение на бота на Telegram
2. "attrai-telegram-bot" получава съобщение от API на Telegram и го анализира
3. Задачата с изображението се добавя към асинхронната опашка „to_estimate“
4. Потребителят получава съобщение с планираното време за оценка
5. „attrai-estimator“ взема задача от опашката „to_estimate“, пуска оценките през тръбопровода и произвежда задачата в опашката „after_estimate“
6. "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?

Изглежда, че използването на Kubernetes в малки и средни проекти е излишно; цялата необходима функционалност може да бъде получена от Docker Swarm, което е доста удобно за оркестратор на контейнери и също така има ниска бариера за влизане.

Инфраструктура

Всичко това беше разгърнато на VDS със следните характеристики:

• CPU: 4-ядрен процесор Intel® Xeon® Gold 5120 @ 2.20 GHz
• RAM: 8 GB
• SSD: 160GB

След тестване на локално натоварване изглеждаше, че при сериозен наплив от потребители тази машина ще бъде достатъчна.

Но веднага след внедряването публикувах връзка към един от най-популярните имиджбордове в ОНД (да, същият), след което хората се заинтересуваха и след няколко часа услугата успешно обработи десетки хиляди изображения. В същото време в пиковите моменти ресурсите на CPU и RAM не бяха използвани дори наполовина.

Още малко графики

Брой уникални потребители и заявки за оценка от внедряването, в зависимост от деня

Разпределение на времето за извод за конвейер за оценка

Данни

Обобщавайки, мога да кажа, че архитектурата и подходът към оркестрацията на контейнерите се оправдаха напълно - дори в пиковите моменти нямаше капки или провисване на времето за обработка. 

Мисля, че малки и средни проекти, които използват изводи в реално време на невронни мрежи на процесора в своя процес, могат успешно да възприемат практиките, описани в тази статия.

Ще добавя, че първоначално статията беше по-дълга, но за да не публикувам дълго четене, реших да пропусна някои точки в тази статия - ще се върнем към тях в бъдещи публикации.

Можете да бутнете бота в Telegram - @AttraiBot, той ще работи поне до края на есента на 2020 г. Нека ви напомня, че не се съхраняват потребителски данни - нито оригиналните изображения, нито резултатите от конвейера за оценка - всичко се унищожава след обработка.

Източник: www.habr.com