The autoscaling of a microservice is considered as a feedback control problem. Based on the container platform logs, a model is built that relates the request rate, the number of replicas, and the service latency. The target load and threshold parameters are selected, at which scaling keeps the latency within the service level agreement. The advantage of adaptive control over static provisioning is shown in terms of the number of violations and resource consumption.
microservices, autoscaling, container orchestration, load balancing, feedback control, queueing theory, replicas, latency, target load
Введение
Микросервисная архитектура делает естественным горизонтальное масштабирование: при росте нагрузки можно запустить дополнительные экземпляры (реплики) сервиса, а при спаде — освободить лишние. В средах контейнерной оркестрации этим занимается отдельный механизм автомасштабирования, который по наблюдаемым метрикам сам меняет число реплик [1]. Однако его поведение определяется набором параметров — целевой загрузкой, порогами, окном стабилизации, — и при неудачном выборе этих параметров система либо не успевает за нагрузкой и нарушает требования к задержке, либо держит избыточные ресурсы и расходует их впустую.
Чаще всего параметры подбирают вручную и по ощущениям, ориентируясь на «среднюю» загрузку. Между тем автомасштабирование удобно рассматривать как задачу управления с обратной связью: контроллер измеряет состояние сервиса, сравнивает его с целевым и вырабатывает воздействие — изменение числа реплик. Такой взгляд позволяет связать параметры контроллера с наблюдаемым качеством обслуживания и подбирать их обоснованно, а не наугад. Близкие задачи распределения ограниченного ресурса при изменяющейся нагрузке рассматриваются в работах [4, 5, 6].
Цель работы — построить по эксплуатационным данным модель, связывающую интенсивность запросов, число реплик и задержку обслуживания микросервиса, и на ней подобрать параметры автомасштабирования, удерживающие задержку в пределах соглашения об уровне сервиса (SLA) [2] при разумном расходе ресурсов.
Объект и метрики
В качестве объекта рассмотрен микросервис обработки заказов, развёрнутый в кластере контейнерной оркестрации. Источником данных служили журналы платформы и балансировщика нагрузки за 14 суток. Для каждого интервала в одну минуту фиксировались: интенсивность поступления запросов (RPS), число активных реплик, средняя загрузка процессора репликой и задержка ответа по 95-му перцентилю (p95).
Выбор 95-го перцентиля вместо среднего здесь принципиален. Среднее «сглаживает» редкие, но болезненные задержки, тогда как именно они нарушают соглашение об уровне сервиса и раздражают пользователя. Целевым показателем качества было принято значение p95 не выше 300 мс. Управляемой величиной является число реплик, а основным наблюдаемым сигналом для контроллера — загрузка процессора, косвенно отражающая, справляется ли сервис с текущим потоком запросов.
Схема взаимодействия компонентов приведена на рисунке 1. Запросы клиентов поступают на балансировщик, который распределяет их по репликам сервиса. Контроллер автомасштабирования собирает метрики с реплик и, сравнивая их с целевыми, добавляет или убирает экземпляры. Получается замкнутый контур: нагрузка влияет на метрики, метрики — на число реплик, а число реплик, в свою очередь, на задержку.
Рисунок 1 – Контур автомасштабирования микросервиса с обратной связью по метрикам
Модель автомасштабирования
Поведение контроллера описывается простым правилом пропорционального типа. Желаемое число реплик определяется отношением текущей загрузки к целевой:
Nж = ⌈ Nт · (Uт / Uц) ⌉ (1)
где Nт — текущее число реплик; Uт — наблюдаемая средняя загрузка реплики; Uц — целевая загрузка; ⌈·⌉ — округление вверх. Если фактическая загрузка превышает целевую, формула (1) даёт прирост реплик, если ниже — сокращение. Целевая загрузка задаёт «запас прочности»: чем она ниже, тем больше резерв и тем устойчивее задержка, но тем выше расход ресурсов.
Чтобы оценить, как число реплик влияет на задержку, сервис рассматривался как система массового обслуживания [3]: реплики — это каналы, запросы — заявки. При коэффициенте загрузки, близком к единице, время ожидания резко растёт, поэтому небольшое увеличение интенсивности запросов в этой зоне приводит к скачку p95. Отсюда практический вывод: целевую загрузку нельзя ставить слишком высокой — работа «на пределе» экономит реплики, но делает задержку неустойчивой.
Чтобы контроллер не «дёргал» число реплик при случайных колебаниях нагрузки, в правило добавлены два ограничения. Окно стабилизации запрещает сокращать реплики сразу после увеличения, а порог нечувствительности игнорирует мелкие отклонения загрузки от целевой. Эти параметры гасят автоколебания (постоянное добавление и удаление реплик) ценой небольшой задержки реакции, и их подбор — компромисс между устойчивостью и быстротой.
Эксперимент: реакция на изменение нагрузки
Параметры контроллера настраивались по данным первых семи суток и проверялись на оставшихся. Целевая загрузка процессора была принята равной 65 %, окно стабилизации на сокращение — 3 минуты, порог нечувствительности — 10 %. На рисунке 2 показан характерный участок с резким ростом нагрузки: интенсивность запросов поднимается с 200 до примерно 980 RPS и затем спадает.
Рисунок 2 – Реакция автомасштабирования: нагрузка и число реплик (а);
задержка обслуживания (б)
Видно, что контроллер наращивает число реплик ступенями вслед за нагрузкой, но с небольшим запаздыванием, связанным со временем запуска новых экземпляров. Именно в эти короткие промежутки задержка p95 подрастает — на графике это пик около 22-й минуты, — но остаётся ниже целевого уровня 300 мс. После того как новые реплики выходят на режим, задержка возвращается к обычным значениям. При спаде нагрузки сокращение реплик происходит плавнее, чем рост, что обеспечивается окном стабилизации и защищает от преждевременного освобождения ресурсов.
Запаздывание реакции оказалось ключевым фактором. При увеличении целевой загрузки до 80 % реплик в среднем требовалось меньше, но во время скачков нагрузки задержка несколько раз превышала порог: система просто не успевала развернуть экземпляры. Снижение целевой загрузки до 50 %, напротив, полностью убирало нарушения, но заметно увеличивало среднее число реплик. Значение 65 % оказалось компромиссным.
Сравнение со статическим резервированием
Адаптивное управление сопоставлялось со статическим резервированием — фиксированным числом реплик, рассчитанным на пиковую нагрузку. Сравнение по проверочной выборке за семь суток приведено в таблице 1. Учитывались доля минут с нарушением SLA, среднее число реплик (как мера расхода ресурсов) и пиковое число реплик.
Таблица 1 – Сравнение стратегий управления числом реплик
|
Стратегия |
Нарушений SLA, % |
Реплик (ср.) |
Реплик (пик) |
|
Фиксированно на пик |
0,2 |
8,0 |
8 |
|
Фиксированно на среднее |
11,4 |
4,0 |
4 |
|
Автомасштабирование |
0,6 |
4,7 |
8 |
Резервирование на пик практически не нарушает соглашение, но постоянно держит восемь реплик, тогда как они нужны лишь в часы максимума. Резервирование на среднюю нагрузку экономит ресурсы, но даёт более 11 % минут с нарушением задержки. Автомасштабирование занимает выгодное положение: при доле нарушений 0,6 % оно расходует в среднем 4,7 реплики вместо восьми, поднимаясь до восьми лишь на короткое время пиков. По сути, адаптивное управление переносит затраты туда, где они действительно нужны.
Обсуждение
Представление автомасштабирования как контура с обратной связью делает настройку прозрачной. Целевая загрузка, окно стабилизации и порог нечувствительности перестают быть «магическими числами»: каждое из них связано с наблюдаемым поведением — задержкой, расходом реплик, устойчивостью к колебаниям. Это позволяет обосновать выбор параметров и воспроизвести его при изменении нагрузочного профиля.
Ограничения модели связаны с её простотой. Не учитывались задержка запуска тяжёлых контейнеров в полном объёме, ограничения со стороны базы данных и сетевые задержки между сервисами, которые при глубокой цепочке вызовов могут стать определяющими. Кроме того, метрика загрузки процессора не всегда отражает узкое место: для сервисов, ограниченных вводом-выводом, точнее масштабировать по длине очереди запросов. Тем не менее даже простая модель позволила обоснованно подобрать параметры и показать выигрыш адаптивного управления, а её сопровождение не требует сложной аналитики.
Заключение
Показано, что автомасштабирование микросервиса целесообразно рассматривать как задачу управления с обратной связью. По журналам контейнерной платформы построена модель, связывающая интенсивность запросов, число реплик и задержку обслуживания, и на ней подобраны параметры контроллера, удерживающие p95-задержку в пределах 300 мс. Сравнение со статическим резервированием показало, что адаптивное управление при доле нарушений менее 1 % сокращает средний расход реплик почти вдвое. Предложенный подход даёт практический способ настраивать автомасштабирование обоснованно, а не подбором наугад.
1. Zhigulin, M. A. Sovremennye podhody k veb-razrabotke: ot monolitnyh prilozheniy k mikroservisam / M. A. Zhigulin // Studencheskiy. – 2025. – № 19-2(315). – S. 25-26. – EDN BZVTMF.
2. Novopashin, A. A. Analiz ispol'zovaniya metoda keshirovaniya dannyh dlya povysheniya bystrodeystviya mikroservisov / A. A. Novopashin, I. B. Gosudarev // Nauchno-tehnicheskie innovacii i veb-tehnologii. – 2022. – № 1. – S. 60-63. – EDN BNEVJO.
3. Chernikova, A. V. Avtomatizaciya processov soprovozhdeniya obrazovatel'noy deyatel'nosti v vuze na osnove vnedreniya mikroservisov / A. V. Chernikova, S. V. Kalmykova, T. V. Sheptunova // Intellektual'naya inzhenernaya ekonomika i Industriya 5.0 (INPROM-2024) : Sbornik trudov X Mezhdunarodnoy nauchno-prakticheskoy konferencii. V 2-h tomah, Sankt-Peterburg, 25–28 aprelya 2024 goda. – Sankt-Peterburg: POLITEH-PRESS, 2024. – S. 545-549. – DOIhttps://doi.org/10.18720/IEP/2024.2/135. – EDN EWTIVS.
4. Mochalov, V. P. Algoritm dinamicheskogo raspredeleniya i balansirovki nagruzki v raspredelennyh oblachnyh vychisleniyah / V. P. Mochalov, N. Yu. Bratchenko, D. V. Gosteva // Modelirovanie sistem i processov. – 2024. – T. 17, № 1. – S. 92-102. – DOIhttps://doi.org/10.12737/2219-0767-2024-17-1-92-102. – EDN EWMPYM.
5. Nasonov, M. A. Modelirovanie raspredeleniya zagruzki remontnyh brigad pri planirovanii tehnicheskogo obsluzhivaniya i remontov oborudovaniya na promyshlennom predpriyatii / M. A. Nasonov, S. A. Mancerov // Modelirovanie sistem i processov. – 2025. – T. 18, № 1. – S. 51-59. – DOIhttps://doi.org/10.12737/2219-0767-2025-51-59. – EDN XFGNMX.
