Текущий год – это ралли среди различных систем распознавания и детекции объектов от различных вендоров. Новые устройства для исполнения нейронных сетей: FPGA, VPU, многоядерные процессоры с VNNI и многое другое предлагается от разработчиков аппаратной части. Параллельно наблюдается рост числа доступных топологий, а также готовых предобученных сеток. Детекция инцидентов, ДТП, подсчет пассажиропотоков, построение половозрастных портретов, распознавание эмоций и многое другое сегодня доступно для разработчиков. И все было бы хорошо, если бы не замысловатый «Time to market» (быстрее, быстрее на тот самый рынок, где деньги и если не мы первые, то точно не успеем), следствием которого мы видим на выходе слабо (читай – сложно, дорого) поддерживаемые монструозные системы All-in-one. А ведь параллельно существуют архитекторы (люди), виртуализация (подходы), способы автоматизации процессов, системы контроля состояний и параметров устройства или их множества. Но ввиду сжатых сроков, это опускается и появляются те самые, описанные выше, монстры. И да, задача «быстрее в рынок», часто бывает достигнутой. Но основная ошибка на начальном этапе заключается в том, что после достижения первичных целей сегодня, требования к скорости дополнения и развития решений будут только усугубляться. Рынок-то растущий, система несовершенна и требует развития, а не шага назад и переработки proof of concept в промышленное решение. И на этом этапе проверка гипотезы уходит в продакшн.
Чем это чревато и кто пострадает?
Для разработчика можно отметить следующие последствия:
- Сложность поддержки и продолжения разработки. Ввиду отсутствия системного подхода и архитектуры огромное количество копипаста будет требовать или исправления ранее допущенных ошибок, а это время, или их последовательного накопления, а это тупик в будущем.
- Сложность расширения команды и отсутствие возможности делегирования конкретных задач аутсорсерам или другим отделам внутри компании.
- Чем больше система, тем сложнее ее поддерживать. Сложнее – это дольше, дольше – это дороже. А там где есть плохое дорогое решение, рано или поздно, появится хорошее, построенное по правильной модели изначально и, как следствие, значительно более дешевое в развитии и поддержке.
- Часто, отсутствие наследования, репозиториев и веток в разработке не даёт технической возможности создавать и проверять альтернативные гипотезы по схожим решениям. Например, веткой объектовой видеоаналитики на х86 архитектуре является портирование на ARM для работы в непосредственной близости от источника данных (камеры) и/или напрямую в камеру. Далее, от ветки порта системы в камеру могут быть различные вендоры, под которых делается адаптация (например, интерфейса и иных частей). При отсутствии структуры каждая из этих веток, которые должны быть в четкой иерархии, делается путем копирования текущего состояния проекта. Дальше появляется разрозненное развитие множества проектов и параллельное решение одних и тех же задач. Параллельное решение одного и того же – зря потраченное время и деньги.
- Сложности в локализации продуктов и решений. Отсутствие локализации тормозит процесс выхода на иные рынки, где решение может быть больше востребовано, чем на текущем.
Для владельца решения (иногда одно лицо с разработчиком, но это не важно):
- Бесконечный рост стоимости проекта.
- Отсутствие возможностей для прогнозирования и бюджетирования проекта.
- Постоянно растущий со временем риск начать работать в минус себе.
- Усложнение и удорожание процессов развития проекта с течением времени и чем дальше будет рефакторинг, тем дороже и дольше он получится.
А для клиентов (или разработчиков на основе SDK вендоров) следствием являются:
- Чем дальше, тем поддержка становится все хуже и хуже.
- Со временем изменения и исправления ошибок делаются все дольше и дольше.
- Не поддерживаются новые протоколы, устройства, сетки или иные направления в развитии системы, хотя изначально, обычно, это предполагается и выделяется как преимущество.
- Отсутствие стабильности в работе систем.
- Отсутствие способов проверки состояния систем и/или устройств, на которых они работают и которые являются неотъемлемой частью общей инфраструктуры. Обычно, данное замечание касается гибридного инференса, где часть систем объектовой видеоаналитики работает «на краю», часть на серверах, а часть непосредственно в камерах. И конечный пользователь обладает подобным «огородом», работоспособность которого с учётом расширения инфраструктуры клиента должна оставаться, а получается с точностью до наоборот. Рост подобных систем без заложенных в них механизмов проверки, отладки и контроля, приводит к снижению их работоспособности во времени и усложнению процессов контроля работы их элементов.
А в чем, собственно, проблема?
Основная проблема кроется в подходе, все и сразу, и как можно быстрее. Архитектура, проектирование, прототипирование требуют времени. Мы же не дом строим, а всего лишь ИТ-решение, сервис или модуль. Зачем все это? И как только вы услышали эти слова, то пути назад уже нет.
Рассмотрим пример системы, которая пришла к нам на поддержку на определенном этапе своего развития. Это комплексная монолитная система, основная задача которой – разбор входящего видеопотока и фиксация событий в базе данных.
Для начала рассмотрим, как строилась эта система изначально:
- Максимальное время и силы были уделены сеткам в основе: сегментации изображений, детектированию объектов по типам и качеству/скорости распознавания. Это – основа системы.
- Минимум времени было уделено обвязке, те архитектуре в целом, а не ее основному модулю. В итоге, в одном окружении оказались прием RTSP потока, его нарезка на фреймы, обработка фреймов под дальнейшие действия, сегментация, детекции, распознавание, тракторный анализ, контроль идентичности объекта в кадре для предотвращения фиксации дублей, СУБД, пост/предобработки, импорт/экспорт данных, веб-интерфейс, REST API и многое другое.
- Рынок требовал ещё и ещё. Вместо одной сетки, которая была в основе изначально, множества сеток. Ведь события, в принципе, универсальны и с точки зрения позиционирования систем – детектор различных событий: люди, лица, номера, не важно что. Но в основе системы – не множество сеток, а одна, конкретная.
- Расширение и доработка системы – ошибки. Общее окружения множества различных систем подсистем – это сложности в отладке, время. Потеря времени – потеря преимущества в выходе на рынок, потеря конкурсного преимущества.
А как могла бы выглядеть архитектура в первом приближении?
Во-первых, это контейнерная виртуализация в Docker. Набор независимых узкопрофильных сервисов для решения своих задач. В рамках каждого блока может располагаться множество контейнеров. Условно, блоки можно представить следующие:
- Вход и обработка входящего потока: gstreamer, ffmpeg + ffserver, valkka
- Веб-интерфейс
- REST API
- Контейнер для инференса множества сетей
- Постобработка фреймов и формирование исходящего RTSP потока с учётом нанесения данных о найденных объектах (по результатам обработки детектором)
- СУБД и хранение данных: PostgreSQL, MySQL, NoSQL DB
С точки зрения детекторов и сеток логично использовать матрицу применимости, указанную на схеме. Тогда детектор срабатывает только для тех сетей, для которых он предназначен. Один детектор может использоваться для одной и более сетей. Например, нам требуется фиксировать автомобили, проезжающие на красный запрещающий сигнал светофора или идентифицировать людей, переходящих дорогу на красный свет. Это один и тот же детектор, но разные сетки детекции и распознавания.
В подобном подходе результатом мы получаем унификацию (общие блоки работают для множества сетей и детекторов), лёгкость отладки и оптимизации каждого из блоков, а также масштабируемость и возможность параллельного развития системы, в целом (делегирование задач различным группам разработчиков).
Результат
- Множество контейнеров с различными вариантами обработки входящих данных и их хранения в зависимости от требований в рамках конкретного внедрения.
- Унифицированная система хранения различных видов события.
- Унифицированная связка различных нейронных сетей и детекторов событий.
- Возможность расширения функционала путем добавления новых общедоступных сетей и детекторов для проверки гипотезы и с их дальнейшим дообучением для запуска продакшн версий.
- Встроенная система контроля состояний устройств и системы, в целом (zabbix, chronograf).
- Кроссплатформенность решения и возможность разворота на любом оборудовании.
- Простота развития продукта и возможность делегирования разработки отдельных частей различным группам, включая команды аутсорсеров.
- Простота отладки проблем в процессе эксплуатации (четкая идентификация места проблемы и возможность логирования внутри каждого контейнера).
- Возможность масштабирования системы и выполнения контейнеров как в рамках одной физической машины, так и в рамках множества
Главное, в процессе реализации не заиграться и правильно построить архитектура проекта, в целом. Работайте с профессионалами, итог – экономия времени, затрат, сил, ресурсов, денег. В противном случае, с Докером бывает и вот так: