Контроль трафика базы данных: новая система для защиты Postgres
Postgres долгое время не имел эффективного механизма управления трафиком запросов. Когда на базу данных поступает неожиданный всплеск плохих запросов или начинается неконтролируемая нагрузка, Postgres просто принимает всё и падает, когда ресурсов больше нет.
PlanetScale представила Database Traffic Control, встроённую систему управления трафиком Postgres, которая позволяет администраторам устанавливать гибкие бюджеты на потребление ресурсов базой данных. С помощью этого инструмента можно в реальном времени контролировать, сколько ресурсов каждая рабочая нагрузка может потребить, и Postgres будет соблюдать эти ограничения.
Система работает через создание бюджетов, нацеленных на подмножества запросов. Правила для отбора запросов можно создавать по разным измерениям: по паттерну самого запроса (идентифицируется в инструменте Insights), по имени приложения, по пользователю БД или по пользовательским тегам в SQL-комментариях (например, название функции, уровень приоритета, регион, уровень клиента).
Для каждого бюджета можно установить ограничения на процент использования CPU, пиковое потребление CPU, количество одновременных процессов и время выполнения отдельных запросов. Бюджеты можно включать в режим предупреждения (только наблюдение) или режим принудительного применения (активная блокировка превышающих лимит запросов).
Инструмент уже доступен для всех Postgres-баз на PlanetScale и может быть автоматизирован через API или CLI.
Ключевые факты
- Postgres впервые получил встроённый механизм управления трафиком запросов через Database Traffic Control
- Система позволяет создавать гибкие бюджеты для разных подмножеств запросов с использованием правил на основе паттернов, имён приложений, пользователей и тегов
- Поддерживает режим предупреждения (warn) и режим принудительного применения (enforce) для постепенного внедрения и тестирования
- Особенно полезна для приоритизации трафика, изоляции AI-запросов, многотенантных приложений и реагирования на инциденты
- Доступна на всех PlanetScale Postgres-базах и может быть настроена через UI, API или CLI с автоматизацией в DevOps-pipelines
Почему это важно
В production-приложениях запросы к базе данных всегда непредсказуемы: может возникнуть рунавей-запрос, AG-агент может взорвать нагрузку неправильными batch-операциями, а когда ресурсов не хватает, вся база падает. Раньше Postgres мог только принимать запросы, пока не рухнул. Теперь PlanetScale встроила систему защиты прямо в БД: база может сама себя защитить от перегрузки. Это критично для production-систем, где любой downtime = потери пользователей и доверия.
Кому это важно
В первую очередь, инженерам, запускающим Postgres на PlanetScale (MySQL-сервис, но недавно добавили Postgres). Но шире: любой платформе-команде, которая управляет многотенантным приложением и хочет защитить платных клиентов от шума пробных пользователей. DevOps-инженерам, которые строят многоуровневые системы приоритизации. И компаниям, добавляющим AI-агентов в продукт, теперь можно гарантировать, что bot не затопит запросы реальных пользователей.
Как это применить
В dashboardе PlanetScale зайти в Insights → Traffic Control → создать первый бюджет, выбрав теги и лимиты (может потребоваться перезагрузка БД). Начать в режиме warn, посмотреть, что будет заблокировано, потом переключиться на enforce. Для максимума, добавить sqlcommenter теги в запросы приложения, чтобы получить богатую систему категоризации трафика. Для DevOps можно автоматизировать создание бюджетов через API или CLI как часть deploy-пайплайна.
Можно ли доверять
PlanetScale, известный хост для MySQL (позже добавили Postgres), используется крупными компаниями. Обычно поднимать собственные Database Traffic Control-системы сложно, поэтому встроенное решение от маркетплейса самого хоста надёжнее. Но это всегда зависит от того, насколько хорошо PlanetScale тестировала такой функционал в своём окружении, судить сложно без собственного production-опыта.
Риски и подводные камни
Во-первых, перезагрузка БД при включении, нужно планировать downtime или делать это на реплике. Во-вторых, неправильно настроенные бюджеты могут заблокировать критичные запросы, если сам лимит слишком мал. В-третьих, режим warn даёт только наблюдение, нужно проактивно переключаться на enforce, иначе защита не сработает. И наконец, если рабочая нагрузка очень непредсказуема или состоит из множества независимых приложений, настраивать правила может быть сложно.
«Traffic Control даёт вашей Postgres-базе то, чего у неё никогда не было: возможность защитить себя»
— PlanetScale