Вычислительные сети, теория и практика.

BC/NW 2019 № 1 (34):6.1

НАГРУЗОЧНОЕ ИССЛЕДОВАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ УПРАВЛЕНИЯ, ОБСЛУЖИВАЮЩЕЙ КЛИЕНТОВ БАНКА

Антонов В. В., Абросимов Л.И.

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

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

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

Объект нагрузочного тестирования

Объектом нагрузочного тестирования может являться любая автоматизированная система, работающая с большим количеством клиентов и большим объемом данных. К объекту предъявлены требования, при которых система должна работать в штатном режиме длительное время.

В данной работе объектом исследования является автоматизированная система АСК.

АСК – система, обслуживающая клиентов банка с просроченной задолженностью на ранней и поздней стадии сборки. АСК включает в себя стационарную версию с пользовательским интерфейсом, мобильное приложение коллектора и систему отчетности.

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

Автоматизированная система АСК - система для обслуживания клиентов банка с просроченными задолженностями на разных стадиях взыскания, начиная с прогнозирования просрочек и заканчивая судебным урегулированием.

В базу данных заносятся данные клиента, желающего взять кредит в банке. Далее АСК выполняет ряд проверок, таких как кредитоспособность, финансовое положение, оценивает социальный статус, кредитная история и ряд других показателей. После проверки клиент распределяется на исполнителя процесса (работника банка) и попадает в один из списков, соответственно результатам проверки. В процессе работы с пользователем он переходит из одного списка в другой, в зависимости от проведенных над ним активностей системы. Все проведенные операции отображаются в базе данных.

Структурная схема системы АСК представлена на рисунке 1:

Рис. 1 - Структурная схема АС АСК

Общая архитектура система на текущую дату представлена на рисунке 2

Рис. 2. Схема стенда НТ

Методика нагрузочного тестирования

Методика нагрузочного тестирования (МНТ) – согласованный с заказчиком документ, регламентирующий проводимые тесты, средства тестирования, профиль нагрузки, SLA (Service level agreement – соглашение о качестве предоставляемых услуг).

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

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

Для определения максимального количества суточных операций была запрошена статистика. Как видно из предоставленной выгрузки, максимальная суточная активность составила 889 394 операций. Данное количество операций принимается за 100% уровень нагрузки L0.

Рис .3 – Суточная статистика за период

Основные цели проведения нагрузочного тестирования:

1. Определение максимальной производительности системы

По результатам тестирования определяется максимальная интенсивность операций в час, при которой система удовлетворяет требованиям по временам отклика. Предусматривается несколько итераций по результатам анализа «узких мест» с исправлением настроек системы для определения оптимальной конфигурации.

2. Проверка стабильности системы

По результатам тестирования определяется возможность системы работать длительное время под нагрузкой (в течение 12 часов).

3. Поиск узких мест в работе системы

По результатам тестирования определяется узкие места системы, негативно влияющие на работу системы.

Виды проводимых тестов

Расчет интенсивности работы виртуальных пользователей

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

При планировании нагрузки важно выдержать заданную интенсивность работы теста. Это достигается за счёт того, что используется фиксированный шаг нагрузки. Шаг нагрузки (Т) (Pacing)- такой интервал времени в течение которого гарантировано выполняется один проход сценария. Шаг нагрузки для N рассчитывается по следующей формуле: Т=N/t , где N – количество ВП, t – время выполнения одной операции.

На рисунке ниже представлен пример работы 5 виртуальных пользователей.

load2

Рис. 4 – Диаграмма работы ВП

Работа виртуальных пользователей

ВП выполняет сценарий конкретной операции. Подробно это описано в главе «Разработка средств тестирования».

При выполнении скрипта на веб приложения поступает web – запрос. В запросе содержится адрес, тип запроса и текст запроса.

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

На рисунке ниже представлен пример параметров одного из скриптов.

Рис. 6 - Пример параметризации скрипта

В данном пуле содержится информация о клиенте: ФИО, номер, серия, дата выдачи паспорта, тип документа, ID клиента. Выборка данных происходит следующим образом:

1. Случайно выбирается ID клиента. Выбор происходит по колонке ClientID.

2. Остальные параметры настраиваются таким образом, чтобы строка со значением для данного параметра совпадала со строкой параметра ClientID.

3. Каждая строка пула данных используется один раз.

Так же среди параметров имеются служебные. Такие параметры нужны, например, для логирования системных метрик (influx).

Настройка сценариев тестирования.

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

В этом тесте нагрузка подается ступенями, начиная с уровня L0. Каждая ступень длится одинаковое время. Ниже приведен пример графика подачи нагрузки:

Рис. 7 – Подача нагрузки для теста максимума

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

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

Тест стабильности показывает как со временем может изменится поведение системы. Такие параметры как исходящий сетевой трафик или оперативная память могут «выстрелить» на дистанции, т.е. при длительной работе системы и при этом не вызывать деградации при кратковременной работе.

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

Рис. 8 – График подачи нагрузки для теста стабильности.

Алгоритм проведения тестов.

Тест поиска максимальной производительности.

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

1. Тест начинается с входа виртуальных пользователей до достижения уровня, соответствующего текущему уровню промышленной нагрузки.

Далее в течение 1 часа выполняется шаг стабильной нагрузки. В течение этого времени число виртуальных пользователей не меняется и происходит загрузка файлов из смежных систем.

2. Далее в течение 30 минут выполняется шаг стабилизации нагрузки, когда число виртуальных пользователей постепенно увеличивается для перехода на следующий уровень нагрузки (с шагом увеличения нагрузки, равным 20%, за исключением первого шага, когда нагрузка увеличивается от текущего уровня промышленной нагрузки).

3. Шаги 2-3 повторяются, при этом на каждой ступени нагрузки производится проверка критериев завершения теста (см. ниже).

4. Тест завершается при выполнении критериев завершения (см. ниже), при этом фиксируется предельный уровень нагрузки L0.

Критерии завершения теста

Тест завершается при выполнении одного из критериев:

· Времена отклика 10% операций превысили допустимые пределы (SLA)

· Количество неуспешных операций увеличилось до уровня более 10%

· Исчерпаны системные или аппаратные ресурсы: CPU, Memory, network utilization).

Тест стабильности.

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

1. Тест начинается с постепенного входа виртуальных пользователей до достижения уровня, соответствующего уровню промышленной нагрузки (L0) .

2. Далее нагрузка держится на постоянном уровне, длительность данного шага составляет 12 часов. Шаг выполняется для эмуляции дневного промежутка работы АС.

Внешние системы.

Для тестирования АС АСК взаимодействие с внешними системами «глушится» эмуляторами этих систем.

Внешние системы, с которыми взаимодействует АС АСК:

· Сбор данных. Система собирает данные клиентов банка по кредитным обязательствам.

· Процессинг. Процессинговая система банковских карт.

· Стоп-лист. Ведение Стоп-листов. В стоп-листы попадают нежелательные клиенты или клиенты не подлежащие кредитованию (террористы, недействительные документы, недобросовестные ссудозаёмщики), формирование транспортных файлов с реквизитами юридических и физических лиц, загрузка файлов журнала обращений и несоответствий.

· Скоринг. Система оценки кредитоспособности клиентов.

· СУДИР – средство управления доступом к информационным ресурсам.

Тип взаимодействия с внешними системами представлен в таблице 2:

Таб. 2 - Тип взаимодействия с внешними системами

Внешняя система	Участие в обработке тестируемых операций	Тип связи	Протокол взаимодействия	Эмуляция на тестовом стенде
Сбор Данных	Данные по просроченной задолженности,	односторонняя (в АСК)	файловый обмен	эмулируется java программой, генерирующей данные в таблицу в базе данных
Процессинг	Онлайн запрос сервиса по получению информации о счетах и банковских картах клиента -	двусторонняя	SSL,XML,MQ,	Эмулятор
Стоп-лист	Выгрузка файла для обработки в АС	односторонняя (из АСК)	файловый обмен	не требуется эмуляция (файл выгружается автоматически)
Скоринг	АС АСК получает результаты скоринга	Односторонняя (в АСК)	Файловый обмен	Заглушка, формирующая файлы необходимого формата и объема.
СУДИР	Управление идентификационными данными пользователей	двусторонняя	https	не эмулируется (аутентификация внутренними механизмами АСК, заведение пользователей на стороне АСК)

Разработка эмулятора внешней системы

В рамках проекта был разработан генератор данных, заполняющий таблицу EXT_SYSTEM_INTERACTION – таблицу взаимодействий с внешними системами.

На промышленном стенде в данную таблицу логируются все входящие и исходящие обращения.

Для проведения нагрузочного тестирования таблицу необходимо заполнить искусственно сгенерированными данными. Количество строк в таблице должно соответствовать промышленному уровню – 60 млн записей.

После проведения тестирования база данных восстанавливается из дампа, что приводит к необходимости заполнять таблицу заново. Время между тестами не превышает 14 часа, время восстановления базы из дампа составляет примерно 10 часов. Исходя из этого, время заполнения таблицы не должно превышать 4 часов.

Описание таблицы EXT_SYSTEM_INTERACTION

Таблица EXT_SYSTEM_INTERACTION показывает взаимодействия между системой АС и внешними системами.

Таб. 4 - Описание полей таблицы.

Поле	Тип	Описание
ID	NUMBER	ID, primary_key
MESSAGE_ID	NUMBER	ID внешней системы
REQUEST	Clob	Текст запроса
RESPONSE	Clob	Текст ответа
CONFIRMATION	Varchar(10)	Подтверждение получения
ERROR	Varchar(10)	Ошибка

Выбор средств разработки

Так как база данных разработана под управлением СУБД Oracle, удобно использовать язык программирования java в среде IntelliJ IDEA.

Для взаимодействия с базами данных java набор интерфейсов JDBC – Java Data Base Connectivity, управляемых драйверами БД.

Драйвер БД – специальная библиотека, реализующая интерфейсы JDBC для работы с конкретной СУБД.

Для разработки генератора будут использованы следующие интерфейсы:

java.sql.Connection – интерфейс, реализующий соединение с БД. Создав соединение с БД, можно создавать объекты типа statement, служащие для выполнения запросов

java.sql.PreparedStatement – расширенный тип запросов statement, используемый для выполнения прекомпилируемых sql-запросов.

Генерация данных.

Для обеспечения необходимой скорости заполнения будет использоваться механика прекомпилируемых запросов. Данная механика позволяет установить соединение с БД один раз и выполнить сразу большое количество запросов.

Прекомпилированные запросы записываются во временный BATCH файл, который затем исполняется и посылает запросы к БД. Для заполнения 10 000 000 записей выбран размер файла в 10 000 записей.

Использование таких запросов значительно повышает скорость заполнения таблицы.

Средства мониторинга системных ресурсов

В процессе тестирования протоколируются следующие бизнес-характеристики при помощи средства HP Performance Center 12.x:

• Количество пользователей;

• Количество выполняемых операций;

• Время отклика (среднее, максимальное, минимальное, 90% выполненных операций);

• Количество превышений времени отклика;

• Скорость исполнения операций.

Помимо этого, в ходе теста стандартными средствами SQL фиксируются изменения объёма основных таблиц, табличных пространств, индексов и lob-сегментов

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

Исследование Системы

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

Для проведения нагрузочного тестирования разрабатываются средства нагрузочного тестирования (СНТ). В данном разделе описаны требования к СНТ.

СНТ разрабатываются с использованием ПО НР Performance Center 12.x, предназначенного для создания скриптов и сценариев, и проведения нагрузочного тестирования.

На основании статистики и бизнес-прогнозов для тестирования были выбраны наиболее часто используемые и ресурсоемкие операции, определенные для проведения нагрузочного тестирования.

Исследование проводится на фоне периодической загрузки данных из смежных систем, а также работы пакетных заданий.

Для получения данных о работе системы в процессе тестирования использовались средства визуализации метрик: мониторинг системных ресурсов в процессе запуска тестов происходит с использованием Grafana (для всех серверов), Oracle Enterprise Manager (для серверов баз данных). Погрешность данных средств мониторинга не превышает 1-2% с учетом влияния самих систем мониторинга.

Для каждой снятой метрики средством визуализации строится график следующим образом: один раз в 10 секунд запрашивается текущее состояние наблюдаемого ресурса, затем строится график линейной зависимости %CPU от времени.

Тест считается успешным, если:

o Выполнены подготовительные операции к проведению теста (проверено наличие свободного места на дисках, отсутствие паразитной нагрузки на серверах, выполнены операции для прогрева системы после перезагрузки и т.д.);

o Отклонение количества любых выполненных операций от запланированных не превысило 5% на анализируемом участке (отклонение может возникнуть из-за использования случайного периода между выполнениями сценария, заключенного в ранее рассчитанный интервал);

o Получены данные производительности системы;

o Отсутствуют блокировки конкуренции на БД;

o По окончании теста получены данные прикладного и системного мониторинга;

Примеры результатов тестирования

Время отклика по транзакциям

В ходе теста время отклика операций не превышало порогового значения в 5 сек. Единичные скачки не являются критичными.

Утилизация ресурса CPU на основной базе данных

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

Утилизация не превышала 65%. Пороговое значение для этой метрики – 80%

Утилизация системных ресурсов на серверах приложеий

На сервере приложений так же виден рост утилизации ресурсов процессора. Утилизация достигала 50% на последнем шаге. Пороговое значение для утилизации на серверах приложений – 80%.

Утилизация ресурсов сети

По мере роста нагрузки возрастает и нагрузка на сеть. В ходе теста не наблюдалось задержек ответа от серверов приложений.

Выводы

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

В ходе теста поиска максимума на систему ступенчато подавалась нагрузка (100%-125% - 150%- 175%-200%-250%). На графиках утилизации ресурсов процессора (сервер БД и сервера приложений) виден плавный рост потребления ресурса. Такой же рост замечен на графике утилизации сетевых ресурсов исходящих запросов на серверах приложений.

На протяжении всего теста времена отклика не превышали порогового значения в 5 секунд. Среднее количество запросов в базу данных за час составило порядка 500 операций в секунду. На последней ступени в системе было порядка 6000 активных пользователей.

Процент успешных транзакций – 97.9%. Тест является успешным. На основании полученных данных можно сделать вывод, что система имеет запас прочности в 150%.

Литература

1. Документация HP LoadRunner (URL:https://admhelp.microfocus.com/lr/en/12.53/help/PDFs/HP%20LoadRunner%20User%20Guide.pdf)

2. Документация HP Performance Center (URL:https://admhelp.microfocus.com/pc/en/12.56/pdfs/PCUserGuide.pdf)

3. Эккель Б. Философия Java. 4-е полное издание, изд. «Питер», 2015 г., 640 страниц

4. Jenkins User Documentation (URL: https://jenkins.io/doc/)

5. Дастин Э. Тестирование программного обеспечения. Внедрение, управление и автоматизация / Э. Дастин, Д. Рэшка, Д. Пол; Пер. с англ. М. Павлов. - М.: Лори, 2013. - 567 c.

6. Диго С.М., Базы данных. Проектирование и создание: Учебно-методический комплекс. – М.: Изд. центр ЕАОИ, 2008. – 171 с.

7. Калбертсон Р., Быстрое тестирование / Р. Калбертсон, К. Браун, Г. Кобб. - М.: Вильямс, 2002. - 384 с.

8. Котляров В.П., Основы тестирования программного обеспечения: Учебное пособие / В. П. Котляров, Т. В. Коликова - М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2006. - 285 с.

9. Булат А., Модель нагрузки, как отправная точка при тестировании производительности. URL: http://www.protesting.ru/automation/practice/work_load_model.html (дата обращения 03.05.2017).

10. Журнал «ТЕОРЕТИЧЕСКИЕ И ПРИКЛАДНЫЕ АСПЕКТЫ СОВРЕМЕННОЙ НАУКИ» изд. ИП ПМГ (Северный), номер 4-1, 2017 год, страницы 89-97, статья «Основные этапы развития нагрузочного тестировнаия»

11. Oracle Enterprise Manager // Русский САПР. URL: http://rusapr.ru/prod/progs/element.php?ID=139

12. Диго С.М., Базы данных. Проектирование и создание: Учебно-методический комплекс. – М.: Изд. центр ЕАОИ, 2008. – 171 с.

13. Котляров В.П., Основы тестирования программного обеспечения: Учебное пособие / В. П. Котляров, Т. В. Коликова - М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2006. - 285 с.

14. Хорстманн Кей С., Java. Библиотека профессионала, том 1. Основы. -М.: Вильямс, 2015. - 864 с

15. Zhen Ming Jiang; Ahmed E. Hassan, A Survey on Load Testing of Large-Scale Software Systems // IEEE Transactions on Software Engineering (Volume: 41, Issue: 11, Nov.1 2015), pp. 1091 – 1118

16. B. A. Pozin, I. V. Galakhov - Models in performance testing, - Programming and Computer Software, vol. 37, no.1, pp. 15-25, 2011.