Что такое rate limiting? Простое руководство для тех, кто строит приложения

Rate limiting — это правило, которое ограничивает, сколько запросов можно отправить системе за заданное время: например, 5 попыток входа в минуту или 100 вызовов API в час. Когда лимит исчерпан, новые запросы отклоняются (обычно с кодом ошибки 429 Too Many Requests) до тех пор, пока окно не сбросится. Это защищает приложение от злоупотреблений, не даёт одному активному пользователю замедлить работу для всех и останавливает неконтролируемый рост расходов.

С rate limiting вы сталкиваетесь с двух сторон: сервисы, которые вы вызываете, ограничивают вас, а ваше приложение должно ограничивать своих пользователей.

Почему rate limiting важен при создании приложений с ИИ

Приложения, созданные с ИИ, часто подключаются к платным сервисам — моделям ИИ, почте, SMS, картам, — и каждый вызов стоит денег. Поэтому rate limiting одновременно и функция безопасности, и инструмент контроля бюджета.

• Контроль расходов. Если в вашем приложении есть окно «спросить ИИ» и нет лимита, бот может отправить туда тысячи запросов за ночь. Вы заплатите за каждый.
• Безопасность. Без лимита на форме входа злоумышленник может перебирать тысячи паролей для одного аккаунта. Лимит в несколько попыток в минуту делает это непрактичным.
• Стабильная работа. Один сбойный скрипт, иногда ваш собственный код, зациклившийся в цикле, может перегрузить базу данных и положить приложение.
• Соблюдение лимитов чужих сервисов. Если ваше приложение слишком часто обращается к внешнему API, ошибки 429 получаете вы, и функции ломаются у ваших пользователей.

ИИ-конструкторы сделают то, что вы попросите. Если вы не упомянете лимиты, их часто не будет вовсе.

Бытовая аналогия

Представьте правило бесплатной долива в кофейне: «Один бесплатный долив на посетителя за визит».

• Оно никому не мешает наслаждаться кофе.
• Оно не даёт одному человеку весь день стоять у стойки и наливать себе термос на весь офис.
• Когда кто-то просит четвёртый долив, бариста вежливо говорит «сейчас не получится» — это и есть 429.

Хороший лимит незаметен для обычных клиентов и замечен только тем, кто делает что-то необычное.

Как работает rate limiting

Ограничителю нужны три вещи:

Когда приходит запрос, приложение проверяет счётчик для этого «кто». Если лимит не превышен, запрос проходит, а счётчик растёт. Если превышен, запрос отклоняется.

Есть несколько распространённых способов подсчёта:

Счётчики нужно где-то хранить — быстро и так, чтобы их видели все. На одном небольшом сервере подойдёт память. Когда приложение работает на нескольких машинах, счётчик обычно живёт в общем хранилище, например Redis или в базе данных. Иначе каждая машина считает сама, и реальный лимит становится в несколько раз выше.

Как выглядит ответ при превышении лимита

Когда запрос сверх лимита, хороший API отвечает так:

• Код статуса 429 Too Many Requests.
• Часто заголовок Retry-After, в котором указано, сколько секунд ждать.
• Иногда заголовки с вашим лимитом и числом оставшихся запросов в этом окне (названия зависят от провайдера).

Ваше приложение должно реагировать на 429 ожиданием и повторной попыткой позже, лучше всего с экспоненциальной задержкой (exponential backoff): ждать всё дольше после каждой неудачной попытки (1 секунда, потом 2, потом 4), а не бомбардировать сервис запросами.

Пример: ИИ-помощник для написания текстов

Допустим, вы сделали приложение, в котором пользователи вставляют текст и получают переписанный ИИ вариант.

Без лимитов: кто-то пишет скрипт, который за ночь отправляет 20 000 запросов. Счёт у провайдера ИИ подскакивает, ваш аккаунт упирается в лимит самого провайдера, и настоящие пользователи весь день видят ошибки.

С разумными лимитами:

1. На каждого вошедшего пользователя: 30 переписываний в час на бесплатном тарифе, 300 на платном. При превышении пользователь видит: «Вы исчерпали лимит на этот час. Попробуйте через 12 минут или подключите тариф».
2. На IP-адрес в форме регистрации: 5 регистраций в час, чтобы боты не создавали тысячи бесплатных аккаунтов и не обходили лимит на пользователя.
3. Лимит расходов, заданный в панели провайдера ИИ, как последняя линия защиты, если всё остальное не сработало.
4. Обработка лимитов провайдера: если провайдер ИИ вернул 429, сервер ждёт и повторяет запрос один-два раза, а потом показывает дружелюбное «Сервис занят, попробуйте ещё раз».

Лимиты проверяются на сервере. Лимит, существующий только в браузере (например, отключение кнопки после 30 нажатий), обходится любым, кто вызывает ваш API напрямую.

Ключевые термины

Распространённые заблуждения

• «Rate limiting нужен только большим приложениям». Маленькие приложения тоже становятся целью, потому что боты сканируют интернет в поисках открытых форм и ИИ-endpoint-ов. Цена злоупотреблений не зависит от размера проекта.
• «Достаточно спрятать кнопку». Ограничения в браузере — это любезность, а не защита. Настоящие лимиты должны работать на сервере.
• «Лимиты по IP всегда справедливы». Многие люди могут делить один IP-адрес: офис, школу, мобильную сеть. Лимиты на пользователя справедливее, когда люди вошли в аккаунт.
• «Ошибка 429 значит, что сервис сломан». Она значит, что вы обращаетесь к нему слишком часто. Проверьте код на циклы и кешируйте результаты, которые меняются редко; см. что такое кеширование.
• «Rate limiting заменяет лимит расходов». Нужно использовать оба. Лимиты в приложении могут содержать ошибки, а лимит расходов у провайдера — страховка.

Что спросить у ИИ-конструктора

• «Добавь серверный rate limiting для входа, регистрации, сброса пароля и ИИ-endpoint-а. Предложи разумные лимиты.»
• «Ограничь каждого вошедшего пользователя [N] запросами к ИИ в час и покажи понятное сообщение с временем ожидания, когда он достигнет лимита.»
• «Когда внешний API возвращает 429, повторяй запрос с экспоненциальной задержкой до 3 раз, а потом показывай понятную ошибку.»
• «Где хранятся счётчики лимитов? Будут ли они работать, если приложение запущено на нескольких машинах?»
• «Записывай, когда пользователь или IP-адрес достигает лимита, чтобы я мог заметить злоупотребления.»
• «К каким внешним сервисам обращается это приложение и каковы их лимиты?»

Rate limiting в Mythex

В документации Mythex об ИИ-функциях сказано прямо: лимиты запросов, безопасность и контроль расходов в приложениях, которые вы создаёте, — ваша зона ответственности. См. создание ИИ-приложения. Попросите агента добавить лимиты в том же сообщении, где просите функцию. На тарифе Pro опубликованный сервис при сильном трафике может работать на трёх машинах (см. лимиты хостинга), поэтому просите счётчики, которые хранятся в базе данных, а не в памяти одного сервера.

Смежные материалы: что такое API, как использовать LLM API и чек-лист безопасности для приложений, созданных с ИИ.

Вопросы