Vertical vs Horizontal Scaling
- ●Vertical scaling (scale up) মানে একই server-কে আরও শক্তিশালী বানানো — বেশি CPU, RAM, disk।
- ●Horizontal scaling (scale out) মানে আরও অনেক server যোগ করে কাজ ভাগ করে দেওয়া।
- ●Vertical সহজ কিন্তু একটা সীমা ও single point of failure আছে; Horizontal জটিল কিন্তু প্রায় unlimited ও fault-tolerant।
সমস্যাটা কী?
ধরো তুমি একটা e-commerce site বানিয়েছ। শুরুতে দিনে ১০০ জন আসত, একটা মাঝারি server দিব্যি সামলাত। কিন্তু একটা ভাইরাল ক্যাম্পেইনের পর এখন একসাথে ৫০,০০০ মানুষ ঢুকছে। Server ঘেমে-নেয়ে একশা, page লোড হতে ১৫ সেকেন্ড, মাঝে মাঝে crash।
এখন তোমার সামনে দুটো রাস্তা:
- যে server আছে সেটাকেই আরও শক্তিশালী বানাও — বেশি RAM, বেশি CPU। একে বলে Vertical Scaling (scale up)।
- আরও কয়েকটা server এনে কাজ ভাগ করে দাও — একে বলে Horizontal Scaling (scale out)।
দুটোই কাজ করে, কিন্তু খরচ, জটিলতা আর নির্ভরযোগ্যতার দিক থেকে সম্পূর্ণ আলাদা। চলো বুঝি।
প্রথমটা: Vertical Scaling (Scale Up)
Vertical Scaling মানে একই machine-কে আরও বড়, আরও শক্তিশালী করা। আগে ছিল 4 CPU + 8GB RAM, এখন বানালে 32 CPU + 128GB RAM। কাজটা অনেকটা ছোট গাড়ি বদলে বড় ইঞ্জিনের গাড়ি নেওয়ার মতো — গাড়ি একটাই, শুধু ক্ষমতা বাড়ল।
সুবিধা:
- সহজ। কোনো code বদলাতে হয় না। তোমার application জানেও না যে hardware বদলেছে।
- কোনো distributed জটিলতা নেই। একটাই machine, একটাই database — data কোথায় আছে, কোন server কী জানে — এসব মাথাব্যথা নেই।
- ছোট ও মাঝারি load-এ এটাই সবচেয়ে কম পরিশ্রমের সমাধান।
অসুবিধা:
- একটা সীমা (hard limit) আছে। তুমি একটা machine-এ অসীম RAM/CPU লাগাতে পারবে না। বাজারে সবচেয়ে বড় server-ও একসময় ফুরিয়ে যায়।
- খরচ লাফিয়ে বাড়ে। ছোট থেকে মাঝারি হওয়া সস্তা, কিন্তু সবচেয়ে বড় machine-গুলোর দাম অস্বাভাবিক বেশি — দ্বিগুণ ক্ষমতার জন্য তিন-চারগুণ দাম।
- Single Point of Failure। একটাই machine মানে সেটা crash করলে পুরো system বন্ধ। Single Point of Failure = এমন একটা component যেটা ফেল করলে গোটা system পড়ে যায়।
- Upgrade করতে গেলে প্রায়ই server বন্ধ করতে (downtime) হয়।
দ্বিতীয়টা: Horizontal Scaling (Scale Out)
Horizontal Scaling মানে একটা বড় machine-এর পেছনে না ছুটে, অনেকগুলো সাধারণ machine যোগ করা এবং তাদের মধ্যে কাজ ভাগ করে দেওয়া। ৫টা মাঝারি server মিলে যা সামলায়, একটা দানব server-এর চেয়ে সেটা প্রায়ই সস্তা ও নিরাপদ। এই সাধারণ, সস্তা machine-গুলোকে বলে Commodity Hardware।
কিন্তু একটা প্রশ্ন: ৫টা server থাকলে কোন user-এর request কোন server-এ যাবে, ঠিক করে কে? এখানেই আসে Load Balancer — সামনে দাঁড়িয়ে সব request নিয়ে নিচের server-গুলোর মধ্যে সমানভাবে বিলি করে দেয়।
সুবিধা:
- প্রায় unlimited scale। ১০ জন বাড়লে আরও server যোগ করো — তাত্ত্বিকভাবে কোনো ছাদ নেই।
- Fault tolerance। একটা server মরে গেলে load balancer বাকিদের দিকে request পাঠায়, user টেরও পায় না।
- খরচ মসৃণভাবে বাড়ে। ঠিক যতটুকু দরকার ততটুকু server যোগ করো; চাপ কমলে সরিয়ে নাও (auto-scaling)।
অসুবিধা:
- জটিলতা বেশি। Load balancing, data কোথায় থাকবে, server-গুলোর মধ্যে state share — এসব ঠিক করতে হয়।
- State সামলানো কঠিন। User-এর login session যদি কোনো এক server-এ আটকে থাকে, পরের request অন্য server-এ গেলে সমস্যা। (তাই stateless design লাগে।)
কল্পনা করো একটা ব্যাঙ্কের শাখায় একজনই ক্যাশিয়ার, কিন্তু লাইনে ৫০ জন। Vertical scaling হলো সেই একজন ক্যাশিয়ারকে দ্রুততর, চটপটে বানানো — কিন্তু একজন মানুষ কতটাই বা দ্রুত হতে পারে! আর তিনি অসুস্থ হলে পুরো শাখা বন্ধ। Horizontal scaling হলো আরও ৫টা কাউন্টার খুলে দেওয়া আর সামনে একজন গাইড (load balancer) রাখা, যিনি বলেন "আপনি ৩ নম্বরে যান, আপনি ৫ নম্বরে।" একজন ক্যাশিয়ার ছুটি নিলেও বাকিরা চালিয়ে নেয়।
পাশাপাশি তুলনা
| বিষয় | Vertical Scaling (Scale Up) | Horizontal Scaling (Scale Out) |
|---|---|---|
| পদ্ধতি | একটা machine বড় করা | অনেক machine যোগ করা |
| সর্বোচ্চ সীমা | আছে (hardware limit) | প্রায় নেই |
| খরচের ধরন | বড় হলে লাফিয়ে বাড়ে | মসৃণভাবে বাড়ে |
| Fault tolerance | কম (single point of failure) | বেশি (একটা মরলে বাকিরা চলে) |
| জটিলতা | কম, code বদলাতে হয় না | বেশি, load balancer + state সামলানো |
| Downtime | upgrade-এ লাগতে পারে | নতুন server যোগে কোনো downtime নেই |
| উপযুক্ত কখন | ছোট/মাঝারি load, দ্রুত সমাধান | বড়, বাড়তে থাকা traffic |
কখন কোনটা বেছে নেবে
- শুরুতে vertical দিয়েই শুরু করো। কম traffic-এ horizontal scaling-এর জটিলতা টানা অপচয়। একটা ভালো server অনেক দূর নিয়ে যায়।
- Traffic বড় ও অনিশ্চিত হলে horizontal-এ যাও। যখন একটা machine আর কুলোয় না, বা একটা machine মরলে business বন্ধ হয়ে যায় — তখন scale out-ই একমাত্র টেকসই পথ।
- বাস্তবে বেশিরভাগ বড় system দুটোই ব্যবহার করে: প্রতিটা server মোটামুটি শক্তিশালী (vertical), আর এমন অনেক server (horizontal)।
সবচেয়ে সাধারণ ভুল: শেষ মুহূর্ত পর্যন্ত অপেক্ষা করে আরও বড় machine কেনা। যখন একটা single machine-ই সব ধরে রাখে, সেটা একসময় ছাদে ঠেকে এবং তখন রাতারাতি horizontal-এ যাওয়া কঠিন — কারণ তোমার code stateless না হলে ভাঙবে। বড় হওয়ার পরিকল্পনা থাকলে আগে থেকেই stateless ও horizontally scalable করে রাখো।
বাস্তব উদাহরণ
- Netflix, Amazon, Google — সম্পূর্ণ horizontal। হাজার হাজার commodity server, সামনে load balancer। একটা একটা করে server মরা স্বাভাবিক ঘটনা, system টের পায় না।
- অনেক traditional database (PostgreSQL, MySQL-এর primary node) দীর্ঘদিন vertical-ই বেশি পছন্দ করত, কারণ একটা database-কে অনেক machine-এ ভাগ করা (sharding) কঠিন।
- Stack Overflow বছরের পর বছর তুলনামূলক কম কিন্তু খুব শক্তিশালী server (vertical-ঘেঁষা) দিয়ে বিশাল traffic সামলেছে — প্রমাণ যে scale up এখনও বহু ক্ষেত্রে যথেষ্ট।
Interview-তে "কীভাবে scale করবে?" জিজ্ঞেস করলে শুধু "আরও server যোগ করব" বোলো না। বলো: "প্রথমে দেখব bottleneck কোথায়। সহজ হলে vertical scaling দিয়ে দ্রুত সমাধান দেব। কিন্তু fault tolerance ও বড় growth-এর জন্য আমি stateless application + load balancer + horizontal scaling-এর দিকে যাব, কারণ এতে single point of failure থাকে না।" — এই উত্তরে trade-off বোঝার ছাপ স্পষ্ট।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. Horizontal scaling বলতে কী বোঝায়?
2. Vertical scaling-এর বড় দুর্বলতা কোনটি?
3. Horizontal scaling-এ অনেক server-এর মধ্যে request ভাগ করে কে?