Ги ограничувавме сопствените сервиси

API-то на Mythex дозволува 300 барања во минута од една мрежна адреса. Тој лимит постои за да нè заштити од еден човек или скрипта што го тепа API-то. Во продукција, почна да ги одбива нашите сопствени сервиси — делот од нашата edge инфраструктура што ги опслужува објавените апликации и сервисот што го извршува AI агентот — затоа што секој од нив го повикува API-то од само неколку адреси. Барањата што ги носат нашите интерни креденцијали сега се исклучени, а сите останати се ограничени точно како порано.

Симптомот

API-то почна некои од нашите интерни повици да ги одговара со 429 Too Many Requests. Погодени беа три видови повици, и секој од нив е важен за некој што користи Mythex:

• Проверка која апликација е на приватен домен. Кога посетител ја отвора објавена апликација на нејзин домен, нашиот edge прашува на API-то каде е тој сајт. 429 таму значи посетител што не може да стигне до сајтот.
• Зачувување на тек на агентот. Додека агентот работи, неговиот напредок се зачувува сè додека оди, за одговорот да преживее освежување или прекинат интернет. 429 таму значи напредок што не е зачуван.
• Проверка на пристап до преглед. Прегледот на апликацијата што ја градите е заштитен, а заштитата го прашува API-то. 429 таму значи преглед што не се отвора.

Ни едно од ова не беше повик од луѓе кон API-то. Сите беа од нас.

Зошто се случи

Ограничувањето по адреса прави една претпоставка: една адреса е приближно еден повикувач. За луѓе, тоа е доволно блиску. За нашата сопствена инфраструктура, тоа е крајно погрешно.

• Edge сервисот што ги опслужува објавените апликации и прегледите го повикува API-то од неколку заеднички излезни адреси. Секој посетител на секоја објавена апликација и секоја проверка на преглед пристигнува како да е од една од тие неколку адреси.
• Orchestrator-от — сервисот што ги извршува агентските турни — го повикува API-то од една контејнерска адреса. Секоја работечка турна, за секој корисник, ја дели таа адреса.

Затоа буџетот наменет за еден човек се делеше меѓу целиот сообраќај на цел сервис. Тие сервиси го трошеа помеѓу себе, а лимитерот направи што му беше наредено: ги одби.

Поправката

Нашите сопствени сервиси веќе докажуваат кои се. Секој интерен повик носи интерен токен, а секоја рута под интерниот дел на API-то го проверува тој токен пред да направи што и да е.

Ограничувачот сега ја користи истата проверка. Барање чиј токен се совпаѓа со интерниот е на листа за дозвола и не се брои во буџетот по адреса. Сè друго се брои точно како и порано: 300 барања во минута по адреса.

Две детали го спречија да стане дупка:

1. Погрешен токен не добива пропуст. Листата за дозвола совпаѓа само со вистинскиот интерен токен. Барање со измислен токен се брои и се ограничува како секое друго, а интерните рути го одбиваат со 401 Unauthorized.
2. Самиот лимит не се промени. Не го зголемивме бројот за да направиме место. Зголемувањето би го скриело проблемот до следниот раст на сообраќајот, а би ја ослабело заштитата за случајот заради кој лимитот постои.

Поставките на лимитерот ги префрливме во една мала функција и напишавме тестови за неа. Едниот испраќа 20 барања со интерниот токен до лимитер поставен да дозволува 5, и очекува сите 20 да успеат. Друг испраќа обични барања од една адреса и очекува првите пет да успеат, а следните да бидат одбиени. Третиот испраќа барања со фалсификуван токен и очекува да бидат одбиени на ист начин.

Што извлековме

• Лимитите носат претпоставки. „Една адреса, еден повикувач“ е вградено во ограничување по адреса. Престанува да важи во мигот кога вашите сопствени сервиси стојат зад заеднички адреси — а многу стојат: load balancer-и, edge мрежи, контејнери, канцелариски мрежи.
• Разликувајте го сопствениот сообраќај по идентитет, не по адреса. Адресите се начинот на кој сообраќајот пристигнува, не кој го испратил. Веќе имавме креденцијал што докажува дека повикот е наш; лимитерот едноставно не го гледаше.
• Не поправајте со зголемување на бројот. Поголем лимит би ги отстранил 429 грешките за некое време, би заштитил помалку и би паднал повторно подоцна.
• Погледнете кој е ограничен. 429 што ја погодува сопствената услуга е извештај за грешка за вашите лимити, не знак дека лимитерот работи како што треба.

Што значи ова ако градите на Mythex

Не треба ништо да менувате од ваша страна. Објавените апликации на приватни домени, агентските турни и прегледите повеќе не зависат од тоа колку е зафатен остатокот на Mythex. Сопствениот сообраќај на вашата апликација е ваша работа: лимитот опишан овде е на нашето API, не на апликациите што ги објавувате.

Ако работите сопствен backend, истата стапица важи за секое ограничување на брзина што го додавате. Нашите водичи за што е API и листата за безбедност за апликации изградени со AI се добро место за почеток. А за друг случај каде нашата сопствена инфраструктура ни се спротивстави, видете како дојдовме до деплои со нула 502 грешки.