Назад в библиотеку

Методы интеграции нейронных сетей

Автор: Истягин А.О., Рычка О.В.
Источник: Истягин А.О. Методы интеграции нейронных сетей / А.О. Истягин, О.В. Рычка // Информатика, управляющие системы, математическое и компьютерное моделирование» (ИУСМКМ-2024) : сб. материалов XV Междунар. науч.-техн. конф. в рамках X Междунар. Науч. форума ДНР; Т.2 Ред. кол.: Аноприенко А. Я. (пред.); Васяева Т. А.; Карабчевский В. В. [и др.]; от. ред. Р. В. Мальчева. – Донецк : ДонНТУ, 2024. - 1303 с.

Аннотация

Истягин А.О., Рычка О.В. - Методы интеграции нейронных сетей В статье проанализированы методы обмена сообщениями между микросервисами в микросервисной архитектуре и их влияние на производительность систем. Основное внимание уделяется интеграции C# и Python сервисов через Redis, RabbitMQ и WebApi. Рассматриваются преимущества и недостатки каждого подхода. В статье проводится сравнительный анализ скорости передачи данных и обработки запросов в различных условиях.

Введение

В современной практике разработки программного обеспечения особое внимание уделяется интеграции с различными внешними сервисами. Эти сервисы могут быть как удаленными, так и внутренними частями больших программных комплексов, работающих по принципу микросервисной архитектуры. Одной из ключевых задач в данной области является выбор наиболее подходящего метода обмена сообщениями между разделенными сервисами. От правильности этого выбора напрямую зависит эффективность работы всей системы в целом. Разработчиками было предложено множество различных технологических решений, направленных на оптимизацию этого процесса. Среди наиболее популярных можно выделить такие технологии, как HTTP WebApi, очереди сообщений (RabbitMQ[1], Kafka, MSMQ), кэширующие базы данных (Redis[2]), удаленный вызов процедур с использованием gRPC, а также постоянное взаимодействие через WebSockets и многие другие. Каждый из этих методов имеет свои особенности, преимущества и потенциальные недостатки, которые будут подробно рассмотрены в рамках данной статьи.

Данная статья представляет собой логическое продолжение предыдущего исследования, описанного в работе «Сравнение производительности различных подходов в задаче классификации»[3], где была разработана нейронная сеть для классификации комнат отелей по предопределенным категориям. Нейронная сеть, реализованная на языке Python с использованием библиотеки PyTorch, демонстрировала возможности глубокого обучения в области автоматизированной классификации данных. Основное внимание в данной работе уделено анализу взаимодействия этого нейросетевого модуля, функционирующего как независимый сервис, с другими сервисами, реализованными на языке C# в контексте передачи сообщений.

Основная цель данной работы – оценить и сравнить производительность разнообразных технологий обмена данными, которые могут быть использованы для эффективной интеграции Python-модуля глубокого обучения с системами, написанными на C#. Рассматриваются различные подходы, включая прямые вызовы API через HTTP, использование технологий асинхронной передачи сообщений через специальные брокеры сообщений (RabbitMQ), передача через базы данных в кэше (Redis) Анализ подкрепляется тестами производительности, которые показывают, как различные методы влияют на задержки и пропускную способность в процессе взаимодействия между модулями.

Постановка задачи

Цель настоящего исследования заключается в анализе и определении наиболее эффективного метода для обмена сообщениями между микросервисами[4], реализованными на C# и Python. Исследование фокусируется на сценариях двустороннего обмена данными, что предполагает отправку и получение информации в обе стороны. В рамках работы особое внимание уделяется трём ключевым технологиям: взаимодействию с базой данных Redis, использованию очереди сообщений RabbitMQ и обмену данными через HTTP WebApi.

Для обеспечения объективности и сопоставимости результатов всех тестовых сценариев данные будут передаваться в едином формате JSON. Этот выбор обусловлен широкой поддержкой JSON в индустрии и его способностью структурировать сложные данные в легко читаемом виде. Кроме того, данный формат позволяет легко масштабировать тесты и модифицировать их при необходимости, добавляя или изменяя структуру передаваемой информации без внесения значительных изменений в логику обработки данных на стороне сервисов.

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

В исследовании будет проведена серия контрольных замеров производительности каждой из рассматриваемых технологий. Результаты этих замеров помогут определить, какие из методов наиболее подходят для использования в проектах, где необходима высокая надежность и эффективность обмена данными между микросервисами на C# и Python.

Анализ методов интеграции

В данной работе основное внимание уделяется изучению трёх технологий: Redis, RabbitMQ и WebApi. Выбор исследуемых технологий обусловлен тем, что они уже успешно применяются в рассматриваемом предприятии отельного бизнеса, что позволяет избежать необходимости в дополнительных ресурсах для разработки и интеграции новых систем. Перед тем как приступить к реализации различных подходов, необходимо провести краткий теоретический анализ каждой из технологий.

Redis

Redis – сокращение от Remote Dictionary Server представляет собой хранилище данных, расположенное в оперативной памяти. В общем случае это распределенная база данных ключ-значение, но ее можно применить в том числе как метод передачи сообщений между сервисами. Для этого в Redis реализованы следующие механизмы: подписки на публикации, списки и стандартное хранение по ключу.

При использовании модели подписок и публикаций одни сервисы публикуют сообщения в каналы, а другие – подписываются на канал и асинхронно обрабатывают получаемые сообщения. К преимуществам модели можно отнести возможность асинхронной обработки, что уменьшит время ожидания ответа, и масштабируемость – на один канал может быть подписано множество подписчиков, что позволит обрабатывать сообщения различными сервисами. Важным недостатком подхода можно выделить невозможность опубликовать сообщение в канал без подписчиков.

Хранение списка в значении по ключу позволяет использовать Redis как обычную очередь сообщений: один сервис добавляет запись в список, другой – читает ее (и удаляет во избежание многократной обработки). Преимущество – сообщения обрабатываются в порядке их публикации. Существенная сложность при использовании списков – необходимость разработки дополнительного функционала, который будет контролировать и регламентировать работу очереди сообщений.

Для разрабатываемого нейросетевого модуля лучший вариант – хранение единственного сообщения в заранее определенной паре ключ-значение. Это простейший механизм работы с Redis, он не требует дополнительной разработки и полностью удовлетворяет поставленной цели исследования. Для прозрачности реализации назовем ключи classificationRequest и classificationResponse, в них будут храниться данные для классификации и результаты соответственно.

RabbitMQ

RabbitMQ – популярный брокер сообщений, в котором реализована гибкая система хранения сообщений. Преимущества брокера: разделение сообщения на различные очереди на основании правил маршрутизации, гарантия надежности доставки сообщений и ответы при получении, возможность горизонтального масштабирования для обработки больших объемов сообщений. При установке дополнительного плагина Management появляется возможность удобнее администрировать все очереди и обмены сообщениями через подробный веб-интерфейс. К недостаткам можно отнести относительную сложность первоначальной настройки и донастройки при расширении. Также при росте объемов передаваемых сообщений требуется более тонкая настройка системы, зависящая от аппаратной конфигурации системы.

В ходе исследования будет рассмотрен простейший алгоритм асинхронной публикации сообщений в очередь и подписку на эту же очередь у принимающего сервиса. По аналогии с предложенным выше именованием определим очередь на классификацию как classificationQueue, а очередь с результатами – classificationResultQueue.

WebApi

HTTP WebApi – достаточно широкое семейство технологий, разработанных с применением протокола HTTP/s, а также правил и спецификация для регламентирования их взаимодействия. WebApi используют стандартные HTTP-методы (GET, POST, PUT, DELETE и другие), позволяют передавать данные в различных форматах (json и xml, например) и обеспечивают безопасность средствами дополнительны протоколов и механизмов авторизации и аутентификации. К преимуществам подхода можно отнести простоту настройки и использования, масштабируемость и универсальность. К недостаткам – сложность мониторинга и необходимость соблюдать множественные правила и спецификации.

Для работы с WebApi на Python чаще всего используют два фреймворка: Flask[5] и FastApi[6]. Легковесный Flask при своей простоте позволяет в полной мере использовать функционал WebApi: поддерживает все виды запросов, механизмы авторизации; с минимальной конфигурацией он отлично применим для небольших проектов и микросервисов, однако для больших систем потребуется дополнительная настройка. FastApi – более обширный фреймворк для более серьезных систем. К преимуществам можно отнести возможность автоматической генерации документации Swagger, явное указание моделей при помощи Pydantic, что позволяет значительно ускорить процесс обмена сообщениями.

В дальнейшем будет рассматриваться работа с Flask, т.к. он позволяет решить все поставленные задачи и не содержит избыточного функционала.

Определение условий и сравнение производительности

Для справедливой оценки различных подходов следует учесть несколько важных факторов в работе рассматриваемых технологий.

Для Redis и RabbitMQ не будет создаваться постоянное соединение, т.к. нейросетевой модуль будет запускаться редко; WebApi не требует постоянного соединения.

Для всех подходов данные будут передаваться в одинаковом виде – в виде json-строки. Контрольные замеры времени выполнения не будут учитывать время сериализации запроса и десериализации ответа классификации. Таким образом, замеряться будет процесс передачи заранее сериализованного сообщения, десериализация на Python, классификации, сериализация ответа и получение сериализованного ответа. Предполагается, что после получения ответа классификации дальнейшая работа с полученными данными в любом случае потребует десериализации.

Также для чистоты эксперимента будут проведены контрольные замеры скорости классификации подготовленных (уже десериализованных) данных внутри самого нейросетевого модуля. Полученные результаты позволят расчетным путем получить время, требуемое для передачи информации. Исходя из бизнес-правил предприятия стоит отметить формат сообщений: запрос содержит массив строк, представляющих собой названия комнат отелей до 300 символов; в ответе должен быть массив, содержащий объект с результатом классификации. В объекте должно быть исходное название комнаты и идентификатор класса, к которому она отнесена. В будущем планируется расширение модуля для классификации по нескольким категориям (тип номера, кровати и другие). Расширение моделей не повлияет на скорость передачи, т.к. идентификаторы классов требуют значительно меньше памяти, чем названия комнат.

Для каждого подхода проводилось 15 замеров времени (в миллисекундах) на одном ПК со следующими характеристиками: CPU: Ryzen 5 2600, RAM: 32 GB DDR4, GPU: GeForce 1660. В таблице 1 приведены результаты замеров времени выполнения вышеописанного цикла обработки данных. В таблице 2 приведены результаты замеров времени классификации без учета передачи, сериализации и десериализации, формирования ответа. В таблице 3 представлены расчетные показатели времени передачи информации между сервисами (результаты из таблицы 2 были вычтены из результатов таблицы 1).

Таблица 1. Результаты замеров времени передачи информации

Число записей для классификации Время передачи информации (мс)
Redis RabbitMQ WebApi
10 17 38 36
100 61 78 45
1000 393 410 381
10000 4251 4050 3969
100000 39344 39355 38733

Таблица 2. Результаты замеров времени классификации

Число записей для классификации Время, мс
10 7
100 42
1000 377
10000 3877
100000 38217

Таблица 3. Результаты вычислений времени отправки-получения сообщений

Число записей для классификации Время отправки-получения сообщений (мс)
Redis RabbitMQ WebApi
10 10 31 29
100 19 36 3
1000 16 33 4
10000 374 173 92
100000 611 622 516

Выводы и обзор методов оптимизации

Анализ эффективности передачи информации между микросервисами в условиях минимальной настройки и базового использования всех рассмотренных технологий показал, что результаты для всех подходов оказались схожими, лежащими в пределах статистической погрешности. Это указывает на то, что при базовом применении различий в производительности между технологиями нет, или они незначительны из-за недостаточного объема выборки данных для статистически значимых выводов. К тому же, в ходе анализа не было учтено время передачи данных по сети, так как все замеры производились в локальных условиях.

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

К методам оптимизации передачи данных можно отнести: более тонкую настройку всех изученных подходов для повышения производительности; применение других методов сериализации данных (ProtoBuff, например). Таким образом, для повышения точности и обоснованности выводов необходимо расширить объем исследования, увеличить выборку данных и провести более глубокий анализ с учетом всех возможных переменных, включая сетевые факторы. Эти шаги помогут обеспечить максимально эффективную интеграцию и использование микросервисов в проектах, где требуется высокая производительность обработки и передачи данных.

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

Список использованной литературы

1. Официальная документация RabbitMQ [Электронный ресурс] / Интернет-Ресурс. Режим доступа: https://www.rabbitmq.com
2. Официальная документация Redis [Электронный ресурс] / Интернет-Ресурс. Режим доступа: https://redis.io
3. Истягин А.О. Рычка О.В. Сравнение производительности различных подходов в задаче классификации. Современные информационные технологии в образовании и научных исследованиях (СИТОНИ-23): сб. материалов VIII Всерос. науч.-техн. конф., г. Донецк, 29 нояб. 2023. / отв. ред. В.Н.Павлыш – Донецк: ДонНТУ, 2023
4. Хорсдал К. Микросервисы на платформе .NET. — СПб.: Питер, 2018. — 352 с.: ил.
5. Официальная документация Flask [Электронный ресурс] / Интернет-Ресурс. Режим доступа: https://flask.palletsprojects.com/en/3.0.x/
6. Официальная документация FastApi [Электронный ресурс] / Интернет-Ресурс. Режим доступа: https://fastapi.tiangolo.com