Omejevali smo lastne storitve

API platforme Mythex dovoli 300 zahtevkov na minuto z enega omrežnega naslova. Ta omejitev obstaja, da nas zaščiti pred enim uporabnikom ali skriptom, ki bombardira API. V produkciji je začela zavračati naše lastne storitve: del našega robu, ki streže objavljene aplikacije, in storitev, ki požene AI agenta. Vsaka od njiju dostopa do API-ja le z nekaj naslovi. Zahtevki, ki nosijo naše interno poverilnico, so zdaj izvzeti, vsi drugi pa so omejeni točno kot prej.

Simptom

API je nekatere naše lastne interne klice začel odgovarjati z 429 Too Many Requests. Zadeli so tri vrste klicev, vsak pa je pomemben za nekoga, ki uporablja platformo Mythex:

• Iskanje, katera aplikacija živi na domeni po meri. Ko obiskovalec odpre objavljeno aplikacijo na lastni domeni, rob vpraša API, kje je ta spletna stran. 429 tam pomeni obiskovalca, ki ne more doseči strani.
• Shranjevanje teka agenta. Medtem ko agent dela, se njegov napredek shranjuje sproti, da odgovor preživi osvežitev ali prekinjeno povezavo. 429 tam pomeni napredek, ki ni bil shranjen.
• Preverjanje dostopa do predogleda. Predogled aplikacije, ki jo gradite, je zaščiten, zaščita pa vpraša API. 429 tam pomeni predogled, ki se ne odpre.

Nobeden od teh ni bil klic API-ja od ljudi. Vsi so bili naši.

Zakaj se je to zgodilo

Omejitev na naslov temelji na eni predpostavki: en naslov je približno en klicatelj. Za ljudi je to dovolj blizu. Za našo lastno infrastrukturo pa je močno napačno.

• Storitev robu, ki streže objavljene aplikacije in predoglede, dostopa do API-ja iz nekaj skupnih odhodnih naslovov. Vsak obiskovalec vsake objavljene aplikacije in vsako preverjanje predogleda se pojavi, kot da prihaja z enega od teh nekaj naslovov.
• Orkestrator, storitev, ki požene teke agenta, dostopa do API-ja iz enega naslova containerja. Vsak tek za vsakega uporabnika deli ta naslov.

Proračun, namenjen eni osebi, se je tako delil med ves promet celotne storitve. Te storitve so ga skupaj porabile in omejevalnik je naredil, kar je bil nastavljen, da naredi: zavrnil jih je.

Popravek

Naše lastne storitve že dokazujejo, kdo so. Vsak interni klic nosi interni žeton, vsaka pot v internem delu API-ja pa ga preveri, preden kar koli naredi.

Omejevalnik zdaj uporablja isto preverjanje. Zahtevek, katerega žeton se ujema z internim, je na seznamu dovoljenih in se ne šteje v proračun na naslov. Vse drugo se šteje točno kot prej: 300 zahtevkov na minuto na naslov.

Dve podrobnosti sta preprečili, da bi to postalo luknja:

1. Napačen žeton ne dobi prehoda. Seznam dovoljenih se ujema le z resničnim internim žetonom. Zahtevek z izmišljenim žetonom se šteje in omeji kot vsak drug, interne poti pa ga še vedno zavrnejo z 401 Unauthorized.
2. Omejitev sama se ni spremenila. Številke nismo dvignili, da bi naredili prostor. To bi problem skrilo do naslednje rasti prometa in hkrati oslabilo zaščito za primer, zaradi katerega omejitev obstaja.

Nastavitve omejevalnika smo premaknili v eno majhno funkcijo in zanjo napisali teste. Eden pošlje 20 zahtevkov z internim žetonom omejevalniku, nastavljenemu na 5, in pričakuje, da bodo vsi uspeli. Drugi pošlje navadne zahtevke z enega naslova in pričakuje, da prvih pet uspe, ostali pa so zavrnjeni. Tretji pošlje zahtevke s ponarejenim žetonom in pričakuje, da bodo zavrnjeni na enak način.

Kaj smo iz tega izvlekli

• Omejitve nosijo predpostavke. »En naslov, en klicatelj« je vgrajeno v omejitev na naslov. Preneha veljati v trenutku, ko so vaše lastne storitve za skupnimi naslovi, in mnoge so: uravnoteževalniki obremenitve, robna omrežja, containerji, pisarniška omrežja.
• Svoj promet ločite po identiteti, ne po naslovu. Naslovi so način, kako promet prihaja, ne kdo ga je poslal. Imeli smo že poverilnico, ki dokazuje, da je klic naš. Omejevalnik je le ni pogledal.
• Ne popravljajte z dvigovanjem številke. Višja omejitev bi napake 429 za nekaj časa odpravila, zaščitila bi manj in se spet pokvarila pozneje.
• Poglejte, kdo je omejen. 429, ki zadene vašo lastno storitev, je prijava napake o vaših omejitvah, ne znak, da omejevalnik deluje.

Kaj to pomeni, če gradite na platformi Mythex

Na vaši strani ni ničesar za spremeniti. Objavljene aplikacije na domenah po meri, teki agentov in predogledi zdaj ne odvisijo od tega, kako zaposlen je ostali Mythex. Promet vaše aplikacije je stvar vaše aplikacije. Omejitev, opisana tukaj, velja za naš API, ne za aplikacije, ki jih objavite.

Če imate lastno backend storitev, velja enaka past za vsako omejitev hitrosti, ki jo dodate. Naša vodnika kaj je API in kontrolni seznam varnosti za aplikacije, zgrajene z AI sta dobro izhodišče. Za drug primer, ko naša lastna infrastruktura sama sebi stoji na poti, glejte kako smo dosegli nič napak 502 pri deployih.