company_banner

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

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



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

    Будем рады ответить на ваши вопросы в комментариях — возможно, о каких-нибудь аспектах тестирования вам интересно узнать подробнее.
    ВТБ
    Компания

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

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

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

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

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

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

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

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

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

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

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

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое