Когда полоса пропускания не ограничена, один тенант или один тяжёлый поток могут повлиять на весь сервис.
В современных приложениях проблемы ёмкости измеряются не только количеством запросов. Загрузка больших файлов, потоковая передача видео, экспорт API, резервный трафик или массовая загрузка данных ботами могут потреблять высокую полосу пропускания даже при низкой частоте запросов. В этих случаях ограничение скорости запросов само по себе недостаточно.
В мультитенантных средах проблема становится более заметной. Когда один тенант выполняет тяжёлую передачу данных, задержка для других тенантов может возрасти. Без границы ёмкости между клиентами, разделяющими один vService, политику справедливого использования технически невозможно обеспечить.
Традиционное формирование трафика обычно требует сложных архитектур очередей и классов на уровне сети. Эта модель мощная, но работать непосредственно с сигналами L7, такими как путь, тенант, пользователь, JWT-клеймы или исходный IP, на уровне доставки приложений — сложно. Отладка и управление изменениями для операционных команд также усложняются.
Правильный подход — применять потолок полосы пропускания на основе соединений и ключей на уровне ADC. Для vService, пользователя, тенанта или группы рискованного трафика должны определяться разные лимиты, а направления загрузки и скачивания должны управляться независимо.
TR7 Формирование трафика и QoS на уровне vService управляет потреблением полосы пропускания на уровне доставки приложений с помощью режимов stream, per-key и shared.
Наш подход
TR7 применяет управление полосой пропускания как трёхрежимную политику через vService, ключ трафика и совместное использование для высокой доступности.
Потолки загрузки и скачивания применяются на уровне vService
Трафик загрузки от клиентов к backend и трафик скачивания от backend к клиентам могут быть ограничены отдельно для каждого vService. Это ставит ёмкость приложения под контроль на уровне сервиса.
Режим stream даёт каждому соединению собственный лимит
В режиме stream каждое соединение работает под собственным потолком полосы пропускания. Потребление ресурсов одного соединения может быть ограничено при длительных загрузках, скачиваниях или WebSocket-подобных потоках.
Режим per-key применяет квоты по пользователю, IP или тенанту
В режиме per-key лимит применяется в соответствии с ключом, созданным FX-выражением. Исходный IP, пользователь, идентификатор тенанта или значение JWT-клейма — всё это может служить ключом полосы пропускания.
Режим shared обеспечивает общий бюджет ёмкости для кластера
В режиме shared бюджет полосы пропускания в конфигурации с двумя узлами не ограничен одним устройством. Общий лимит для одного тенанта или сервиса может применяться более последовательно на уровне кластера.
Возможности
Формирование трафика превращает ограничения полосы пропускания на уровне соединения, ключа и общие в политику уровня vService.
Три режима ограничений охватывают разные сценарии управления ёмкостью
Режим stream применяет отдельный потолок к каждому соединению. Режим per-key применяет общий лимит для IP, пользователя, тенанта или любого другого ключа FX. Режим shared помогает применять один и тот же лимит между узлами в конфигурации высокой доступности. Таким образом, одна функция охватывает простое ограничение соединений, управление квотами тенантов и управление ёмкостью, общей для всего кластера.
Ядра CPU и память выделяются на службу, а не на арендатора
Каждая опубликованная служба получает свои ядра, свой приоритет CPU и свой потолок памяти. Всплеск трафика на одном приложении или тяжёлая политика WAF на другом остаются внутри этого приложения и не могут заморить остальные. Изоляция ресурсов именно на уровне службы делает плотную консолидацию безопасной: двадцать приложений на одном устройстве ведут себя как двадцать устройств — без двадцати устройств.
Лимиты загрузки и скачивания определяются независимо
В некоторых сервисах доминирует трафик скачивания; в других загрузка потребляет критическую ёмкость. TR7 может независимо ограничивать направление загрузки от клиентов к backend и направление скачивания от backend к клиентам. Например, загрузка может быть более жёстко контролируема в сервисе загрузки файлов, а скачивание — более жёстко в видеосервисе. Это разделение согласовывает политику полосы пропускания с реальным поведением трафика.
FX key builder создаёт лимиты на уровне тенанта и пользователя
В режиме per-key ключ полосы пропускания строится с использованием движка выражений FX. Исходный IP, информация о пользователе JWT, идентификатор тенанта, значение заголовка или любая комбинация этих данных могут служить ключом. Например, все пользователи, принадлежащие одному тенанту, могут разделять общий потолок ёмкости. Это мощный механизм обеспечения справедливого использования в мультитенантных SaaS-моделях.
Таблица per-key может отслеживать большое количество пользователей или тенантов
В режиме per-key каждый ключ отслеживается как отдельное состояние использования. Ключи, которые молчали в течение определённого периода, удаляются; активные ключи остаются под действием политики ограничений. Эта модель обеспечивает централизованный контроль ёмкости для тысяч пользователей или тенантов. Оператор применяет лимиты к логическому владельцу трафика, а не к отдельным соединениям.
Режим shared сохраняет общий лимит для пары высокой доступности
В конфигурациях активный-активный или активный-пассивный трафик может распределяться между двумя узлами. Режим shared помогает применять бюджет полосы пропускания как общее поведение сервиса, а не ограниченное одним узлом. Когда тенант перемещается с одного узла на другой, логика ограничений не нарушается. Это особенно важно для корпоративных сценариев SLA и квот.
Условное применение разделяет премиальный и стандартный трафик
Правила формирования трафика могут работать условно. Премиальный тенант может быть без ограничений, бесплатный тенант ограничен до 100 Кбит/с, а подозрительный IP — до 1 Мбит/с. Условия могут строиться на основе пути, пользователя, заголовка, JWT-клейма, исходного IP или любого FX-выражения. Политика полосы пропускания перестаёт быть единой глобальной настройкой.
В рамках vService и пула может быть определено несколько правил ограничений
Для разных срезов трафика в рамках одного vService могут применяться разные правила ограничений. Например, путь `/download` может иметь собственный лимит, `/api/export` — другой, а стандартные вызовы API — ещё один. Это разбивает управление ёмкостью на сегменты, согласованные с поведением приложения. Оператор применяет контекстно-чувствительное формирование, а не единый грубый потолок.
Потолок на уровне соединения применяется к долгоживущим потокам
WebSocket, загрузка больших файлов или длительные потоковые соединения могут обходить классические ограничения на основе запросов. Режим stream применяет потолок полосы пропускания к каждому такому потоку. Одно долгое соединение не может исчерпать ёмкость сервиса. Эта модель важна для сценариев с медиа, передачей файлов и потоковой передачей в реальном времени.
Изменения лимитов могут применяться без прерывания сервиса
Ограничения полосы пропускания могут обновляться через изменение конфигурации. Новые лимиты применяются к производственному трафику управляемым образом. Это обеспечивает быстрый отклик во время кампаний, подозреваемых событий DDoS, изменений квоты тенантов или временных ограничений ёмкости. Операционным командам не нужно ждать изменения отдельного сетевого устройства.
Мониторинг показывает, какой ключ потребляет свой лимит
В режиме per-key состояние использования для каждого пользователя, IP или тенанта может наблюдаться. Оператор может видеть, какой ключ приближается к потолку квоты. Эта информация ценна для поддержки клиентов, анализа безопасности и планирования ёмкости. События превышения лимита могут быть подключены к логам и конвейерам SIEM.
Потолок скорости может применяться к подозрительному трафику при DDoS-митигации
Не каждый подозрительный поток должен блокироваться полностью. TR7 может применять низкий лимит полосы пропускания к рискованным IP, ASN, путям или группам поведения. Это снижает воздействие атаки, избегая при этом полного отключения реальных пользователей в ситуациях ложного срабатывания. Подход соответствует модели постепенной защиты.
Работает как прозрачный и предсказуемый контроль потока на уровне соединений
Эта функция не является сложной системой очередей на уровне сети или аппаратным механизмом QoS. TR7 применяет потолок полосы пропускания на уровне соединения и потока. Это ограничение понятно в управлении на уровне vService, ключа и условия. Оператор чётко определяет, какой объём ёмкости получает каждый сервис или пользователь.
Операционная глубина
Формирование трафика следует планировать совместно с режимом ограничений, дизайном ключа, направлением загрузки и скачивания, долгоживущими потоками, общим использованием кластера и видимостью аудита.
Выбор режима ограничений
Режим stream подходит для ограничений на уровне соединений, режим per-key — для ограничений на уровне пользователя или тенанта, а режим shared — для общего ограничения для всего кластера. Выбор неправильного режима может нарушить ожидаемое поведение ёмкости. Цель политики должна быть прояснена первой.
Дизайн ключа
Ключ, используемый в режиме per-key, определяет, кому фактически принадлежит ограничение. Исходный IP достаточен в некоторых средах; информация о тенанте или пользователе может обеспечить более точную модель квот. Для нескольких пользователей за NAT один IP может быть несправедливым.
Разделение загрузки и скачивания
Направления загрузки и скачивания имеют разное влияние на ресурсы. Загрузка больших файлов потребляет входящую ёмкость backend; скачивание потребляет исходящую ёмкость. Эти два направления должны ограничиваться отдельно.
Долгоживущие соединения
WebSocket, потоки и передача больших файлов могут оставаться открытыми на длительный период. Ограничения на уровне соединений делают потребление ресурсов более предсказуемым в этих потоках. Настройки тайм-аута и ограничения полосы пропускания следует оценивать совместно.
Общее использование кластера
Режим shared может использоваться для поведения общего бюджета в конфигурациях с двумя узлами. Цель — чтобы политика ограничений оставалась согласованной при изменении распределения трафика между узлами. Это поведение важно для критических SLA тенантов.
Аудит и оповещения
Ключи, достигающие порога ограничений, могут логироваться. На стороне SIEM могут настраиваться оповещения о превышении квоты на уровне тенанта, пользователя или IP. Эта информация полезна как для операций безопасности, так и для поддержки клиентов.
Когда применять
Обеспечение квот полосы пропускания для SaaS-тенантов
В мультитенантной SaaS-среде для каждого тенанта может быть определён отдельный потолок ёмкости. Идентификатор тенанта используется как ключ, и все пользователи, принадлежащие одному тенанту, разделяют общий лимит.
Предоставление разных скоростей для премиального и бесплатного тарифов
Премиальным клиентам может быть дан более высокий лимит полосы пропускания, а бесплатным пользователям — более низкий. Различие тарифов управляется в политике ADC без встраивания логики в код приложения.
Применение ограничений скорости по уровню качества при потоковой передаче медиа
Разные уровни качества в видео- или медиасервисах требуют разной полосы пропускания. TR7 может применять потолок скачивания на основе пути или уровня подписки пользователя.
Замедление подозрительного трафика вместо его блокировки
При подозреваемом DDoS или событии с ботами трафик может быть помещён под низкий лимит скорости, а не полностью отключён. Это снижает воздействие атаки, избегая при этом полного отключения реальных пользователей в ситуациях ложного срабатывания.
Отдельные политики ёмкости для внутреннего и внешнего трафика
Внутренние вызовы API могут оставаться без ограничений, пока трафик из интернета ограничивается. Разделение производится централизованно с использованием условий исходного IP, пути или заголовка.
Троттлинг определённых эндпоинтов во время рекламных кампаний
Определённые эндпоинты могут получать внезапные всплески трафика во время e-commerce кампаний. TR7 применяет временный потолок полосы пропускания к эндпоинтам оформления заказа или кампаний для поддержания стабильности сервиса.
Часто задаваемые вопросы
Как выбрать между режимами stream, per-key и shared?
Можно ли определять лимиты загрузки и скачивания отдельно?
Как строится ключ в режиме per-key и сколько ключей можно отслеживать?
Как работает режим shared в конфигурации высокой доступности?
Является ли эта функция тем же, что Linux tc или аппаратные системы QoS?
Что происходит при превышении лимита и можно ли отслеживать эти события?
Управляйте пропускной способностью трафика на уровне vService и тенанта
Перенесите управление полосой пропускания на ADC. Устанавливайте политики ёмкости с помощью режимов stream, per-key и shared — без отдельных сетевых устройств или сложной архитектуры очередей.