Update project task cards to version 1.1

This commit is contained in:
2026-09-07 21:46:04 +03:00
parent 2bbfdac874
commit f8a5e00ab9
42 changed files with 264 additions and 103 deletions
+3 -1
View File
@@ -1,6 +1,6 @@
# P15. Autothrottle: двухуровневое управление ресурсами микросервисов
- **Версия и дата проверки:** 1.0, 05.09.2026.
- **Версия и дата проверки:** 1.1, 07.09.2026.
- **Статус:** готово к назначению.
## Статья и исходные материалы
@@ -9,11 +9,13 @@
- **Кратко о статье:** В графе микросервисов трудно связать сквозной SLO по задержке с CPU, выделенным каждому отдельному сервису. Autothrottle разделяет управление на верхний контроллер, задающий сервисам целевые коэффициенты throttling, и локальные контроллеры, подбирающие CPU для выполнения этих целей. В проекте двухуровневый подход сравнивается с фиксированными лимитами и одноуровневым управлением на сокращённом графе.
- **Почему результат актуален:** двухуровневый контроллер используется как baseline и расширяется в [Galileo](https://www.usenix.org/conference/nsdi26/presentation/saxena), опубликованной на NSDI 2026. Центральный вопрос о связи сквозного SLO с локальным распределением CPU сохраняется независимо от конкретной версии Kubernetes и обученной модели статьи.
- **Артефакты и данные:** [microsoft/autothrottle](https://github.com/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; имитация допустима только для дополнительного масштабирования.