Ми обмежували самі себе: наші сервіси під власним лімітом

API Mythex дозволяє 300 запитів на хвилину з однієї мережевої адреси. Цей ліміт існує, щоб захистити нас від однієї людини або скрипта, що завалює API запитами. У продакшені він почав відмовляти в доступі нашим власним сервісам: частині нашого edge, що віддає опубліковані застосунки, і сервісу, який запускає агента ШІ, бо кожен з них звертається до API лише з кількох адрес. Запити, що несуть наш внутрішній ключ, тепер звільнені від ліміту, а всі інші обмежуються так само, як раніше.

Симптом

API почав відповідати деяким нашим внутрішнім викликам кодом 429 Too Many Requests. Потрапляли три види викликів, і кожен важливий для того, хто користується Mythex:

Пошук того, який застосунок живе на власному домені. Коли відвідувач відкриває опублікований застосунок за власним доменом, наш edge питає API, де знаходиться цей сайт. 429 тут означає, що відвідувач не може відкрити сайт.
Збереження ходу агента, що виконується. Поки агент працює, його прогрес зберігається по ходу, щоб відповідь пережила оновлення сторінки або обірване з'єднання. 429 тут означає прогрес, який не зберігся.
Перевірка доступу до попереднього перегляду. Попередній перегляд застосунку, який ви будуєте, закритий, і шлюз запитує про доступ у API. 429 тут означає, що попередній перегляд не відкривається.

Жоден із цих викликів не був від людей. Усі вони були від нас самих.

Чому це сталося

Ліміт запитів на адресу робить одне припущення: одна адреса це приблизно один абонент. Для людей це достатньо близько. Для нашої власної інфраструктури це сильно неправильно.

Сервіс edge, що віддає опубліковані застосунки і попередні перегляди, звертається до API з кількох спільних вихідних адрес. Кожен відвідувач кожного опублікованого застосунку і кожна перевірка попереднього перегляду виглядають так, ніби прийшли з однієї з цих кількох адрес.
Оркестратор, тобто сервіс, що виконує ходи агента, звертається до API з однієї адреси контейнера. Кожен хід, що виконується, для кожного користувача, ділить її.

Тож бюджет, призначений для однієї людини, ділився між усім трафіком цілого сервісу. Ці сервіси вичерпали його разом, а ліміт зробив те, що мав: відмовив їм.

Виправлення

Наші власні сервіси вже доводять, хто вони. Кожен внутрішній виклик несе внутрішній токен, і кожен маршрут у внутрішньому розділі API перевіряє цей токен, перш ніж щось зробити.

Тепер обмежувач запитів використовує ту саму перевірку. Запит, чий токен збігається з внутрішнім, потрапляє в список дозволених і не враховується в бюджеті на адресу. Усе інше рахується так само, як і раніше: 300 запитів на хвилину на адресу.

Дві деталі не дали цьому стати дірою:

Неправильний токен не отримує пропуску. Список дозволених збігається лише з справжнім внутрішнім токеном. Запит із підробленим токеном рахується й обмежується, як будь-який інший, а внутрішні маршрути все одно відхиляють його з 401 Unauthorized.
Сам ліміт не змінився. Ми не підняли число, щоб звільнити місце. Підвищення приховало б проблему, доки трафік знову не зросте, і послабило б захист для того випадку, заради якого ліміт існує.

Ми перенесли налаштування обмежувача в одну невелику функцію і написали для неї тести. Один надсилає 20 запитів із внутрішнім токеном до обмежувача, налаштованого на 5, і очікує, що всі 20 пройдуть. Інший надсилає звичайні запити з однієї адреси і очікує, що перші п'ять пройдуть, а наступні буде відхилено. Третій надсилає запити з підробленим токеном і очікує, що їх буде відхилено так само.

Що ми з цього взяли

Ліміти містять припущення. «Одна адреса, один абонент» вбудовано в ліміт на адресу. Воно перестає бути правдою, щойно ваші власні сервіси стоять за спільними адресами, а багато з них стоять: балансувальники, мережі edge, контейнери, офісні мережі.
Розрізняйте свій трафік за ідентичністю, а не за адресою. Адреса це спосіб, яким трафік надходить, а не те, хто його надіслав. У нас уже був облікові дані, що доводять, що виклик наш; обмежувач просто на них не дивився.
Не вирішуйте це підняттям числа. Більший ліміт прибрав би 429 на деякий час, захищав би менше і знову зламався б пізніше.
Дивіться, кого обмежують. 429, що потрапляє на ваш власний сервіс, це повідомлення про помилку у ваших лімітах, а не ознака того, що обмежувач працює.

Що це означає, якщо ви будуєте на Mythex

Нічого змінювати з вашого боку не потрібно. Опубліковані застосунки на власних доменах, ходи агента та попередні перегляди більше не залежать від того, наскільки зайнятий решта Mythex. Трафік вашого застосунку є справою вашого застосунку: обмеження, про яке йдеться тут, діє на наш API, а не на застосунки, які ви публікуєте.

Якщо ви маєте власний бекенд, та сама пастка чекає на будь-який ліміт запитів, який ви додасте. Посібники що таке API і контрольний список безпеки для застосунків, створених з AI є хорошим початком. А інший випадок, коли наша власна інфраструктура заважала сама собі, описано в як ми досягли нуля помилок 502 під час розгортань.