Перейти к основному содержимому
Версия: 1.17.1

Конфигурация

Масштабирование

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

  • platform-processing-dep
  • image-api-face-detector-liveness-estimator-dep
  • image-api-age-estimator
  • image-api-gender-estimator
  • image-api-mask-estimator
  • image-api-emotion-estimator
  • image-api-face-detector-template-extractor-dep

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

kubectl scale deployment <SERVICE_NAME> --replicas <COUNT>

где <SERVICE_NAME> - наименование сервиса (например, gateway-dep), а <COUNT> - количество экземпляров сервиса.

примечание

При использовании GPU-ускорения сервис platform-processing-dep поддерживает только один экземпляр, а значит для его масштабирования необходимо иметь N доступных видеоускорителей в кластере. При отсутствии нескольких GPU можно увеличить утилизацию, изменив параметр processing.workers в файле ./cfg/platform.values.yaml.

Для поддержания нагрузки в A запросов/сек., направленной на обработку изображений, на сервере с физическим количеством ядер CPU равным B следует установить значение реплик каждого из указанных сервисов по формуле min(A, B).

Для сохранения параметров масштабирования откройте файлы ./cfg/platform.values.yaml и ./cfg/image-api.values.yaml, найдите поле replicas в блоке сервиса и укажите новые значения реплик.

При следующих установках платформы и image-api сервисы будут автоматически масштабироваться до указанных значений.

подсказка

При увеличении запросов поиска по изображению увеличьте число реплик сервиса image-api-face-detector-template-extractor-dep. Также можно увеличить количество потоков, которые используются для вычисления биометрического шаблона.

При увеличении запросов на детекцию, создание профилей и создание сэмплов увеличьте число реплик сервисов:

  • platform-processing-dep
  • image-api-face-detector-liveness-estimator-dep
  • image-api-age-estimator
  • image-api-gender-estimator
  • image-api-mask-estimator
  • image-api-emotion-estimator

Изменение TTL сэмплов и активностей

предупреждение

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

предупреждение

Параметр activity_ttl убран по умолчанию, т.к. добавлен функционал очистки по количеству хранящихся данных. При этом можно включить функционал, описанный здесь. Для этого в файле ./cfg/platform.values.yaml добавьте поле backend.activity_ttl: "2592000".

Файл ./cfg/platform.values.yaml:

  • backend.activity_ttl: время хранения активностей в базе данных. Значение задается в секундах. Например, 2592000 секунд (30 дней).
  • backend.sample_ttl: время хранения сэмплов в базе данных. Значение задается в секундах. Например, 2592000 секунд (30 дней).

Изменение количества хранящихся активностей и событий

Файл ./cfg/platform.values.yaml:

  • backend.retention_activities_count: количество хранящихся активностей на один воркспейс.
  • backend.activity_handler_period: частота проверки количества активностей в базе. Значение задается в секундах. Например, 604800 секунд (7 дней).
подсказка

Для нахождения оптимального количества активностей можно воспользоваться формулой a = V/(w*0.0025), где a — количество активностей на один воркспейс; V — желаемый объем памяти в ГБ, который будут занимать активности; 0.0025 — средний размер одной активности в ГБ; w — количество воркспейсов пользователей.

Файл ./cfg/platform.values.yaml:

  • event_service.retention_events_count: количество хранящихся событий на один воркспейс.
  • event_service.event_handler_period: частота проверки количества событий в базе. Значение задается в секундах. Например, 604800 секунд (7 дней).
подсказка

Для нахождения оптимального количества событий можно воспользоваться формулой e = V/(w*0.004), где e — количество событий на один воркспейс; V — желаемый объем памяти, который будут занимать события; 0.004 — средний размер одного события в ГБ; w — количество воркспейсов пользователей.

Изменение метода распознавания лиц

OMNI Platform использует методы распознавания лиц из набора библиотек Face SDK. Под методом имеется в виду версия модели распознавания лиц. По умолчанию в OMNI Platform установлен метод 12v1000. Для более быстрой работы вы можете переключиться на метод 12v100, однако при этом снизится точность распознавания.

Смена метода во время установки платформы

На этапе заполнения файлов конфигурации откройте файл ./cfg/platform.values.yaml и замените метод в поле generic.default_template_version. Далее откройте файл ./cfg/image-api.values.yaml и замените метод в полях face-detector-template-extractor.configs.recognizer.name, template-extractor.configs.recognizer.name и verify-matcher.configs.recognizer.name.

Смена метода на развернутой платформе

  1. Остановите платформу.
./cli.sh platform uninstall
  1. Остановите сервисы image-api.
./cli.sh image-api uninstall
  1. Удалите базу данных платформы.
./cli.sh platform db-reset
  1. Откройте файл ./cfg/platform.values.yaml и замените метод в полях generic.recognizer, backend.default_template_version, processing.recognizer_methods. Далее откройте файл ./cfg/image-api.values.yaml и замените метод в полях face-detector-template-extractor.configs.recognizer.name и verify-matcher.configs.recognizer.name.

  2. Запустите установку сервисов image-api.

./cli.sh image-api install
  1. Запустите платформу.
./cli.sh platform install
примечание

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

Настройка порога схожести лиц (score)

Параметр score показывает степень схожести лиц от 0 (0%) до 1 (100%). Высокая степень схожести означает, что два биометрических шаблона принадлежат одному и тому же человеку. Пороговое значение по умолчанию — 0.85.

Изменить порог score на OMNI Platform можно через API-запрос updateWorkspaceConfig, где в качестве аргументов указываются два пороговых значения: activityScoreThreshold (требуемый score для привязки активности к профилю) и notificationScoreThreshold (требуемый score для создания оповещений для профиля).

подсказка

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

Например:

  • score, указанный на стороне OMNI-агента = 0.7
  • score, указанный на OMNI Platform = 0.85

В этом случае активности, сформированные из процессов OMNI-агента со значением score в диапазоне [0.7, 0.85), не будут прикреплены к соответствующему профилю, оповещения по ним также не появятся.

Для настройки порога score для OMNI-агента см. руководство пользователя OMNI-агента.

Отправка писем на SMTP-сервер

  1. Остановите развернутую OMNI Platform:

    ./cli.sh platform uninstall
  2. Внесите изменения в файле ./cfg/platform.secrets.json в platform-email-secret.

  3. Пересоздайте секреты:

    ./cli.sh platform install-secrets
  4. Заново разверните OMNI Platform:

    ./cli.sh platform install