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

Долженко А.И.1, Ермолов И.А.1, Полиев А.Д.1
1 Ростовский государственный экономический университет (РИНХ), Россия, Ростов-на-Дону

Статья в журнале

Информатизация в цифровой экономике (РИНЦ, ВАК)
опубликовать статью | оформить подписку

Том 2, Номер 2 (Апрель-июнь 2021)

Цитировать:
Долженко А.И., Ермолов И.А., Полиев А.Д. Мониторинг программного обеспечения основанного на микросервисной архитектуре // Информатизация в цифровой экономике. – 2021. – Том 2. – № 2. – С. 55-62. – doi: 10.18334/ide.2.2.113382.

Эта статья проиндексирована РИНЦ, см. https://elibrary.ru/item.asp?id=49251475

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

Ключевые слова: архитектура, микросервисы, система, мониторинг, метрики, бизнес-процессы



Последние несколько лет с развитием 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

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

Название
Область
Описание
Время
время выполнения
Система / Сервис
Время выполнения одной задачи
пропускная способность
Система / Сервис
Количество задач, обрабатываемых за единицу времени
время ожидания в очереди
Система / Сервис
Время простоя задачи в очереди
Количество
длина очереди
Система / Сервис
Количество задач в очереди на единицу времени
задачи в обработке
Система
Количество задач, выполняемых в определенный момент времени
Механизмы
уровень простоя
Система / Сервис
Обратное соотношение времени работы системы ко времени его доступности
эффективность использования
Сервис
Количество задач, решаемых сервисом, по отношению к количеству задач системы
Нормативность
уровень производительности
Система / Сервис
Вероятность того, что производительность сервиса не опустится ниже заданного уровня
нормативность производительности
Сервис
Соотношение количества сервисов, производительность которых не ниже заданного уровня, к суммарному количеству сервисов

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

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

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

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

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


Источники:

1. Balalaie A., Heydarnoori A., Jamshidi P. Microservices Architecture Enables DevOps: Migration to a Cloud-Native Architecture // IEEE Software. – 2016. – № 3. – p. 42-52. – doi: 10.1109/MS.2016.64.
2. Timóteo Aline Lopes, Álvaro Re, Almeida Eduardo Santana De, De Silvio Romero, Meira Lemos. Software Metrics: A Survey – CiteSeerX
3. Strunk A. Algorithm to Predict the QoS-Reliability of Service Compositions // 6th World Congress on Services (SERVICES-1). Miami, FL, 2006. – p. 205-212.
4. Yang L., Yu D., Zhang B. Reliability Oriented QoS Driven Composite Service Selection Based on Performance Prediction // Knowledge Systems Institute Graduate School: The 20-th International Conference on Software Engineering & Knowledge Engineerin. 2008. – p. 215-218.
5. Grassi V. Architecture-Based Reliability Prediction for Service-Oriented Computing. / In book: Architecting Dependable Systems III. - Berlin: Springer, 2005. – 279-299 p.
6. Jong Myoung Ko, Chang Ouk Kim, Ick-Hyun Kwon Quality-of-service oriented web service composition algorithm and planning architecture // Journal of Systems and Software. – 2008. – № 11. – p. 2079-2090.
7. Sato N., Trivedi S. Stochastic Modeling of Composite Web Services for Closed-Form Analysis of Their Performance and Reliability Bottlenecks. / Service-Oriented Computing – ICSOC. - Berlin: Springer, 2007. – 107-118 p.
8. Aalst W. Business Process Simulation Survival Guide. / Handbook on Business Process Management. - Berlin: Springer-Verlag, 2015. – 337-370 p.
9. Silver G., Maduko A., Rabia J., Amit Sh., Miller J.A. Modeling and Simulation of Quality of Service for Composite Web Services // 7th World Multiconference on Systemics, Cybernetics, and Informatics. Orlando, Florida, USA, 2003. – p. 420-425.
10. Артамонов И.В. Показатели производительности микросервисных систем // Вестник НГИЭИ. – 2018. – № 8(87). – c. 24-33.

Страница обновлена: 26.03.2024 в 21:49:57