Открыть список
Как стать автором
Обновить

Комментарии 10

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

Каким образом вам удалось подготовить тестовые данные для тестирования «в реальных условиях эксплуатации»?
Если правильно понял вопрос, то речь о подготовке данных с точки зрения объемного тестирования.
Для того, чтобы организовать данные для тестовой среды нагрузочного тестирования мы:
1) Полностью мигрировали справочные данные из актуальной боевой инфраструктры
2) Выполнили миграцию данных за период двух месяцев и применили их мультиплексирование за счет созданных скриптов, которые фактически берут реальные данные и версионируют их.

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

Профиль нагрузки, т.е фактические сценарии использования их количество и интенсивность,
распределения по ролям, мы получали за счет системы мониторинга реальной боевой среды.
А если не секрет, то какие мощности были потрачены на эмуляцию клиентских запросов? И как они осуществлялись? По опыту на это надо потратить тоже немало ресурсов.
Пользовательская нагрузка осуществлялась посредством кластера, состоящего из двух виртуальных машин, с установленными на них
Linux RedHat 7.5 и JMeter 5.1.
Аппаратные ресурсы ВМ:

CPU: 8 vCPU
RAM: 32GB
-Xmx24576m
Network: 10Gb/sec

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

авторизация пользователя в системе — 400 мс
— это много или мало? И про остальные цифры тот же вопрос.
Как повлияли манипуляции с софтом и железом на эти цифры?
Спасибо за вопрос. Я считаю так: если бизнес-пользователь не испытывает каких либо проблем (времена совпадают или опережают его ожидания ), то это очень неплохой результат. Исходя из этого, можно сказать что к данным цифрам стоит относиться позитивно.
С другой стороны, стоит задать вопрос: какой ценой дались эти времена? И здесь ответ однозначен: на оборудовании хуавей можем вот так. С технической точки зрения уверен, что есть ещё возможность улучшить данные цифры.
можете про сам стек приложения рассказать?
микросервисы или монолит?
про cl/cd, monitoring?
Про стек технологий используемых для построения системы можно было бы написать отдельную статью если будет интересно. Сама система — это совокупность сервисов, объединённая общей шиной событий на основе Apache ActiveMQ Artemis. Ряд сервисов действительно микросервисы (сервис шрихкодирования, сервис конвертации в pdf, сервис проверки эп и тд). Но основной сервис бизнес логики это многослойный пирог объединяющий прикладную функциональность. С точки зрения сервиса бизнес логики мы выдерживаем компромисс между трудоемкостью сопровождения и развития. Слои сервиса бизнес логики состоит из слоя restapi, слоя доменной логики, слоя документоориентированных коннекторов к хранилищу и платформы AF5. Для большинства сервисов используем Spring Framework. Для различных клиентов: GWT, Angular, также есть нативные для iOS и Android. Поисковый движок Apache Solr. Субд соответсвенно PostgreSQL Все сервисы контейниризируются. Для автоматизации сборок Jenkins и maven, контроль качества автотесты на selenium, юнит тесты, интеграционные тесты и метрики через Sonar Cube.
объем файлов-вложений: 1 Тб в год;

Данные приложения консолидировали на… 117 SSD по 3,6 ТБ каждый, общий полезный объем — более 300 ТБ.

Зачем вам так много места? Процесс согласований — это по сути просто текст. Там нужно хранить — кто когда и что нажал, что написал, это все — максимум сотня килобайт на документ.
Прикрепляемые документы- всего 1 ТБ в год. Даже если вы закачаете в него всю историю за 10 лет, у вас останется ещё грубо 290 ТБ.
Конечно, есть ещё мета-информация — описания файлов, поиск по ключевым словам, но не настолько во много больше же, чем у вас самих документов?

Метрика объем файлов вложений\в год не учитывает общую потребность в подсистеме хранения. СХД для системы используется монопольно. Это позволяет решить вопросы тюнинга и конкуренции с прочими системами Банка. Помимо исторического набора данных с вложениями которых сейчас порядка 25 ТБ, мы имеем накладные расходы на поисковые индексы, на сервисы архивного хранения протоколов аудита и прочих, интеграционные сервисы и микросервисы системы. Т.е общая потребность в подсистеме хранения на текущий момент порядка 100 ТБ, а также заложены объемы на развитие.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.