Введение в мир автоскейлинга в Kubernetes часто ассоциируется с использованием Prometheus — мощного инструмента мониторинга и сбора метрик. Однако по мере роста нагрузки и усложнения систем традиционный подход начал показывать свои ограничения. Мы в Tinybird столкнулись с проблемами задержки и неточности метрик, что мешало нам эффективно масштабировать системы под реальную нагрузку. В итоге мы приняли смелое решение отказаться от Prometheus в пилотном проекте автоскейлинга и перейти на собственную платформу метрик вместе с Kubernetes Event-Driven Autoscaling (KEDA). В этом материале мы делимся нашим опытом и рассказываем, почему отказ от Prometheus оказался одним из лучших решений для стабильной и быстрой адаптации к изменяющимся нагрузкам.
Мир высоконагруженных сервисов известен непредсказуемой нагрузкой. В Tinybird пользователи отправляют тысячи событий в секунду, причем в моменты пикового трафика нагрузка может вырасти в десять раз. При таких условиях классические методы масштабирования, основанные на использовании показателей CPU и памяти, оказались абсолютно недостаточными. CPU часто реагировал слишком поздно — тогда, когда уже возникли задержки в обработке, а память вводила в заблуждение, поскольку иногда высокое потребление могло быть связанно не с необходимостью масштабирования, а с внутренними оптимизациями в приложении. Главной проблемой стала реактивность традиционных метрик, отложенность в данных и неспособность определить реальные бизнес-метрики, такие как глубина очереди или лаг обработчика сообщений.
Стандартная схема с Prometheus предполагает циклический процесс: приложение публикует метрики в формате Prometheus на endpoint /metrics, Prometheus периодически их скрапит и агрегирует, затем KEDA опрашивает Prometheus для получения данных и принимает решения о масштабировании на основе заданных порогов. На первый взгляд все логично, но в реальности появляется множество дополнительных звеньев. Каждый из этих этапов добавляет свою задержку и потенциальные точки отказа. Особенно остро эти проблемы проявляются при пиковых нагрузках, когда скорость реакции критична. Переход на Tinybird и использование KEDA позволил внедрить подход, основанный на реальном времени и данных, вычисляемых на лету.
Вместо того, чтобы хранить и регулярно опрашивать предагрегированные данные, мы начали генерировать метрики в момент запроса KEDA благодаря встроенным SQL-пайпам в Tinybird. Это означало отсутствие задержек на скрапинг и хранение, а также большую гибкость — изменение логики масштабирования свелось к правке SQL-запроса без необходимости разворачивать дополнительный мониторинговый стек. Ключевой метрикой для нас стал лаг потребителей Kafka. Отставание обработки сообщений — важнейший индикатор, который напрямую влияет на производительность и качество сервиса. Tinybird позволяет вытягивать эту метрику из исторических данных с использованием мощной аналитической базы ClickHouse с минимальной задержкой.
Используя Prometheus-совместимый endpoint, мы интегрировали эту метрику в KEDA, которая затем принимала скороспелые решения по добавлению или уменьшению количества подов. Еще одним весомым преимуществом стала высочайшая доступность и отказоустойчивость платформы Tinybird. В то время как поддержка масштабируемого кластера Prometheus требует нескольких реплик, федерации и управления сложными retention-политиками, Tinybird обеспечивает все это «из коробки» без дополнительного операционного оверхеда. Нам больше не нужно заботиться о настройке сложных систем хранения — весь процесс сведен к управлению SQL-запросами. Результаты были впечатляющими.
Отсутствие многослойной задержки позволило сократить время реакции системы на резкие скачки нагрузки с нескольких минут до нескольких секунд. Мы перестали испытывать «промахи» в масштабировании — ситуация, когда новые поды запускаются слишком поздно, а пользователи уже сталкиваются с деградацией сервиса. Также уменьшилась общая сложность инфраструктуры, так как не было необходимости в дополнительном мониторинговом стеке и сервисах сбора метрик. Все происходило в рамках одной платформы, основанной на качественном, актуальном и практически мгновенном состоянии данных. Для обеспечения безопасности взаимодействия KEDA с Tinybird используются токены API и Kubernetes-секреты, что гарантирует авторизацию запросов и защищает метрики от несанкционированного доступа.
Подключение к Tinybird происходит через стандартизированный механизм аутентификации TriggerAuthentication в KEDA, что упрощает настройку и интеграцию с уже существующими конвейерами деплоя. Реализация масштабирования основывается на гибкой конфигурации ScaledObject с несколькими триггерами. В дополнение к кастомным метрикам из Tinybird мы применяем классический CPU-триггер, который выступает в роли дополнительного фильтра и предотвращает недомасштабирование при определенных сценариях. Такой подход обеспечивает сбалансированное решение, учитывающее характеристики и специфики нагрузки. Наш опыт показал, насколько важен подбор правильных метрик для автоскейлинга.
Неподходящие показатели могут привести к нежелательному флаппингу или злой задержке в масштабировании. Поддержание стабильности достигается с помощью настройки «окна стабилизации» — временных интервалов, в течение которых масштабирование вверх или вниз не происходит, что предотвращает частые срабатывания и нестабильность. Для тестирования поведения системы при различных сценариях нагрузки был разработан симулятор, позволяющий генерировать различные паттерны метрик с визуализацией и отладкой на лету. Это дало возможность отточить параметры порогов масштабирования и предотвратить ошибки на реальных данных. Важным открытием стала необходимость регионального подхода к масштабированию.
Из-за различий в трафике и поведении пользователей в разных регионах мы настроили отдельные endpoints Tinybird с индивидуальными порогами и конфигурациями. Это позволило добиться большей оптимизации и адаптации инфраструктуры к локальным условиям. Разумеется, такой отказ от привычного мониторингового стека требует определенного уровня доверия и готовности адаптироваться. Тем не менее выгоды очевидны: уменьшение сложностей поддержки, повышение скорости масштабирования и адаптации к бизнес-метрикам, снижение затрат на операционное сопровождение. Использование платформы, на которой мы сами построили продукт, гарантирует быстрое обнаружение и устранение проблем, а также более тесную связь между разработкой и эксплуатацией.
В итоге — сочетание KEDA с реалтайм аналитикой и кастомными метриками Tinybird обеспечило нам более умное, быстреее и надежнее автоскейлинг. Наш кейс доказывает, что переход на новый уровень управления ресурсами на основе событийной модели и живых данных помогает не только улучшить стабильность и качество сервиса, но и сократить операционные расходы. Те, кто сталкивается с задачей масштабирования сервисов с высокими требованиями по времени отклика и нестабильной нагрузкой, могут попробовать подобный подход без крупномасштабных изменений инфраструктуры. Нужно только организовать публикацию ключевых метрик через Tinybird, подключить KEDA через metrics-api триггер, и можно получить современный механизм, отвечающий реалиям высоконагруженных продакшенов. В эпоху, когда цифровые сервисы устойчивы не столько за счет масштабных ресурсов, сколько благодаря быстрому и точному реагированию, способы автоскейлинга на основе реальных бизнес-метрик приобретают критическую важность.
Наш отказ от Prometheus — не протест против проверенной технологии, а эволюция инструментов, ведущая к более эффективному управлению инфраструктурой и улучшению пользовательского опыта. Tinybird и KEDA — отличный пример такой эволюции, которая и дальше будет искать пути к еще более интеллектуальному масштабированию.