OpenAI-এর ChatGPT বন্ধ: একটি নতুন মনিটরিং টুলের ভুল কনফিগারেশনের ফলে বিপর্যয়


১১ ডিসেম্বর, OpenAI এর পুরো সিস্টেম ৪ ঘণ্টারও বেশি সময় ধরে বন্ধ ছিল। এতে বন্ধ ছিলো: - ChatGPT - API Services - Sora কিন্তু কেন? - কোনো cyber attack?? - নতুন features এ কোনো software bug?? না, এটি ঘটেছিল একটি নতুন monitoring tool আপডেটের এর কারণে! - যা আসলে system reliability বাড়ানোর জন্যই ডিপ্লয় করা হয়েছিল!!! এমন কেন হলো? একটা সহজ উদাহরণ দিয়ে বুঝি - কল্পনা করুন একটা বড় school cafeteria, যেখানে হঠাৎ করে প্রতিটি ছাত্রকে বলা হলো অন্য সবার নাম রেকর্ড করতে। একটা ছোট ক্লাসরুমে এটা সম্ভব হতে পারে, কিন্তু হাজার হাজার ছাত্র থাকা ক্যাফেটেরিয়ায় এটা অসম্ভব হয়ে পড়বে। কেন? সবাই সবাইকে নাম জিজ্ঞেস করবে। এক জনের মিলিয়ন মানুষকে নাম জিজ্ঞেস করতে হবে। আবার আরেকজনের মিলিয়ন মানুষকে নাম জিজ্ঞেস করতে হবে। চিন্তা করুন কি হারে কম্পেক্সিটি বাড়ছে? আসল 𝘁𝗲𝗰𝗵𝗻𝗶𝗰𝗮𝗹 কারণটা কী ছিল? OpenAI তাদের Kubernetes clusters এ একটা নতুন telemetry সার্ভিস ডিপ্লয় করেছিল। এই সার্ভিস টি Kubernetes control plane সম্পর্কে metrics কালেক্ট করার জন্য configure করা হয়েছিল। কিন্তু কনফিগারেশন এর কারণে cluster এর প্রতিটি node resource-intensive API কল করতে শুরু করে। যত বড় cluster, তত বেশি computational power resource intensive API call। তত বেশি লোড। নতুন সার্ভিসটি বেশি computational power ব্যবহার করেছে infrastructure এ চাপ সৃষ্টি করেছে। সমস্যাটা তিনভাবে হয়: ১. Telemetry service এর কারণে হাজার হাজার node থেকে একসাথে API request যায় ২. Cluster যত বড়, প্রতিটি request এর complexity ততই বাড়ে ৩. DNS caching এর কারণে প্রথমে সমস্যাটা ধরা পড়েনি, যার ফলে problematic deployment টা ছড়িয়ে পড়ে (এটা নিয়ে বিস্তারিত পরে বলব) কিন্তু কেন এটা টেস্টিং এ ধরা পড়লো না? কেন এটা প্রোডাকশনে গিয়ে ধরা পড়ল? প্রথমত, Testing environment আর Production environment এর মধ্যে অনেক পার্থক্য থাকে। Testing environment এ যেখানে কয়েক হাজার request handle করা হয়, Production এ সেখানে মিলিয়ন মিলিয়ন request handle করতে হয়। OpenAI এর ক্ষেত্রে প্রতি সেকেন্ডে লাখ লাখ request handle করতে হয়। Testing environment এ এত বড় scale এ টেস্ট করা প্রায় অসম্ভব। দ্বিতীয়ত, Monitoring tool নিজেই system এর performance monitor করে। তাই এই tool নিজের performance টেস্ট করা একটা চ্যালেঞ্জিং ব্যাপার। এটা অনেকটা নিজের চোখ দিয়ে নিজের চোখ দেখার মতো! কীভাবে ঠিক করা হলো? লোডের কারণে সিস্টেমেই ঢুকা যাচ্ছিল না। সিস্টেমে ঢুকতে পারলে সহজেই এর সমাধান হত। তাই প্রথম কাজ ছিলো লোড কমানো। কিভাবে? ১. Cluster scale-down করে Kubernetes API load কমানো হয় ২. Kubernetes admin API access block করে নতুন expensive requests আটকানো হয় ৩. API server resources বাড়িয়ে pending requests handle করা হয় শেষমেশ সিস্টেমে ঢুকে সমস্যা সমাধান করা যায়। এই incident থেকে বড় শিক্ষাটা হলো - distributed systems এ simple changes ও catastrophic failure আনতে পারে। তাই large-scale systems এ যেকোনো পরিবর্তন খুব সাবধানে, gradually করা উচিত। emergency procedures সব সময় ready রাখা উচিত। &Infra

Similar News
গুরুত্বপূর্ণ! Chrome-এর নিরাপত্তা আপডেট: ডেটা রক্ষা করুন

গুরুত্বপূর্ণ নিরাপত্তা ত্রুটি সংশোধন করে গুগল ক্রোমের নতুন আপডেট প্রকাশিত হয়েছে। এটি ডেটা চুরি ও সিস্টেমের ঝুঁকি কমাবে এবং ব্রাউজারের স্থিতিশীলতা বাড়াবে। অবিলম্বে আপডেট করুন! ...

1 week ago

Read more
CIRT Infra Team Celebrates Shantanu Dey Anik's Success and Farewell

The CIRT Infra team celebrated a memorable October evening with a delicious buffet. We honored Shantanu Dey Anik's impressive career growth and wished him well as he embarks...

1 week ago

Read more
২০২৪-এর প্রধান অনলাইন প্রতারণা: সতর্কতা ও প্রতিরোধ

২০২৪ সালে এআই-চালিত ব্যক্তিগতকৃত প্রতারণা, শিক্ষা ঋণ মওকুফ, ক্রিপ্টোকারেন্সি, ফোন কল, চাকরি ও সরকারি সহায়তা নামে ছদ্মবেশে প্রতারণার ঝুঁকি বৃদ্ধি পেয়েছে। সতর্কতা ও যাচাইয়ের মাধ্যমে নিরাপদ থাকুন। ...

2 weeks ago

Read more
৭-জিপের গুরুতর নিরাপত্তা ঝুঁকি: অবিলম্বে আপডেট করুন!

৭-জিপে গুরুতর নিরাপত্তা ত্রুটি (CVE-2024-11477) আবিষ্কৃত হয়েছে। অবিলম্বে 24.07 সংস্করণে আপডেট করুন; অন্যথায় ক্ষতিকারক কোড চালানোর ঝুঁকি রয়েছে। ...

1 month ago

Read more

Posted by Hamayoun Kabir Hemel, 4 days ago