Piirasime ise oma teenuseid

Mythexi API lubab ühest võrguaadressist 300 päringut minutis. See piirang on olemas selleks, et kaitsta meid üksiku inimese või skripti eest, mis API-d üle koormab. Tootmises hakkas see keelama hoopis meie enda teenuseid — osa meie serverist, mis teenindab avaldatud rakendusi, ja teenus, mis käitab tehisintellekti agenti — sest igaüks neist pöördub API poole ainult mõne aadressi kaudu. Päringud, mis kannavad meie sisemist volitust, on nüüd piirangust vabastatud ja kõik teised on piiratud täpselt nagu varem.

Sümptom

API hakkas mõnele meie enda sisemisele kutsele vastama 429 Too Many Requests. Kolme tüüpi kutseid tabas see ja igaüks neist on oluline kellelegi, kes Mythexit kasutab:

Kontroll, milline rakendus asub kohandatud domeenil. Kui külastaja avab avaldatud rakenduse oma domeenil, küsib meie server API-lt, kus see sait asub. 429 seal tähendab külastajat, kes ei pääse saidile.
Töötava agendi pöörde salvestamine. Kui agent töötab, salvestatakse tema edenemine samal ajal, nii et vastus püsib ka värskendamise või katkenud ühenduse korral. 429 seal tähendab edenemist, mida ei salvestatud.
Eelvaate juurdepääsu kontroll. Sinu ehitatava rakenduse eelvaade on piiratud ja piirang küsib API-lt. 429 seal tähendab eelvaadet, mis ei avane.

Neist ükski ei olnud inimene, kes API-d kutsus. Kõik olid meie.

Miks see juhtus

Aadressipõhine päringupiirang teeb ühe eelduse: üks aadress on ligikaudu üks kutsuja. Inimeste puhul on see piisavalt lähedane. Meie enda infrastruktuuri jaoks on see väga vale.

Avaldatud rakendusi ja eelvaateid teenindav serveriteenus pöördub API poole mõne jagatud väljuva aadressi kaudu. Iga külastaja igale avaldatud rakendusele ja iga eelvaate kontroll tuleb nendest mõnest, nagu oleks need ühest aadressist.
Orkestraator, teenus, mis käitab agendi pöördeid, pöördub API poole ühe konteineri aadressi kaudu. Iga töötav pööre, iga kasutaja jaoks, jagab seda.

Seega jagati ühe inimese jaoks mõeldud eelarvet kogu ühe teenuse liikluse vahel. Need teenused kulutasid selle omavahel ära ja piirang tegi seda, mida talle käsket anti: keeldus neist.

Parandus

Meie enda teenused tõendavad juba, kes nad on. Iga sisemine kutse kannab sisemist tokenit ja iga marsruut API sisemises jaotises kontrollib seda tokenit enne, kui midagi teeb.

Päringupiirang kasutab nüüd sama kontrolli. Päring, mille token vastab sisemisele, on lubatud nimekirjas ja seda ei loeta aadressipõhisesse eelarvesse. Kõik muu loetakse täpselt nagu varem: 300 päringut minutis aadressi kohta.

Kaks detaili hoidsid selle ära muutumast auguks:

Vale token ei saa läbipääsu. Lubatud nimekiri vastab ainult tegelikule sisemisele tokenile. Päring väljamõeldud tokeniga loetakse ja piiratakse nagu iga teine, ja sisemised marsruudid lükkavad selle ikka tagasi koodiga 401 Unauthorized.
Piirang ise ei muutunud. Me ei tõstnud numbrit, et ruumi teha. Numbri tõstmine oleks probleemi peitnud, kuni liiklus jälle kasvab, ja nõrgendanud kaitset juhul, mille jaoks piirang on.

Tõstsime piirangu seaded ühte väikesesse funktsiooni ja kirjutasime nende vastu testid. Üks saadab 20 päringut sisemise tokeniga piirangule, mis lubab 5, ja eeldab, et kõik 20 õnnestuvad. Teine saadab tavalisi päringuid ühest aadressist ja eeldab, et esimesed viis õnnestuvad ja neile järgnevad keeldutakse. Kolmas saadab päringuid võltsitud tokeniga ja eeldab, et need keeldutakse samamoodi.

Mida sellest õppisime

Piirangutel on eeldused. „Üks aadress, üks kutsuja“ on aadressipõhises piirangus sisse ehitatud. See lakkab kehtimast, kui sinu enda teenused asuvad jagatud aadresside taga — ja paljud asuvad: koormusjaotajad, servõrgud, konteinerid, kontorivõrgud.
Eristage oma liiklust identiteedi, mitte aadressi järgi. Aadressid on see, kuidas liiklus saabub, mitte see, kes selle saatis. Meil oli juba volitus, mis tõestab, et kutse on meie oma; piirang lihtsalt ei vaadanud seda.
Ära paranda seda numbri tõstmisega. Suurem piirang oleks 429-d mõneks ajaks kaotanud, kaitsnud vähem ja ebaõnnestunud hiljem uuesti.
Vaata, keda piiratakse. 429, mis tabab sinu enda teenust, on veateade sinu piirangute kohta, mitte märk, et piirang töötab.

Mida see tähendab, kui ehitad Mythexil

Sinu poolelt ei pea midagi muutma. Avaldatud rakendused kohandatud domeenidel, agendi pöörded ja eelvaated ei sõltu enam sellest, kui hõivatud on ülejäänud Mythex. Sinu rakenduse enda liiklus on sinu asi: siin kirjeldatud piirang kehtib meie API kohta, mitte sinu avaldatud rakenduste kohta.

Kui käitad oma taustateenust, kehtib sama lõks iga päringupiirangu kohta, mille lisad. Head kohad alustamiseks on juhendid mis on API ja tehisintellektiga ehitatud rakenduste turvakontrollnimekiri. Teise näite selle kohta, kuidas meie enda infrastruktuur ise endale teel on, leiad lehelt kuidas saime deploy-d nullini 502-vigadeni.