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

Въведение

Здравейте!

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

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

Приятно четене!

Няколко думи за задачата и нейното решение

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

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

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

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

1. Изолиране на лицата на снимката
2. Оценка на всяко от лицата
3. Рендериране на резултата

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

Функционална диаграма на пайплайна за оценка

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

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

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

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

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

Архитектура

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

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

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

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

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

Микросервис «attrai-telegram-bot»

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

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

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

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

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

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

Микросервис за оценка «attrai-estimator»

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

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

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

Graylog (+ mongoDB + Elasticsearch)

Graylog — е решение за централизирано управление на логовете. В този проект той беше използван по предназначение.

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

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

RabbitMQ

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

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

Redis

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

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

Например, в Redis се съхранява hashmap вида «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-compose файл в

Но означава ли това, че можете да използвате същия docker-compose файл в  — система за клъстеризация, чиято функционалност е реализирана вътре в Docker Engine и е налична от кутията.

С помощта на «роя», всички ноди в нашия клъстер могат да бъдат разделени на 2 типа – worker и manager. На машините от първия тип се разгръщат групи контейнери (стекове), а машините от втория тип отговарят за скалиране, балансировка и други страхотни функции. Мениджърите по подразбиране са и работници.

Клъстер с един leader manager и три worker

Минимално възможният размер на клъстера е 1 нод, единствената машина ще изпълнява едновременно функциите на leader manager и worker. Въз основа на размера на проекта и минималните изисквания за отказоустойчивост, беше взето решение да се използва именно този подход.

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

Docker Stack

В режим «роя» за разгръщането на стековете (набори от docker услуги) отговаря 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 — stateful услуги и не е толкова просто да ги мащабираш, както «attrai-estimator».

Предвещавайки въпрос – защо не Kubernetes?

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

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

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

• CPU: 4 ядра Intel® Xeon® Gold 5120 CPU @ 2.20GHz
• RAM: 8 GB
• SSD: 160 GB

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

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

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

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

Разпределение на времето за инференс на оценъчния пайплайн

Изводи

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

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

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

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

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