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

Большие «игроки» часто сталкиваются с молниеносным масштабированием бизнес-решений в условиях неопределённости и неустойчивой стабильности сервисов. Борьба между скоростью принятия решений и качеством продукта нередко сопровождается высокой конкурентностью рынка.

С просьбой решить подобную проблему обратилась крупная международная компания, занимающаяся транспортировкой сырья в различные локации. Численность персонала составила 5’000 сотрудников, объём грузоперевозок – 6 лайнеров в месяц при общем количестве – 40.

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

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

• обработку 4’000 инвойсов в месяц без сбоев и ошибок
• снижение обработки одиночных заявок с 10-15 минут до 2-3
• оптимизация времени работы с комплексными заявками до 10 минут
• увеличение скорости работы системы для нивелирования простоя персонала.

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

1. Выстроить надёжную схему поддержки качества и устойчивости обновлённой системы.
2. Проанализировать существующий процесс сбора, обработки и выполнения заявок.
3. Идентифицировать действующие системные ограничения и возникающие ошибки.
4. Внедрить технические решения, ориентированные на производительность.
5. Подготовить варианты оптимизации и улучшения программного продукта.
6. Определить наиболее удобное решение с учётом целей и задач бизнеса.
7. Измерять полученные результаты, опираясь на целевые показатели.

Начали работу с анализа существующей цепочки поставки продукта, пошагово определив процесс:

1. Попадание клиентской заявки в служебный кабинет сотрудника.
2. Обработка запроса и уточнения дополнительной информации.
3. Подтверждение заказа путём верификации данных клиента.
4. Запрос финальной сметы на товарный склад в кабинет администратора.
5. Компоновка и упаковка товаров с последующей отгрузкой на отправку.
6. Доставка клиентского заказа до места назначения в целевом порту.
7. Обновление статуса заявки в системе на местном порту по прибытии.
8. Выгрузка и доставка товара по указанному адресу через локальный сервис.
9. Подтверждение получения заказа от клиента и перевозчика.
10. Формирование отзыва, оценки и закрытие заявки в системе.

Исходя из вышеописанного идентифицировали проблематику:

1. Замедление времени получения заявок при возрастающей нагрузке свыше 60 шт. в час.
2. Снижение производительности системы при параллельном пользовании на 46%.
3. Понижение времени отклика при заявке администратору на склад до 2 минут.
4. Зависание системы при обновлении статуса заявка на месте выгрузки.
5. Падение скорости отклика серверов при закрытии заявки при доставке.
6. Убыль производительности при большом количестве отзывов.

Дополнительно выделили возможные упущения:

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

Проанализировав уязвимости, сформировали пути решения:

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

Систематизировав полученное, перешли к реализации задуманного.

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

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

Прошлись по структуре данных, переформатировав старую версию на основе SQL, использующую язык MySQL, на более гибкую NoSQL с использованием MongoDB. В рамках первого подхода ограничились отдельной структурой, описывающей её двухмерным способом (рис. 1,2).

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

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

Итоговое архитектурное решение, внедрённое на основе вышеперечисленных принципов, превратили в понятную модельную структуру.

Рис. 1. Структура базы данных приложения на основе NoSQL с использованием MongoDB

Одним из критически важных внешних (third-party) решений выбрали систему учёта выставления счетов и отчётности Zoho Invoice – производительное, с совместным внедрением мини-СРМ-системы для работы с различными платформами: Windows, MacOS, iOS и Android.

Рис. 2. Иерархия вложенных объектов в MongoDB

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

Выделили режимы нагрузок: регулярный, допустимо высокий и максимальный. Первые два тестировались на длительных периодах – 4-8 часов, последний – на работу до отказа.

Выстроив общую структуру сети (рис. 5), определили показатели отклонения от нормы по каждому из параметров (рис. 6), узкие места прохождения запросов и ответов (рис. 7). Подытожили тенденции в виде анализа общего трафика, обратив внимания на детали (рис. 8).

Внедрив вышеизложенные изменения, пришли к финальным показателям:

• скомпенсировали коэффициент месячного простоя персонала в 3,53 раза до 32 часов
• оптимизировали время обработки одиночных заявок с 15 минут до средних 45 секунд
• достигли максимального показателя 4’300 инвойсов за месяц с процентов сбоев 2,3%
• снизили цифру обработки комплексных заявок с 30 до 2,5 минут
• увеличили скорость работы системы на 268%.

В заключение помогли структурировать департамент службы поддержки клиентов:

1. Создали понятные инструкции для инженеров начиная с первого дня работы, учли основные сценарии поведения пользователей, прописав детальный путь решения каждого.
2. Подключили отдел разработки в график дежурств 24/7 для оперативного решения критических задач в течение трёх часов с момента подачи заявки.
3. Обучили персонал специализированной терминологии английского языка для отрасли с целью эффективной письменной и устной коммуникации.
4. Реструктуризировали модель сбора заявок путём создания отдельной JIRA-доски со специфическими фильтрами.

Рис. 3. Оптимизированная архитектура комплексной системы

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

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

Рис. 4. Решение по формированию отчётности в рамках мини-СРМ

Рис. 5. Общая структура MPLS сети с учётом ACI карты

Рис. 6. Сигналы различной важности для каждого из видов нагрузки

Рис. 7. Качество прохождения запросов через каждый из узлов сервера

Рис. 8. Детализированный анализ трафика в различных временных диапазонах