COLA: Коллективное автомасштабирование для облачных микросервисов

1. Введение

Переход от монолитных архитектур к слабосвязанным микросервисам в облачных приложениях вносит значительную сложность в управление ресурсами. Разработчикам необходимо решать, сколько вычислительных ресурсов (например, реплик контейнеров, ВМ) выделить каждому микросервису. Это решение критически влияет как на операционные затраты разработчика, так и на сквозную задержку, которую испытывает пользователь приложения. Традиционные методы автомасштабирования, такие как Horizontal Pod Autoscaling (HPA), масштабируют каждый микросервис независимо на основе локальных метрик, например, загрузки ЦП. Однако этот подход неоптимален, поскольку игнорирует взаимозависимую природу микросервисов в рамках рабочего процесса приложения. COLA (Collective Autoscaler) предлагается в качестве решения, которое коллективно распределяет ресурсы между всеми микросервисами с глобальной целью: минимизировать денежные затраты, обеспечивая при этом, чтобы сквозная задержка приложения оставалась ниже заданного целевого значения.

2. Проблема независимого автомасштабирования

Текущий отраслевой стандарт автомасштабирования работает распределённо, для каждого микросервиса отдельно. Каждая служба запускает действия по масштабированию (добавление/удаление ВМ или подов), когда её собственное использование ресурсов (ЦП, память) пересекает пороговое значение. Фундаментальный недостаток заключается в том, что этот локальный взгляд не учитывает глобальную производительность приложения. Улучшение задержки одного микросервиса может оказать незначительное влияние на общую задержку, воспринимаемую пользователем, если другая служба в цепочке остаётся узким местом. Это приводит к неэффективному распределению ресурсов — избыточному выделению для одних служб и недостаточному для критических узких мест, — что влечёт за собой более высокие затраты без достижения желаемого целевого показателя уровня обслуживания (SLO) по задержке.

3. COLA: Подход коллективного автомасштабирования

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

3.1. Основная оптимизационная модель

Цель формализуется следующим образом:

Цель: Минимизировать общие вычислительные затраты.
Ограничение: Средняя или процентильная сквозная задержка приложения ≤ Целевая задержка.
Переменные решения: Количество ВМ (или реплик), выделенных каждому микросервису $i$, обозначаемое как $n_i$.

Это сложная нелинейная задача оптимизации, поскольку связь между $n_i$ и сквозной задержкой не является прямой и зависит от паттернов нагрузки и межсервисного взаимодействия.

3.2. Процесс офлайн-поиска

Решение этой оптимизации в реальном времени непрактично из-за времени, необходимого для выделения ресурсов и стабилизации производительности. Поэтому COLA использует процесс офлайн-поиска:

Применение нагрузки: Применение репрезентативной нагрузки к приложению.
Идентификация узкого места: Определение наиболее перегруженного микросервиса (с наибольшим ростом загрузки ЦП под нагрузкой).
Распределение ресурсов через задачу о многоруком бандите: Для службы-узкого места определение оптимального количества ВМ с использованием формулировки задачи о многоруком бандите. Функция «вознаграждения» балансирует улучшение задержки и увеличение затрат.
Итерация: Повторение шагов 2-3 для следующего наиболее перегруженного микросервиса до достижения глобальной целевой задержки.
Генерация политики: Результатом является политика масштабирования (отображение характеристик нагрузки в распределения ресурсов), которую можно развернуть в реальном времени.

COLA может интерполировать между известными нагрузками и возвращаться к автомасштабаторам по умолчанию при столкновении с неизвестным паттерном нагрузки.

4. Технические детали и математическая формулировка

Основную задачу оптимизации можно абстрактно представить как:

$$\min_{\{n_i\}} \sum_{i=1}^{M} C_i(n_i)$$ $$\text{при условии: } L_{e2e}(\{n_i\}, \lambda) \leq L_{target}$$ $$n_i \in \mathbb{Z}^+$$ Где:

$M$: Количество микросервисов.
$n_i$: Количество единиц ресурсов (например, ВМ) для микросервиса $i$.
$C_i(n_i)$: Функция затрат для микросервиса $i$ с $n_i$ единицами.
$L_{e2e}$: Функция сквозной задержки, зависящая от всех $n_i$ и интенсивности нагрузки $\lambda$.
$L_{target}$: Желаемый SLO по задержке.

«Задача о многоруком бандите» на шаге 3 поиска COLA предполагает рассмотрение каждого возможного выделения ВМ для службы-узкого места как «руки». Выбор руки соответствует выделению этой конфигурации и измерению результирующего компромисса между затратами и задержкой. Для эффективного исследования и использования пространства конфигураций могут применяться алгоритмы, такие как Upper Confidence Bound (UCB).

5. Результаты экспериментов и оценка

COLA была тщательно оценена в сравнении с несколькими базовыми автомасштабаторами (на основе утилизации и на основе машинного обучения) на платформе Google Kubernetes Engine (GKE).

5.1. Экспериментальная установка

Приложения: 5 приложений с открытым исходным кодом на микросервисах (например, Simple WebServer, BookInfo, Online Boutique).
Платформы: GKE Standard (узлы, управляемые пользователем) и GKE Autopilot (инфраструктура, управляемая провайдером).
Базовые методы: Стандартный HPA (на основе ЦП), продвинутые автомасштабаторы на основе машинного обучения.
Нагрузки: 63 различных паттерна нагрузки.
Цель: Соблюдение заданного SLO по медианной или процентильной (например, p95) задержке.

5.2. Ключевые метрики производительности

Достижение SLO

53/63

Нагрузки, для которых COLA достигла целевой задержки.

Среднее снижение затрат

19.3%

По сравнению со следующим по дешевизне автомасштабатором.

Наиболее экономичная политика

48/53

COLA была самой дешёвой для 48 из 53 успешных нагрузок.

Оптимальность для небольших приложений

~90%

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

5.3. Краткое изложение результатов

Результаты демонстрируют значительное преимущество COLA. Она стабильно достигала желаемого SLO по задержке там, где другие методы терпели неудачу, и делала это при существенно более низких затратах. Экономия была настолько значительной, что «стоимость обучения» (затраты на выполнение офлайн-поиска COLA) окупалась в течение нескольких дней эксплуатации. На GKE Autopilot преимущества COLA были ещё более очевидны, поскольку она эффективно использовала абстракцию, управляемую провайдером, для минимизации затрат.

Описание диаграммы (предполагаемое): Столбчатая диаграмма, вероятно, показывала бы «Затраты на успешный запрос» или «Общую стоимость кластера» на оси Y, а различные автомасштабаторы (COLA, HPA, ML-A) — на оси X. Столбец COLA был бы значительно ниже. Вторая диаграмма могла бы показывать «Частоту нарушений SLO по задержке», где столбец COLA приближается к нулю, в то время как у других наблюдаются более высокие показатели нарушений.

6. Аналитическая модель и пример

Взгляд аналитика: Четырёхэтапная деконструкция

Ключевое понимание: Фундаментальным прорывом статьи является не новый сложный алгоритм, а критический сдвиг в перспективе: рассмотрение всего микросервисного приложения как единой системы для оптимизации, а не как набора независимых частей. Это аналогично сдвигу в компьютерном зрении, вызванному такими моделями, как CycleGAN (Zhu et al., 2017), которые вышли за рамки парного перевода изображений, рассматривая цикличную согласованность всей области преобразования. COLA применяет аналогичный принцип «глобальной согласованности» к управлению ресурсами.

Логический поток: Аргументация убедительно проста: 1) Локальные оптимумы (масштабирование по службам) в сумме дают глобальную неэффективность. 2) Следовательно, используйте глобальную цель (затраты) с глобальным ограничением (сквозная задержка). 3) Поскольку решение этой задачи в реальном времени слишком медленное, решите её офлайн с помощью поиска и разверните полученную политику. Элегантность заключается в использовании задачи о многоруком бандите для эффективного поиска оптимального выделения ресурсов для узкого места — техника, поддерживаемая обширными исследованиями в области обучения с подкреплением для оптимизации систем (например, работы из RISELab Калифорнийского университета в Беркли).

Сильные стороны и недостатки: Сильные стороны: Эмпирические результаты превосходны — снижение затрат на 19,3% является показателем уровня совета директоров. Офлайн-подход прагматичен, избегая нестабильности во время выполнения. Модель не зависит от платформы. Недостатки: Ахиллесовой пятой является зависимость от репрезентативных офлайн-нагрузок. В быстро развивающихся приложениях или при «чёрных лебедях» трафика предварительно вычисленная политика может устареть или привести к катастрофическим последствиям. Возврат к автомасштабаторам по умолчанию, описанный в статье, является временным решением, а не лекарством от этой проблемы устойчивости. Кроме того, сложность поиска, вероятно, плохо масштабируется с увеличением количества микросервисов, что потенциально ограничивает его использование в чрезвычайно больших и сложных приложениях.

Практические выводы: Для облачных архитекторов сообщение ясно: прекратите устанавливать пороги ЦП изолированно. Инвестируйте в создание или внедрение глобальной наблюдаемости производительности и централизованного механизма принятия решений. Начните с гибридного подхода: используйте философию COLA для определения критических цепочек служб и применения к ним коллективного масштабирования, оставляя менее критические, независимые службы на традиционном HPA. Рентабельность инвестиций, как показано, может быть быстрой. Облачным провайдерам следует принять это к сведению; таким инструментам, как GKE Autopilot, необходимы такие интеллектуальные уровни оркестрации, чтобы действительно выполнить обещание «управляемой» инфраструктуры.

7. Перспективы применения и направления развития

Принципы, лежащие в основе COLA, имеют широкую применимость за пределами базового масштабирования ВМ:

Многокритериальное и гетерогенное масштабирование: Будущие версии могли бы коллективно решать о размере ВМ (оптимизированных под память или вычисления), выделении GPU и даже о размещении между зонами доступности или облачными провайдерами для снижения затрат и повышения отказоустойчивости.
Интеграция с сервисными сетками: Связывание COLA с сервисной сеткой (например, Istio) предоставило бы более богатую телеметрию (трассировка на уровне запросов, графы зависимостей) и даже позволило бы напрямую управлять маршрутизацией трафика и размыкателями цепи как частью оптимизации.
Адаптация в реальном времени и метаобучение: Основным исследовательским рубежом является преодоление офлайн-ограничения. Методы метаобучения могли бы позволить COLA быстро адаптировать свою политику в реальном времени на основе обратной связи или безопасно исследовать новые конфигурации в периоды низкой нагрузки.
Цели «зелёных» вычислений: Цель оптимизации может быть расширена для минимизации углеродного следа или потребления энергии в соответствии с инициативами устойчивых вычислений, путём включения данных из таких источников, как проект Cloud Carbon Footprint.
Маркетплейс политик: Для распространённых паттернов приложений (например, электронная коммерция, потоковая передача медиа) предварительно оптимизированные политики COLA могли бы распространяться или продаваться, снижая необходимость в индивидуальных прогонах обучения.

8. Ссылки

Sachidananda, V., & Sivaraman, A. (2022). COLA: Collective Autoscaling for Cloud Microservices. arXiv preprint arXiv:2112.14845v3.
Zhu, J., Park, T., Isola, P., & Efros, A. A. (2017). Unpaired Image-to-Image Translation using Cycle-Consistent Adversarial Networks. Proceedings of the IEEE International Conference on Computer Vision (ICCV).
Burns, B., Grant, B., Oppenheimer, D., Brewer, E., & Wilkes, J. (2016). Borg, Omega, and Kubernetes. Queue, 14(1), 70–93.
Hoffman, M., Shahriari, B., & Aslanides, J. (2020). Addressing Function Approximation Error in Actor-Critic Methods. Proceedings of the 37th International Conference on Machine Learning (ICML). (Пример продвинутого RL, актуального для адаптации в реальном времени).
Cloud Carbon Footprint. (n.d.). An open source tool to measure and visualize the carbon footprint of cloud usage. Retrieved from https://www.cloudcarbonfootprint.org/.
Verma, A., Pedrosa, L., Korupolu, M., Oppenheimer, D., Tune, E., & Wilkes, J. (2015). Large-scale cluster management at Google with Borg. Proceedings of the European Conference on Computer Systems (EuroSys).