CLASP показывает, почему auto-scaling для stateful serverless stream processing нельзя сводить только к parallelism и количеству slots. Важны chained requests, operator placement и state migration.
Stateful serverless environments всё чаще рассматриваются как практическая runtime-среда для stream processing. Но как только операторы начинают обмениваться данными через chained requests, простая модель capacity быстро перестаёт работать. Результат знаком любому архитектору: на бумаге кластер выглядит недогруженным, но в реальности упирается в пределы производительности — или, наоборот, получает слишком много workers, что приводит к росту latency и лишним затратам.
Основная проблема заключается не только в том, сколько работы выполняет каждый оператор. Важно также учитывать, сколько ресурсов worker тратит на scheduling и dispatching chained requests между workers. Существующие подходы часто оценивают нагрузку на worker только через executor slots или execution workload, не учитывая overhead удалённых запросов. Если назначено слишком мало workers, кластер не успевает обрабатывать входной поток. Если workers слишком много, больше chained requests пересекают границы между workers, и end-to-end latency растёт.
CLASP предлагает более полную модель. Он рассматривает нагрузку на worker как комбинацию execution cost и chained-request cost. Во время работы система оценивает оба показателя на основе наблюдаемых metrics, а затем использует полученную модель, чтобы определить необходимое количество workers и оптимальное размещение операторов.
Компромисс очевиден: CLASP добавляет больше логики в planner, зато получает более точное представление о том, какую нагрузку кластер действительно способен выдерживать.
Стратегия operator placement строится вокруг простой цели: использовать минимальное количество workers, которое всё ещё позволяет поддерживать заданный input rate. Для этого CLASP размещает операторы на workers, одновременно учитывая стоимость как local, так и remote chained requests. Кроме того, операторы размещаются в reverse-topological order, начиная с sinks. Благодаря этому стоимость коммуникаций уже известна в момент принятия каждого следующего решения.
Это прагматичная эвристика, а не точный solver. Но в статье исходная задача operator placement рассматривается как NP-hard, поэтому использование heuristics здесь является вполне логичным инженерным выбором.
Особенно важна реализация, поскольку stateful serverless systems легко ломаются во время rescaling. Если instances операторов перемещаются, а их state остаётся на прежнем месте, новое размещение немедленно создаёт remote state access и приводит к росту latency.
Поэтому CLASP переносит state одновременно с operator instances и pending requests. Migration выполняется децентрализованно. Planner рассчитывает план и рассылает его workers, после чего сами workers напрямую передают данные друг другу. Каждый worker возобновляет processing локально сразу после завершения собственных входящих transfers.
Интересна и runtime-модель CLASP. Система отслеживает queue length, request latency, chained-request rates и количество различных remote workers, к которым обращаются chained requests. Затем она оценивает три коэффициента: для local chained-request dispatch, remote dispatch и fan-out.
Эти коэффициенты обучаются online на основе данных от saturated workers с использованием recursive least squares. Это полезное архитектурное решение: overhead зависит от конкретного deployment, поэтому его жёсткое задание в конфигурации сделало бы модель менее устойчивой.
Есть и несколько важных trade-offs. CLASP предполагает homogeneous cluster. Кроме того, он использует warm-up phase и зависит от runtime observations от saturated workers. Поэтому модель адаптивна, но не магична: если workload никогда не достигает saturation, у estimator будет меньше данных для обучения.
При поиске количества workers система также использует определённый tolerance, когда применяет binary search после достижения cluster limit. Это разумный инженерный компромисс, но он означает, что система оптимизируется прежде всего под operational stability, а не под математическую точность.
Результаты evaluation показывают, что дополнительное моделирование действительно окупается. По сравнению с state-of-the-art baselines, рассмотренными в статье, CLASP увеличивает throughput до 3,3 раза и снижает median end-to-end latency до 76%.
При этом сама migration выполняется быстро. Planner-side migration обычно занимает 10–20 мс, а workers, как правило, возобновляют работу менее чем за 10 мс. Статья не приводит единого универсального значения latency для всех сценариев, но показывает, что coordinated state migration позволяет избежать длинного recovery path, который возникал бы при постепенном incremental rebalancing.
Более широкий вывод достаточно прост. В stateful serverless stream processing scaling — это не только capacity planning. Это совместная задача operator placement, communication cost и state locality. CLASP представляет собой эволюционное улучшение именно потому, что рассматривает эти три уровня как единый control loop, а не как отдельные подсистемы.
Источник информации
arXiv — крупнейший открытый репозиторий препринтов (с 1991 года, под эгидой Корнелла), где исследователи оперативно размещают рабочие версии статей; материалы общедоступны, но не проходят полное рецензирование, поэтому результаты следует считать предварительными и, по возможности, сверять с обновленными версиями или рецензируемыми журналами. arxiv.org