API pieprasījumu ierobežošana: marķieru kausa algoritma ieviešana

Mūsdienu savstarpēji saistītajā pasaulē API (lietojumprogrammu saskarnes) ir neskaitāmu lietotņu un pakalpojumu pamatā. Tās ļauj dažādām programmatūras sistēmām nemanāmi sazināties un apmainīties ar datiem. Tomēr API popularitāte un pieejamība tās pakļauj arī iespējamai ļaunprātīgai izmantošanai un pārslodzei. Bez atbilstošiem aizsardzības pasākumiem API var kļūt neaizsargātas pret pakalpojumatteices (DoS) uzbrukumiem, resursu izsmelšanu un vispārēju veiktspējas pasliktināšanos. Tieši šeit savu lomu spēlē API pieprasījumu ierobežošana.

Pieprasījumu ierobežošana (rate limiting) ir būtiska metode API aizsardzībai, kontrolējot pieprasījumu skaitu, ko klients var veikt noteiktā laika periodā. Tā palīdz nodrošināt godīgu lietošanu, novērst ļaunprātīgu izmantošanu un uzturēt API stabilitāti un pieejamību visiem lietotājiem. Pieprasījumu ierobežošanas ieviešanai pastāv dažādi algoritmi, un viens no populārākajiem un efektīvākajiem ir marķieru kausa (Token Bucket) algoritms.

Kas ir marķieru kausa algoritms?

Marķieru kausa algoritms ir konceptuāli vienkāršs, bet jaudīgs pieprasījumu ierobežošanas algoritms. Iedomājieties kausu, kurā var ietilpt noteikts skaits marķieru (tokens). Marķieri tiek pievienoti kausam ar iepriekš noteiktu ātrumu. Katrs ienākošais API pieprasījums patērē vienu marķieri no kausa. Ja kausā ir pietiekami daudz marķieru, pieprasījumam tiek ļauts turpināties. Ja kauss ir tukšs (t.i., nav pieejamu marķieru), pieprasījums tiek noraidīts vai ievietots rindā, līdz kļūst pieejams jauns marķieris.

Šeit ir galveno komponentu sadalījums:

• Kausa izmērs (ietilpība): Maksimālais marķieru skaits, ko kauss var saturēt. Tas atspoguļo pēkšņas slodzes kapacitāti – spēju apstrādāt pēkšņu pieprasījumu pieaugumu.
• Marķieru papildināšanas ātrums: Ātrums, ar kādu marķieri tiek pievienoti kausam, parasti mērīts marķieros sekundē vai marķieros minūtē. Tas nosaka vidējo pieprasījumu ierobežojumu.
• Pieprasījums: Ienākošs API pieprasījums.

Kā tas darbojas:

1. Kad pienāk pieprasījums, algoritms pārbauda, vai kausā ir kādi marķieri.
2. Ja kausā ir vismaz viens marķieris, algoritms noņem vienu marķieri un ļauj pieprasījumam turpināties.
3. Ja kauss ir tukšs, algoritms noraida pieprasījumu vai ievieto to rindā.
4. Marķieri tiek pievienoti kausam ar iepriekš noteiktu papildināšanas ātrumu, līdz tiek sasniegta kausa maksimālā ietilpība.

Kāpēc izvēlēties marķieru kausa algoritmu?

Marķieru kausa algoritms piedāvā vairākas priekšrocības salīdzinājumā ar citām pieprasījumu ierobežošanas metodēm, piemēram, fiksēta loga skaitītājiem vai slīdošā loga skaitītājiem:

• Pēkšņas slodzes kapacitāte: Tas ļauj apstrādāt pieprasījumu uzliesmojumus līdz pat kausa izmēram, pielāgojoties likumīgiem lietošanas modeļiem, kas var ietvert neregulārus datplūsmas pieaugumus.
• Vienmērīga pieprasījumu ierobežošana: Papildināšanas ātrums nodrošina, ka vidējais pieprasījumu ātrums paliek noteiktajās robežās, novēršot ilgstošu pārslodzi.
• Konfigurējamība: Kausa izmēru un papildināšanas ātrumu var viegli pielāgot, lai precīzi noregulētu pieprasījumu ierobežošanas uzvedību dažādām API vai lietotāju līmeņiem.
• Vienkāršība: Algoritms ir salīdzinoši vienkārši saprotams un ieviešams, padarot to par praktisku izvēli daudzos scenārijos.
• Elastīgums: To var pielāgot dažādiem lietošanas gadījumiem, tostarp pieprasījumu ierobežošanai, pamatojoties uz IP adresi, lietotāja ID, API atslēgu vai citiem kritērijiem.

Ieviešanas detaļas

Marķieru kausa algoritma ieviešana ietver kausa stāvokļa (pašreizējais marķieru skaits un pēdējās atjaunināšanas laikspiedols) pārvaldību un loģikas piemērošanu ienākošo pieprasījumu apstrādei. Šeit ir konceptuāls ieviešanas soļu izklāsts:

1. Inicializācija:
   • Izveidojiet datu struktūru, kas attēlo kausu un parasti satur:
   • `tokens`: Pašreizējais marķieru skaits kausā (sākotnēji iestatīts uz kausa izmēru).
   • `last_refill`: Pēdējās kausa papildināšanas reizes laikspiedols.
   • `bucket_size`: Maksimālais marķieru skaits, ko kauss var saturēt.
   • `refill_rate`: Ātrums, ar kādu marķieri tiek pievienoti kausam (piemēram, marķieri sekundē).
2. Pieprasījumu apstrāde:
   • Kad pienāk pieprasījums, izgūstiet klienta kausu (piemēram, pamatojoties uz IP adresi vai API atslēgu). Ja kauss neeksistē, izveidojiet jaunu.
   • Aprēķiniet marķieru skaitu, kas jāpievieno kausam kopš pēdējās papildināšanas:
   • `time_elapsed = current_time - last_refill`
   • `tokens_to_add = time_elapsed * refill_rate`
   • Atjauniniet kausu:
   • `tokens = min(bucket_size, tokens + tokens_to_add)` (Nodrošiniet, lai marķieru skaits nepārsniegtu kausa izmēru)
   • `last_refill = current_time`
   • Pārbaudiet, vai kausā ir pietiekami daudz marķieru, lai apkalpotu pieprasījumu:
   • Ja `tokens >= 1`:
     • Samaziniet marķieru skaitu: `tokens = tokens - 1`
     • Atļaujiet pieprasījumam turpināties.
   • Cits (ja `tokens < 1`):
     • Noraidiet vai ievietojiet rindā pieprasījumu.
     • Atgrieziet pieprasījumu ierobežojuma pārsniegšanas kļūdu (piemēram, HTTP statusa kodu 429 Too Many Requests).
   • Saglabājiet atjaunināto kausa stāvokli (piemēram, datubāzē vai kešatmiņā).

Ieviešanas piemērs (konceptuāls)

Šeit ir vienkāršots, konceptuāls piemērs (ne specifiskā valodā), lai ilustrētu galvenos soļus:

class TokenBucket:
    def __init__(self, bucket_size, refill_rate):
        self.bucket_size = bucket_size
        self.refill_rate = refill_rate  # marķieri 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  # Pieprasījums atļauts
        else:
            return False # Pieprasījums noraidīts (pārsniegts pieprasījumu ierobežojums)

    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

# Lietošanas piemērs:
bucket = TokenBucket(bucket_size=10, refill_rate=2)  # Kauss ar 10 marķieriem, papildinās ar 2 marķieriem sekundē

if bucket.consume():
    # Apstrādāt pieprasījumu
    print("Request allowed")
else:
    # Pārsniegts pieprasījumu ierobežojums
    print("Rate limit exceeded")

Piezīme: Šis ir pamata piemērs. Ražošanai gatavai ieviešanai būtu nepieciešams apstrādāt vienlaicīgumu, noturību un kļūdu apstrādi.

Pareizo parametru izvēle: kausa izmērs un papildināšanas ātrums

Atbilstošu vērtību izvēle kausa izmēram un papildināšanas ātrumam ir izšķiroša efektīvai pieprasījumu ierobežošanai. Optimālās vērtības ir atkarīgas no konkrētās API, tās paredzētajiem lietošanas gadījumiem un vēlamā aizsardzības līmeņa.

• Kausa izmērs: Lielāks kausa izmērs nodrošina lielāku pēkšņas slodzes kapacitāti. Tas var būt noderīgi API, kas saskaras ar neregulāriem datplūsmas pieaugumiem vai kur lietotājiem likumīgi nepieciešams veikt vairākus ātrus pieprasījumus pēc kārtas. Tomēr ļoti liels kausa izmērs varētu mazināt pieprasījumu ierobežošanas mērķi, ļaujot ilgstoši izmantot lielu apjomu. Nosakot kausa izmēru, apsveriet savu lietotāju tipiskos pēkšņās slodzes modeļus. Piemēram, fotoattēlu rediģēšanas API varētu būt nepieciešams lielāks kauss, lai lietotāji varētu ātri augšupielādēt attēlu partiju.
• Papildināšanas ātrums: Papildināšanas ātrums nosaka atļauto vidējo pieprasījumu ātrumu. Augstāks papildināšanas ātrums ļauj veikt vairāk pieprasījumu laika vienībā, savukārt zemāks papildināšanas ātrums ir ierobežojošāks. Papildināšanas ātrums jāizvēlas, pamatojoties uz API kapacitāti un vēlamo godīguma līmeni starp lietotājiem. Ja jūsu API ir resursietilpīga, jūs vēlēsities zemāku papildināšanas ātrumu. Apsveriet arī dažādus lietotāju līmeņus; premium lietotāji varētu saņemt augstāku papildināšanas ātrumu nekā bezmaksas lietotāji.

Piemēru scenāriji:

• Publiskā API sociālo mediju platformai: Mazāks kausa izmērs (piemēram, 10-20 pieprasījumi) un mērens papildināšanas ātrums (piemēram, 2-5 pieprasījumi sekundē) varētu būt piemērots, lai novērstu ļaunprātīgu izmantošanu un nodrošinātu godīgu piekļuvi visiem lietotājiem.
• Iekšējā API mikropakalpojumu saziņai: Lielāks kausa izmērs (piemēram, 50-100 pieprasījumi) un augstāks papildināšanas ātrums (piemēram, 10-20 pieprasījumi sekundē) varētu būt piemērots, pieņemot, ka iekšējais tīkls ir salīdzinoši uzticams un mikropakalpojumiem ir pietiekama kapacitāte.
• API maksājumu vārtejai: Mazāks kausa izmērs (piemēram, 5-10 pieprasījumi) un zemāks papildināšanas ātrums (piemēram, 1-2 pieprasījumi sekundē) ir būtiski, lai aizsargātu pret krāpšanu un novērstu neatļautus darījumus.

Iteratīva pieeja: Sāciet ar saprātīgām sākotnējām vērtībām kausa izmēram un papildināšanas ātrumam, un pēc tam uzraugiet API veiktspēju un lietošanas modeļus. Pielāgojiet parametrus pēc nepieciešamības, pamatojoties uz reālās pasaules datiem un atsauksmēm.

Kausa stāvokļa glabāšana

Marķieru kausa algoritms prasa katra kausa stāvokļa (marķieru skaita un pēdējā papildināšanas laikspiedola) noturīgu glabāšanu. Pareiza glabāšanas mehānisma izvēle ir izšķiroša veiktspējai un mērogojamībai.

Biežākās glabāšanas iespējas:

• Operatīvās atmiņas kešatmiņa (piemēram, Redis, Memcached): Piedāvā visātrāko veiktspēju, jo dati tiek glabāti atmiņā. Piemērota augstas noslodzes API, kur zema latentitāte ir kritiska. Tomēr dati tiek zaudēti, ja kešatmiņas serveris tiek restartēts, tāpēc apsveriet replikācijas vai noturības mehānismu izmantošanu.
• Relāciju datubāze (piemēram, PostgreSQL, MySQL): Nodrošina datu noturību un konsekvenci. Piemērota API, kur datu integritāte ir vissvarīgākā. Tomēr datubāzes operācijas var būt lēnākas nekā operatīvās atmiņas kešatmiņas operācijas, tāpēc optimizējiet vaicājumus un izmantojiet kešatmiņas slāņus, kur iespējams.
• NoSQL datubāze (piemēram, Cassandra, MongoDB): Piedāvā mērogojamību un elastīgumu. Piemērota API ar ļoti lielu pieprasījumu apjomu vai kur datu shēma attīstās.

Apsvērumi:

• Veiktspēja: Izvēlieties glabāšanas mehānismu, kas spēj apstrādāt paredzamo lasīšanas un rakstīšanas slodzi ar zemu latentitāti.
• Mērogojamība: Nodrošiniet, ka glabāšanas mehānismu var horizontāli mērogot, lai pielāgotos pieaugošajai datplūsmai.
• Noturība: Apsveriet datu zuduma sekas, ko rada dažādas glabāšanas iespējas.
• Izmaksas: Novērtējiet dažādu glabāšanas risinājumu izmaksas.

Rīcība, pārsniedzot pieprasījumu ierobežojumu

Kad klients pārsniedz pieprasījumu ierobežojumu, ir svarīgi apstrādāt šo notikumu korekti un sniegt informatīvu atgriezenisko saiti.

Labākās prakses:

• HTTP statusa kods: Atgrieziet standarta HTTP statusa kodu 429 Too Many Requests.
• Retry-After galvene: Atbildē iekļaujiet `Retry-After` galveni, norādot sekunžu skaitu, cik klientam jāgaida pirms nākamā pieprasījuma veikšanas. Tas palīdz klientiem izvairīties no API pārslogošanas ar atkārtotiem pieprasījumiem.
• Informatīvs kļūdas paziņojums: Sniedziet skaidru un kodolīgu kļūdas paziņojumu, paskaidrojot, ka pieprasījumu ierobežojums ir pārsniegts, un iesakot, kā atrisināt problēmu (piemēram, pagaidīt pirms atkārtota mēģinājuma).
• Žurnālēšana un monitorings: Reģistrējiet pieprasījumu ierobežojuma pārsniegšanas notikumus monitoringam un analīzei. Tas var palīdzēt identificēt potenciālu ļaunprātīgu izmantošanu vai nepareizi konfigurētus klientus.

Atbildes piemērs:

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

{
  "error": "Rate limit exceeded. Please wait 60 seconds before retrying."
}

Papildu apsvērumi

Papildus pamata ieviešanai, vairāki papildu apsvērumi var vēl vairāk uzlabot API pieprasījumu ierobežošanas efektivitāti un elastīgumu.

• Līmeņota pieprasījumu ierobežošana: Ieviesiet dažādus pieprasījumu ierobežojumus dažādiem lietotāju līmeņiem (piemēram, bezmaksas, pamata, premium). Tas ļauj piedāvāt dažādus pakalpojumu līmeņus, pamatojoties uz abonēšanas plāniem vai citiem kritērijiem. Glabājiet lietotāja līmeņa informāciju kopā ar kausu, lai piemērotu pareizos pieprasījumu ierobežojumus.
• Dinamiska pieprasījumu ierobežošana: Pielāgojiet pieprasījumu ierobežojumus dinamiski, pamatojoties uz reāllaika sistēmas slodzi vai citiem faktoriem. Piemēram, jūs varētu samazināt papildināšanas ātrumu noslogotākajās stundās, lai novērstu pārslodzi. Tas prasa sistēmas veiktspējas monitoringu un attiecīgu pieprasījumu ierobežojumu pielāgošanu.
• Izkliedēta pieprasījumu ierobežošana: Izkliedētā vidē ar vairākiem API serveriem ieviesiet izkliedētu pieprasījumu ierobežošanas risinājumu, lai nodrošinātu konsekventu pieprasījumu ierobežošanu visos serveros. Izmantojiet kopīgu glabāšanas mehānismu (piemēram, Redis klasteri) un konsekventu jaukšanu (consistent hashing), lai sadalītu kausus starp serveriem.
• Granulāra pieprasījumu ierobežošana: Ierobežojiet pieprasījumus dažādiem API galapunktiem vai resursiem atšķirīgi, pamatojoties uz to sarežģītību un resursu patēriņu. Piemēram, vienkāršam tikai lasīšanas galapunktam varētu būt augstāks pieprasījumu ierobežojums nekā sarežģītai rakstīšanas operācijai.
• IP bāzēta vs. lietotāja bāzēta pieprasījumu ierobežošana: Apsveriet kompromisus starp pieprasījumu ierobežošanu, pamatojoties uz IP adresi, un pieprasījumu ierobežošanu, pamatojoties uz lietotāja ID vai API atslēgu. IP bāzēta pieprasījumu ierobežošana var būt efektīva, lai bloķētu ļaunprātīgu datplūsmu no konkrētiem avotiem, bet tā var arī ietekmēt likumīgus lietotājus, kuriem ir kopīga IP adrese (piemēram, lietotāji aiz NAT vārtejas). Lietotāja bāzēta pieprasījumu ierobežošana nodrošina precīzāku kontroli pār atsevišķu lietotāju lietojumu. Abu metožu kombinācija varētu būt optimāla.
• Integrācija ar API vārteju: Izmantojiet savas API vārtejas (piemēram, Kong, Tyk, Apigee) pieprasījumu ierobežošanas iespējas, lai vienkāršotu ieviešanu un pārvaldību. API vārtejas bieži vien nodrošina iebūvētas pieprasījumu ierobežošanas funkcijas un ļauj konfigurēt pieprasījumu ierobežojumus caur centralizētu saskarni.

Globālā perspektīva par pieprasījumu ierobežošanu

Izstrādājot un ieviešot API pieprasījumu ierobežošanu globālai auditorijai, apsveriet sekojošo:

• Laika joslas: Iestatot papildināšanas intervālus, ņemiet vērā dažādas laika joslas. Konsekvences nodrošināšanai apsveriet UTC laikspiedolu izmantošanu.
• Tīkla latentitāte: Tīkla latentitāte var ievērojami atšķirties dažādos reģionos. Iestatot pieprasījumu ierobežojumus, ņemiet vērā potenciālo latentitāti, lai nejauši nesodītu lietotājus attālās vietās.
• Reģionālie noteikumi: Esiet informēti par jebkādiem reģionālajiem noteikumiem vai atbilstības prasībām, kas varētu ietekmēt API lietošanu. Piemēram, dažos reģionos var būt datu privātuma likumi, kas ierobežo datu apjomu, ko var vākt vai apstrādāt.
• Satura piegādes tīkli (CDN): Izmantojiet CDN, lai izplatītu API saturu un samazinātu latentitāti lietotājiem dažādos reģionos.
• Valoda un lokalizācija: Nodrošiniet kļūdu paziņojumus un dokumentāciju vairākās valodās, lai apkalpotu globālu auditoriju.

Noslēgums

API pieprasījumu ierobežošana ir būtiska prakse, lai aizsargātu API no ļaunprātīgas izmantošanas un nodrošinātu to stabilitāti un pieejamību. Marķieru kausa algoritms piedāvā elastīgu un efektīvu risinājumu pieprasījumu ierobežošanas ieviešanai dažādos scenārijos. Rūpīgi izvēloties kausa izmēru un papildināšanas ātrumu, efektīvi glabājot kausa stāvokli un korekti apstrādājot pieprasījumu ierobežojuma pārsniegšanas gadījumus, jūs varat izveidot robustu un mērogojamu pieprasījumu ierobežošanas sistēmu, kas aizsargā jūsu API un nodrošina pozitīvu lietotāja pieredzi jūsu globālajai auditorijai. Atcerieties nepārtraukti uzraudzīt savu API lietojumu un pielāgot pieprasījumu ierobežošanas parametrus pēc nepieciešamības, lai pielāgotos mainīgajiem datplūsmas modeļiem un drošības draudiem.

Izprotot marķieru kausa algoritma principus un ieviešanas detaļas, jūs varat efektīvi aizsargāt savas API un veidot uzticamas un mērogojamas lietojumprogrammas, kas apkalpo lietotājus visā pasaulē.