LUNA PLATFORM v.5.51.0

Изменения

• SDK обновлен до версии 5.16.0.

  В LUNA PLATFORM добавлена поддержка новой 62-ой модели нейронной сети для извлечения биометрических шаблонов лиц.

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

  Полноценная работа с сервисом Lambda возможна только при разворачивании сервисов LUNA PLATFORM в Kubernetes. Для использования необходимо самостоятельно развернуть сервисы LUNA PLATFORM в Kubernetes или обратиться за консультацией к специалистам VisionLabs. При необходимости можно использовать Minikube для локальной разработки и тестирования, обеспечивая таким образом Kubernetes-подобную среду без необходимости управления полноценным продакшн Kubernetes-кластером.

  Сервис позволяет написать и использовать собственный обработчик или написать внешний сервис, который будет тесно взаимодействовать с LUNA PLATFORM и сразу иметь несколько функций, типичных для сервисов LP (таких как логирование, автоматическая перезагрузка конфигураций и т.д.). Пользователю достаточно лишь написать код и отправить в сервис Lambda, после чего можно будет использовать свой модуль без разворачивания дополнительных контейнеров и пр.

  Сервис создает образ Docker на основе ZIP-архива с кодом разработчика, а затем запускает его в кластере Kubernetes. Пользовательский модуль, запущенный в кластере Kubernetes, называется lambda.

  Для работы с сервисом Lambda нужна отдельная лицензируемая функция. В запросы "get platform features", "get system info" и "get license" добавлены поля "lambdas", отображающие статус лицензируемой функции.

  В токен добавлено новое разрешение "lambda", регулирующее права "creation", "view", "modification", "deletion" для lambda.

  Для запуска и работы с сервисом требуется:

  • наличие запущенных сервисов Licenses и Configurator*;
  • наличие бакета S3 для хранения архивов с кодом разработчика;
  • наличие Docker registry для хранения Docker-образов;
  • наличие кластера Kubernetes.

  * во время своей работы, lambda будет дополнительно взаимодействовать с некоторыми сервисами LUNA PLATFORM. Перечень сервисов зависит от типа lambda.

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

  Lambda создается с помощью запроса "create lambda", где указывается архив, имя и её тип (см. ниже).

  Lambda может быть двух типов:

  Handlers-lambda

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

  • как пользовательский обработчик, который имеет свою собственную схему ответа, которая может отличаться от ответа классических обработчиков и не может быть должным образом использована в других сервисах LUNA PLATFORM (например, {"similarity": 0.123});
  • как пользовательский обработчик, который имитирует ответ классического обработчика (например, { "images": [ { ... } ], "events": [ { ... } ] ... }). Такой обработчик должен соответствовать схеме ответа запроса на генерацию события и правильно обрабатывать данные, чтобы другие сервисы могли его использовать.

  В связи с добавлением Handlers-lambda была переработана схема тела ответа запроса "create handler". В тело запроса добавлен новый параметр "handler_type", принимающий три значения — "0" (статический обработчик), "1" (динамический обработчик), "2" (обработчик lambda). Для использования значения "2" требуется также указать идентификатор "lambda_id" (см. логику работы ниже). Параметр "is_dynamic" считается устаревшим (Deprecated) и будет проигнорирован при использовании параметра "handler_type".

  Доступно два способа взаимодействия с Handlers-lambda: 1. С помощью запросов "generate events" или "estimator task". Для использования данных запросов необходимо предварительно создать обработчик, указав "handler_type" = "2" и "lambda_id", полученный на этапе создания lambda. В ответе на генерацию события будет выдан пользовательский результат, формат которого либо совпадает с форматом классического события и позволяет использовать его сервисами LP в дальнейшем, либо не совпадает. 2. С помощью запроса "proxy post request to lambda", когда не предполагается имитировать ответ классического обработчика, поскольку сервисы LP предполагают строгий формат ответа на запрос генерации события.

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

  Standalone-lambda

  Такой тип предназначен для реализации самостоятельного функционала для выполнения тесной интеграции с LUNA PLATFORM. Для работы с таким типом используется запрос "proxy post request to lambda" с собственной схемой запроса и ответа. Данный тип предназначен для узкой целевой аудитории и достаточно сложен в реализации.

  С помощью Standalone-lambda можно написать сервис, реализующий запись видеопотока в файл и сохраняющий его в сервис Image Store для последующей обработки приложением FaceStream.

  Также в сервис LUNA Dashboards добавлено создание дашборда для сервиса Lambda.

  См. диаграммы последовательности создания и обработки lambda в разделе "Lambda diagrams".

  См. дополнительную информацию для базового ознакомления с функционалом сервиса Lambda в разделе "Lambda service" руководства администратора.

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

• Ответ на запрос "get system info" к сервису Admin расширен дополнительной информацией по статистике использования эстиматоров и изображений.

  Добавлено поле "estimators_performance_stats", отображающее месяц, имя эстиматора, среднее время выполнения эстимации и средний размер батча для каждого эстиматора. Пример:

  "estimators_performance_stats": [ { "month": "2021-09", "name": "body_descriptor", "execution_time": 0.029135203011156546, "batch_size": 1.0952380952380951 } ]

  Добавлено поле "image_processing_stats", отображающее месяц, среднее время декодирования изображения, количество изображений по их размеру и количество изображений по высоте лица. Пример:

  "image_processing_stats": [ { "month": "2021-09", "image_load_time": 0.006479793069339647, "image_size": { "w_1000_h_1050": 4, "w_1000_h_800": 212, }, "face_detection_size": { "h_100": 2, "h_180": 197 } } ]

  Здесь: * "w_1000_h_800": 212 -- 212 изображений с шириной 1000 пикселей и высотой 800 пикселей * "h_180": 197 -- 197 изображений с высотой лица 180 пикселей

  Для изображений применяется округление до ближайших 50 пикселей. Например, если у изображения ширина 105 пикселей, то она будет округлена до 150 пикселей. Все изображения с одинаковыми округленными значениями будут находиться в одном и том же бакете.

  Примечание. Для использования новой статистики необходимо выполнить команду python influx2_cli.py create_usage_task --luna-config http://127.0.0.1:5070/1 после запуска сервиса Admin (см. руководство по установке)

• В пользовательский интерфейс сервиса Admin добавлена вкладка Schedules, позволяющая управлять расписанием задач и создавать расписание для задачи Garbage Collection.

  Во вкладке отображаются все созданные расписания задач и вся соответствующая информация (статус, идентификатор, Cron-строка и т.д.). Во вкладке также можно создавать, удалять и редактировать расписания, а также управлять отложенным запуском (ставить на паузу и запускать остановленные расписания).

  См. подробную информацию в разделе "Пользовательский интерфейс сервиса Admin".

Исправленные ошибки

• Исправлено отсутствие следующих параметров сортировки аккаунтов и токенов:

  • фильтров "create_time" и "create_time__gte" в запросе "get tokens";
  • полей "create_time" и "last_update_time" в телах ответов на запросы "get account", "get tokens", "get token".

• Исправлена ошибка, при которой во время запуска сервиса Admin не выполнялась проверка соединения и healthcheck к сервису Remote SDK.

• Исправлена ошибка, при которой во время миграции базы данных сервиса Handlers на версию v.3.0.0 некорректно обновлялось поле "detect_policy" > "estimate_people_count" в существующих обработчиках.

  В результате после обновления при попытке использования обработчиков с таким полем могла возникать ошибка с кодом "12022" и описанием "Failed to validate input json. Path: 'policies.detect_policy.estimate_people_count', message: 'value is not a valid dict'".