Autoscaling
- ●Autoscaling মানে load অনুযায়ী স্বয়ংক্রিয়ভাবে resource বাড়ানো বা কমানো — খরচ ও performance-এর ভারসাম্য।
- ●Horizontal scaling (instance সংখ্যা বাড়ানো) সাধারণত vertical (একটি মেশিন বড় করা)-র চেয়ে বেশি resilient ও সীমাহীন।
- ●Metric-based reactive scaling সাধারণ, কিন্তু warm-up সময় ও predictive scaling বিবেচনা না করলে spike সামলানো কঠিন।
সমস্যাটা কী?
তোমার অ্যাপের traffic সারাদিন এক রকম থাকে না। সকালে কম, দুপুরে মাঝারি, সন্ধ্যায় তুমুল ভিড়, রাতে আবার কম। আর বিশেষ দিনে (ঈদের অফার, সেল) হঠাৎ ১০ গুণ traffic আসতে পারে।
এখন তুমি কত server রাখবে? সবচেয়ে বেশি traffic-এর জন্য যথেষ্ট server সবসময় চালু রাখলে — রাতে আর কম-traffic সময়ে সেই server গুলো অলস বসে থাকবে, কিন্তু বিল ঠিকই দিতে হবে। আবার কম server রাখলে — সেল-এর দিন site crash করবে।
মানুষ হাতে হাতে server বাড়ানো-কমানো করতে পারে না; বিশেষ করে রাত ৩টায় হঠাৎ spike এলে। দরকার একটা স্বয়ংক্রিয় ব্যবস্থা যা load বুঝে নিজে থেকেই resource বাড়াবে-কমাবে। এটাই Autoscaling।
মূল ধারণা
Autoscaling হলো এমন একটি প্রক্রিয়া যেখানে অ্যাপ্লিকেশনের বর্তমান load বা metric অনুযায়ী স্বয়ংক্রিয়ভাবে computing resource বাড়ানো বা কমানো হয়।
মূল লক্ষ্য একটা ভারসাম্য — যথেষ্ট resource থাকবে যাতে performance ভালো থাকে, কিন্তু অতিরিক্ত resource থাকবে না যাতে খরচ অপচয় হয়। বেশি traffic এলে scale up, কমলে scale down।
কীভাবে কাজ করে
Horizontal বনাম Vertical
দুই ধরনের scaling:
| বৈশিষ্ট্য | Vertical Scaling | Horizontal Scaling |
|---|---|---|
| অর্থ | একটি মেশিন বড় করা (বেশি CPU/RAM) | আরও মেশিন/instance যোগ করা |
| সীমা | hardware-এর সর্বোচ্চ সীমা পর্যন্ত | প্রায় সীমাহীন |
| Downtime | প্রায়ই restart লাগে | লাগে না |
| Fault tolerance | একটি মেশিন, single point of failure | একাধিক মেশিন, বেশি resilient |
| জটিলতা | সরল | load balancer ও stateless design দরকার |
বড় স্কেলের জন্য সাধারণত horizontal scaling-ই পছন্দনীয়, কারণ এটি সীমাহীন ও fault-tolerant। তবে এর জন্য অ্যাপ stateless হতে হয় (session যেন কোনো নির্দিষ্ট মেশিনে আটকে না থাকে)।
Metric-based scaling
Autoscaler সিদ্ধান্ত নেয় কিছু metric দেখে:
- CPU utilization — সবচেয়ে সাধারণ (যেমন CPU 70%-এর বেশি হলে scale up)।
- Memory usage।
- QPS / RPS (প্রতি সেকেন্ডে request সংখ্যা)।
- Request latency বা queue depth (অপেক্ষমাণ কাজের সংখ্যা)।
সঠিক metric বাছাই গুরুত্বপূর্ণ — যেমন একটা I/O-heavy অ্যাপের জন্য CPU হয়তো ভালো signal নয়, বরং queue depth ভালো।
Reactive বনাম Predictive
- Reactive scaling: metric বাড়ার পর scale করে। সরল, কিন্তু একটু পিছিয়ে থাকে।
- Predictive scaling: অতীত pattern (যেমন প্রতিদিন সন্ধ্যায় traffic বাড়ে) থেকে শিখে আগেভাগে scale করে। spike আসার আগেই প্রস্তুত থাকে।
Warm-up ও Cold start
নতুন instance চালু হতে কিছু সময় লাগে — OS boot, অ্যাপ load, cache গরম হওয়া (warm-up)। এই বিলম্বের কারণে reactive autoscaler হঠাৎ spike-এ সাময়িকভাবে পিছিয়ে পড়ে। এজন্য কিছু buffer (extra capacity) রাখা বা predictive scaling করা হয়।
ভাবো একটা জনপ্রিয় ইফতার বাজারের দোকান। স্বাভাবিক দিনে ২ জন কর্মী যথেষ্ট (vertical scaling হলো — একজন কর্মীকে আরও দক্ষ/দ্রুত বানানো, কিন্তু তারও সীমা আছে)। রমজানে ভিড় বাড়লে মালিক আরও কর্মী ডেকে আনে (horizontal scaling)। মালিক দেখে লাইন কত লম্বা (metric) — লাইন বাড়লে কর্মী বাড়ায়, কমলে ছুটি দেয়। অভিজ্ঞ মালিক জানে মাগরিবের ঠিক আগে ভিড় হবেই, তাই আগেভাগে কর্মী রেডি রাখে (predictive)। নতুন কর্মীকে কাজ বুঝে নিতে কিছুক্ষণ লাগে — সেটাই warm-up।
কৌশল
Scale-to-zero
কিছু platform (যেমন AWS Lambda, Cloud Run, Knative) scale-to-zero সমর্থন করে — কোনো request না থাকলে instance সংখ্যা শূন্যে নেমে আসে, খরচ শূন্য হয়। প্রথম request এলে আবার চালু হয়। অসুবিধা — সেই প্রথম request-এ cold start latency। মাঝে মাঝে ব্যবহৃত internal tool বা ব্যাচ কাজের জন্য চমৎকার।
খরচ বনাম performance
Autoscaling-এর মূল উদ্দেশ্যই খরচ optimization। তবে খুব আক্রমণাত্মকভাবে scale down করলে spike-এ ভুগতে হয়; খুব রক্ষণশীল হলে টাকা নষ্ট। min ও max সীমা এবং cooldown period সাবধানে সেট করতে হয়।
কখন ব্যবহার করবে / করবে না
ব্যবহার করবে যখন:
- traffic ওঠানামা করে (দৈনিক pattern, ঋতু, সেল)।
- খরচ optimize করতে চাও।
- অ্যাপ stateless ও horizontally scalable।
করবে না / সতর্ক থাকবে যখন:
- stateful service (যেমন database) — এখানে autoscaling জটিল, আলাদা কৌশল লাগে।
- traffic প্রায় স্থির — তখন fixed capacity সহজ ও পূর্বানুমেয়।
Autoscaling সব সমস্যার সমাধান নয়। যদি তোমার অ্যাপের একটা component (যেমন একটা database বা একটা slow downstream API) bottleneck হয়, তাহলে শুধু অ্যাপ instance বাড়ালে সেই bottleneck-এর উপর চাপ আরও বাড়বে — পুরো system আরও দ্রুত ভেঙে পড়তে পারে। scale করার আগে নিশ্চিত হও যে পুরো system horizontally scale করার মতো ডিজাইন করা।
বাস্তব উদাহরণ
একটা food delivery অ্যাপ (ধরো Foodpanda-জাতীয়) ভাবো। সকাল ও গভীর রাতে অর্ডার কম, কিন্তু দুপুর ১টা ও রাত ৮টায় তুমুল ভিড়। তারা HPA (Horizontal Pod Autoscaler) সেট করেছে — CPU 65%-এর বেশি হলে নতুন pod যোগ হয়। স্বাভাবিক সময়ে ৪টা pod, peak-এ ৩০টা।
কিন্তু তারা লক্ষ্য করল reactive scaling-এ peak-এর শুরুতে কয়েক মিনিট latency বাড়ে (warm-up-এর জন্য)। তাই তারা predictive scaling যোগ করল — যেহেতু peak সময় জানা, ১২:৪৫-এই আগেভাগে pod বাড়িয়ে রাখে। এছাড়া তাদের রাতের ব্যাচ report-generation service scale-to-zero-তে চলে — দিনে শূন্য instance, রাতে চালু হয়ে কাজ শেষ করে আবার বন্ধ। ফলে performance ভালো থাকে আর cloud bill অনেক কমে।
Interview-তে "তোমার system traffic spike কীভাবে সামলাবে?" প্রশ্নে শুধু "autoscaling" বললে যথেষ্ট নয়। বলো — horizontal scaling-এর জন্য অ্যাপ stateless রাখতে হবে, সঠিক metric (CPU/QPS/queue depth) বাছতে হবে, আর warm-up/cold start latency-র কারণে reactive scaling-এর সীমা আছে বলে buffer বা predictive scaling লাগতে পারে। এই nuance-গুলোই তোমাকে আলাদা করবে।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. Horizontal scaling বলতে কী বোঝায়?
2. Reactive autoscaling-এর একটি সীমাবদ্ধতা কী?
3. Scale-to-zero কখন সবচেয়ে উপযোগী?