ওয়েবসাইট বিপর্যয় ও মুক্তির উপায় – পর্ব ২

প্রথম পর্বের লিঙ্ক : http://subeen.com/?p=28

 

২০১১ সালের ডিসেম্বর মাসে সাস্ট (SUST) থেকে শিক্ষক রুহুল আমিন সজীবের নেতৃত্বে একটি দল ঢাকায় আসে প্রায় দুই সপ্তাহের জন্য। মিশন জাতীয় বিশ্ববিদ্যালয়ের ভর্তি পরীক্ষার ফলাফল প্রসেস করে রেজাল্ট তৈরি করা। চার লক্ষ পরীক্ষার্থীর জন্য এই কাজটি এক বিশাল আয়োজন। এর মধ্যে একটি ছোট্ট অংশ হচ্ছে রেজাল্ট তৈরি করার পরে সেটি ওয়েবসাইটে প্রকাশ করা।

 

সজীবকে বললাম, ‘সজীব, চল ওয়েবসাইটটা ক্লাউডে হোস্ট করি, আর এমনভাবে করি যেন সেটা ডাউন না হয়।

সজীব উত্তর দিল, ‘আরে সুবিন ভাই, সব ব্যবস্থা করে ফেলছি, রেকস্পেস ক্লাউড সাইটে ওয়েবসাইট হোস্ট করবো, সেটা অনেক লোড সামলাতে পারবে

– ‘লোড সামলাতে পারলে ভালো, কিন্তু সেটা তো যথেষ্ট নয়। ডাটাবেজ কানেকশনতো একটা মূল ইস্যু।

– ‘তাহলে কী করতে বলেন?’

– ‘মেমক্যাশ (memcached) ব্যবহার করি।

– ‘কোনো সমস্যা হবে না?’

– ‘না, সমস্যা নাই, সবার রেজাল্ট মেমোরিতে ক্যাশ করা থাকবে, আর কোনো কারণে সেটা ফেইল করলে মাইএসকিউএল ডাটাবেজ থেকে রেজাল্ট আনা হবে।

– ‘ঠিক আছে, আপনে যা ভালো বুঝেন করেন। আর টাকাপয়সা সমস্যা না, সার্ভারে যত টাকা খরচ করতে হয় করবো, আপনে খালি দেখবেন, মানইজ্জত যেন না ডুবে।

 

আমি খুশিমনে তিনদিনের জন্য ওদের সাথে থেকে গেলাম।

 

নতুন সিস্টেমের আর্কিটেকচার: আমরা সিদ্ধান্ত নিলাম, ক্লাউড সাইটের পেছনে আটটি সার্ভার ব্যবহার করবো। প্রতিটি সার্ভারে সব পরীক্ষার্থীর ফলাফল থাকবে। ফলাফল প্রতিটি সার্ভারের ডাটাবেজে (এক্ষেত্রে MySQL) থাকবে। সেই সাথে প্রতিটি সার্ভারে মেমক্যাশ ইনস্টল করা হবে এবং মেমক্যাশেও সবার রেজাল্ট লোড করা থাকবে।

 

এখন আমরা যে আটটি সার্ভার ব্যবহার করবো, সেখানে কখন কোন সার্ভারে রিকোয়েস্ট যাবে, সেটা নির্ধারণ করা হবে কীভাবে? আমরা সহজ একটা সিদ্ধান্তে আসলাম। একটা ভেরিয়েবল N নেই। N-এর মান ৮। N ভেরিয়েবল হওয়ার সুবিধা হচ্ছে আমরা ইচ্ছামতো সার্ভার মূল সিস্টেমে যুক্ত করতে পারবো, আবার বাদও দিতে পারবো। এখন পরীক্ষার্থীদের রোল নাম্বারকে ৮ দিয়ে মড করা হবে (মড করলে সেটা হবে ০ থেকে ৭এর ভিতরে)। মড করলে যেই সংখ্যাটি পাওয়া যাবে তার সাথে ১ যোগ করে তত নম্বর সার্ভারে রিকোয়েস্ট করা হবে। তাহলে প্রতিটি সার্ভারকে গড়ে ৫০ হাজার স্টুডেন্টের ফলাফল প্রসেস করতে হবে, যেহেতু মোট পরীক্ষার্থী ৪ লক্ষ! লোড অনেক কমে গেলো।

cloud-arch1

তারপরে কাজ হচ্ছে প্রতিটি সার্ভার যেন একসাথে যত বেশি সম্ভব রিকোয়েস্ট হ্যান্ডেল করতে পারে। সার্ভারগুলোয় ওয়েব সার্ভার হিসেবে এপাচি (Apache) ইনস্টল করা ছিলো। সেটার কনফিগরেশন ফাইল এদিকসেদিক করে দেখলাম আগের চেয়ে বেশি রিকোয়েস্ট হ্যান্ডেল করা যাচ্ছি। কিন্তু আমি জানতাম যে ইঞ্জিনএক্স নামে আরেকটি ওয়েব সার্ভার আছে যেটা আরো বেশি কনকারেন্ট (concurrent) রিকোয়েস্ট হ্যান্ডেল করতে পারে। তাই এপাচি বাদ দিয়ে ইঞ্জিনএক্স (Nginx) ইনস্টল করলাম। সেটার কনফিগারেশন ফাইল একটু এদিকসেদিক করলাম। পরীক্ষা করে দেখলাম এপাচির চেয়ে ৫ গুণ বেশি কনকারেন্ট রিকোয়েস্ট হ্যান্ডেল করা যাচ্ছিল। সার্ভারের সবকিছু সিদ্ধান্ত চূড়ান্ত করে সেগুলো দেখাশোনার দায়িত্ব পড়ল সাস্টের ছাত্র শিব্বির হোসেনের উপর।

 

তারপরে সব সার্ভারে মেমক্যাশ ইনস্টল করা হলো। পিএইচপি স্ক্রিপ এমনভাবে লেখা হলো যে কোনো স্টুডেন্টের রেজাল্টের জন্য রিকোয়েস্ট আসলে সেটি প্রথমে মেমোরিতে খোঁজা হবে (মেমক্যাশে)। যদি পাওয়া যায়, তাহলে সেটি প্রসেস করে পাঠিয়ে দেওয়া হবে, আর পাওয়া না গেলে ডাটাবেজে কুয়েরি করা হবে এবং সেটি মেমক্যাশে সেভ করে রেখে তারপরে পাঠিয়ে দেওয়া হবে। এটি একটি বাড়তি নিরাপত্তা আর কী। কারণ রেজাল্ট একবার তৈরি হয়ে গেলে সেখানে পরিবর্তনের সম্ভাবনা খুবই কম। বিকাশ (সাস্টের শিক্ষক আবু নাসের বিকাশ) পিএইচপির কোড করেছিল। সে তো মেমক্যাশের পারফরমেন্স দেখে হতবাক এবং আনন্দিত!

 

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

 

এখন শেষ আরেকটা ইস্যু। সজীব বললো, ‘সুবিন ভাই, ক্লাউড সাইট কিন্তু শুরুতে বেশি রিকোয়েস্ট হ্যান্ডেল করতে পারে না। লোড যখন বেশি পড়ে তখন সেটা অটোমেটিক একটা উন্নত পারফরম্যান্সের সার্ভারে ট্রান্সফার হয়। তাই শুরুতে রেজাল্ট দেখায় একটু সমস্যা হতে পারে, তবে কয়েক ঘণ্টা পরে ঠিক হয়ে যাবে। আমি বললাম, ‘এটা শুরু থেকেই ঠিক করে দেই। তাওয়া গরম করার ব্যাপারই তো।আমরা একটা স্ক্রিপ্ট লেখে অনেকগুলো সার্ভারে আর আমাদের ল্যাপটপে চালিয়ে দিলাম। স্ক্রিপ্টের কাজ ছিল ওয়েবসাইটে অটোমেটিক হিট করতে থাকা। তাওয়া গরম হয়ে গেল‌ো! আমরা রাত ১১টায় ওয়েবসাইটে রেজাল্ট পাবলিশ করলাম। আমার মনে আছে রাত ১টা থেকে ২টার মধ্যে দুই লক্ষ হিট হয়েছিল। এত রাতে লোকজনের ওয়েবসাইটে রেজাল্ট দেখার আগ্রহ দেখে অবাক হলাম। তো আমরা সিস্টেম সার্বক্ষণিক মনিটর করছিলাম। প্রথম দিনে এক মিলিয়ন (দশ লক্ষ) হিট হয়েছিল। দ্বিতীয় দিনের শেষে আমরা আটটি সার্ভারের মধ্যে ছয়টি বাদ দিয়ে কেবল দুইটি রাখি কারণ তখন একসাথে আর খুব বেশি হিটের সম্ভাবনা নাই। শেষমেষ আমাদের কাজটি সফল হয়েছিল। প্রথমদিনে আমাদের সিস্টেম এক সেকেন্ডের জন্যও ডাউন হয় নি। ৭২ ঘণ্টার সফল পরিশ্রম শেষে আনন্দ নিয়ে বাসায় চলে আসলাম। সজীব ও তাঁর দলকে ধন্যবাদ এমন একটি গুরুত্বপূর্ণ কাজে আমাকে কাজ করার সুযোগ করে দেওয়ার জন্য।

ওয়েবসাইট বিপর্যয় ও মুক্তির উপায় – পর্ব ১

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

এই সমস্যা হওয়ার কারণ হচ্ছে ওয়েবসাইটের আর্কিটেকচার। সাধারণত ওয়েবসাইটগুলো বানানো হয় এভাবে : সবার পরীক্ষার ফলাফল ডাটাবেজে সংরক্ষিত থাকে। ওয়েবসাইটে কোনো ফর্ম সাবমিট করা হলে (যেমন বোর্ড এবং রোল নাম্বার সিলেক্ট করে সাবমিট করলে) সেই রিকোয়েস্ট সার্ভারের কাছে যায়। সার্ভার তখন ডাটাবেজে কুয়েরি করে রেজাল্ট আনে নিজের কাছে। তারপর সেটা প্রসেসিং করে পাঠিয়ে দেয়। তখন ব্যবহারকারি ওয়েবসাইটে পরীক্ষার ফল দেখতে পারে।

webarch

এখানে দুটো জিনিস লক্ষ করতে হবে। ওয়েবসাইট থেকে রিকোয়েস্ট প্রথমে যখন সার্ভারের কাছে যায়, সেখানে একটি ওয়েব অ্যাপ্লিকেশন সার্ভার (যেমন : এপাচি কিংবা ইঞ্জিন-এক্স) সেটি হ্যান্ডেল করে। সেই ওয়েব অ্যাপ্লিকেশন সার্ভারের রিকোয়েস্ট হ্যান্ডেল করার একটি ক্যাপাসিটি থাকে, যেই ক্যাপাসিটির বেশি রিকোয়েস্ট সে হ্যান্ডেল করতে পারে না। দ্বিতীয়ত হচ্ছে ডাটাবেজ সার্ভার (যেমন : মাইএসকিউএল, পোস্টজিআরই এসকিউল, ওরাকল)। সেটিরও রিকোয়েস্ট বা কানেকশন হ্যান্ডেল করার একটা সীমা থাকে। একই সাথে একটি নির্দিষ্ট সংখ্যক কানেকশনের বেশি সে হ্যান্ডেল করতে পারে না। তাই ফলাফল প্রকাশের পর যখন লাখ লাখ পরীক্ষার্থী ও তাদের অভিভাবক ওয়েবসাইটে ফল দেখার চেষ্টা করতে থাকে, সার্ভারের ওপর তৈরি হয় প্রচন্ড চাপ, যেই চাপ সে সামলাতে পারে না এবং ওয়েবসাইটি থেকে আর ফলাফল দেখা সম্ভব হয় না।

এই সমস্যা থেকে মুক্তি পাওয়ার উপায় কী? উপায় হচ্ছে ডিসট্রিবিউটেড কম্পিউটিং (distributed computing), যা ক্লাউড কম্পিউটিং (cloud computing) ব্যবহার করে সহজে করা যায়। আগামী পর্বে লিখব ২০১১-২০১২ সালের জাতীয় বিশ্ববিদ্যালয়ের ভর্তি পরীক্ষার ফল প্রকাশের ওয়েবসাইটের জন্য  ক্লাউড কম্পিউটিং ব্যবহারের অভিজ্ঞতার কথা।

দ্বিতীয় পর্ব পড়তে এখানে ক্লিক করুন