API Rate Limiting: Strategijos, kaip sukurti skalūnias API

Šiandieniame tarpusavyje susietame pasaulyje API (Application Programming Interfaces) yra daugybės programų ir paslaugų pagrindas. Jos leidžia sklandų bendravimą ir duomenų mainus tarp skirtingų sistemų. Tačiau didėjanti priklausomybė nuo API taip pat kelia iššūkių, ypač susijusių su jų skalūnumu ir saugumu. Vienas svarbiausių API valdymo aspektų yra apribojimų nustatymas (rate limiting), kuris atlieka gyvybiškai svarbų vaidmenį užkertant kelią piktnaudžiavimui, užtikrinant sąžiningą naudojimą ir palaikant bendrą jūsų API infrastruktūros stabilumą.

Kas yra API apribojimų nustatymas?

API apribojimų nustatymas yra technika, naudojama kontroliuoti, kiek užklausų klientas gali pateikti API per tam tikrą laikotarpį. Ji veikia kaip vartininkas, apsaugantis nuo kenkėjiškų atakų, tokių kaip „Denial of Service“ (DoS) ir „Distributed Denial of Service“ (DDoS), taip pat nuo netyčinio perkrovimo, kurį sukelia prastai suprojektuotos programos. Įgyvendindami apribojimus, galite apsaugoti savo API išteklius, užtikrinti nuoseklią vartotojo patirtį ir išvengti paslaugų trikdžių.

Kodėl apribojimų nustatymas yra svarbus?

Apribojimų nustatymas yra būtinas dėl kelių priežasčių:

• Piktnaudžiavimo prevencija: Tai padeda užkirsti kelią kenkėjiškiems veikėjams perkrauti jūsų API per dideliu kiekiu užklausų, galinčiu sugriauti jūsų serverius ar sukelti didelių išlaidų.
• Sąžiningo naudojimo užtikrinimas: Tai užtikrina, kad visi vartotojai turėtų vienodą galimybę pasiekti jūsų API išteklius, neleisdama vienam vartotojui monopolizuoti paslaugą.
• API stabilumo palaikymas: Kontroliuodami užklausų dažnį, galite apsaugoti savo API nuo perkrovimo, užtikrindami nuoseklų našumą ir prieinamumą.
• Infrastruktūros apsauga: Tai apsaugo jūsų pagrindinę infrastruktūrą nuo perkrovimo dėl didelio srauto, užkertant kelią galimiems trikdžiams ir duomenų praradimui.
• Monetizavimas ir lygių prieiga: Tai leidžia pasiūlyti skirtingus API prieigos lygius pagal naudojimą, leidžiant jums monetizuoti savo API ir patenkinti skirtingus klientų poreikius.

Diegimo strategijos

Yra keletas skirtingų API apribojimų nustatymo metodų, kiekvienas turi savo privalumų ir trūkumų. Štai keletas populiariausių strategijų:

1. Žetonų kibiro algoritmas (Token Bucket Algorithm)

Žetonų kibiro algoritmas yra populiarus ir lankstus apribojimų nustatymo metodas. Įsivaizduokite kibirą, kuriame laikomi žetonai. Kiekviena užklausa sunaudoja vieną žetoną. Jei yra laisvų žetonų, užklausa apdorojama; kitaip ji atmetama arba atidedama. Kibiras periodiškai papildomas žetonais tam tikru dažniu.

Kaip tai veikia:

• Kiekvienam klientui sukurtas kibiras su maksimaliu pajėgumu ir papildymo dažniu.
• Kiekvieną kartą, kai klientas pateikia užklausą, iš kibiro pašalinamas žetonas.
• Jei kibiras tuščias, užklausa atmetama arba atidedama, kol atsiras žetonų.
• Kibiras papildomas žetonais fiksuotu dažniu, iki jo maksimalaus pajėgumo.

Privalumai:

• Lankstumas: Papildymo dažnį ir kibiro dydį galima reguliuoti, kad atitiktų skirtingus API reikalavimus.
• Srautų leidimas: Leidžia atsitiktiniams srautų antplūdžiams be apribojimų paleidimo.
• Lengva įdiegti: Gana paprasta įdiegti ir suprasti.

Trūkumai:

• Sudėtingumas: Reikia valdyti kibirus ir žetonus kiekvienam klientui.
• Konfigūracija: Reikia kruopščiai konfigūruoti papildymo dažnį ir kibiro dydį.

Pavyzdys:

Tarkime, kad jūsų API apribojimas yra 10 užklausų per sekundę vienam vartotojui, naudojant žetonų kibiro algoritmą. Kiekvienas vartotojas turi kibirą, kuris gali sutalpinti iki 10 žetonų. Kas sekundę kibiras papildomas 10 žetonų (iki maksimalaus pajėgumo). Jei vartotojas per vieną sekundę pateikia 15 užklausų, pirmosios 10 užklausų sunaudos žetonus, o likusios 5 užklausos bus atmestos arba atidėtos.

2. Pratekantis kibiro algoritmas (Leaky Bucket Algorithm)

Pratekantis kibiro algoritmas panašus į žetonų kibirą, bet sutelkia dėmesį į užklausų ištekėjimo kontrolę. Įsivaizduokite kibirą su nuolat pratekančiu greičiu. Atvykstančios užklausos dedamos į kibirą, o kibiras išleidžia užklausas fiksuotu greičiu. Jei kibiras perpildomas, užklausos išmetamos.

Kaip tai veikia:

• Kiekvienam klientui sukurtas kibiras su maksimaliu pajėgumu ir pratekėjimo greičiu.
• Kiekviena atvykstanti užklausa pridedama prie kibiro.
• Kibiras praleidžia užklausas fiksuotu greičiu.
• Jei kibiras pilnas, atvykstančios užklausos išmetamos.

Privalumai:

• Sklandus srautas: Užtikrina sklandų užklausų ištekėjimą, apsaugant nuo staigių srauto antplūdžių.
• Paprastas diegimas: Gana paprasta įdiegti.

Trūkumai:

• Ribotas srautų leidimas: Neleidžia staigių srautų antplūdžių taip lengvai, kaip žetonų kibiro algoritmas.
• Galimybė prarasti užklausas: Gali lemti atmestas užklausas, jei kibiras perpildomas.

Pavyzdys:

Apsvarstykite API, kuri apdoroja vaizdus. Siekiant užkirsti kelią paslaugos perkrovimui, įdiegtas pratekantis kibiras su 5 vaizdų per sekundę pratekėjimo greičiu. Bet kokie vaizdų įkėlimai, viršijantys šį greitį, yra atmestami. Tai užtikrina, kad vaizdų apdorojimo tarnyba veiktų sklandžiai ir efektyviai.

3. Fiksuoto lango skaitiklis (Fixed Window Counter)

Fiksuoto lango skaitiklio algoritmas dalija laiką į fiksuoto dydžio langus (pvz., 1 minutė, 1 valanda). Kiekvienam klientui jis skaičiuoja užklausų, pateiktų per dabartinį langą, skaičių. Jei skaičius viršija limitą, vėlesnės užklausos atmetamos, kol langas atsinaujins.

Kaip tai veikia:

• Laikas dalijamas į fiksuoto dydžio langus.
• Kiekvienam klientui palaikomas skaitiklis, sekantis užklausų skaičių dabartiniame lange.
• Jei skaitiklis viršija limitą, vėlesnės užklausos atmetamos, kol langas atsinaujins.
• Kai langas atsinaujina, skaitiklis nustatomas į nulį.

Privalumai:

• Paprastumas: Labai lengva įdiegti.
• Mažas našumo sutrikimas: Reikalauja minimalių išteklių.

Trūkumai:

• Galimybė staigiems srautams: Gali leisti staigiems srautams prie langų kraštų. Vartotojas galėtų pateikti leistiną užklausų skaičių prieš pat lango atnaujinimą, o tada iš karto pateikti dar vieną pilną užklausų rinkinį naujo lango pradžioje, efektyviai padvigubindamas savo leistiną greitį.
• Netikslūs apribojimai: Gali būti netikslus, jei užklausos sutelktos lango pradžioje arba pabaigoje.

Pavyzdys:

Pagalvokite apie API su 100 užklausų per minutę apribojimu, naudojant fiksuoto lango skaitiklio algoritmą. Vartotojas teoriškai galėtų pateikti 100 užklausų paskutinę vienos minutės sekundę ir tada dar 100 užklausų kitos minutės pirmą sekundę, efektyviai padvigubindamas savo leistiną greitį.

4. Slankiojo lango žurnalas (Sliding Window Log)

Slankiojo lango žurnalo algoritmas saugo visų užklausų, pateiktų per slankiojantį laikotarpį, žurnalą. Kiekvieną kartą, kai pateikiama užklausa, algoritmas patikrina, ar žurnale užklausų skaičius viršija limitą. Jei viršija, užklausa atmetama.

Kaip tai veikia:

• Kiekvienam klientui palaikomas žurnalas, kuriame saugomi visų užklausų laiko žymės per slankiojantį laikotarpį.
• Kai pateikiama nauja užklausa, patikrinamas žurnalas, ar užklausų skaičius per laikotarpį neviršija limito.
• Jei limitas viršijamas, užklausa atmetama.
• Seni įrašai pašalinami iš žurnalo, kai jie išeina iš slankiojo lango ribų.

Privalumai:

• Tikslumas: Užtikrina tikslesnius apribojimus nei fiksuoto lango skaitiklis.
• Nėra langų kraštų problemų: Išvengiama galimybės staigiems srautams prie langų kraštų.

Trūkumai:

• Didesnis našumo sutrikimas: Reikalauja daugiau saugojimo ir apdorojimo galios nei fiksuoto lango skaitiklis.
• Sudėtingumas: Sudėtingiau įdiegti.

Pavyzdys:

Socialinės medijos API gali naudoti slankiojo lango žurnalą, kad apribotų vartotojus iki 500 įrašų per valandą. Žurnale saugomos paskutinių 500 įrašų laiko žymės. Kai vartotojas bando paskelbti naują pranešimą, algoritmas patikrina, ar per pastarąją valandą jau yra 500 įrašų. Jei taip, įrašas atmetamas.

5. Slankiojo lango skaitiklis (Sliding Window Counter)

Slankiojo lango skaitiklis yra hibridinis metodas, derinantis fiksuoto lango skaitiklio ir slankiojo lango žurnalo privalumus. Jis dalija langą į mažesnius segmentus ir naudoja svorinio skaičiavimo metodą, kad nustatytų apribojimo greitį. Tai suteikia tikslesnius apribojimus, palyginti su fiksuoto lango skaitikliu, ir yra mažiau resursų reikalaujantis nei slankiojo lango žurnalas.

Kaip tai veikia:

• Laiko langas dalijamas į mažesnius segmentus (pvz., sekundės per minutę).
• Kiekvienam segmentui palaikomas skaitiklis.
• Dabartinis užklausų greitis apskaičiuojamas atsižvelgiant į baigtus segmentus ir dabartinį segmentą.
• Jei apskaičiuotas greitis viršija limitą, užklausa atmetama.

Privalumai:

• Geresnis tikslumas: Siūlo geresnį tikslumą, palyginti su fiksuoto lango skaitikliu.
• Mažesnis našumo sutrikimas: Mažiau resursų reikalaujantis nei slankiojo lango žurnalas.
• Balansuoja sudėtingumą ir našumą: Geras kompromisas tarp tikslumo ir išteklių naudojimo.

Trūkumai:

• Sudėtingesnis diegimas: Sudėtingiau įdiegti nei fiksuoto lango skaitiklis.
• Vis tiek yra apytikslis: Tai vis dar apytikslis metodas, nors ir tikslesnis nei fiksuotas langas.

Pavyzdys:

Elektroninės komercijos API gali naudoti slankiojo lango skaitiklį su 200 užklausų per minutę apribojimu, padalydama minutę į 10 sekundžių segmentus. Algoritmas apskaičiuoja svorinio vidurkio užklausas iš ankstesnių pilnų segmentų ir dabartinio segmento, kad nustatytų, ar vartotojas viršija savo apribojimą.

Tinkamos strategijos pasirinkimas

Geriausia apribojimų nustatymo strategija jūsų API priklauso nuo jūsų specifinių reikalavimų ir apribojimų. Apsvarstykite šiuos veiksnius:

• Tikslumas: Koks tikslus turi būti apribojimų nustatymas? Ar reikia užkirsti kelią net nedideliems srautų antplūdžiams?
• Našumas: Koks yra apribojimų nustatymo algoritmo našumo poveikis? Ar jis gali atlaikyti numatomą srauto kiekį?
• Sudėtingumas: Kiek sudėtingas algoritmas įdiegti ir palaikyti?
• Išteklių naudojimas: Kiek saugojimo ir apdorojimo galios sunaudos algoritmas?
• Lankstumas: Kiek lankstus algoritmas prisitaikyti prie besikeičiančių reikalavimų?
• Naudojimo atvejis: Konkretūs jūsų API poreikiai, pvz., jei tai kritinė paslauga, tikslumas turėtų būti aukštas, palyginti su analitikos API, kur tam tikras nedidelis netikslumas gali būti priimtinas.

Paprastai paprastesni algoritmai, tokie kaip fiksuoto lango skaitiklis, tinka API su mažiau griežtais reikalavimais, o sudėtingesni algoritmai, tokie kaip slankiojo lango žurnalas ar slankiojo lango skaitiklis, labiau tinka API, kurioms reikalingi tikslesni apribojimai.

Diegimo aspektai

Įgyvendindami API apribojimų nustatymą, atsižvelkite į šias geriausias praktikas:

• Klientų identifikavimas: Naudokite API raktus, autentifikavimo žetonus ar IP adresus klientams identifikuoti.
• Apribojimų nustatymas: Nustatykite tinkamus apribojimus kiekvienam klientui ar API galutiniam taškui.
• Apribojimų duomenų saugojimas: Pasirinkite tinkamą apribojimų duomenų saugojimo mechanizmą, pvz., atminties talpyklą (Redis, Memcached), duomenų bazes arba paskirstytas apribojimų paslaugas.
• Informacinės klaidos žinutės: Pateikite informatyvias klaidos žinutes klientams, kai jie viršija apribojimą. Įtraukite tokią informaciją, kaip ilgai jiems reikia laukti prieš pakartojant bandymą (pvz., naudojant „Retry-After“ antraštę).
• Stebėjimas ir analizė: Stebėkite ir analizuokite apribojimų duomenis, kad nustatytumėte galimas problemas ir optimizuotumėte apribojimus.
• API versijų atsižvelgimas: Skirtingos API versijos gali reikalauti skirtingų apribojimų.
• Įgyvendinimo vieta: Apribojimus galite taikyti skirtinguose lygiuose (pvz., API vartai, taikomoji programa). API vartai dažnai yra pageidaujamas pasirinkimas.
• Globalus prieš vietinį apribojimą: Nuspręskite, ar apribojimas turėtų būti taikomas globaliai visuose serveriuose, ar lokaliai kiekvienam serveriui. Globalus apribojimas yra tikslesnis, bet sudėtingesnis įdiegti.
• Graceful Degradation: Apsvarstykite nuoseklaus degradavimo strategiją, jei apribojimų nustatymo paslauga sugenda.
• Dinaminė konfigūracija: Užtikrinkite, kad konfigūracija gali būti dinamiškai atnaujinama, kad apribojimai būtų keičiami be paslaugos trikdžių.

Pavyzdys: Apribojimų nustatymas naudojant „Redis“ ir API vartus

Šis pavyzdys apibūdina supaprastintą diegimą, naudojant „Redis“ apribojimų duomenims saugoti ir API vartus (pvz., „Kong“, „Tyk“ ar debesų paslaugų teikėjų, tokių kaip „AWS“, „Azure“ ar „Google Cloud“, API valdymo paslaugas) apribojimams taikyti.

1. Kliento autentifikacija: API vartai gauna užklausą ir autentifikuoja klientą naudodami API raktą arba JWT.
2. Apribojimų patikrinimas: Vartai gauna kliento ID (pvz., API raktą) ir „Redis“ patikrina dabartinį užklausų skaičių tam klientui ir konkrečiam API galutiniam taškui. „Redis“ raktas gali būti panašus į `rate_limit:api_key:{api_key}:endpoint:{endpoint}`.
3. Skaitiklio padidinimas: Jei užklausų skaičius yra mažesnis nei nustatytas limitas, vartai padidina skaitiklį „Redis“ naudodami atomines operacijas (pvz., „INCR“ ir „EXPIRE“ komandas „Redis“).
4. Leidimas arba atmetimas: Jei padidintas skaičius viršija limitą, vartai atmeta užklausą su „429 Too Many Requests“ klaida. Kitu atveju užklausa persiunčiama į pagrindinę API.
5. Klaidos tvarkymas: Vartai pateikia naudingą klaidos žinutę, įskaitant „Retry-After“ antraštę, nurodančią, kiek laiko klientas turėtų laukti prieš pakartojant bandymą.
6. „Redis“ konfigūracija: „Redis“ sukonfigūruokite su tinkamais nustatymais, skirtiems patvarumui ir aukštam prieinamumui.

Pavyzdys klaidos pranešimo:

`HTTP/1.1 429 Too Many Requests` `Content-Type: application/json` `Retry-After: 60` `{"error": "Rate limit exceeded. Please try again in 60 seconds."}`

Debesų paslaugų teikėjų sprendimai

Pagrindiniai debesų paslaugų teikėjai, tokie kaip „AWS“, „Azure“ ir „Google Cloud“, siūlo integruotas API valdymo paslaugas, kurios apima apribojimų nustatymo funkcijas. Šios paslaugos dažnai teikia pažangesnes funkcijas, pvz.:

• Grafinė vartotojo sąsaja: Paprasta naudoti sąsaja apribojimų nustatymui konfigūruoti.
• Analitika: Išsami API naudojimo ir apribojimų nustatymo analitika.
• Integracija: Sklandi integracija su kitomis debesų paslaugomis.
• Skalūnumas: Labai skalūniška ir patikima infrastruktūra.
• Politikos įgyvendinimas: Sudėtingos politikos įgyvendinimo sistemos.

Pavyzdžiai:

• AWS API Gateway: Teikia integruotą apribojimų nustatymo palaikymą naudojant naudojimo planus ir ribojimo nustatymus.
• Azure API Management: Siūlo įvairias apribojimų nustatymo politikas, kurios gali būti taikomos API.
• Google Cloud API Gateway: Teikia apribojimų nustatymo ir kvotų valdymo funkcijas.

Išvada

API apribojimų nustatymas yra kritinis patvarių ir skalūnių API kūrimo aspektas. Įgyvendindami tinkamas apribojimų nustatymo strategijas, galite apsaugoti savo API išteklius, užtikrinti sąžiningą naudojimą ir palaikyti bendrą API infrastruktūros stabilumą. Tinkamos strategijos pasirinkimas priklauso nuo jūsų specifinių reikalavimų ir apribojimų, todėl reikėtų atidžiai apsvarstyti diegimo geriausias praktikas. Naudojant debesų paslaugų teikėjų sprendimus arba trečiųjų šalių API valdymo platformas, galima supaprastinti diegimą ir teikti pažangesnes funkcijas.

Suprasdami skirtingus apribojimų nustatymo algoritmus ir diegimo aspektus, galite kurti API, kurios yra atsparios, saugios ir skalūnios, atitinkančios šiandienos tarpusavyje susieto pasaulio poreikius. Nepamirškite nuolat stebėti ir analizuoti savo API srautą, kad pritaikytumėte apribojimus ir užtikrintumėte optimalų našumą. Gerai įdiegtas apribojimų nustatymo strategija reikšmingai prisideda prie teigiamos kūrėjų patirties ir stabilios programų ekosistemos.