Що таке обмеження частоти запитів? Простий посібник для створювачів застосунків

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 потрібен лише великим застосункам». Малі застосунки теж є мішенями, бо боти сканують весь інтернет на предмет відкритих форм і кінцевих точок ШІ. Вартість зловживання не залежить від розміру.
• «Достатньо сховати кнопку». Обмеження на стороні браузера — це люб'язність, а не захист. Справжні ліміти мають застосовуватися на сервері.
• «Обмеження за IP завжди справедливі». Багато людей можуть ділити одну IP-адресу — офіс, школа, мобільна мережа. Обмеження на користувача справедливіші, коли люди авторизовані.
• «429 означає, що сервіс зламаний». Це означає, що ви звертаєтеся до нього надто часто. Перевірте свій код на цикли і кешуйте результати, які рідко змінюються — див. що таке кешування.
• «Rate limiting замінює ліміт витрат». Використовуйте обидва. Ліміти у вашому застосунку можуть містити помилки; ліміт витрат провайдера — ваша страховка.

Що питати у вашого конструктора ШІ

• «Додай rate limiting на сервері для входу, реєстрації, скидання пароля та ендпоінта ШІ. Запропонуй розумні ліміти.»
• «Обмеж кожного авторизованого користувача до [N] запитів до ШІ на годину і покажи чітке повідомлення з часом очікування, коли ліміт досягнуто.»
• «Коли зовнішній API повертає 429, повторюй запит з експоненційною затримкою до 3 разів, а потім показуй дружню помилку.»
• «Де зберігаються лічильники обмежень? Чи працюватимуть вони, якщо застосунок запуститься на кількох машинах?»
• «Логуй кожен випадок, коли користувач або IP досягає ліміту, щоб я міг помічати зловживання.»
• «Які зовнішні сервіси викликає цей застосунок і які в них ліміти частоти?»

Rate limiting у Mythex

Документація Mythex прямо каже про це для функцій ШІ: ліміти частоти, безпека і контроль витрат у застосунках, які ви створюєте, — це ваша відповідальність при проєктуванні. Див. Створення застосунку з ШІ. Просіть агента додати ліміти в тому ж повідомленні, де просите функцію. На Pro опублікований сервіс може працювати на до трьох машинах під час великого навантаження (див. Ліміти хостингу), тож просіть лічильники, які живуть у базі даних, а не в пам'яті одного сервера.

Додаткове читання: що таке API, як використовувати LLM API і чек-лист безпеки для застосунків, створених з ШІ.

Запитання