API užklausų ribojimas: „Token Bucket“ algoritmo diegimas

Šiuolaikiniame tarpusavyje susijusiame pasaulyje API (aplikacijų programavimo sąsajos) yra daugybės programų ir paslaugų pagrindas. Jos leidžia skirtingoms programinės įrangos sistemoms sklandžiai bendrauti ir keistis duomenimis. Tačiau API populiarumas ir prieinamumas taip pat daro jas pažeidžiamas galimam piktnaudžiavimui ir perkrovai. Be tinkamų apsaugos priemonių, API gali tapti pažeidžiamos paslaugų trikdymo (DoS) atakoms, išteklių išeikvojimui ir bendram našumo sumažėjimui. Būtent čia į pagalbą ateina API užklausų ribojimas.

Užklausų ribojimas yra esminė technika, skirta apsaugoti API, kontroliuojant užklausų, kurias klientas gali pateikti per tam tikrą laikotarpį, skaičių. Tai padeda užtikrinti sąžiningą naudojimą, užkirsti kelią piktnaudžiavimui ir išlaikyti API stabilumą bei prieinamumą visiems vartotojams. Egzistuoja įvairūs algoritmai užklausų ribojimui įgyvendinti, o vienas populiariausių ir efektyviausių yra „Token Bucket“ algoritmas.

Kas yra „Token Bucket“ algoritmas?

„Token Bucket“ algoritmas yra konceptualiai paprastas, tačiau galingas algoritmas, skirtas užklausų ribojimui. Įsivaizduokite kibirą, kuriame telpa tam tikras skaičius žetonų. Žetonai į kibirą dedami iš anksto nustatytu greičiu. Kiekviena gaunama API užklausa sunaudoja vieną žetoną iš kibiro. Jei kibire yra pakankamai žetonų, užklausa leidžiama vykdyti. Jei kibiras tuščias (t. y. nėra laisvų žetonų), užklausa atmetama arba statoma į eilę, kol atsiras laisvas žetonas.

Štai pagrindinių komponentų apžvalga:

• Kibiro dydis (talpa): Maksimalus žetonų skaičius, kurį gali talpinti kibiras. Tai atspindi pliūpsnio talpą – galimybę aptarnauti staigų užklausų antplūdį.
• Žetonų papildymo greitis: Greitis, kuriuo žetonai pridedami į kibirą, paprastai matuojamas žetonais per sekundę arba žetonais per minutę. Tai apibrėžia vidutinį užklausų limitą.
• Užklausa: Gaunama API užklausa.

Kaip tai veikia:

1. Kai gaunama užklausa, algoritmas patikrina, ar kibire yra žetonų.
2. Jei kibire yra bent vienas žetonas, algoritmas pašalina žetoną ir leidžia užklausai tęstis.
3. Jei kibiras tuščias, algoritmas atmeta arba įtraukia užklausą į eilę.
4. Žetonai į kibirą dedami iš anksto nustatytu papildymo greičiu, iki maksimalios kibiro talpos.

Kodėl verta rinktis „Token Bucket“ algoritmą?

„Token Bucket“ algoritmas siūlo keletą pranašumų, palyginti su kitomis užklausų ribojimo technikomis, tokiomis kaip fiksuoto lango skaitikliai ar slenkančio lango skaitikliai:

• Pliūpsnio talpa: Jis leidžia užklausų pliūpsnius iki kibiro dydžio, prisitaikydamas prie teisėtų naudojimo modelių, kurie gali apimti retkarčiais pasitaikančius srauto šuolius.
• Sklandus užklausų ribojimas: Papildymo greitis užtikrina, kad vidutinis užklausų skaičius išliktų nustatytose ribose, užkertant kelią ilgalaikei perkrovai.
• Konfigūruojamumas: Kibiro dydį ir papildymo greitį galima lengvai koreguoti, norint tiksliai suderinti užklausų ribojimo elgseną skirtingoms API ar vartotojų pakopoms.
• Paprastumas: Algoritmą gana paprasta suprasti ir įdiegti, todėl jis yra praktiškas pasirinkimas daugeliu atvejų.
• Lankstumas: Jis gali būti pritaikytas įvairiems naudojimo atvejams, įskaitant užklausų ribojimą pagal IP adresą, vartotojo ID, API raktą ar kitus kriterijus.

Diegimo detalės

Diegiant „Token Bucket“ algoritmą, reikia valdyti kibiro būseną (dabartinį žetonų skaičių ir paskutinio atnaujinimo laiko žymą) ir taikyti logiką gaunamoms užklausoms tvarkyti. Štai konceptualus diegimo žingsnių planas:

1. Inicijavimas:
   • Sukurkite duomenų struktūrą, kuri atspindėtų kibirą, paprastai joje yra:
   • `tokens`: Dabartinis žetonų skaičius kibire (inicijuojamas iki kibiro dydžio).
   • `last_refill`: Paskutinio kibiro papildymo laiko žyma.
   • `bucket_size`: Maksimalus žetonų skaičius, kurį kibiras gali talpinti.
   • `refill_rate`: Greitis, kuriuo žetonai pridedami į kibirą (pvz., žetonai per sekundę).
2. Užklausų tvarkymas:
   • Kai gaunama užklausa, gaukite kliento kibirą (pvz., pagal IP adresą arba API raktą). Jei kibiras neegzistuoja, sukurkite naują.
   • Apskaičiuokite, kiek žetonų reikia pridėti į kibirą nuo paskutinio papildymo:
   • `time_elapsed = current_time - last_refill`
   • `tokens_to_add = time_elapsed * refill_rate`
   • Atnaujinkite kibirą:
   • `tokens = min(bucket_size, tokens + tokens_to_add)` (Užtikrinkite, kad žetonų skaičius neviršytų kibiro dydžio)
   • `last_refill = current_time`
   • Patikrinkite, ar kibire yra pakankamai žetonų užklausai aptarnauti:
   • Jei `tokens >= 1`:
     • Sumažinkite žetonų skaičių: `tokens = tokens - 1`
     • Leiskite užklausai tęstis.
   • Kitu atveju (jei `tokens < 1`):
     • Atmeskite arba įtraukite užklausą į eilę.
     • Grąžinkite klaidą dėl viršyto užklausų limito (pvz., HTTP būsenos kodą 429 Too Many Requests).
   • Išsaugokite atnaujintą kibiro būseną (pvz., duomenų bazėje ar talpykloje).

Pavyzdinis diegimas (konceptualus)

Štai supaprastintas, konceptualus pavyzdys (ne konkrečiai kalbai), iliustruojantis pagrindinius žingsnius:

class TokenBucket:
    def __init__(self, bucket_size, refill_rate):
        self.bucket_size = bucket_size
        self.refill_rate = refill_rate  # žetonai per sekundę
        self.tokens = bucket_size
        self.last_refill = time.time()

    def consume(self, tokens_to_consume=1):
        self._refill()
        if self.tokens >= tokens_to_consume:
            self.tokens -= tokens_to_consume
            return True  # Užklausa leidžiama
        else:
            return False # Užklausa atmesta (viršytas užklausų limitas)

    def _refill(self):
        now = time.time()
        time_elapsed = now - self.last_refill
        tokens_to_add = time_elapsed * self.refill_rate
        self.tokens = min(self.bucket_size, self.tokens + tokens_to_add)
        self.last_refill = now

# Naudojimo pavyzdys:
bucket = TokenBucket(bucket_size=10, refill_rate=2)  # 10 žetonų kibiras, papildomas 2 žetonų per sekundę greičiu

if bucket.consume():
    # Apdoroti užklausą
    print("Užklausa leidžiama")
else:
    # Viršytas užklausų limitas
    print("Viršytas užklausų limitas")

Pastaba: Tai yra pagrindinis pavyzdys. Gamybai paruoštas diegimas reikalautų valdyti lygiagretumą, išsaugojimą ir klaidų tvarkymą.

Tinkamų parametrų pasirinkimas: kibiro dydis ir papildymo greitis

Tinkamų verčių parinkimas kibiro dydžiui ir papildymo greičiui yra labai svarbus efektyviam užklausų ribojimui. Optimalios vertės priklauso nuo konkrečios API, jos numatytų naudojimo atvejų ir norimo apsaugos lygio.

• Kibiro dydis: Didesnis kibiro dydis leidžia didesnę pliūpsnio talpą. Tai gali būti naudinga API, kurios patiria retkarčiais pasitaikančius srauto šuolius arba kur vartotojams teisėtai reikia pateikti eilę greitų užklausų. Tačiau labai didelis kibiro dydis gali panaikinti užklausų ribojimo tikslą, leisdamas ilgai trunkančius didelės apimties naudojimo periodus. Nustatydami kibiro dydį, atsižvelkite į tipiškus savo vartotojų pliūpsnio modelius. Pavyzdžiui, nuotraukų redagavimo API gali prireikti didesnio kibiro, kad vartotojai galėtų greitai įkelti vaizdų paketą.
• Papildymo greitis: Papildymo greitis nustato leidžiamą vidutinį užklausų dažnį. Didesnis papildymo greitis leidžia daugiau užklausų per laiko vienetą, o mažesnis yra labiau ribojantis. Papildymo greitis turėtų būti pasirinktas atsižvelgiant į API pajėgumą ir norimą sąžiningumo lygį tarp vartotojų. Jei jūsų API reikalauja daug išteklių, norėsite mažesnio papildymo greičio. Taip pat apsvarstykite skirtingas vartotojų pakopas; aukščiausios klasės vartotojai gali gauti didesnį papildymo greitį nei nemokami vartotojai.

Scenarijų pavyzdžiai:

• Vieša API socialinės medijos platformai: Mažesnis kibiro dydis (pvz., 10-20 užklausų) ir vidutinis papildymo greitis (pvz., 2-5 užklausos per sekundę) gali būti tinkami siekiant išvengti piktnaudžiavimo ir užtikrinti sąžiningą prieigą visiems vartotojams.
• Vidinė API mikropaslaugų komunikacijai: Didesnis kibiro dydis (pvz., 50-100 užklausų) ir didesnis papildymo greitis (pvz., 10-20 užklausų per sekundę) gali būti tinkami, darant prielaidą, kad vidinis tinklas yra gana patikimas, o mikropaslaugos turi pakankamai pajėgumų.
• API mokėjimų šliuzui: Mažesnis kibiro dydis (pvz., 5-10 užklausų) ir mažesnis papildymo greitis (pvz., 1-2 užklausos per sekundę) yra labai svarbūs siekiant apsisaugoti nuo sukčiavimo ir užkirsti kelią neteisėtoms operacijoms.

Iteracinis požiūris: Pradėkite nuo pagrįstų pradinių verčių kibiro dydžiui ir papildymo greičiui, o tada stebėkite API našumą ir naudojimo modelius. Prireikus koreguokite parametrus, remdamiesi realaus pasaulio duomenimis ir atsiliepimais.

Kibiro būsenos saugojimas

„Token Bucket“ algoritmas reikalauja nuolat saugoti kiekvieno kibiro būseną (žetonų skaičių ir paskutinio papildymo laiko žymą). Tinkamo saugojimo mechanizmo pasirinkimas yra labai svarbus našumui ir mastelio keitimui.

Dažniausiai pasitaikančios saugojimo parinktys:

• Atminties talpykla (pvz., Redis, Memcached): Siūlo didžiausią našumą, nes duomenys saugomi atmintyje. Tinka didelio srauto API, kur svarbus mažas delsimas. Tačiau duomenys prarandami, jei talpyklos serveris paleidžiamas iš naujo, todėl apsvarstykite galimybę naudoti replikavimo ar išsaugojimo mechanizmus.
• Reliacinė duomenų bazė (pvz., PostgreSQL, MySQL): Suteikia ilgaamžiškumą ir nuoseklumą. Tinka API, kur duomenų vientisumas yra svarbiausias. Tačiau duomenų bazės operacijos gali būti lėtesnės nei atminties talpyklos operacijos, todėl optimizuokite užklausas ir, kur įmanoma, naudokite talpyklos sluoksnius.
• NoSQL duomenų bazė (pvz., Cassandra, MongoDB): Siūlo mastelio keitimą ir lankstumą. Tinka API su labai dideliais užklausų kiekiais arba kur duomenų schema kinta.

Svarstymai:

• Našumas: Pasirinkite saugojimo mechanizmą, kuris gali apdoroti numatomą skaitymo ir rašymo apkrovą su mažu delsimu.
• Mastelio keitimas: Užtikrinkite, kad saugojimo mechanizmas galėtų keisti mastelį horizontaliai, kad prisitaikytų prie didėjančio srauto.
• Ilgaamžiškumas: Apsvarstykite duomenų praradimo pasekmes, susijusias su skirtingomis saugojimo parinktimis.
• Kaina: Įvertinkite skirtingų saugojimo sprendimų kainą.

Viršyto užklausų limito įvykių tvarkymas

Kai klientas viršija užklausų limitą, svarbu sklandžiai sutvarkyti įvykį ir pateikti informatyvų atsakymą.

Geriausios praktikos:

• HTTP būsenos kodas: Grąžinkite standartinį HTTP būsenos kodą 429 Too Many Requests.
• `Retry-After` antraštė: Įtraukite `Retry-After` antraštę į atsakymą, nurodydami sekundžių skaičių, kurį klientas turėtų palaukti prieš pateikdamas kitą užklausą. Tai padeda klientams išvengti API perkrovimo pasikartojančiomis užklausomis.
• Informatyvus klaidos pranešimas: Pateikite aiškų ir glaustą klaidos pranešimą, paaiškinantį, kad užklausų limitas buvo viršytas, ir siūlantį, kaip išspręsti problemą (pvz., palaukti prieš bandant dar kartą).
• Registravimas ir stebėjimas: Registruokite viršyto užklausų limito įvykius stebėjimui ir analizei. Tai gali padėti nustatyti galimą piktnaudžiavimą ar netinkamai sukonfigūruotus klientus.

Atsakymo pavyzdys:

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 60

{
  "error": "Viršytas užklausų limitas. Prieš bandydami dar kartą, palaukite 60 sekundžių."
}

Išplėstiniai svarstymai

Be pagrindinio diegimo, keletas išplėstinių svarstymų gali dar labiau padidinti API užklausų ribojimo efektyvumą ir lankstumą.

• Pakopinis užklausų ribojimas: Įdiekite skirtingus užklausų limitus skirtingoms vartotojų pakopoms (pvz., nemokama, pagrindinė, aukščiausios klasės). Tai leidžia siūlyti skirtingus paslaugų lygius, atsižvelgiant į prenumeratos planus ar kitus kriterijus. Saugokite vartotojų pakopų informaciją kartu su kibiru, kad būtų taikomi teisingi užklausų limitai.
• Dinaminis užklausų ribojimas: Koreguokite užklausų limitus dinamiškai, atsižvelgiant į realaus laiko sistemos apkrovą ar kitus veiksnius. Pavyzdžiui, piko valandomis galėtumėte sumažinti papildymo greitį, kad išvengtumėte perkrovos. Tam reikia stebėti sistemos našumą ir atitinkamai koreguoti užklausų limitus.
• Paskirstytas užklausų ribojimas: Paskirstytoje aplinkoje su keliais API serveriais įdiekite paskirstytą užklausų ribojimo sprendimą, kad užtikrintumėte nuoseklų užklausų ribojimą visuose serveriuose. Naudokite bendrą saugojimo mechanizmą (pvz., Redis klasterį) ir nuoseklų maišymą (consistent hashing), kad paskirstytumėte kibirus tarp serverių.
• Granuliuotas užklausų ribojimas: Ribokite skirtingus API galinius punktus ar išteklius skirtingai, atsižvelgiant į jų sudėtingumą ir išteklių suvartojimą. Pavyzdžiui, paprastas tik skaitymui skirtas galinis punktas gali turėti didesnį užklausų limitą nei sudėtinga rašymo operacija.
• Užklausų ribojimas pagal IP adresą vs. pagal vartotoją: Apsvarstykite kompromisus tarp užklausų ribojimo pagal IP adresą ir ribojimo pagal vartotojo ID ar API raktą. Ribojimas pagal IP gali būti veiksmingas blokuojant kenkėjišką srautą iš konkrečių šaltinių, tačiau jis taip pat gali paveikti teisėtus vartotojus, kurie dalijasi IP adresu (pvz., vartotojai už NAT šliuzo). Ribojimas pagal vartotoją suteikia tikslesnę individualių vartotojų naudojimo kontrolę. Abiejų metodų derinys gali būti optimalus.
• Integracija su API šliuzu: Pasinaudokite savo API šliuzo (pvz., Kong, Tyk, Apigee) užklausų ribojimo galimybėmis, kad supaprastintumėte diegimą ir valdymą. API šliuzai dažnai teikia integruotas užklausų ribojimo funkcijas ir leidžia konfigūruoti limitus per centralizuotą sąsają.

Globali perspektyva į užklausų ribojimą

Kuriant ir diegiant API užklausų ribojimą pasaulinei auditorijai, atsižvelkite į šiuos dalykus:

• Laiko juostos: Nustatydami papildymo intervalus, atsižvelkite į skirtingas laiko juostas. Apsvarstykite galimybę naudoti UTC laiko žymas nuoseklumui užtikrinti.
• Tinklo delsa: Tinklo delsa gali labai skirtis skirtinguose regionuose. Nustatydami užklausų limitus, atsižvelkite į galimą delsą, kad netyčia nenubaustumėte vartotojų atokiose vietovėse.
• Regioniniai reglamentai: Žinokite apie bet kokius regioninius reglamentus ar atitikties reikalavimus, kurie gali turėti įtakos API naudojimui. Pavyzdžiui, kai kuriuose regionuose gali būti duomenų privatumo įstatymų, ribojančių renkamų ar apdorojamų duomenų kiekį.
• Turinio pristatymo tinklai (CDN): Naudokite CDN, kad paskirstytumėte API turinį ir sumažintumėte delsą vartotojams skirtinguose regionuose.
• Kalba ir lokalizacija: Pateikite klaidų pranešimus ir dokumentaciją keliomis kalbomis, kad prisitaikytumėte prie pasaulinės auditorijos.

Išvada

API užklausų ribojimas yra esminė praktika, skirta apsaugoti API nuo piktnaudžiavimo ir užtikrinti jų stabilumą bei prieinamumą. „Token Bucket“ algoritmas siūlo lankstų ir efektyvų sprendimą užklausų ribojimui įvairiais scenarijais. Atidžiai pasirinkdami kibiro dydį ir papildymo greitį, efektyviai saugodami kibiro būseną ir sklandžiai tvarkydami viršyto užklausų limito įvykius, galite sukurti tvirtą ir keičiamo mastelio užklausų ribojimo sistemą, kuri apsaugo jūsų API ir suteikia teigiamą vartotojo patirtį jūsų pasaulinei auditorijai. Nepamirškite nuolat stebėti savo API naudojimo ir prireikus koreguoti užklausų ribojimo parametrus, kad prisitaikytumėte prie kintančių srauto modelių ir saugumo grėsmių.

Suprasdami „Token Bucket“ algoritmo principus ir diegimo detales, galite efektyviai apsaugoti savo API ir kurti patikimas bei keičiamo mastelio programas, kurios aptarnauja vartotojus visame pasaulyje.