ইঞ্জিনিয়ারিং

ইঞ্জিনিয়ারিং

Mythex কীভাবে তৈরি ও পরিচালিত হয়, কী ভেঙেছিল আর কীভাবে ঠিক করেছি তা-সহ।

• ব্যর্থ পুনঃপ্রকাশ কখনো চালু থাকা ব্যাকএন্ড মোছে না — ব্যর্থ পুনঃপ্রকাশ একটি অ্যাপের চালু API মুছে ফেলতে পারত, অথবা ভাঙা নতুন সংস্করণ চালু রেখে দিতে পারত। Mythex কীভাবে ব্যর্থ প্রকাশ উল্টে দেয়, তার তিনটি সংশোধন।
• সতর্কবার্তা একবার যায়, প্রতি সার্ভারে একবার নয় — একটি দৈনিক সতর্কবার্তা এক বিকেলে পাঁচবার এসেছিল। ইন-মেমরি ডুপ্লিকেট-রোধ কেন দুই সার্ভারে ভাঙে, এবং শেয়ার্ড স্টেট কীভাবে তা ঠিক করল।
• অপেক্ষা না করিয়ে বড় ওয়ার্কস্পেসে যাওয়া — আমাদের এক-চতুর্থাংশ ওয়ার্কস্পেস ২ GB-তে যাওয়ার পরও ১ GB-তেই আটকে ছিল। প্রথম সমাধানে একজনকে সাত মিনিট অপেক্ষা করতে হয়। আমরা কী বদলালাম, আর আবার কী বদলালাম।
• ডাটাবেসের বিল হোক, তারা আসলে যতটুকু ব্যবহার করে — আমরা আগে প্রতিটি অ্যাপের ডাটাবেস খরচ আন্দাজ করতাম, আর আন্দাজটি দু'দিকেই ভুল ছিল। এখন প্রতিটি ডাটাবেস মাপা ব্যবহার অনুযায়ী, ঘণ্টায় ঘণ্টায় বিল হয়।
• পাবলিশের পরপরই ক্র্যাশ করা অ্যাপ ধরা — তিনটি পাবলিশ আমাদের হেলথ চেক পাস করেছিল, অথচ তাদের API প্রতিটি বুটের কয়েক সেকেন্ড পরেই ক্র্যাশ করছিল। কারণ: পাঁচটি এন্ট্রির তালিকায় ক্র্যাশ গোনা।
• ছবি-ভারী এজেন্ট টার্নকে মেমোরির মধ্যে রাখা — ক্যাটালগ স্ক্যান দেখতে থাকা একটি এজেন্ট টার্ন ৯৫২ MB-তে মেমোরি শেষ করেছিল। তিনটি আলাদা কারণ, প্রতিটি ছবি বেশিক্ষণ ধরে রাখছিল — এবং আমরা কীভাবে ঠিক করেছি।
• দীর্ঘ এজেন্ট টার্নকে প্রসঙ্গ-উইন্ডোর ভেতরে রাখা — সাব-এজেন্ট এত বড় হতো যে মডেল তা ফিরিয়ে দিত, ঘর বাঁচাতে আগেই থামত, আর রুশ ভাষায় টোকেন ভুল গুনত। তিনটি সমাধান, যাতে দীর্ঘ AI কাজ শেষ হয়।
• ফোন ঘুমালেও চ্যাট সচল রাখা — ফোন ঘুমায়, ট্যাব বদলায়, নেটওয়ার্ক হারায় — বিল্ডের মাঝখানে। দুটি বাগ চ্যাটকে আটকে রাখত বা পরে আধখানা উত্তর দেখাত। কীভাবে খুঁজে পেয়ে ঠিক করলাম।
• একটি ভারী চ্যাট কীভাবে আমাদের API বন্ধ করে দিতে পারত — ২৮ সেপ্টেম্বর আমাদের দুটি API সার্ভারের মেমোরি একই সময়ে ফুরিয়ে যায়। প্রথম সমাধান ছিল বেশি মেমোরি; আসল সমাধান ছিল চ্যাট ইতিহাস আকার অনুযায়ী লোড করা।
• Publish দুবার চাপলে এখন একবারই প্রকাশ হয় — একই অ্যাপের তিনটি publish অনুরোধ ৮৪ মিলিসেকেন্ড ব্যবধানে এসে প্রতিটি পূর্ণ deploy চালায়। ডেটাবেস ঠিক করে কে publish করবে, আর বাকিদের সত্যিটা জানানো হয়।
• নিজেদের সাইট ঠিক করে শেখা SEO-র পাঠ — ডুপ্লিকেট FAQ মার্কআপ, Google-এর ভুল থাম্বনেইল, কেউ ক্লিক না করা টেমপ্লেট পেজ, আর আমাদের এজ যে পথ প্রত্যাখ্যান করছিল: mythex.ai-তে যা পেয়েছি ও ঠিক করেছি।
• স্ট্যাটিক সাইট এখন পুনঃপ্রকাশের সময়ও চালু থাকে — স্ট্যাটিক সাইট পুনঃপ্রকাশের সময় আগে পুরো সাইট খালি হয়ে যেত। এখন নতুন সংস্করণ বসা পর্যন্ত পুরনোটি চালু থাকে, আর পরিবর্তন কয়েক সেকেন্ডে দেখা যায়।
• একটি প্রগ্রেস লেবেলে লুকানো মেমোরি-ক্র্যাশ — আমাদের AI এজেন্টের একটি বড় ফাইল লিখতে গিয়ে মেমোরি ফুরিয়ে গিয়েছিল। কারণ মডেল বা সমান্তরাল সাব-এজেন্ট নয় — একটি স্ট্যাটাস লেবেল ৪১,০০০ বার পুনরায় পাঠানো হচ্ছিল।
• সোয়াপ ফাইল না থাকায় যেভাবে আমাদের সার্ভার জমে গিয়েছিল — একটি প্রোডাকশন সার্ভার ক্র্যাশ না করেই সাড়া দেওয়া বন্ধ করে দিয়েছিল। swap ছাড়া বক্সে page-cache থ্র্যাশিং — কী ঘটেছিল আর আমরা কী বদলেছি।
• ঘুম থেকে জেগে ওঠা ডেটাবেস, মৃত connection ছাড়াই — ঘুম থেকে জাগা একটি published app-এর প্রথম অনুরোধ ঘুমানোর সময় মরে যাওয়া database connection-এ ১০–১২ সেকেন্ড আটকে ছিল। কীভাবে আমরা তা ২.৩ সেকেন্ডে নামালাম।
• আমরা নিজেদের সেবাগুলোকে রেট-লিমিট করছিলাম — আমাদের API-র প্রতি-ঠিকানা রেট লিমিট নিজের সেবাগুলোকে একজন ব্যস্ত মানুষের মতো গণ্য করেছিল, ফলে প্রোডাকশনে তারা 429 পেতে শুরু করে। কীভাবে ধরা পড়ল ও ঠিক হলো।
• কেন আমরা Mythex-এর সার্ভার ARM-এ নিয়ে গেলাম — ভারী কাজ প্রতি-প্রজেক্ট sandbox-এ সরানোর পর আমাদের সার্ভার মেমরির এক-তৃতীয়াংশ ব্যবহার করছিল। ছোট ARM instance মাসিক খরচ প্রায় ৩০% কমিয়েছে। কীভাবে।
• কীভাবে ডিপ্লয়ে আমরা 502 এরর শূন্যে নামিয়ে আনলাম — একটি ওয়াচডগ যা আমাদের ডিপ্লয়ের সঙ্গে দৌড়াচ্ছিল এবং একটি লোড ব্যালেন্সার যা দেরিতে টের পেল: দুটিই কীভাবে খুঁজে ঠিক করলাম, ১০টি 502 থেকে শূন্যে মাপলাম।