Ограничавахме собствените си услуги

API-то на Mythex допуска 300 заявки в минута от един мрежов адрес. Този лимит съществува, за да ни пази от един човек или скрипт, който бомбардира API-то. В продукцията той започна да отхвърля нашите собствени услуги — частта от нашия edge, която сервира публикуваните приложения, и услугата, която пуска AI агента — защото всяка от тях достига API-то от шепа адреси. Заявките, които носят нашия вътрешен идентификатор, вече са освободени, а всички останали са ограничени точно както преди.

Симптомът

API-то започна да отговаря на някои от нашите собствени вътрешни повиквания с 429 Too Many Requests. Засегнати бяха три вида повиквания и всяко от тях има значение за някого, който ползва Mythex:

Търсене кое приложение живее на персонален домейн. Когато посетител отвори публикувано приложение на собствен домейн, нашият edge пита API-то къде е този сайт. 429 там е посетител, който не може да достигне сайт.
Запазване на работещ ход на агента. Докато агентът работи, напредъкът му се запазва по пътя, така че отговорът да оцелее при опресняване или прекъсната връзка. 429 там е напредък, който не е запазен.
Проверка на достъпа до преглед. Прегледът на приложение, което строите, е защитен, а защитата пита API-то. 429 там е преглед, който не се отваря.

Нито едно от тези не бяха хора, които викат API-то. Всички бяхме ние.

Защо се случи

Пер-адресният лимит прави едно предположение: един адрес е приблизително един повикващ. За хората това е достатъчно близко. За нашата собствена инфраструктура е силно грешно.

Услугата на edge, която сервира публикуваните приложения и прегледите, достига API-то от няколко споделени изходящи адреса. Всеки посетител на всяко публикувано приложение и всяка проверка на преглед изглежда, че идва от един от тях.
Оркестраторът — услугата, която пуска ходовете на агента — достига API-то от един адрес на контейнер. Всеки работещ ход, за всеки потребител, споделя този адрес.

Така бюджетът, предназначен за един човек, се делеше между целия трафик на цяла услуга. Тези услуги го изразходваха заедно, а лимитерът направи точно каквото му беше казано: отказа ги.

Поправката

Нашите собствени услуги вече доказват кои са. Всяко вътрешно повикване носи вътрешен токен, а всеки маршрут в вътрешната секция на API-то проверява този токен, преди да направи каквото и да е.

Лимитерът вече използва същата проверка. Заявка, чийто токен съвпада с вътрешния, е в позволен списък и не се брои към бюджета на адреса. Всичко останало се брои точно както преди: 300 заявки в минута на адрес.

Две подробности не позволиха това да стане дупка:

Грешният токен не минава. Позволеният списък съвпада само с истинския вътрешен токен. Заявка с фалшив токен се брои и се ограничава като всяка друга, а вътрешните маршрути я отхвърлят с 401 Unauthorized.
Самият лимит не се промени. Не вдигнахме числото, за да направим място. Вдигането би скрило проблема до следващото нарастване на трафика и би отслабило защитата за случая, за който лимитът съществува.

Преместихме настройките на лимитера в една малка функция и написахме тестове срещу нея. Един изпраща 20 заявки с вътрешния токен към лимитер, настроен на 5, и очаква всичките 20 да минат. Друг изпраща обикновени заявки от един адрес и очаква първите пет да минат, а тези след тях да бъдат отказани. Трети изпраща заявки с подправен токен и очаква да бъдат отказани по същия начин.

Какво взехме от това

Лимитите носят предположения. „Един адрес — един повикващ“ е вграден в пер-адресен лимит. Той спира да е верен в момента, в който вашите собствени услуги стоят зад споделени адреси — а много от тях стоят: балансьори на натоварването, edge мрежи, контейнери, офис мрежи.
Разпознавайте собствения си трафик по идентичност, не по адрес. Адресите са начинът, по който трафикът пристига, а не кой го е изпратил. Вече имахме идентификатор, който доказва, че повикването е наше; лимитерът просто не го гледаше.
Не го поправяйте, като вдигате числото. По-голям лимит би направил 429 изчезнали за известно време, би защитавал по-слабо и би се провалил пак по-късно.
Гледайте кой е ограничен. 429, който попада върху собствена услуга, е сигнал за бъг във вашите лимити, а не знак, че лимитерът работи.

Какво означава това, ако строите върху Mythex

Нищо за промяна от ваша страна. Публикуваните приложения на персонални домейни, ходовете на агента и прегледите вече не зависят от това колко е натоварен останалият Mythex. Собственият трафик на вашето приложение е ваша работа: лимитът, описан тук, е на нашия API, а не на приложенията, които публикувате.

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