Управление производительностью приложений

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

• Нагрузка — это объём транзакций, обрабатываемых приложением, например число транзакций в секунду, запросов в секунду, страниц в секунду. Если на приложение не оказывается серьёзная нагрузка со стороны вычислительных запросов (например, поиска, расчётов, передачи данных), большинство приложений демонстрируют достаточную производительность. Поэтому разработчики часто не замечают проблем с производительностью на стадии разработки.

• Время отклика — это время, необходимое приложению для отклика на действие пользователя при данной нагрузке^[2].

Второй набор метрик производительности фиксирует вычислительные ресурсы, используемые приложением при данной нагрузке, позволяя определить, хватает ли ресурсов для обработки заданных объёмов данных и где может возникнуть «узкое место» производительности. Измерения этих параметров позволяют сформировать эмпирическую производственную базовую линию для приложения. Она затем служит для обнаружения изменений производительности. Изменения производительности могут коррелироваться с внешними событиями, что создаёт возможность прогнозировать будущие изменения в поведении приложения^[3].

Использование APM особенно характерно для веб-приложений, что связано с возможностью глубокого и детального мониторинга^[4]. Помимо оценки времени отклика для пользователя, можно также отслеживать время отклика отдельных компонентов веб-приложения с целью выявления причин задержек. Существуют также HTTP-аппараты, позволяющие декодировать связанное с транзакцией время отклика на уровне веб-сервера.

В своей Концептуальной модели APM исследователи Gartner выделяют пять измерений менеджмента производительности приложений^[5][6][7][8]:

• Мониторинг пользовательского опыта (как активный, так и пассивный)
• Автоматическое обнаружение и моделирование архитектуры выполнения приложений
• Профилирование пользовательских транзакций (также известно как управление бизнес-транзакциями)
• Мониторинг компонентов приложения
• Отчётность и аналитика данных приложений.

В 2016 году Gartner пересмотрела определение, выделив три основные функциональные области^[9]:

• Мониторинг пользовательского опыта (EUEM), эволюционировавший в мониторинг цифрового опыта (DEM);
• Новая область — обнаружение, трассировка и диагностика приложений (ADTD), объединяющая три ранее отдельных направления (обнаружение и визуализация архитектуры, профилирование пользовательских транзакций, глубокая диагностика компонентов), поскольку они все направлены на локализацию проблем и тесно связаны друг с другом;
• Аналитика приложений (AA).

С первой половины 2013 года рынок управления производительностью приложений характеризуется интенсивной конкуренцией как в технологической, так и в стратегической сферах, с большим числом вендоров и различных взглядов на проблему^[10]. Это привело к заметной трансформации рынка — к управлению производительностью приложений стали обращаться поставщики из смежных областей (например, мониторинга сетей, управления системами, инструментирования приложений, мониторинга веб-производительности). В результате термин APM утратил строгость и превратился в концепцию управления производительностью приложений для множества вычислительных платформ, а не только для одной технологической ниши^[11]. Из-за большого числа поставщиков выбор подходящего решения становится сложнее. Необходимо очень внимательно выбирать инструменты, чтобы их возможности действительно соответствовали требованиям^[12].

Среди ключевых проблем внедрения APM — (1) трудности инструментирования приложений для отслеживания производительности, особенно при взаимодействии компонентов, а (2) виртуализация приложений, которая увеличивает изменчивость показаний^[13][14]. Для решения первой проблемы управление сервисами приложений предполагает акцент на видимости бизнес-сервисов. Вторая проблема связана с тем, что современные облачные и распределённые приложения больше не размещаются на одном сервере — зачастую отдельные функции реализованы как сетевые сервисы, работающие на множестве виртуализированных платформ. Приложения могут динамически перемещаться между системами для достижения целей по обслуживанию и для преодоления временных сбоев^[15].

Сами приложения становятся всё более сложными для управления, поскольку строятся по принципу распределённых, многоуровневых, многокомпонентных систем и часто используют такие фреймворки как .NET и Java^[16]. Концептуальная модель APM помогает выстроить приоритеты внедрения — на первом этапе следует сосредоточиться на отдельных измерениях, соответствующих определённым целям и эффектам. На схеме модели представлены три основных фокуса для каждого измерения, их преимущества и области реализации. Фокусы с приоритетом помечены как «основные», с меньшим приоритетом — как «второстепенные»^[17].

Измерение передачи трафика от пользовательского запроса к данным и обратно — часть мониторинга пользовательского опыта (EUE)^[18]. Результатом такого мониторинга является реал-тайм мониторинг приложений («мониторинг сверху вниз»), включающий пассивные и активные компоненты. Пассивный мониторинг — обычно агентное решение, реализующееся посредством зеркалирования портов сетевого оборудования. К важным функциям относится поддержка мультикомпонентной аналитики. В активном мониторинге используются синтетические пробы и веб-роботы для отчёта о доступности системы и бизнес-транзакций. Активный мониторинг хорошо дополняет пассивный — вместе эти методы обеспечивают видимость состояния приложения в периоды низкой активности.

Управление пользовательским опытом (UEM) — подкласс, выделившийся из мониторинга EUE, отвечающий за отслеживание поведенческого контекста пользователя. В современном понимании UEM охватывает не только доступность, но и задержки, и нестабильность, возникающие во взаимодействии пользователя с приложением и сервисами^[19]. UEM обычно реализуется через агенты, иногда с помощью внедрения JavaScript на стороне пользователя.

Перед внедрением архитектуры исполнения важно организовать мониторинг работоспособности (up/down) всех узлов и серверов среды (bottom-up monitoring). Это создаёт фундамент для дальнейшей корреляции событий и позволяет обобщённо понимать, как совмещаются сетевые и прикладные уровни.

Основное внимание уделяется транзакциям, определяемым пользователями, или URL-страницам, имеющим значение для бизнеса. Например, если для приложения определено 200–300 уникальных страниц, их целесообразно сгруппировать в 8–12 ключевых категорий. Это позволяет составлять значимые SLA-отчёты и отслеживать тренды производительности приложения с бизнес-точки зрения: начинать с широких категорий и постепенно уточнять их структуру. Подробнее см. управление бизнес-транзакциями.

Глубокий мониторинг компонентов (DDCM) требует установки агентов и ориентирован, как правило, на мониторинг middleware (веб-, прикладные, месседжинг-серверы). Он обеспечивает актуальное представление о состояниях стеков J2EE и .NET Framework, связывая их с бизнес-транзакциями. Эффективные мониторы ясно показывают путь от выполнения кода до рендеринга URL и запроса пользователя. Поскольку DDCM тесно связан со вторым измерением APM, большинство решений на рынке также предлагают функциональность application discovery dependency mapping.