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

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

Специалисты компании «Интертраст» протестировали СДО ВТБ на оборудовании 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. В ходе теста мы круглосуточно наблюдали за всеми показателями работы системы. Все результаты, включая исторические данные, фиксировали в виде графиков и таблиц для последующего анализа. 

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

Благодаря высокой производительности СХД 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