ഞങ്ങൾ ഞങ്ങളുടെ സ്വന്തം സേവനങ്ങളെ റേറ്റ്-ലിമിറ്റ് ചെയ്യുകയായിരുന്നു

Mythex-ന്റെ API ഒരു നെറ്റ്‌വർക്ക് വിലാസത്തിൽ നിന്ന് മിനിറ്റിൽ 300 അഭ്യർത്ഥനകൾ അനുവദിക്കുന്നു. ഒരു വ്യക്തിയോ സ്ക്രിപ്റ്റോ API-യെ ആക്രമിക്കുന്നതിൽ നിന്ന് ഞങ്ങളെ സംരക്ഷിക്കാനാണ് ആ പരിധി. പ്രൊഡക്ഷനിൽ, അത് ഞങ്ങളുടെ സ്വന്തം സേവനങ്ങളെ — പ്രസിദ്ധീകരിച്ച ആപ്പുകൾക്ക് സേവനം നൽകുന്ന ഞങ്ങളുടെ എഡ്ജ് ഭാഗത്തെയും AI ഏജന്റ് പ്രവർത്തിപ്പിക്കുന്ന സേവനത്തെയും — നിരസിക്കാൻ തുടങ്ങി, കാരണം അവ ഓരോന്നും ഒരു ചെറിയ എണ്ണം വിലാസങ്ങളിൽ നിന്നാണ് API-യെ സമീപിക്കുന്നത്. ഞങ്ങളുടെ ആന്തരിക ക്രെഡൻഷ്യൽ വഹിക്കുന്ന അഭ്യർത്ഥനകൾക്ക് ഇപ്പോൾ ഒഴിവുണ്ട്; മറ്റെല്ലാവരെയും മുമ്പത്തെപ്പോലെ തന്നെ പരിമിതപ്പെടുത്തുന്നു.

ലക്ഷണം

API ഞങ്ങളുടെ സ്വന്തം ചില ആന്തരിക കോളുകൾക്ക് 429 Too Many Requests നൽകാൻ തുടങ്ങി. മൂന്ന് തരം കോളുകൾ ബാധിക്കപ്പെട്ടു, അവയിൽ ഓരോന്നും Mythex ഉപയോഗിക്കുന്ന ആർക്കെങ്കിലും പ്രധാനമാണ്:

• ഒരു ഇഷ്ടാനുസൃത ഡൊമെയ്‌നിൽ ഏത് ആപ്പാണ് താമസിക്കുന്നതെന്ന് നോക്കൽ. ഒരു സന്ദർശകൻ പ്രസിദ്ധീകരിച്ച ആപ്പ് അതിന്റെ സ്വന്തം ഡൊമെയ്‌നിൽ തുറക്കുമ്പോൾ, ആ സൈറ്റ് എവിടെയാണെന്ന് ഞങ്ങളുടെ എഡ്ജ് API-യോട് ചോദിക്കുന്നു. അവിടെ വരുന്ന 429 എന്നാൽ ഒരു സൈറ്റിൽ എത്താൻ കഴിയാത്ത ഒരു സന്ദർശകൻ.
• പ്രവർത്തിക്കുന്ന ഒരു ഏജന്റ് ടേൺ സേവ് ചെയ്യൽ. ഏജന്റ് പ്രവർത്തിക്കുമ്പോൾ, അതിന്റെ പുരോഗതി പോകുമ്പോൾ തന്നെ സേവ് ചെയ്യപ്പെടുന്നു, അതിനാൽ ഒരു റീഫ്രഷോ തകർന്ന കണക്ഷനോ ഉണ്ടായാലും മറുപടി നിലനിൽക്കും. അവിടെ വരുന്ന 429 എന്നാൽ സേവ് ചെയ്യപ്പെടാത്ത പുരോഗതി.
• ഒരു പ്രിവ്യൂവിലേക്കുള്ള ആക്സസ് പരിശോധിക്കൽ. നിങ്ങൾ നിർമ്മിക്കുന്ന ആപ്പിന്റെ പ്രിവ്യൂ ഗേറ്റ് ചെയ്തിരിക്കുന്നു, ആ ഗേറ്റ് API-യോട് ചോദിക്കുന്നു. അവിടെ വരുന്ന 429 എന്നാൽ തുറക്കാത്ത ഒരു പ്രിവ്യൂ.

ഇവയിൽ ഒന്നും API-യെ സമീപിച്ച ആളുകളായിരുന്നില്ല. എല്ലാം ഞങ്ങളായിരുന്നു.

എന്തുകൊണ്ട് ഇത് സംഭവിച്ചു

ഓരോ വിലാസത്തിനുമുള്ള റേറ്റ് ലിമിറ്റ് ഒരു അനുമാനം മാത്രമേ നടത്തുന്നുള്ളൂ: ഒരു വിലാസം ഏകദേശം ഒരു വിളിക്കുന്നയാളാണ്. ആളുകൾക്ക് അത് ഏതാണ്ട് മതി. ഞങ്ങളുടെ സ്വന്തം അടിസ്ഥാനസൗകര്യത്തിന്, അത് തീർത്തും തെറ്റാണ്.

• പ്രസിദ്ധീകരിച്ച ആപ്പുകളും പ്രിവ്യൂകളും സേവിക്കുന്ന എഡ്ജ് സേവനം API-യെ കുറച്ച് പങ്കിട്ട പുറത്തേക്കുള്ള വിലാസങ്ങളിൽ നിന്ന് സമീപിക്കുന്നു. ഓരോ പ്രസിദ്ധീകരിച്ച ആപ്പിലേക്കും ഓരോ സന്ദർശകനും ഓരോ പ്രിവ്യൂ പരിശോധനയും ഈ കുറച്ചിൽ ഒന്നിൽ നിന്ന് വന്നതുപോലെ കാണപ്പെടുന്നു.
• ഓർക്കസ്ട്രേറ്റർ — ഏജന്റ് ടേണുകൾ പ്രവർത്തിപ്പിക്കുന്ന സേവനം — API-യെ ഒരൊറ്റ കണ്ടെയ്‌നർ വിലാസത്തിൽ നിന്ന് സമീപിക്കുന്നു. പ്രവർത്തിക്കുന്ന ഓരോ ടേണും, എല്ലാ ഉപയോക്താക്കൾക്കും, ആ വിലാസം പങ്കിടുന്നു.

അതിനാൽ ഒരു വ്യക്തിക്കായി ഉദ്ദേശിച്ച ബജറ്റ് ഒരു മുഴുവൻ സേവനത്തിന്റെ എല്ലാ ട്രാഫിക്കിനും വിഭജിക്കപ്പെട്ടു. ആ സേവനങ്ങൾ അവയ്ക്കിടയിൽ അത് തീർത്തു, പരിധി പറഞ്ഞത് പോലെ തന്നെ ചെയ്തു: അവയെ നിരസിച്ചു.

പരിഹാരം

ഞങ്ങളുടെ സ്വന്തം സേവനങ്ങൾ ഇതിനകം തെളിയിക്കുന്നു അവ ആരാണെന്ന്. ഓരോ ആന്തരിക കോളും ഒരു ആന്തരിക ടോക്കൺ വഹിക്കുന്നു, API-യുടെ ആന്തരിക വിഭാഗത്തിന് കീഴിലുള്ള ഓരോ റൂട്ടും എന്തെങ്കിലും ചെയ്യുന്നതിന് മുമ്പ് ആ ടോക്കൺ പരിശോധിക്കുന്നു.

റേറ്റ് ലിമിറ്റർ ഇപ്പോൾ അതേ പരിശോധന ഉപയോഗിക്കുന്നു. ആന്തരിക ടോക്കണുമായി പൊരുത്തപ്പെടുന്ന ഒരു അഭ്യർത്ഥന ഒരു അനുവദിച്ച പട്ടികയിലാണ്, ഓരോ-വിലാസ ബജറ്റിനെതിരെ കണക്കാക്കില്ല. മറ്റെല്ലാം മുമ്പത്തെപ്പോലെ തന്നെ കണക്കാക്കുന്നു: ഓരോ വിലാസത്തിനും മിനിറ്റിൽ 300 അഭ്യർത്ഥനകൾ.

ഇത് ഒരു പഴുതാകാതിരിക്കാൻ രണ്ട് വിശദാംശങ്ങൾ സഹായിച്ചു:

1. തെറ്റായ ടോക്കണിന് ഒരു ഇളവുമില്ല. അനുവദിച്ച പട്ടിക യഥാർത്ഥ ആന്തരിക ടോക്കണുമായി മാത്രമേ പൊരുത്തപ്പെടൂ. വ്യാജ ടോക്കണുള്ള അഭ്യർത്ഥന മറ്റേതിനെയും പോലെ കണക്കാക്കുകയും പരിമിതപ്പെടുത്തുകയും ചെയ്യുന്നു, ആന്തരിക റൂട്ടുകൾ അതിനെ 401 Unauthorized നൽകി ഇപ്പോഴും നിരസിക്കുന്നു.
2. പരിധി തന്നെ മാറിയില്ല. ഇടം ഉണ്ടാക്കാൻ ഞങ്ങൾ സംഖ്യ ഉയർത്തിയില്ല. ഉയർത്തിയിരുന്നെങ്കിൽ ട്രാഫിക് വീണ്ടും വളരുന്നതുവരെ പ്രശ്നം മറഞ്ഞിരിക്കുമായിരുന്നു, പരിധി നിലനിൽക്കുന്ന കേസിനുള്ള സംരക്ഷണം ദുർബലമാകുമായിരുന്നു.

റേറ്റ് ലിമിറ്ററിന്റെ ക്രമീകരണങ്ങൾ ഒരു ചെറിയ ഫംഗ്ഷനിലേക്ക് മാറ്റി അതിനെതിരെ ടെസ്റ്റുകൾ എഴുതി. ഒന്ന് ആന്തരിക ടോക്കണുള്ള 20 അഭ്യർത്ഥനകൾ 5 അനുവദിക്കുന്ന ഒരു ലിമിറ്ററിലേക്ക് അയയ്ക്കുന്നു, എല്ലാ 20-ഉം വിജയിക്കണമെന്ന് പ്രതീക്ഷിക്കുന്നു. മറ്റൊന്ന് ഒരു വിലാസത്തിൽ നിന്ന് സാധാരണ അഭ്യർത്ഥനകൾ അയയ്ക്കുന്നു, ആദ്യത്തെ അഞ്ചെണ്ണം വിജയിക്കുകയും പിന്നീടുള്ളവ നിരസിക്കപ്പെടുകയും ചെയ്യണമെന്ന് പ്രതീക്ഷിക്കുന്നു. മൂന്നാമത്തേത് വ്യാജ ടോക്കണുള്ള അഭ്യർത്ഥനകൾ അയയ്ക്കുന്നു, അവ അതേ രീതിയിൽ നിരസിക്കപ്പെടണമെന്ന് പ്രതീക്ഷിക്കുന്നു.

ഞങ്ങൾ ഇതിൽ നിന്ന് പഠിച്ചത്

• പരിധികൾ അനുമാനങ്ങൾ വഹിക്കുന്നു. "ഒരു വിലാസം, ഒരു വിളിക്കുന്നയാൾ" എന്നത് ഓരോ-വിലാസ പരിധിയിൽ അന്തർനിർമ്മിതമാണ്. നിങ്ങളുടെ സ്വന്തം സേവനങ്ങൾ പങ്കിട്ട വിലാസങ്ങൾക്ക് പിന്നിൽ ഇരിക്കുമ്പോൾ അത് സത്യമല്ലാതാകുന്നു — പലതും അങ്ങനെയാണ്: ലോഡ് ബാലൻസറുകൾ, എഡ്ജ് നെറ്റ്‌വർക്കുകൾ, കണ്ടെയ്‌നറുകൾ, ഓഫീസ് നെറ്റ്‌വർക്കുകൾ.
• നിങ്ങളുടെ സ്വന്തം ട്രാഫിക്കിനെ വിലാസം കൊണ്ടല്ല, ഐഡന്റിറ്റി കൊണ്ട് വേർതിരിക്കുക. വിലാസങ്ങൾ ട്രാഫിക് എത്തുന്ന വഴിയാണ്, ആരാണ് അയച്ചതെന്നല്ല. ഒരു കോൾ ഞങ്ങളുടേതാണെന്ന് തെളിയിക്കുന്ന ഒരു ക്രെഡൻഷ്യൽ ഞങ്ങൾക്ക് ഇതിനകം ഉണ്ടായിരുന്നു; റേറ്റ് ലിമിറ്റർ അതിലേക്ക് നോക്കിയിരുന്നില്ല എന്ന് മാത്രം.
• സംഖ്യ ഉയർത്തി പരിഹരിക്കരുത്. വലിയ പരിധി 429-കളെ കുറച്ചുകാലത്തേക്ക് ഇല്ലാതാക്കുമായിരുന്നു, സംരക്ഷണം കുറയ്ക്കുകയും പിന്നീട് വീണ്ടും പരാജയപ്പെടുകയും ചെയ്യുമായിരുന്നു.
• ആരാണ് തടയപ്പെടുന്നതെന്ന് നോക്കുക. നിങ്ങളുടെ സ്വന്തം സേവനത്തിൽ വരുന്ന 429 നിങ്ങളുടെ പരിധികളെക്കുറിച്ചുള്ള ഒരു ബഗ് റിപ്പോർട്ടാണ്, റേറ്റ് ലിമിറ്റർ പ്രവർത്തിക്കുന്നതിന്റെ സൂചനയല്ല.

നിങ്ങൾ Mythex-ൽ നിർമ്മിക്കുകയാണെങ്കിൽ ഇതിന്റെ അർത്ഥം

നിങ്ങളുടെ ഭാഗത്ത് മാറ്റാൻ ഒന്നുമില്ല. ഇഷ്ടാനുസൃത ഡൊമെയ്‌നുകളിലെ പ്രസിദ്ധീകരിച്ച ആപ്പുകൾ, ഏജന്റ് ടേണുകൾ, പ്രിവ്യൂകൾ എന്നിവ ഇപ്പോൾ Mythex-ന്റെ ബാക്കി എത്ര തിരക്കിലാണെന്നതിനെ ആശ്രയിക്കുന്നില്ല. നിങ്ങളുടെ ആപ്പിന്റെ സ്വന്തം ട്രാഫിക് നിങ്ങളുടെ ആപ്പിന്റെ കാര്യമാണ്: ഇവിടെ വിവരിച്ച പരിധി ഞങ്ങളുടെ API-യിലാണ്, നിങ്ങൾ പ്രസിദ്ധീകരിക്കുന്ന ആപ്പുകളിലല്ല.

നിങ്ങൾക്ക് സ്വന്തമായി ഒരു ബാക്കെൻഡ് ഉണ്ടെങ്കിൽ, നിങ്ങൾ ചേർക്കുന്ന ഏത് റേറ്റ് ലിമിറ്റിനും ഇതേ കെണി ബാധകമാണ്. API എന്താണെന്ന്, AI-നിർമ്മിത ആപ്പുകൾക്കുള്ള സുരക്ഷാ ചെക്ക്‌ലിസ്റ്റ് എന്നിവ തുടങ്ങാൻ നല്ല സ്ഥലങ്ങളാണ്. ഞങ്ങളുടെ സ്വന്തം അടിസ്ഥാനസൗകര്യം സ്വയം വഴിമുടക്കിയ മറ്റൊരു കേസിന്, ഡിപ്ലോയ്‌കൾ പൂജ്യം 502 പിശകുകളിലേക്ക് എങ്ങനെ എത്തിച്ചു എന്നത് കാണുക.