Сопровождение процесса разработки и работы демонстрационных стендов

2ГИС — это городской информационный сервис. Он объединяет в себе бесплатный справочник организаций, точную карту города и навигатор. Собственная технология сбора и выверки информации об организациях и территории обеспечивает до 95% точности данных. 2ГИС доступен в онлайн-версии на сайте 2gis.ru, в мобильных приложениях и на ПК. Software Cats более 1.5 лет успешно сотрудничает с 2ГИС в рамках DevOps направления, помогая решать инфраструктурные задачи. Один из интересных кейсов совместной работы команд описан ниже.

В рамках длительного контракта, одной из задач была подготовка и обеспечение корректной работы демонстрационных стендов продукта на одном из форумов, в котором участвовал заказчик. Было необходимо обеспечить развертывание проекта (web приложение) на системах и экранах, расположенных непосредственно в местах проведения мероприятия.

Проект представляет собой систему из трех основных компонентов:

• модуль для запуска на touchscreen экране;
• модуль для запуска на системе с широкоформатным экраном;
• модуль синхронизации двух систем.

От DevOps инженера требовалось сопровождать процесс разработки и подготовить конфигурацию для развертывания проекта на системах и экранах, расположенных непосредственно в местах проведения мероприятий.

Июнь-сентябрь 2024

DevOps инженер, команда frontend разработчиков, бэкэнд разработчик, тестировщик, руководитель проекта

Проект включал в себя получение данных о передвижении транспорта от поставщика данных и последующим отображением маркера ТС на карте. Еще одной функциональностью, которую необходимо было реализовать и поддержать на уровне инфраструктуры стала функция показа видео о транспортном потоке при клике на карту.

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

Основную сложность с точки зрения DevOps, представляла необходимость интеграции с системой по протоколу EGTS (протокол, для передачи данных от транспортных средств, в частности, от устройств GPS/ГЛОНАСС мониторинга, к серверным платформам). Из-за требований по безопасности, данные не могут передаваться в “открытом” – незашифрованном виде. Интеграция с системой выполнялась в пассивном режиме – клиент инициирует соединение и запрашивает необходимый поток данных, после чего система начинает передачу.

Предложенное решение предполагало использовать уже согласованную схему доступа к другим API-сервисам поставщика через протокол https (wss). В существующую архитектуру системы добавили новый сервис - прокси и одновременно конвертор данных, основная задача которого запросить данные от системы по протоколу EGTS и передать необходимые сообщения клиенту по HTTPS.

Подписка клиента на данные о соответствующем типе транспорта осуществлялась также через прокси-конвертор, путем отправки соответствующего сообщения, которое конвертировалось в формат, описанный EGTS. Сервис был разработан и развернут совместно с backend разработчиком. Для того, чтобы получить визуальный эффект, Frontend разработчик вместе с DevOps инженером реализовали интеграцию сервиса в основной проект и добились отображения местоположения транспорта на карте в реальном времени (Общественный транспорт, такси, и т.д.).

Второй важной функцией, с проблемами при реализации которой мы столкнулись, стала функция показа видео по клику на карте. К реализации этой функции решено было подойти исследовательски. Проект содержал набор предзаписанных видео различного назначения – от демонстрационных и презентаций, до примера видеопотока с камеры наружнего видеонаблюдения.
При обзоре способов передачи видео клиенту из файловой системы сервера, было установлено, что несмотря на поддержку веб-сервером Nginx форматов mp4, размер отдаваемого блока видео не являлся постоянным. Из-за этого, несмотря на возможность кэширования на стороне браузера, каждое новое отображение запрашиваемого видео требовало времени, а иногда и полной его загрузки. Такое решение имеет ряд недостатков: загрузка и отображение видео напрямую зависит от его размера и длительности; закрытие окна отображения видео в сервисе не всегда прерывало загрузку видеофайла, и поэтому не подходило в качестве финальной реализации.

DevOps инженером был проведен анализ: работы модуля mp4 nginx; цепочки запросов генерируемой html инструкцией (тегом) <video> и спецификации протокола http, а именно - инструкции (заголовка) Range. По результатам проведенного анализа разработан сервис для отдачи видеофайла путем фрагментации данных на равные части и установки в заголовок Range информации о блоке - значений смещения относительно начала исходного файла в байтах.

Совместно с frontend-разработчиками, созданный сервис был интегрирован в проект. Экспериментальным путем был установлен оптимальный размер блока 2-4 МБ, что позволило получить и отобразить первые секунды видео, загружая последующие блоки в фоновом режиме, а также поддержать возможность прерывания загрузки фрагментов видео при закрытии соответствующего окна в приложении.

Изначально проект был ориентирован на работу в браузере Chrome. Chrome имеет ограничение на использование оперативной памяти для каждой вкладки в 4 ГБ.  В процессе проведения тестирования, проект показал высокие требования к размеру оперативной памяти, что привело к необходимости выделения более 4 ГБ оперативной памяти для вкладки браузера.
Браузер Firefox, в свою очередь, не имел такого ограничения, поэтому было принято решение перенести запуск и процесс разработки проекта на работу в Firefox.

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