Rajoitimme omia palveluitamme

Mythexin API sallii 300 pyyntöä minuutissa yhdestä verkko-osoitteesta. Raja on olemassa suojaamaan meitä siltä, että yksi ihminen tai skripti kuormittaa API:a. Tuotannossa se alkoi kuitenkin kieltäytyä omista palveluistamme: osasta reunaverkkoamme, joka palvelee julkaistuja sovelluksia, ja palvelusta, joka ajaa tekoälyagenttia. Syy oli, että kumpikin ottaa yhteyttä API:in vain muutamasta osoitteesta. Sisäisen tunnuksemme kantavat pyynnöt on nyt vapautettu rajasta, ja kaikki muut rajoitetaan täsmälleen kuten ennenkin.

Oire

API alkoi vastata joihinkin sisäisiin kutsuihimme virheellä 429 Too Many Requests. Kolme kutsutyyppiä osui, ja jokainen niistä on tärkeä jollekulle, joka käyttää Mythexiä:

Mukautetun domainin sovelluksen selvittäminen. Kun kävijä avaa julkaistun sovelluksen omalla domainillaan, reunapalvelimemme kysyy API:lta, missä sivusto on. 429 siinä kohdassa tarkoittaa kävijää, joka ei saa sivustoa auki.
Käynnissä olevan agenttivuoron tallentaminen. Kun agentti työskentelee, sen edistyminen tallennetaan samalla, jotta vastaus säilyy päivityksen tai katkenneen yhteyden yli. 429 siinä kohdassa tarkoittaa edistystä, jota ei tallennettu.
Esikatselun käytön tarkistaminen. Rakentamasi sovelluksen esikatselu on suojattu, ja suojaus kysyy API:lta. 429 siinä kohdassa tarkoittaa esikatselua, joka ei aukea.

Mikään näistä ei ollut ihmisten kutsuja API:in. Kaikki olimme me.

Miksi näin tapahtui

Osoitekohtainen nopeusraja tekee yhden oletuksen: yksi osoite on suunnilleen yksi kutsuja. Ihmisille se on riittävän lähellä. Omalle infrastruktuurillemme se on pahasti väärin.

Reunapalvelu, joka palvelee julkaistuja sovelluksia ja esikatseluja, ottaa yhteyden API:in muutamasta jaetusta lähtevästä osoitteesta. Jokainen julkaistun sovelluksen kävijä ja jokainen esikatselun tarkistus näyttää tulevan jostain näistä muutamasta.
Orkestroija, eli palvelu, joka ajaa agenttivuoroja, ottaa yhteyden API:in yhdestä konttiosoitteesta. Jokainen käynnissä oleva vuoro jokaiselta käyttäjältä jakaa sen.

Yhden ihmisen budjetti jaettiin siis koko palvelun koko liikenteen kesken. Nuo palvelut käyttivät sen loppuun yhdessä, ja rajoitin teki sen, mihin se oli määritetty: kieltäytyi niiltä.

Korjaus

Omat palvelumme todistavat jo, kuka ne ovat. Jokainen sisäinen kutsu kantaa sisäistä tunnusta, ja jokainen API:n sisäisen osan reitti tarkistaa sen ennen kuin tekee mitään.

Nopeusrajoitin käyttää nyt samaa tarkistusta. Pyyntö, jonka tunnus vastaa sisäistä, on sallittujen listalla eikä lasketa osoitekohtaiseen budjettiin. Kaikki muu lasketaan täsmälleen kuten ennen: 300 pyyntöä minuutissa osoitetta kohden.

Kaksi yksityiskohtaa esti tästä tulemasta aukkoa:

Väärä tunnus ei saa läpipääsyä. Sallittujen lista täsmää vain oikeaan sisäiseen tunnukseen. Pyyntö, jolla on keksitty tunnus, lasketaan ja rajoitetaan kuten mikä tahansa muu, ja sisäiset reitit hylkäävät sen edelleen virheellä 401 Unauthorized.
Itse raja ei muuttunut. Emme nostaneet lukua tilan tekemiseksi. Sen nostaminen olisi piilottanut ongelman, kunnes liikenne kasvaa taas, ja se olisi heikentänyt suojaa siltä tapaukselta, jota varten raja on olemassa.

Siirsimme rajoittimen asetukset yhteen pieneen funktioon ja kirjoitimme niille testit. Yksi lähettää 20 pyyntöä sisäisellä tunnuksella rajoittimelle, joka sallii 5, ja odottaa, että kaikki 20 onnistuvat. Toinen lähettää tavallisia pyyntöjä yhdestä osoitteesta ja odottaa, että ensimmäiset viisi onnistuvat ja sen jälkeiset hylätään. Kolmas lähettää pyyntöjä väärennetyllä tunnuksella ja odottaa, että ne hylätään samalla tavalla.

Mitä tästä opimme

Rajoilla on oletuksia. "Yksi osoite, yksi kutsuja" on rakennettu osoitekohtaiseen rajaan. Se lakkaa pitämästä paikkaansa heti, kun omat palvelut ovat jaettujen osoitteiden takana, ja monet ovat: tasapainottajat, reunaverkot, kontit ja toimistoverkot.
Erota oma liikenteesi tunnisteella, älä osoitteella. Osoitteet kertovat, miten liikenne saapuu, eivät kuka sen lähetti. Meillä oli jo tunnus, joka todistaa kutsun olevan meidän, rajoitin vain ei katsonut sitä.
Älä korjaa nostamalla lukua. Suurempi raja olisi poistanut 429-virheet hetkeksi, suojannut vähemmän ja epäonnistunut myöhemmin uudelleen.
Katso, ketä rajoitetaan. 429, joka osuu omaan palveluusi, on virheraportti rajoistasi, ei merkki siitä, että rajoitin toimii.

Mitä tämä tarkoittaa, jos rakennat Mythexillä

Sinun ei tarvitse muuttaa mitään. Julkaistut sovellukset mukautetuilla domaineilla, agenttivuorot ja esikatselut eivät enää riipu siitä, kuinka kiireistä muu Mythex on. Oma sovelluksesi liikenne on sovelluksesi asia: täällä kuvattu raja koskee API:amme, ei julkaisemiasi sovelluksia.

Jos ylläpidät omaa taustapalvelua, sama ansa koskee mitä tahansa nopeusrajaa, jonka lisäät. Hyvä lähtökohta ovat oppaamme mikä API on ja tekoälyllä rakennettujen sovellusten turvallisuuslista. Toisesta esimerkistä, jossa oma infrastruktuurimme esti itseään, katso miten saimme käyttöönotot nollaan 502-virheeseen.