Публикация Школы траблшутеров

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

Время чтения: 9 мин 10 сек
26 января 2024 г. Просмотров: 134

Тестирование, Производительность | Олег Брагинский, Владислав Бурлака

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

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

С просьбой решить подобную проблему обратилась крупная международная компания, занимающаяся транспортировкой сырья в различные локации. Численность персонала составила 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. Детализированный анализ трафика в различных временных диапазонах