ভার্টিক্যাল ও হরাইজনটাল স্কেলিং

একটি ওয়েব অ্যাপ্লিকেশন যখন কোনো সার্ভারে রান করে, তখন সেটি মূলতঃ চারটি জিনিসের ওপর নির্ভর করে :

  1. সিপিইউ (CPU) বা প্রসেসিং পাওয়ার
  2. মেমোরি
  3. হার্ড ডিস্ক
  4. নেটওয়ার্ক

screen-shot-2016-11-04-at-12-22-51-pm

তো ওয়েব অ্যাপ্লিকেশনে যখন ট্রাফিক বেড়ে যায়, মানে অনেক ব্যবহারকারী সেই ওয়েব অ্যাপ্লিকেশন ব্যবহার করে, তখন এই চারটি জিনিসের ওপর লোড বাড়ে। কোন অংশে কেমন চাপ পড়বে, সেটি নির্ভর করে অ্যাপ্লিকেশনের ধরনের ওপর। ক্লাউড কম্পিউটিংয়ের যুগে আমরা যখন কোনো ওয়েব অ্যাপ্লিকেশন তৈরি করি, তখন আমাদের প্রয়োজন অনুযায়ী একটি সার্ভার নিয়ে নিই। শুরুর দিকে যেহেতু ব্যবহারকারী খুবই কম থাকে, তাই সার্ভারের কনফিগারেশন কম নেওয়াটাই যুক্তিসঙ্গত (কারণ কনফিগারেশন ভালো হলে খরচও বেশি হবে)। আস্তে আস্তে যখন আমাদের ওয়েব অ্যাপ্লিকেশনের ট্রাফিক বাড়বে, তখন আমরা দেখতে পাবো যে ওয়েব অ্যাপ্লিকেশনটি যেই সার্ভারে চলছে, সেটির সিপিইউ অনেক বেশি ব্যবহার হচ্ছে, কিংবা মেমোরি প্রায় পূর্ণ হয়ে গিয়েছে, কিংবা ডিস্কের স্পেস প্রায় শেষ হয়ে আসছে, অথবা নেটওর্য়ার্কের ব্যান্ডউইডথ পূর্ণ ব্যবহার হয়ে যাচ্ছে। এই সমস্যাগুলোর যেকোনো একটি বা একাধিক সমস্যায় আমরা পরতে পারি। এখন এরকম সমস্যা হলে আমরা সার্ভারের কনফিগারেশন বাড়াতে পারবো, একে বলে স্কেল (scale) করা। মানে আরো প্রসেসিং ক্ষমতা, আরো বেশি মেমোরি, আরো বেশি ডিস্ক স্পেস, ব্যান্ডউইডথ এসব যুক্ত করা। ক্লাউড কম্পিউটিংয়ের কল্যাণে এই স্কেল করার কাজটি এখন বেশ সহজ ও ঝামেলামুক্ত। এই স্কেলিং মূলত দুই প্রকার –

  1. ভার্টিক্যাল স্কেলিং (Vertical Scaling)
  2. হরাইজনটাল স্কেলিং (Horizontal Scaling)

ভার্টিক্যাল শব্দের বাংলা অর্থ উল্লম্ব বা খাড়া। এখন আমরা একটি বিল্ডিংয়ের কথা চিন্তা করতে পারি। আমরা ১০০ তলা ফাউন্ডেশন দিয়ে একটি বিল্ডিং তৈরি করলাম, কিন্তু শুরুতে মাত্র দশ তলা তৈরি করা হলো। তারপরে আস্তে আস্তে যখন চাহিদা বাড়তে লাগল, তখন সেই বিল্ডিংকে আমরা আরো ওপরের দিকে বাড়াতে পারবো। এটিই হচ্ছে ভার্টিক্যাল স্কেলিং। সার্ভারে ভার্টিক্যাল স্কেলিংয়ের ক্ষেত্রে আমরা আরো উন্নত কনফিগারেশনের সার্ভার ব্যবহার করবো। আমরা যদি অ্যামাজন ওয়েব সার্ভিসের ইসি২ (ec2) ইনস্ট্যান্স টাইপের কথা বিবেচনা করি, সেখানে সর্বনিম্ন কনফিগারেশনের সার্ভার হচ্ছে টি২ ন্যানো (T2 nano) যেখানে মাত্র একটি ভার্চুয়াল সিপিইউ ও মাত্র ৫১২ মেগাবাইট মেমোরি রয়েছে। আবার x1.32xlarge টাইপের সার্ভারে ১২৮টি ভার্চুয়াল সিপিইউ, ১৯৫২ গিগাবাইট মেমোরি রয়েছে। https://aws.amazon.com/ec2/instance-types/ লিঙ্কে গেলে বিস্তারিত জানা যাবে এবং আমরা আমাদের প্রয়োজনমতো কনফিগারেশনের সার্ভার ব্যবহার করতে পারবো, যখন খুশি তখন! তো এই ধরনের স্কেলিংয়ের সুবিধা হচ্ছে, স্কেলিং করা খুব সহজ, অতিরিক্ত কোনো ডিজাইন বা কাজের তেমন প্রয়োজন পড়ে না। আর সীমাবদ্ধতা হচ্ছে সেই ১০০ তালা বিল্ডিংয়ের মতো। যেখানে আমরা স্কেল করতে পারবো ১০০ তলা পর্যন্ত।

আর হরাইজনটাল মানে আনুভূমিক (সহজ বাংলায় বললে সরলরৈখিক বা বরাবর)। ধরা যাক, আমার বিশাল জায়গা রয়েছে। সেখানে একটি দশ তলা বিল্ডিং তৈরি করলাম। এখন আমাকে আরো মানুষের জায়গা দিতে হবে। আমি তখন আরেকটি দশ তলা বিল্ডিং তৈরি করলাম। এভাবে চাহিদা যত বাড়তে থাকবে, আমি ততগুলো বিল্ডিং তৈরি করতে পারবো। অ্যামাজনের ওয়েব সার্ভিস (AWS) ব্যবহার করে এই কাজটি করা যায়। সেখানে আমি লোড ব্যালেন্সার (ELB -> Elastic Load Balancer) ব্যবহার করে বলে দিতে পারি যে সর্বনিম্ন কয়টি ও সর্বোচ্চ কয়টি ইনস্ট্যান্স (সার্ভার) চলবে, এবং তারপরে কিছু নিয়মকানুন বলে দিতে হবে। নিয়মকানুনগুলো এরকম হতে পারে যে, সিপিইউ লোড ৭০% এর চেয়ে বেশি হলে আরো একটি ইনস্ট্যান্স চালু হবে। কিংবা মেমোরি ৮০% এর চেয়ে বেশি হলে আরো একটি ইনস্ট্যান্স চালু হবে। একে বলে স্কেল আপ (scale up)। আবার সিপিইউ লোড ৪০% এর চেয়ে কম হলে এবং মেমোরির ব্যবহার ৫০% এর চেয়ে কম হলে একটি ইনস্ট্যান্স বা সার্ভার বন্ধ করে দেওয়া হবে। একে বলে স্কেল ডাউন (scale down)। এই রুলসগুলো সেট করে দিলে কাজগুলো স্বয়ংক্রিয়ভাবেই হবে। হরাইজনটাল স্কেলিংয়ের সুবিধা হচ্ছে এক্ষেত্রে অনেক বেশি লোড সামাল দেওয়া যায়, এবং যেহেতু স্কেল আপ ও ডাউনের সুবিধা আছে, তাই যখন লোড বেশি তখন বেশি ইনস্ট্যান্স ব্যবহৃত হবে, লোড কম থাকলে কম সংখ্যক ইনস্ট্যান্স ব্যবহৃত হবে। তাই খরচও কম পড়বে অনেক। আর অসুবিধা হচ্ছে এখানে কিছু কনফিগারেশনের ব্যাপার আছে আর আর্কিটেকচারও অন্যভাবে ডিজাইন করতে হবে। অর্থাৎ এক্ষেত্রে একটু লেখাপড়া, জ্ঞানার্জন ও অভিজ্ঞতার প্রয়োজন।

পাদটীকা :

  • ক্লাউডভিত্তিক ওয়েব আর্কিটেকচার সম্পর্কে আরো জানতে হলে গুগলে সার্চ করে বিভিন্ন ব্লগ ও আর্টিকেল পড়তে হবে, ভিডিও দেখতে হবে।
  • অ্যামাজন ছাড়া গুগল, আলিবাবা ও মাইক্রোসফটেরও ক্লাউড সার্ভিস রয়েছে।
  • ওয়েব সম্পর্কে বেসিক ধারণা পাকাপোক্ত করার জন্য রয়েছে দ্বিমিক কম্পিউটিংয়ের ফ্রি অনলাইন কোর্স – ওয়েব কনসেপ্টস্

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

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

 

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

 

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

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

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

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

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

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

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

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

 

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

 

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

 

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

cloud-arch1

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

 

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

 

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

 

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

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

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

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

webarch

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

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

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