В Банке ВТБ проведено нагрузочное тестирование системы документационного обеспечения на базе ПО CompanyMedia и аппаратного комплекса Huawei

Специалисты компании «ИнтерТраст» завершили первый этап нагрузочного тестирования системы документационного обеспечения (СДО) Банка ВТБ в среде, полностью воспроизводящей реальные сценарии использования системы в Банке. Тестирование проводилось на оборудовании Huawei — полном комплексе технической инфраструктуры, включающей в себя серверную ферму, сеть передачи данных и систему хранения данных на базе твердотельных накопителей. Результаты тестирования показали высокую производительность системы в высоконагруженном режиме эксплуатации. Также в процессе испытаний была исследована новая архитектура распределения данных — данные приложения были консолидированы на одной системе хранения для оптимизации использования ресурсов и повышения производительности и надежности.

СДО — сложный, взаимоувязанный программный комплекс, обеспечивающий поддержку ключевых процессов управления в Банке за счет предоставления общих сервисов документирования, электронного взаимодействия, аналитики. Правильно выстроенное документационное обеспечение ускоряет принятие управленческих решений, делает процедуру их принятия прозрачной и контролируемой, повышая качество управления и усиливая конкурентоспособность банка. Если решение принимается, то оно исполняется, причем строго в соответствии с принятыми регламентами — это обеспечивает СДО. Критичность для Банка процессов, которые поддерживает СДО, требует от системы высокой производительности, отказоустойчивости, гибкого масштабирования. Непрерывное развитие, усложнение системы, изменения в архитектуре, замена устаревающих технологий на современные требует обязательного тестирования всех компонент, в том числе, в плане обеспечения требований непрерывного функционирования в высоконагруженных режимах работы.

Характерными особенностями эксплуатации СДО в Банке являются большое число подключенных пользователей (65 000), большой объем одновременно обрабатываемых документов, высокие требования к управлению доступом к документам. Параметры эксплуатации имеют потенциал кратного увеличения в связи с планируемым расширением Банка.

В настоящее время в Банке осуществляется перевод СДО на базовые компоненты, не содержащие проприетарного ПО и, в частности, импортонезависимые компоненты.

В связи с этим в Банке было спланировано и проведено нагрузочное тестирование для новой архитектуры СДО.

Тестирование проводилось для достижения следующих целей:

• выявление точных параметров горизонтального и вертикального сайзинга серверов под профиль нагрузки Банка;
• проверка стрессоустойчивости программного продукта;
• проверка отказоустойчивости компонентов в условиях высокой нагрузки;
• определение коэффициента энтропии межкластерного взаимодействия при горизонтальном масштабировании;
• проверка масштабирования запросов на чтение при использовании платформенного балансировщика. Определение коэффициента горизонтального масштабирования всех улов и компонентов системы;
• определение максимально возможных аппаратных параметров серверов разного функционального назначения (вертикальное масштабирование);
• исследование профиля нагрузки приложения на техническую инфраструктуру и аппроксимация полученных результатов для планирования развития информационной системы;
• исследование влияния консолидации данных приложения на одной системе хранения данных для оптимизации ресурсов и повышения надежности и производительности.

Методология тестирования

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

Нагрузочное тестирование СДО преследовало в первую очередь цель максимально точного воспроизведения реальных эксплуатационных характеристик. Для этого в течение месяца собиралась статистика активностей пользователей и фоновой работы всех сервисов системы с использованием постоянно действующей системы мониторинга работы СДО. Статистические данные по документопотокам были скорректированы (совместно с владельцем процесса) с учетом прогнозируемого роста. На основании этих данных была разработана методология тестирования, полностью воспроизводящая все реально протекающие процессы в системе. На тестовом стенде были повторены самые распространенные бизнес операции, а также самые времяемкие запросы согласно собранной статистике. Тестировалась производительность работы всех компонентов системы с учетом операций по вычислению прав доступа пользователей к объектам системы, открытию документов со сложной разветвленной иерархией, большим количеством связей. Имитировалась нагрузка при полнотекстовом поиске и многое другое. Данные приложения были консолидированы на единой системе хранения Huawei OceanStor Dorado 6000 V3, вычислительные мощности располагались на модульной серверной системе Huawei E9000, данные передавались по сети передачи на базе коммутаторов уровня ЦОД Huawei серии CE. В процессе исследований производилось круглосуточное наблюдение за всеми показателями работы системы с возможностью построения графиков и создания табличных отчетов для последующего анализа включая исторические данные.

Профиль нагрузочного тестирования Банка

• количество зарегистрированных пользователей: 65000 с увеличением до 150000;
• частота входа (аутентификации) пользователей в систему: 50 тыс./час;
• количество пользователей, одновременно работающих в системе: 10000;
• количество регистрируемых документов: 10 млн./год;
• объем файлов вложений: 1 Тб/год;
• количество процессов согласования документов: 1,5 млн./год;
• количество виз участников согласования: 7,5 млн./год;
• количество резолюций/поручений: 15 млн./год;
• количество отчетов по резолюциям/поручениям: 15 млн./год;
• количество пользовательских задач: 7 млн.

Аппаратная инфраструктура нагрузочного тестирования состояла из следующих серверов:

В качестве системы хранения использовалась высокопроизводительная система хранения данных Huawei OceanStor Dorado 6000 V3 c 117 SSD дисками 3,6 ТБ каждый общим полезным объемом более 300 ТБ. Задержки при выполнении пользовательских запросов редко превышали 1 мс, что существенно ускорило выполнение типовых и нестандартных запросов. Высокая скорость работы дисковой подсистемы приложения привела к необходимости дополнительного исследования для выявления типов нагрузки работы приложения на техническую инфраструктуру путем анализа исторических данных — операции приложения выполнялись в разы быстрее и занимали существенно меньшее время. Таким образом, благодаря полученным результатам исследования, появилась возможность более гибко и точно планировать развитие системы в соответствии с конкретными требования к аппаратной платформе.

Проверялись следующие компоненты с точки зрения масштабирования:

• сервер приложения (CMJ). Проверка пределов вертикального масштабирования (ресурсы по степени критичности: количество ядер и частота, объем ОЗУ). Поддержка горизонтального масштабирования за счет дублирование функционально-идентичных сервисов и балансировка между ними;
• сервер клиента (Web-GUI). Проверка пределов вертикального и горизонтального масштабирования;
• файловое хранилище (FS). Проверка пределов вертикального масштабирования (ресурсы по степени критичности: пропускная способность сети, скорость дисков). Поддержка горизонтального масштабирования за счет распределенной файловой системы (CEPH, GLUSTERFS);
• база Данных (PostgreSQL). Проверка пределов вертикального масштабирования (ресурсы по степени критичности: объем ОЗУ, скорость дисков, количество ядер и частота). Поддержка горизонтального масштабирования — масштабирование читающей нагрузки по slave-серверам, масштабирование пишущей нагрузки по принципу деления на функциональные модули;
• брокер сообщений (Apache Artemis). Проверка пределов вертикального и горизонтального масштабирования;
• сервер поиска (Apache Solr). Проверка пределов вертикального и горизонтального масштабирования.

Результаты нагрузочного тестирования

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

• падение пропускной способности кэша сервера приложений при инвалидации на большом количестве экземпляров приложений в кластере;
• образование «бутылочного горлышка» на операции регистрации документов с увеличением числа точек регистрации (от 500 на одном сервере);
• образование «бутылочного горлышка» при увеличении числа одновременных авторизаций на одном сервере (от 1000 и выше);
• уменьшение пропускной способности сервиса бизнес-логикипри интенсивном логировании запросов к СУБД.

После устранения проблем производительности нагрузочное тестирование показало следующие средние времена типовых операций работы в системе СДО с реляционным хранилищем на профиле Банка:

• авторизация пользователя в системе — 400 ms;
• просмотр хода исполнения в среднем — 2,5 s;
• создание регистрационно-контрольной карточки — 1,4 s;
• регистрация регистрационно-контрольной карточки — 600 ms;
• создание резолюции — 1,0 s

По результатам проведенного нагрузочного тестирования СДО Банка ВТБ сделаны следующие выводы:

1. система ведет себя существенно лучше на операционных системах семейства Linux;
2. заявленные принципы обеспечения отказоустойчивости работают на уровне каждого компонента в «горячем» режиме. Вывод из строя компонент системы остается незаметным для пользователя (администратор проактивно устраняет проблемы);
3. ключевой компонент — сервис бизнес логики (принимающий пользовательские запросы) имеет «зеркальное» горизонтальное масштабирование, практически линейное масштабирование пропускной способности при росте числа экземпляров;
4. ожидаемые значения пропускной способности системы при увеличении числа пользователей и, как следствие, числа запускаемых сценариев обеспечиваются заявленными характеристиками масштабирования;
5. наиболее оптимальный сайзинг сервиса бизнес логики — 8 vCPU на 1200 одновременных пользователей и 1,5 vCPU СУБД;
6. консолидация данных приложения на единой системе хранения данных существенно увеличивает производительность и надежность приложения и повышает масштабируемость;
7. использование комплекса технической инфраструктуры Huawei дало превосходные результаты с точки зрения обеспечения необходимых эксплуатационных характеристик системы.

СПЕЦПРОЕКТ КОМПАНИИ ИНТЕРТРАСТ