Mikä on rate limiting? Selkeä opas sovellusrakentajille

Rate limiting on sääntö, joka rajoittaa, kuinka monta pyyntöä joku voi tehdä järjestelmään tietyssä ajassa, esimerkiksi 5 kirjautumisyritystä minuutissa tai 100 API-kutsua tunnissa. Kun raja on täynnä, lisäpyynnöt hylätään yleensä virheellä 429 Too Many Requests, kunnes aikaikkuna nollautuu. Se suojaa sovelluksia väärinkäytöltä, estää yksittäistä raskasta käyttäjää hidastamasta kaikkia ja pysäyttää hallitsemattomat kustannukset.

Kohtaat rate limitingin kahdelta suunnalta: palvelut, joita kutsut, rajoittavat sinua, ja oman sovelluksesi pitäisi rajoittaa käyttäjiään.

Miksi rate limiting on tärkeä, kun rakennat tekoälyllä

Tekoälyllä rakennetut sovellukset yhdistyvät usein maksullisiin palveluihin, kuten tekoälymalleihin, sähköpostiin, tekstiviesteihin ja karttoihin, ja jokainen kutsu maksaa. Siksi rate limiting on sekä tietoturvaominaisuus että budjettiominaisuus.

• Kustannusten hallinta. Jos sovelluksessasi on ”kysy tekoälyltä” -laatikko eikä rajaa ole, botti voi lähettää siihen tuhansia pyyntöjä yön aikana. Maksat jokaisesta.
• Tietoturva. Ilman rajaa kirjautumislomakkeella hyökkääjä voi kokeilla tuhansia salasanoja tiliin. Muutaman yrityksen raja minuutissa tekee siitä epäkäytännöllistä.
• Pysyminen pystyssä. Yksi toimimaton skripti, joskus oma koodisi jumissa silmukassa, voi kuormittaa tietokannan ja kaataa sovelluksen.
• Muiden palvelujen rajojen kunnioittaminen. Kun sovelluksesi kutsuu ulkopuolista rajapintaa liian usein, sinä saat 429-virheitä ja ominaisuudet hajoavat käyttäjiltäsi.

Tekoälyrakentajat rakentavat sen, mitä pyydät. Jos et mainitse rajoja, ne jäävät usein pois.

Arkinen vertaus

Ajattele kahvilan ilmaista täydennystä: ”Yksi ilmainen täydennys asiakasta kohden per käynti.”

• Se ei estä ketään nauttimasta kahvista.
• Se estää yhtä ihmistä seisomasta tiskillä koko päivän ja täyttämästä termosta koko toimistolle.
• Kun joku pyytää neljättä täydennystä, baristasi sanoo kohteliaasti ”ei nyt”. Se on 429.

Hyvä rajoitus on näkymätön tavallisille asiakkaille ja huomataan vain, jos joku tekee jotain epätavallista.

Miten rate limiting toimii

Rate limiter tarvitsee kolme asiaa:

Kun pyyntö saapuu, sovellus tarkistaa laskurin sille ”kuka”-osapuolelle. Rajan alla pyyntö menee läpi ja laskuri kasvaa. Rajan yli pyyntö hylätään.

Laskemiseen on muutama yleinen tapa:

Laskurit täytyy tallentaa johonkin nopeaan ja jaettuun paikkaan. Yhdellä pienellä palvelimella muisti riittää. Kun sovellus toimii useilla koneilla, laskuri on yleensä jaetussa tallennuksessa, kuten Redisissä tai tietokannassa. Muuten jokainen kone laskee erikseen ja todellinen raja on moninkertainen.

Miltä rajoitetun pyynnön vastaus näyttää

Kun pyyntö ylittää rajan, hyvin toimiva rajapinta vastaa:

• Tilakoodi 429 Too Many Requests.
• Usein Retry-After-otsake, joka kertoo, kuinka monta sekuntia odottaa.
• Joskus otsakkeita, jotka kertovat rajasi ja kuinka monta pyyntöä sinulla on jäljellä tässä ikkunassa. Nimet vaihtelevat palveluntarjoajittain.

Sovelluksesi pitäisi vastata 429-virheeseen odottamalla ja yrittämällä myöhemmin, mieluiten eksponentiaalisella viiveellä (exponential backoff). Se tarkoittaa, että odotat hieman pidempään jokaisen epäonnistuneen yrityksen jälkeen (1 sekunti, sitten 2, sitten 4), sen sijaan että hakkaisit palvelua.

Työstetty esimerkki: tekoälykirjoitusavustaja

Oletetaan, että olet rakentanut sovelluksen, johon käyttäjät liittävät tekstiä ja saavat tekoälyltä uudelleenkirjoituksen.

Ilman rajoja: joku kirjoittaa skriptin, joka lähettää 20 000 pyyntöä yön aikana. Tekoälyntarjoajasi lasku nousee, ja tili osuu palveluntarjoajan omaan rajaan, joten oikeat käyttäjät näkevät virheitä koko aamun.

Järkevillä rajoilla:

1. Kirjautunutta käyttäjää kohden: 30 uudelleenkirjoitusta tunnissa ilmaisella tasolla, 300 maksullisella. Rajan ylittyessä käyttäjä näkee: ”Olet saavuttanut tämän tunnin rajan. Yritä uudelleen 12 minuutin kuluttua tai päivitä.”
2. IP-osoitetta kohden rekisteröitymislomakkeella: 5 rekisteröitymistä tunnissa, jotta botit eivät luo tuhansia ilmaistilejä kiertääkseen käyttäjäkohtaista rajaa.
3. Kulutusraja tekoälyntarjoajasi hallintapaneelissa viimeisenä puolustuslinjana, jos kaikki muu pettää.
4. Palveluntarjoajan rajojen käsittely: jos tekoälyntarjoaja palauttaa 429:n, palvelimesi odottaa ja yrittää uudelleen kerran tai kahdesti, minkä jälkeen näkyy ystävällinen viesti ”palvelu on kiireinen, yritä uudelleen”.

Rajat tarkistetaan palvelimella. Pelkästään selaimessa oleva raja, esimerkiksi painikkeen poistaminen käytöstä 30 napsautuksen jälkeen, voidaan ohittaa kuka tahansa, joka kutsuu rajapintaasi suoraan.

Keskeiset termit

Yleiset väärinkäsitykset

• ”Rate limiting on vain isoille sovelluksille.” Pienetkin sovellukset ovat kohteita, koska botit skannaavat koko internetin avoimia lomakkeita ja tekoälyrajapintoja. Väärinkäytön kustannus ei riipu koosta.
• ”Piilottaa napin riittää.” Selainpuolen rajat ovat kohteliaisuus, eivät suojaus. Oikeat rajat on pakotettava palvelimella.
• ”Käyttäjäkohtaiset IP-rajat ovat aina reiluja.” Monet ihmiset voivat jakaa yhden IP-osoitteen, kuten toimisto, koulu tai mobiiliverkko. Kun ihmiset ovat kirjautuneita, käyttäjäkohtaiset rajat ovat reilumpia.
• ”429 tarkoittaa, että palvelu on rikki.” Se tarkoittaa, että kutsut sitä liian usein. Tarkista koodistasi silmukat ja tallenna tulokset välimuistiin, jos ne eivät muutu usein. Katso mitä välimuisti on.
• ”Rate limiting korvaa kulutusrajan.” Käytä molempia. Sovelluksesi rajoissa voi olla bugeja, ja palveluntarjoajan kulutusraja on varasuunnitelmasi.

Mitä kysyä tekoälyrakentajalta

• ”Lisää palvelinpuolen rate limiting kirjautumiseen, rekisteröitymiseen, salasanan palautukseen ja tekoälyrajapintaan. Ehdota järkeviä rajoja.”
• ”Rajoita jokainen kirjautunut käyttäjä [N] tekoälypyyntöön tunnissa ja näytä selkeä viesti odotusajasta, kun raja täyttyy.”
• ”Kun ulkopuolinen rajapinta palauttaa 429:n, yritä uudelleen eksponentiaalisella viiveellä enintään 3 kertaa ja näytä sitten ystävällinen virhe.”
• ”Mihin rajalaskurit on tallennettu? Toimivatko ne edelleen, jos sovellus toimii useammalla koneella?”
• ”Kirjaa jokainen kerta, kun käyttäjä tai IP-osoite osuu rajaan, jotta voin havaita väärinkäytöksen.”
• ”Mitä ulkopuolisia palveluja tämä sovellus kutsuu ja mitkä ovat niiden rajat?”

Rate limiting Mythexissä

Mythexin dokumentaatio on tästä suora tekoälyominaisuuksien kohdalla: rajat, turvallisuus ja kustannusten hallinta rakentamissasi sovelluksissa ovat sinun suunniteltavissasi. Katso Rakenna tekoälysovellus. Pyydä agenttia lisäämään rajat samassa viestissä, jossa pyydät ominaisuutta. Pro-tasolla julkaistu palvelu voi toimia enintään kolmella koneella, kun liikenne on suurta (katso isännöinnin rajat), joten pyydä laskureita, jotka asuvat tietokannassa eivätkä yhden palvelimen muistissa.

Aiheeseen liittyvää: mikä API on, miten LLM-rajapintoja käytetään ja tietoturvatarkistuslista tekoälyllä rakennetuille sovelluksille.

Kysymykset