ကျွန်ုပ်တို့ ကိုယ်ပိုင် ဝန်ဆောင်မှုများကို ကန့်သတ်နေခဲ့သည်

Mythex ၏ API သည် address တစ်ခုမှ တစ်မိနစ်လျှင် request ၃၀၀ ခွင့်ပြုသည်။ ထိုကန့်သတ်ချက်သည် လူတစ်ယောက် သို့မဟုတ် script တစ်ခုက API ကို အလွန်အကျွံ ခေါ်ခြင်းမှ ကာကွယ်ရန် ရှိသည်။ Production တွင် ကျွန်ုပ်တို့၏ edge (ထုတ်ဝေထားသော အက်ပ်များနှင့် preview ကို serve လုပ်သော အစိတ်အပိုင်း) နှင့် agent ကို run သော ဝန်ဆောင်မှုတို့ကို ထိုကန့်သတ်ချက်က ငြင်းဆိုခဲ့သည်။ အဘယ်ကြောင့်ဆိုသော ထိုဝန်ဆောင်မှုများ တစ်ခုစီသည် အရေအတွက်အနည်းငယ်သော address မှသာ API ကို ခေါ်သည်။ အတွင်းပိုင်း credential ပါသော request များကို ယခု ကင်းလွတ်စေပြီး အခြားအရာအားလုံးကို ယခင်အတိုင်း ကန့်သတ်ထားသည်။

ရောဂါလက္ခဏာ

API သည် ကျွန်ုပ်တို့ကိုယ်ပိုင် ခေါ်ဆိုမှု အချို့ကို 429 Too Many Requests ဖြင့် ပြန်ဖြေခဲ့သည်။ အသုံးပြုသူများအတွက် အရေးကြီးသော ခေါ်ဆိုမှု သုံးမျိုးကို ထိခိုက်ခဲ့သည်:

• Custom domain ပေါ်ရှိ အက်ပ်ကို ရှာခြင်း။ ဧည့်သည်က ကိုယ်ပိုင် domain ဖြင့် publish လုပ်ထားသော အက်ပ်ကို ဖွင့်သောအခါ edge က ထိုဆိုဒ်သည် ဘယ်မှာရှိသလဲဟု API ကို မေးသည်။ ထို 429 သည် ဆိုဒ်ကို မရောက်နိုင်သော ဧည့်သည် ဖြစ်သည်။
• Agent turn ကို သိမ်းခြင်း။ Agent လုပ်နေစဉ် ၎င်း၏ တိုးတက်မှုကို လုပ်ရင်းသိမ်းသဖြင့် refresh သို့မဟုတ် ချိတ်ဆက်မှု ပြတ်သော်လည်း အဖြေ ပျောက်မသွားပါ။ ထို 429 သည် မသိမ်းနိုင်သော တိုးတက်မှု ဖြစ်သည်။
• Preview ဝင်ခွင့် စစ်ဆေးခြင်း။ သင်တည်ဆောက်နေသော အက်ပ်၏ preview သည် ဂိတ်ပေါက် ရှိပြီး ဂိတ်က API ကို မေးသည်။ ထို 429 သည် မဖွင့်နိုင်သော preview ဖြစ်သည်။

ဤအရာများသည် ဘယ်တော့မှ လူ API ကို ခေါ်ခြင်း မဟုတ်ပါ။ အားလုံးသည် ကျွန်ုပ်တို့ကိုယ်တိုင် ဖြစ်သည်။

ဘာကြောင့် ဖြစ်ခဲ့သလဲ

Address တစ်ခုချင်း rate limit သည် ယူဆချက်တစ်ခု ပြုလုပ်သည်: address တစ်ခုသည် ခေါ်ဆိုသူ တစ်ယောက်ခန့်ဖြစ်သည်။ လူများအတွက် ၎င်းသည် နီးစပ်လုံလောက်ပါသည်။ ကိုယ်ပိုင် infrastructure အတွက် မှားနေသည်။

• ထုတ်ဝေထားသော အက်ပ်များနှင့် preview ကို serve လုပ်သော edge ဝန်ဆောင်မှုသည် ထွက်သွားသော address အနည်းငယ် မှ API ကို ခေါ်သည်။ ထုတ်ဝေထားသော အက်ပ်တိုင်းနှင့် preview စစ်ဆေးမှုတိုင်းမှ ဧည့်သည်အားလုံးသည် ထို address အနည်းငယ်မှတစ်ခုမှ ရောက်လာသည့် ပုံစံဖြစ်သည်။
• Orchestrator — agent turn များကို run သော ဝန်ဆောင်မှု — သည် container address တစ်ခု မှ API ကို ခေါ်သည်။ Run နေသော turn တိုင်း၊ user တိုင်းအတွက် ထို address ကို မျှဝေသည်။

ထို့ကြောင့် လူတစ်ယောက်အတွက် ရည်ရွယ်သော budget သည် ဝန်ဆောင်မှု တစ်ခုလုံး၏ traffic အားလုံးကြား ခွဲဝေခံနေရသည်။ ထိုဝန်ဆောင်မှုများက ၎င်းတို့အကြား အသုံးချကုန်ပြီး limiter က ပြောထားသည့်အတိုင်း ငြင်းဆိုခဲ့သည်။

ပြင်ဆင်ချက်

ကိုယ်ပိုင် ဝန်ဆောင်မှုများသည် ကိုယ်ကို သက်သေပြပြီးသား ဖြစ်သည်။ ခေါ်ဆိုမှုတိုင်းတွင် internal token ပါလာပြီး API ၏ internal အပိုင်းအောက်ရှိ route တိုင်းသည် မည်သည့်အရာမဆို မလုပ်မီ ထို token ကို စစ်ဆေးသည်။

Rate limiter သည် ယခု တူညီသော စစ်ဆေးမှုကို သုံးသည်။ Internal token နှင့် တူညီသော request ကို allow list ပေါ်တွင် ထားပြီး per-address budget တွင် မရေတွက်ပါ။ အခြားအရာအားလုံးကို ယခင်အတိုင်း ရေတွက်သည်: address တစ်ခုလျှင် တစ်မိနစ် ၃၀၀။

အထောက်အကူ အသေးစိတ် နှစ်ခုက ဤအရာကို အပေါက်ဖြစ်လာခြင်းမှ ကာကွယ်ခဲ့သည်:

1. မှားသော token ကို ကျော်ခွင့်မပေးပါ။ Allow list သည် အမှန်တကယ် internal token ကိုသာ ကိုက်ညီသည်။ အတုအယောင် token ပါသော request ကို ရေတွက်ပြီး ကန့်သတ်သည်၊ အခြား request များလိုပင်၊ internal route များက 401 Unauthorized ဖြင့် ငြင်းဆိုသည်။
2. ကန့်သတ်ချက် ကိန်းဂဏန်း မပြောင်းခဲ့ပါ။ နေရာလွတ်ဖန်တီးရန် နံပါတ်ကို မမြှင့်ခဲ့ပါ။ မြှင့်လျှင် ပြဿနာကို ယာယီ ဖုံးကွယ်ပြီး traffic ပိုများလာသည့်အခါ ထပ်ပြန်ဖြစ်မည်၊ ကန့်သတ်ချက် ရည်ရွယ်သည့် ကာကွယ်မှုကိုလည်း အားနည်းစေမည်။

ကန့်သတ်ချက်ဆက်တင်များကို function သေးသေးတစ်ခုတွင် စုပြီး ၎င်းအပေါ် test ရေးခဲ့သည်။ Test တစ်ခုသည် internal token ဖြင့် request ၂၀ ကို ၅ ခွင့်ပြုသော limiter သို့ ပို့ပြီး ၂၀ လုံး အောင်မြင်ရမည်ဟု မျှော်လင့်သည်။ အခြား test တစ်ခုသည် address တစ်ခုမှ ပုံမှန် request များကို ပို့ပြီး ပထမ ၅ ခု အောင်မြင်ကာ နောက်တွေ ငြင်းဆိုရမည်ဟု မျှော်လင့်သည်။ တတိယ test သည် အတုလုပ်ထားသော token ဖြင့် request များကို ပို့ပြီး တူညီစွာ ငြင်းဆိုရမည်ဟု မျှော်လင့်သည်။

ကျွန်ုပ်တို့ ရရှိခဲ့သည့်အရာ

• ကန့်သတ်ချက်များတွင် ယူဆချက်များ ပါသည်။ "Address တစ်ခု၊ ခေါ်ဆိုသူတစ်ယောက်" သည် address အလိုက် ကန့်သတ်ချက်တွင် တည်ဆောက်ထားသည်။ ကိုယ်ပိုင် ဝန်ဆောင်မှုများ shared address များနောက်တွင် ရောက်သည်နှင့် ထိုယူဆချက်သည် မမှန်တော့ပါ — load balancer၊ edge network၊ container၊ office network များ၌ များစွာ ရှိသည်။
• သင့်ကိုယ်ပိုင် traffic ကို address မဟုတ်ဘဲ identity ဖြင့် ခွဲပါ။ Address သည် traffic ရောက်ပုံဖြစ်ပြီး ဘယ်သူပို့သည်ဖြစ်သည် မဟုတ်ပါ။ ခေါ်ဆိုမှုသည် ကျွန်ုပ်တို့၏ဟု သက်သေပြသော credential ကို ကျွန်ုပ်တို့ ရှိပြီးသား ဖြစ်သော်လည်း limiter က မကြည့်ခဲ့ပါ။
• နံပါတ်ကို မြှင့်ခြင်းဖြင့် မပြင်ပါနှင့်။ ကြီးသော ကန့်သတ်ချက်သည် 429 ကို ခဏ ပျောက်စေမည်၊ ကာကွယ်မှု နည်းမည်၊ နောက်မှ ထပ်ပျက်မည်။
• ဘယ်သူ throttle ခံနေရသည်ကို ကြည့်ပါ။ ကိုယ်ပိုင် ဝန်ဆောင်မှုပေါ်ရောက်သော 429 သည် ကန့်သတ်ချက် အကြောင်း bug report ဖြစ်သည်၊ limiter အလုပ်လုပ်ကြောင်း လက္ခဏာ မဟုတ်ပါ။

Mythex ပေါ်တွင် တည်ဆောက်လျှင်

သင့်ဘက်တွင် ပြောင်းစရာ မရှိပါ။ Custom domain ပေါ်ရှိ publish လုပ်ထားသော အက်ပ်များ၊ agent turn များနှင့် preview များသည် Mythex ၏ ကျန်အရာများ မည်မျှ အလုပ်များသည်ဖြစ်စေ မှီခိုခြင်း မရှိတော့ပါ။ သင့်အက်ပ်၏ ကိုယ်ပိုင် traffic သည် သင့်အက်ပ်ဆိုင်ရာ ကိစ္စဖြစ်သည်။ ဤဆောင်းပါးတွင် ဖော်ပြသော ကန့်သတ်ချက်သည် ကျွန်ုပ်တို့၏ API ပေါ်တွင်ဖြစ်ပြီး သင် publish လုပ်သော အက်ပ်များပေါ်တွင် မဟုတ်ပါ။

ကိုယ်ပိုင် backend ရှိလျှင် ထည့်သော rate limit မည်သည့်အရာတွင်မဆို အလားတူ ထောင်ချောက် ရှိသည်။ API ဆိုသည်မှာ ဘာလဲ နှင့် AI ဖြင့် တည်ဆောက်ထားသော အက်ပ်များအတွက် လုံခြုံရေး စစ်ဆေးစာရင်း တို့သည် စတင်ရန် ကောင်းသည်။ ကျွန်ုပ်တို့ကိုယ်ပိုင် infrastructure က ကိုယ့်ကိုယ်ကို ဟန်တားခဲ့သော အခြားဥပမာအတွက် deploy 502 error သုည ရအောင် ဘယ်လိုလုပ်သလဲ ကို ကြည့်ပါ။