nis2/project-tasks/p15-autothrottle.md

P15. Autothrottle: двухуровневое управление ресурсами микросервисов

• Версия и дата проверки: 1.1, 07.09.2026.
• Статус: готово к назначению.

Статья и исходные материалы

• Основная статья: Zibo Wang и соавт. — Autothrottle: A Practical Bi-Level Approach to Resource Management for SLO-Targeted Microservices. NSDI 2024, Outstanding Paper.
• Кратко о статье: В графе микросервисов трудно связать сквозной SLO по задержке с CPU, выделенным каждому отдельному сервису. Autothrottle разделяет управление на верхний контроллер, задающий сервисам целевые коэффициенты throttling, и локальные контроллеры, подбирающие CPU для выполнения этих целей. В проекте двухуровневый подход сравнивается с фиксированными лимитами и одноуровневым управлением на сокращённом графе.
• Почему результат актуален: двухуровневый контроллер используется как baseline и расширяется в Galileo, опубликованной на NSDI 2026. Центральный вопрос о связи сквозного SLO с локальным распределением CPU сохраняется независимо от конкретной версии Kubernetes и обученной модели статьи.
• Артефакты и данные: microsoft/autothrottle под MIT, с тремя приложениями, производственными трассами и автоматизированной оценкой. Полное воспроизведение рассчитано на пять крупных машин, поэтому проект использует уменьшенный стенд и собственную калибровку. Зафиксированные ревизии: microsoft/autothrottle@d237d7f3d765 (MIT; архивирован).
• Что уже предоставляет артефакт: Autothrottle содержит контроллеры, три приложения, трассы и автоматизированную оценку. Разрешено использовать код и нагрузки как основу уменьшенного стенда; опубликованные серии служат исходными материалами.

Обязательный результат

• Проверяемый вопрос или утверждение: разделение управления на сквозной и локальный уровни позволяет экономить CPU при соблюдении SLO устойчивее, чем фиксированные лимиты и один общий либо только локальные контроллеры.
• Технический результат: Развернуть сокращённый граф из 3–5 сервисов или вариант DeathStarBench, реализовать локальные контроллеры CPU и упрощённый верхний контроллер сквозной цели. Добавить фиксированные лимиты и одноуровневую политику как baselines, общий генератор нагрузки и автоматическую проверку соблюдения SLO.
• Обязательное приращение команды: Реализовать и откалибровать предусмотренное локальное управление CPU и упрощённый верхний контроллер для 3–5 сервисов, подготовить фиксированный и одноуровневый baselines. Собственная работа включает перенос контроля на малый стенд, проверку SLO и сравнение при ступенчатой и переменной нагрузке.
• Эксперимент: на подготовленном графе сравнить двухуровневое управление с фиксированными лимитами и одноуровневой политикой при ступенчатой и переменной нагрузке по соблюдению SLO, потреблению CPU и устойчивости управления.
• Границы выводов: соблюдение SLO и экономия CPU проверяются для сокращённого графа, выбранных нагрузок и упрощённых контроллеров; эксперимент не подтверждает устойчивость исходной политики на крупном производственном кластере.
• Ресурсный профиль: расширенно локально, Linux, Docker или Kubernetes, CPU, желательно 16–32 ГБ памяти. Если DeathStarBench не помещается, использовать собственную цепочку сервисов с реальной очередью и управляемым потреблением CPU; имитация допустима только для дополнительного масштабирования.

Содержательные направления

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

Возможное продолжение

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