Мониторинг программного обеспечения основанного на микросервисной архитектуре

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

Микросервисная архитектура – вариант сервис-ориентированной архитектуры программного обеспечения, направленный на взаимодействие слабо связанных и легко изменяемых модулей [1] (Balalaie, Heydarnoori, Jamshidi, 2016).

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

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

Преимущества микросервисной архитектуры:

⎯ высокая отказоустойчивость: падение отдельного сервиса не помешает рабочему процессу всей системы;

⎯ гибкость: можно пробовать различные технологии, а также заменять сервисы на другие;

⎯ простота: чем меньше сервис, тем легче его обслуживать;

⎯ масштабируемость: сервисы можно дополнять и расширять.

Недостатки микросервисной архитектуры:

⎯ сложность взаимодействия между сервисами, что делает сложным и тестирование совместной работы;

⎯ рост числа сервисов влечет за собой рост инфраструктуры.

Рисунок 1. Схема ПО с использованием микросервисной архитектуры

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

Для оценки работоспособности сервисов предлагаются два направления:

⎯ метод математического моделирования;

⎯ метод имитационного моделирования.

Для анализа структуры системы применяют метод математического моделирования [3, 5, 6] (Strunk, 2006; Grassi, 2005; Jong Myoung Ko, Chang Ouk Kim, Ick-Hyun Kwon, 2008). Для простых систем используются расчеты, учитывающие расположение сервисов, а в более сложных случаях предлагается использовать различные формулы расчета производительности на основе типовых конструкций [10] (Artamonov, 2018). Однако при росте сложности системы растет и сложность методов моделирования.

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

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

Метрика программного обеспечения – мера, позволяющая получить численное значение некоторого свойства программного обеспечения или его спецификаций [2].

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

Счетчик – это совокупный показатель, представляющий один монотонно увеличивающийся счетчик. Этот тип считает элементы за период времени. Например: количество статусов HTTP «500 Internal Server error» или количество посещений пользователями веб страницы.

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

Гистограмма – тип метрик, представляющий собой выборку наблюдений (обычно такие вещи, как длительность запросов или размер ответов), который подсчитывает их в настраиваемых сегментах. Он также предоставляет сумму всех наблюдаемых значений.

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

При выборе средств мониторинга необходимо выбрать ресурсы, которые будут подвергаться мониторингу. Также нужно определить показатели, определяющие частоту мониторинга, количество оповещений при поломке и прочие параметры [10] (Artamonov, 2018).

Таким образом, в таблице 1 представлен набор показателей работоспособности микросервисов.

Из таблицы 1 видно, что многие показатели одинаково применимы как к отдельным микросервисам, так и ко всей системе.

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

Таблица 1

Показатели работоспособности микросервисов

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

⎯ загруженность сервисов;

⎯ время работы;

⎯ отношение к принятым нормативам и стандартам;

количественные данные.