Нефункциональные особенности#

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

Нефункциональные характеристики продукта#

Ниже приведены характеристики продукта, которые достигаются на конфигурации из раздела Аппаратные требования. Выполнение заявленных НФТ проверялось в конфигурации Platform V DropApp (K8S).

Удобство использования#

Доступность#

Доступность сервиса зависит от клиентской конфигурации и инфраструктуры, требований по SLA не предъявлялось.

Механизмы отказоустойчивости:

• Горизонтальное масштабирование в Kubernetes.

• Балансировка нагрузки через NGINX Ingress.

• Активный healthcheck компонентов.

Устанавливаемость#

Целостность#

Производительность#

Коэффициент горизонтального масштабирования — 0,8

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

Производительность IDMX#

Производительность (количество обработанных аккаунтов в минуту) IDMX при выполнении операций на виртуальных тестовых данных, исключающая воздействие внешних факторов, была проверена на следующих сценариях:

Сценарии приведены в таблице ниже в нотации 3s-50m-3t-50m-50a-1500u, где:

• s — количество ресурсов-источников данных, из которых IDMX импортирует учетные карточки пользователей;

• m — количество маппингов с одним и с множественными (пятью) значениями параметров (фактически 50m означает 100 маппингов, 50 одиночных, 50 множественных). Параметр может встречаться дважды, для входящих (из ресурса-источника в IDMX) и исходящих (из IDMX в целевые ресурсы) маппингов;

• t — количество целевых ресурсов, в которых IDMX создает учетные записи, привязанные к учетным карточкам пользователей;

• a — количество прямых назначений у каждого пользователя;

• u — количество аккаунтов в каждом ресурсе-источнике. Для обозначения тысяч может использоваться символ k после цифр, например 1ku — 1000 аккаунтов.

Ресурсы машины, на которой проверялись сценарии:

• CPU — Intel Core i7-6700 (3.40 GHz) (4 ядра, 8 потоков);

• RAM — 16 ГБ;

• SSD — 500 ГБ.

При проверке сценариев JVM ядра IDMX не была ограничена в потребляемых ресурсах.

Производительность в end-to-end сценарии#

При тестировании на реальных (хранящихся в БД) данных, на производительность начинают влиять внешние факторы. Тестовая инсталляция IDMX была развернута в кластерном режиме в виде Docker-контейнеров в Kubernetes. Кластер IDMX в тесте имеет по одному узлу в двух пространствах имен.

Ресурсы каждого пространства Kubernetes:

• 2x Intel® Xeon® Processor E5-2697 v2 (2.70 GHz):

  • 12 ядер / 24 потока;

  • 30 МБ Cache.

• 158 ГБ RAM.

В каждом пространстве подняты следующие контейнеры:

• Тестовый HR-ресурс. БД на PostgreSQL, содержащая 10 миллионов аккаунтов пользователей, 5000 организаций, 5000 групп, 20 миллионов связей аккаунт-группа (в среднем по 2 на пользователя).

• Системная БД IDMX.

• Контейнер IDMX в кластерном режиме.

• БД, содержащая таблицы для 8 тестовых целевых ресурсов (7 с подключением через коннектор DBTable, 1 с подключением через коннектор ScriptedSQL).

Контейнер с системной БД IDMX ограничен по ресурсам до 6 CPU и 8 RAM. Контейнер IDMX не ограничен по ресурсам, но в параметрах JVM выставлен максимальный лимит на heap в 20 ГБ.

В задаче импорта данных из ресурсов установлены следующие параметры обработки:

• 2 обрабатываемых подзадачи (всего 4, так как два узла в кластере IDMX).

• 12 потоков обработки на подзадачу (всего 48).

• Размер бакета (количество учетных записей в одной подзадаче) — 5000 учетных записей.

Производительность IDMX в таких условиях достигает 1450 операций в минуту.

Надежность#

Устойчивость#

Безопасность#

Масштабируемость#