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

Рассказываем, как с помощью нового подхода «КОРУС Консалтинг» смогли сэкономить и минимизировать ручные операции при испытании производительности систем на платформе 1С. Подробности под катом!

Используйте навигацию, если не хотите читать текст полностью:

→ Где брать ресурсы
→ Решение
→ Система онлайн-мониторинга
→ Анализ полученных данных
→ Как новый подход уменьшил расходы в 7 раз
→ Возможности и дальнейшее применение

Где брать ресурсы

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

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

Тогда почему бы не сэкономить и не арендовать мощности только на время выполнения теста, который занимает не так много времени относительно всего проекта? Этим вопросом озадачился Дмитрий Овчаренко, технический архитектор департамента 1С «КОРУС Консалтинг».

Рассмотрим ключевые требования к решению.

• Использование облачных ресурсов только во время выполнения сценариев.
• Максимальная автоматизация создания инфраструктуры для нагрузочного тестирования и сбора результатов (выгрузка отчетов и логов, сохранение скриншотов дашбордов).
• Возможность масштабирования и переиспользования. Решение должно быть достаточно гибким, чтобы запускать тесты в разных условиях (версия платформы 1С, количество серверов в кластере, версия СУБД Postgres и ее параметры).

Решение

Проект состоит из двух частей. Первая управляет развертыванием серверов в облаке с помощью Terraform, вторая — установкой и настройкой ПО с помощью Ansible.


Сетевая топология проекта «КОРУС Консалтинг».

В качестве провайдера выбран Selectel. У «КОРУС Консалтинг» уже был фиксированный сервер лицензирования 1С (lic) и файловый сервер (Shared folder).

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

Разберем вкратце основные компоненты инфраструктуры.

• DB — сервер с базой данных.
• app1c — кластер серверов 1С. Проект поддерживает различные конфигурации кластера. Например, с одним или двумя центральными серверами, основным и рабочим и т. д.
• RDP-01, RDP-02, RDP-NN — терминальные серверы, которые выполняют роль агентов. На них запускаются виртуальные рабочие места.
• Bastion host — сервер на Linuх c доступом в интернет по белому (статическому) IP. На нем подняты служебные компоненты для контура, сбора метрик и анализа, а также различные утилиты.
• Control Host — сервер на Windows для запуска испытаний через тест-центр. Для удобства сервер тоже получает белый IP.
• Global router — глобальный роутер, программно-аппаратное средство облака, которое позволяет связывать разные сегменты и сети в единое пространство. Благодаря ему контур нагрузочного тестирования может получать лицензии 1С, которые развернуты на выделенных серверах Selectel.
• lic — сервер лицензирования 1С. Он подключается к кластеру машин 1С, чтобы выдавать лицензии.
• Shared folder — файловый сервер, где размещаются резервные копии тестируемых баз.

Этапы работы

1. Создаем инфраструктуру. Вводим параметры контура в конфигурационный файл. Запускаем Terraform, который разворачивает все серверы, затем — Ansible Playbook, который устанавливает на них необходимое ПО: 1С для соответствующего кластера серверов, Postgres на сервер СУБД и другое.

2. С помощью Ansible Playbook загружаем базу данных в подготовленную инфраструктуру.

Второй этап может занять несколько часов, если база большая. При тестировании 1С, рассчитанной на 1 000 пользователей, требуется около 16 RDP. Чтобы сэкономить, мы поднимаем терминальные серверы только на следующих этапах.

3. Выполняем terraform apply для RDP-серверов и с помощью Ansible Playbook устанавливаем на них тонкие клиенты. Затем на каждом RDP запускаем базу в режиме агента тестирования.

4. Интерактивно открываем базу в режиме «1C: Предприятие», настраиваем и запускаем сценарий.

5. После окончания теста собираем со всех хостов логи, скриншоты дашбордов, формируем отчеты и сохраняем прочую информацию, которая позволит проанализировать результаты. Этот процесс также автоматизирован — после выполнения Ansible Playbook все нужные данные сохраняются локально в виде архива.

6. Запускаем terraform destroy. Команда удаляет все ресурсы из облачного проекта.

7. Анализируем результаты.

Ключевые параметры

Вкратце рассмотрим параметры, которым уделили внимание при конфигурировании решения.

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

• количество RDP,
• объем ОЗУ,
• количество vCPU,
• размер диска.

На данный момент решение поддерживает единственный инстанс Postgres. Среди настроек, которыми можно управлять:

• количество vCPU,
• объем ОЗУ и дисков,
• типы дисков,
• версия Postgres Pro.

В кластере серверов тоже много параметров. Наиболее важные:

• общее количество серверов,
• количество vCPU,
• объем ОЗУ,
• размер диска,
• количество центральных серверов.

Что еще указываем в файле конфигурации решения?

1. Настройки, которые позволяют включить в кластер «внешний» сервер лицензирования 1С.
2. Версию платформы 1C. Если подходящий дистрибутив не будет найден локально, скрипт скачает и установит все необходимое с официального сайта вендора.
3. Путь к dt-файлу, из которого загружается база для проведения испытаний.

Система онлайн-мониторинга

Система построена на Grafana. Дашборды подготовлены заранее, а Ansible отвечает за то, чтобы они были скопированы в правильный каталог. Все виртуальные машины отслеживают следующие показатели: CPU, ОЗУ, I/O, сеть.

Дополнительно на сервере Postgres мониторятся:

• shared buffers,
• cache hit ratio,
• блокировки и транзакции,
• объемы обрабатываемых данных операциями SELECT, INSERT UPDATE, DELETE.

На сервере 1С:

• память rphost, ragent, rmngr суммарно/по сеансам;
• сессии, лицензии;
• текущее время вызова (и время вызова СУБД);
• ожидания на управляемых блокировках;
• доступная производительность;
• количество исключений.

На скриншоте выше видно, что нагрузка распределилась очень плавно — это хороший показатель для «чистового» нагрузочного тестирования. Каждая точка — это короткий серверный вызов, который произошел только в одно окно сбора метрик. Более длительные вызовы относятся к определенной категории пользователей, которые выполняли сложные отчеты.


Дашборд выше — это показатели рабочего процесса в консоли серверов 1С.


Панель с длительностью управляемых блокировок берет данные из ClickHouse. Плагин Filebeat (установлен на каждом сервере в кластере 1С) разбирает технологический журнал 1С и отправляет его в Logstash. Последний не только агрегирует эти данные, но и заменяет имена таблиц по специальному словарю, чтобы они отображались в терминах 1С, а не СУБД. После этих манипуляций данные отправляются на хранение в ClickHouse.

Grafana запрашивает из таблицы ClickHouse события блокировок TLOCK с ненулевой длительностью и наличием WaitConnections, затем суммирует их по области (Region) и выводит результат в панель.

Анализ полученных данных

В ходе нагрузочного тестирования генерируется много важных для дальнейшего анализа данных. Перед уничтожением всех ресурсов в облачном проекте запускаем еще один Ansible Playbook.

Полезная информация, которую необходимо собрать и локально сохранить:

• сводный отчет «Тест-центра»,
• выгрузка технологического журнала,
• журнал регистрации,
• логи PostgreSQL,
• отчет pgBadger,
• планы запросов,
• скриншоты дашбордов Grafana.

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


Отчет pgBadger.

Одна из самых популярных утилит для анализа логов и сбора метрик PostgreSQL — pgBadger. В отчете имена таблиц БД заменяются по словарю на имена в контексте метаданных 1С.


Скрипт, выполняемый при выгрузке данных.

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

Как новый подход уменьшил расходы в 7 раз

Специалисты «КОРУС Консалтинг» подсчитали затраты на нагрузочное тестирование в рамках реального проекта. Дано: 1 000 пользователей ИТ-системы, 30 дней, 10 запусков по 8 часов. Стоимость необходимого контура — 12 000 ₽/день. При классическом подходе, который предполагает аренду сервера на все время работы над проектом, пришлось бы заплатить 360 000 ₽. При новом — 48 000 ₽, так как оплата производится только за продолжительность использования мощностей.

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



Графическое сравнение затрат двух подходов.

Возможности и дальнейшее применение

Решение «КОРУС Консалтинг» позволяет в разы сократить затраты на тестирование производительности, а также снять с ИТ-партнера и заказчика головную боль в виде поиска необходимых ресурсов для проведения испытаний. Кроме того, из-за высоких требований к объему вычислительных ресурсов у проектных команд может уходить много сил на согласование и поиск компромиссов. Использование облачного провайдера решает и этот вопрос.

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

Помимо прочего, минимизация ручных операций позволяет ИТ-специалистам уделять больше времени написанию сценариев. Чем выше их качество, тем более релевантные результаты получит заказчик. У решения есть еще один плюс — оно значительно упрощает повторное проведение нагрузочных испытаний. Например, при переходе на новую версию платформы или при внесении изменений в конфигурацию кластера 1С.

Интересно, как работает решение на практике? Смотрите запись митапа «Без нагрузки на бюджет: как в разы сократить затраты на тестирование производительности 1С».