আমরা নিজেদের সেবাগুলোকে রেট-লিমিট করছিলাম

Mythex-এর API একটি নেটওয়ার্ক ঠিকানা থেকে মিনিটে ৩০০টি অনুরোধ দেয়। এই সীমা আছে একজন মানুষ বা script-কে API-তে বারবার আঘাত করা থেকে রক্ষা করতে। প্রোডাকশনে এটি উল্টো আমাদের নিজের সেবাগুলোকেই ফিরিয়ে দিতে শুরু করল: আমাদের edge-এর সেই অংশ, যা published app পরিবেশন করে, এবং সেই সেবা, যা AI এজেন্ট চালায়। কারণ তাদের প্রত্যেকে হাতে গোনা কয়েকটি ঠিকানা থেকে API-তে পৌঁছায়। যেসব অনুরোধে আমাদের অভ্যন্তরীণ credential থাকে, এখন সেগুলো ছাড় পায়। বাকি সবার উপর সীমা আগের মতোই প্রযোজ্য।

লক্ষণ

API আমাদের নিজের কিছু অভ্যন্তরীণ কলের উত্তর দিতে শুরু করল 429 Too Many Requests দিয়ে। তিন ধরনের কল আঘাত পেল, এবং প্রত্যেকটি Mythex ব্যবহারকারীর কাছে গুরুত্বপূর্ণ:

• কাস্টম ডোমেইনে কোন app আছে তা খোঁজা। কোনো published app নিজের ডোমেইনে খোলা হলে, আমাদের edge API-কে জিজ্ঞেস করে সাইটটি কোথায়। সেখানে 429 মানে একজন ভিজিটর সাইটে পৌঁছাতে পারছে না।
• একটি চলমান এজেন্ট turn সংরক্ষণ করা। এজেন্ট কাজ করার সময়, তার অগ্রগতি চলতে চলতেই সংরক্ষিত হয়, যাতে রিফ্রেশ বা সংযোগ বিচ্ছিন্ন হলেও উত্তর টিকে থাকে। সেখানে 429 মানে সংরক্ষণ হয়নি এমন অগ্রগতি।
• একটি preview-তে প্রবেশাধিকার যাচাই করা। আপনি যে app বানাচ্ছেন তার preview একটি গেটের পেছনে থাকে, এবং সেই গেট API-কে জিজ্ঞেস করে। সেখানে 429 মানে preview খুলবে না।

এর কোনোটিই মানুষের API কল ছিল না। সবই ছিল আমরা।

কেন এমন হলো

প্রতি-ঠিকানা রেট লিমিট একটি অনুমান করে: একটি ঠিকানা মানে মোটামুটি একজন কলার। মানুষের ক্ষেত্রে এটি যথেষ্ট কাছাকাছি। কিন্তু আমাদের নিজের অবকাঠামোর ক্ষেত্রে এটি সম্পূর্ণ ভুল।

• যে edge সেবা published app ও preview পরিবেশন করে, সে কয়েকটি ভাগ করা outgoing ঠিকানা থেকে API-তে পৌঁছায়। প্রতিটি published app-এর প্রতিটি ভিজিটর এবং প্রতিটি preview check এই কয়েকটি ঠিকানার একটি থেকে এসেছে বলে মনে হয়।
• Orchestrator, অর্থাৎ যে সেবা agent turn চালায়, সে একটি container ঠিকানা থেকে API-তে পৌঁছায়। প্রতিটি চলমান turn, প্রতিটি ব্যবহারকারীর জন্য, সেটি ভাগ করে।

ফলে একজন মানুষের জন্য বরাদ্দ বাজেট পুরো একটি সেবার সব ট্র্যাফিকের মধ্যে ভাগ হচ্ছিল। সেবাগুলো নিজেদের মধ্যে সেটি শেষ করে ফেলছিল, আর লিমিটার যা করার কথা তাই করল: তাদের ফিরিয়ে দিল।

সমাধান

আমাদের নিজের সেবাগুলো আগে থেকেই প্রমাণ করে তারা কে। প্রতিটি অভ্যন্তরীণ কলে একটি অভ্যন্তরীণ token থাকে, এবং API-র অভ্যন্তরীণ অংশের প্রতিটি route কিছু করার আগে সেই token যাচাই করে।

Rate limiter এখন একই যাচাই ব্যবহার করে। যে অনুরোধের token অভ্যন্তরীণ token-এর সঙ্গে মেলে, সেটি একটি allow list-এ থাকে এবং প্রতি-ঠিকানা বাজেটে গণনা হয় না। বাকি সবই আগের মতোই গণনা হয়: প্রতি ঠিকানায় মিনিটে ৩০০ অনুরোধ।

এটিকে ফাঁক হতে না দেওয়ার জন্য দুটি বিষয় ছিল:

1. ভুল token কোনো ছাড় পায় না। Allow list কেবল আসল অভ্যন্তরীণ token-এর সঙ্গেই মেলে। বানানো token-সহ অনুরোধ গণনা হয় ও throttle হয় অন্য যেকোনো অনুরোধের মতো, এবং অভ্যন্তরীণ route গুলো সেটিকে 401 Unauthorized দিয়ে প্রত্যাখ্যান করে।
2. সীমাটি বদলানো হয়নি। জায়গা তৈরি করতে আমরা সংখ্যাটি বাড়াইনি। বাড়ালে সমস্যা কিছুদিনের জন্য লুকিয়ে যেত, ট্র্যাফিক আবার বাড়লে আবার ফিরত, এবং যে ক্ষেত্রে সীমাটি রক্ষা করার কথা, সেখানে সুরক্ষাও দুর্বল হতো।

আমরা লিমিটারের সেটিংগুলো একটি ছোট function-এ সরিয়ে আনলাম এবং সেটির বিরুদ্ধে test লিখলাম। একটি test ৫ অনুরোধে সীমা-সেট একটি লিমিটারে অভ্যন্তরীণ token-সহ ২০টি অনুরোধ পাঠায় এবং আশা করে সবকটি সফল হবে। আরেকটি এক ঠিকানা থেকে সাধারণ অনুরোধ পাঠায় এবং আশা করে প্রথম পাঁচটি সফল হবে, তারপরের গুলো প্রত্যাখ্যাত হবে। তৃতীয়টি জাল token-সহ অনুরোধ পাঠায় এবং আশা করে সেগুলো একইভাবে প্রত্যাখ্যাত হবে।

এ থেকে আমরা যা নিয়েছি

• সীমার মধ্যে অনুমান লুকিয়ে থাকে। “এক ঠিকানা, এক কলার” প্রতি-ঠিকানা সীমার ভেতরে গাঁথা। নিজের সেবাগুলো ভাগ করা ঠিকানার পেছনে বসলেই এটি আর সত্য থাকে না, এবং অনেক সেবাই তা করে: load balancer, edge network, container, অফিস নেটওয়ার্ক।
• নিজের ট্র্যাফিককে ঠিকানা দিয়ে নয়, পরিচয় দিয়ে আলাদা করুন। ঠিকানা হলো ট্র্যাফিক কীভাবে আসে তার উপায়, কে পাঠাল তা নয়। আমাদের কাছে আগে থেকেই এমন credential ছিল যা প্রমাণ করে কল আমাদের, রেট লিমিটার কেবল সেদিকে তাকাচ্ছিল না।
• সংখ্যা বাড়িয়ে ঠিক করবেন না। বড় সীমা কিছুদিনের জন্য 429 থামাত, কিন্তু কম সুরক্ষা দিত এবং পরে আবার ব্যর্থ হতো।
• কে throttle হচ্ছে তা দেখুন। নিজের সেবার উপর পড়া 429 আপনার সীমা সম্পর্কে একটি bug report, লিমিটার ঠিকমতো কাজ করছে তার প্রমাণ নয়।

Mythex-এর উপর যদি আপনি তৈরি করেন তবে এর মানে কী

আপনার দিকে বদলানোর কিছু নেই। কাস্টম ডোমেইনের published app, agent turn ও preview আর Mythex-এর অন্য অংশের ব্যস্ততার উপর নির্ভর করে না। আপনার app-এর নিজস্ব ট্র্যাফিক আপনার app-এর বিষয়: এখানে বর্ণিত সীমা আমাদের API-র উপর, আপনার publish করা app-গুলোর উপর নয়।

নিজের কোনো backend চালালে, আপনার যোগ করা যেকোনো রেট লিমিটে একই ফাঁদ থাকে। API কী এবং AI-তে বানানো app-এর জন্য নিরাপত্তা চেকলিস্ট সম্পর্কে আমাদের গাইডগুলো শুরু করার ভালো জায়গা। আর আমাদের নিজের অবকাঠামো কীভাবে নিজের পথে বাধা হয়ে দাঁড়িয়েছিল তার আরেকটি উদাহরণের জন্য দেখুন কীভাবে আমরা deploy-এর 502 শূন্যে নামিয়েছি।