Повесть о двух автоскейлерах Flink

В сфере искусственного интеллекта произошло заметное событие. levashove 38 минут назад Повесть о двух автоскейлерах Flink 9 мин 1. 1K Блог компании VK Tech DevOps * Высоконагруженные системы * Kubernetes * Big Data * Перевод Автор оригинала: Samuel Yeboah, Francesco Di Chiara и Mingliang Liu Команда VK Cloud перевела материал Netflix о двух подходах к автомасштабированию Apache Flink. Сначала компания разработала собственный автоскейлер, который анализировал внешние метрики кластера и эффективно экономил ресурсы на простых потоковых конвейерах.

Но с ростом числа stateful-задач и сложных графов обработки этого стало недостаточно. В статье — о том, чем автомасштабирование на уровне отдельных операторов отличается от масштабирования всего кластера, как Flink Autoscaler использует показатель True Processing Rate, зачем Netflix запускает отдельный Temporal workflow для каждой задачи и почему ради стабильности иногда выгоднее сознательно оставить запас вычислительных ресурсов. Почему автомасштабирование не опционально при нашем масштабеNetflix использует потоковую обработку на Apache Flink с 2017 года.

Технические детали

По состоянию на 2026 год мы эксплуатируем более 30 000 задач Flink в нескольких регионах AWS. Большинство из них разворачивается не вручную; они генерируются нашей управляемой платформой Data Mesh, поэтому большинство пользователей никогда не работают с задачами Flink напрямую. Меньшая, но растущая часть — это кастомные задачи, которые создают и эксплуатируют команды по всей компании для таких сценариев использования, как персонализация, рекламные технологии (Ads) и прямые трансляции событий (Live events).

Они варьируются от задач с одним оператором, которые перекладывают записи между топиками Kafka, до stateful-конвейеров с ветвлениями, соединениями и терабайтами состояния. Их нагрузка колеблется в зависимости от суточных циклов, релизов и региональных аварийных переключений. Выделять ресурсы под пиковую нагрузку для каждой задачи расточительно, а под среднюю — во время всплесков это приводит к задержкам.

А в нашей платформе действие масштабирования не бесплатно. По умолчанию это означает создание savepoint, плавную остановку задачи и ее перезапуск с новым размером. Для крупной stateful-задачи такой цикл может занять несколько минут.

Отраслевые последствия

Это оставляет по-настоящему сложный вопрос: как дать каждой задаче ресурсы, которые ей нужны, именно тогда, когда они ей нужны? И как сделать это без участия человека, не сломав при этом ничего? Первый автоскейлер: наблюдение снаружиНаш первый ответ мы создали примерно в 2019 году: это был автоскейлер, устроенный как задача потоковой обработки.

Он работал на Mantis, потребляя живой поток метрик уровня кластера из Atlas, нашей платформы телеметрии, включая сигналы CPU, network, Kafka lag, input-rate и consume-rate для каждой задачи.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.