+7 (495) 956-79-28
ГлавнаяПресс - центрСтатьи и интервьюНе нагрузишь — не протестируешь: как мы выявляли проблемы с системой документооборота ВТБ

Не нагрузишь — не протестируешь: как мы выявляли проблемы с системой документооборота ВТБ

Недавно в ВТБ поменялись некоторые аппаратные и программные компоненты системы документооборота. Изменения были слишком существенными, чтобы продолжать работу без полномасштабного нагрузочного тестирования: любая проблема с системой документационного обеспечения (СДО) чревата огромными убытками. 

ycvoe5se_fq1pfmmaumbgodslew.jpeg


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

Для чего нужна система документооборота в банке и зачем ее тестировать

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

СДО должна обеспечивать четкое исполнение решений в соответствии с принятыми регламентами. Это требует высокой производительности, отказоустойчивости, гибкого масштабирования. К системе предъявляются высокие требования к управлению доступами, объему одновременно обрабатываемых документов, к количеству пользователей. Сейчас в СДО ВТБ их насчитывается 65 тысяч, и это число продолжает расти. 

Система постоянно развивается: меняется архитектура, на смену устаревающим технологиям приходят современные. А недавно часть компонентов системы заменили на импортонезависимые, без проприетарного ПО. Справится ли новая архитектура СДО на базе ПО CompanyMedia и аппаратного комплекса Huawei с повышенной нагрузкой? Однозначно ответить на этот вопрос, не дожидаясь возникновения подобной ситуации в реальности, можно было только с помощью нагрузочного тестирования.

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

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

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

Зачастую такие оторванные от реальности тесты проводят поставщики решений. Оно и понятно: для вендора важно продемонстрировать потенциальному клиенту высокую производительность и скорость работы системы. Неудивительно, что упрощенные модели тестов показывают рекордное время отклика системы, даже если количество пользователей и документов существенно увеличивается. 

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

Итогом стала методология тестирования, с помощью которой получилось смоделировать протекающие в системе процессы с учетом всех реально существующих нагрузок. На тестовом стенде мы воспроизвели — по отдельности и в различных комбинациях — самые распространенные бизнес-операции, а также наиболее времязатратные запросы. В ходе тестирования производительности все компоненты подвергались нагрузке. Проводились операции по вычислению прав доступа пользователей к объектам системы, открытию документов со сложной разветвленной иерархией и большим количеством связей, поиска по системе и так далее. 

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

  • зарегистрированных пользователей: 65 тыс. с увеличением до 150 тыс.;
  • частота входов пользователей в систему (аутентификаций): 50 тыс. в час;
  • пользователей, одновременно работающих в системе: 10 тыс.;
  • регистрируемых документов: 10 млн в год;
  • объем файлов-вложений: 1 Тб в год;
  • процессов согласования документов: 1,5 млн в год;
  • виз участников согласования: 7,5 млн в год;
  • резолюций и поручений: 15 млн в год;
  • отчетов по резолюциям и поручениям: 15 млн в год;
  • пользовательских задач: 18 млн в год.
Данные приложения консолидировали на единой системе хранения Huawei OceanStor Dorado 6000 V3 со 117 SSD дисками по 3,6 ТБ каждый, общий полезный объем — более 300 ТБ. Вычислительные мощности разместили на модульной серверной системе Huawei E9000, а передачу данных вели по сети на базе коммутаторов уровня ЦОД Huawei серии CE. В ходе теста мы круглосуточно наблюдали за всеми показателями работы системы. Все результаты, включая исторические данные, фиксировали в виде графиков и таблиц для последующего анализа. 

Серверы аппаратной инфраструктуры нагрузочного тестирования

таблица.png

сервер huavey.png

Благодаря высокой производительности СХД Huawei OceanStor Dorado 6000 V3 задержки при выполнении любых пользовательских запросов редко превышали 1 мс. Такая скорость работы дисковой подсистемы приложения вдохновила нас на дополнительное исследование. Мы решили путем анализа исторических данных определить влияние различных типов нагрузки на техническую инфраструктуру. Полученные результаты позволяют гибко и точно планировать развитие системы в соответствии с требованиями к аппаратной платформе. 

С точки зрения масштабирования мы проверили:

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

Проблемы и решения

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

Блокировки синхронной записи в лог. Операции записи в лог в стандартной конфигурации WildFly выполняются синхронно и сильно влияют на производительность. Было решено перейти на асинхронный логер, а заодно писать не на диск, а в систему агрегации логов ELK. 

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

Блокировки при работе с объектами кэша приложения. В приложении использовались довольно тяжелые блокировки reentrantLock (Java 7), которые отрицательно сказывались на скорости выполнения запросов. Был изменен тип блокировки на stampedLock, что позволило значительно сократить время на работу с объектами кеша.

После этого мы снова запустили нагрузочное тестирование, чтобы определить среднее время типовых операций работы в системе СДО с реляционным хранилищем на профиле банка. Мы получили такие результаты:
  • авторизация пользователя в системе — 400 мс;
  • просмотр хода исполнения в среднем — 2,5 с;
  • создание регистрационно-контрольной карточки — 1,4 с;
  • регистрация регистрационно-контрольной карточки — 600 мс;
  • создание резолюции — 1 с. 

Выводы

Помимо выявления проблем, нагрузочное тестирование подтвердило и некоторые наши предположения.
  • Система гораздо лучше функционирует на ОС семейства Linux.
  • Заявленные принципы обеспечения отказоустойчивости работают на уровне каждого компонента в «горячем» режиме.
  • Ключевой компонент — сервис бизнес-логики (принимающий пользовательские запросы) — имеет «зеркальное» горизонтальное масштабирование и практически линейное масштабирование пропускной способности при росте числа экземпляров.
  • Оптимальный сайзинг сервиса бизнес-логики на 1200 одновременных пользователей — 8 vCPU для сервиса и 1,5 vCPU для СУБД.
  • Консолидация данных приложения на единой СХД существенно увеличивает производительность и надежность, повышает масштабируемость.
Будем рады ответить на ваши вопросы в комментариях — возможно, о каких-нибудь аспектах тестирования вам интересно узнать подробнее.

Источник: Habr.com

Модуль Email-маркетинга в настоящее время недоступен.