Auto Scaling Group আর Scaling Policy

এই লেসন শেষে তুমি যা পারবে

• Auto Scaling group (ASG) আসলে কী করে, বুঝিয়ে বলতে পারবে: min আর max-এর মাঝে সুস্থ instance-এর সংখ্যা ধরে রাখা, নষ্টগুলো বদলে দেওয়া, আর Availability Zone জুড়ে ছড়িয়ে রাখা।
• launch configuration-এর জায়গা কেন launch template নিল, আর কোন কাজগুলো শুধু launch template-ই পারে, বলতে পারবে।
• ASG-কে load balancer-এর সাথে জুড়তে পারবে, ঠিক health check type আর grace period বেছে নিতে পারবে, আর “load balancer বলছে unhealthy, অথচ কিছুই বদলাচ্ছে না” সমস্যাটা ঠিক করতে পারবে।
• target tracking, step, simple, scheduled আর predictive scaling-এর মধ্যে ঠিকটা বেছে নিতে পারবে, ভালো metric চিনতে পারবে, আর queue-র backlog দেখে group-এর আকার হিসাব করতে পারবে।
• cooldown আর default instance warm-up ঠিকভাবে ব্যবহার করতে পারবে, আর runaway scaling থামাতে পারবে।
• একটা instance-এর পুরো lifecycle ধরে ধরে বলতে পারবে: lifecycle hook, standby, detach, scale-in protection, termination policy, instance refresh আর warm pool।
• একই group-এ On-Demand আর Spot মিশিয়ে capacity rebalancing দিয়ে চালাতে পারবে, আর সবসময় চালু থাকা অংশটা Reserved Instance বা Savings Plan দিয়ে ঢাকতে পারবে।

#নিজে নিজে scale হওয়া কেন দরকার

লেসন ৬.১-এ দেখেছ web tier কেন horizontally scale করে: load বাড়লে server যোগ করো, কমলে সরিয়ে দাও। লেসন ৬.২ থেকে ৬.৪-এ সামনে একটা load balancer বসানো হয়েছে, যাতে সব server মিলে একটার মতো দেখায়। বাকি রইল আসল কাজটা: কয়টা server থাকা উচিত সেটা ঠিক করা, আর রাত ৩টায় কেউ dashboard-এর দিকে তাকিয়ে না থাকলেও নিজে নিজে server বানানো বা সরানো।

বাস্তবের load কখনো এক রকম থাকে না। একটা দোকান রাতে ফাঁকা, দুপুরে ব্যস্ত, আর sale-এর দিনে পাগলের মতো ভিড়। সারাদিন peak-এর মাপে server চালালে বেশিরভাগ সময় বসে থাকা মেশিনের টাকা দিতে হয়। গড়ের মাপে চালালে peak-এর সময় site ধীর হয়ে যায়, নয়তো পড়েই যায়। data centre-এ উপায় ছিল না, একটা server কিনতেই কয়েক সপ্তাহ লাগত। AWS-এ একটা instance মোটামুটি এক মিনিটে চালু হয়, আর terminate করার সেকেন্ড থেকেই টাকা লাগা বন্ধ, তাই server-এর সংখ্যা load-এর পেছনে পেছনে চলতে পারে।

#Auto Scaling group আসলে কী

Auto Scaling group হলো কতগুলো EC2 instance-এর একটা দল, যেটাকে EC2 Auto Scaling একসাথে একটা জিনিস হিসেবে সামলায়। তুমি তাকে তিনটা সংখ্যা আর একটা রেসিপি দাও:

এগুলো দিয়ে group যা করে:

• সংখ্যাটা desired-এ ধরে রাখে। কোনো instance terminate হলে (নষ্ট হয়ে, Spot interruption-এ, বা কেউ ভুল করে terminate চাপলে), group তার জায়গায় নতুন একটা চালু করে।
• অসুস্থ instance বদলে দেয়। নিয়মিত প্রতিটা instance পরীক্ষা করে, যেগুলো ফেল করে সেগুলো terminate করে নতুন চালায় (পরের অংশে বিস্তারিত)।
• Scale out আর scale in করে, যখন কোনো scaling policy বা schedule desired capacity বদলায়, কিন্তু সবসময় min আর max-এর ভেতরে থাকে।
• তোমার বেছে দেওয়া AZ-গুলোতে instance সমানভাবে ছড়িয়ে রাখে, প্রতিটা নতুন instance চালায় যে AZ-এ সবচেয়ে কম আছে সেখানে। একটা AZ নষ্ট হলে বাকিগুলোতে চালায়; AZ ঠিক হলে আবার rebalance করে।
• load balancer-এ instance নিজেই register করে, যখন তুমি একটা target group জুড়ে দাও, আর terminate করার আগে deregister করে।

একটা ASG থাকে একটা Region-এ, ওই Region-এর সব AZ জুড়ে ছড়াতে পারে, কিন্তু কখনো দুটো Region-এ না। group-টার নিজের কোনো দাম নেই, ফ্রি: টাকা দাও শুধু যে instance আর অন্যান্য resource সে চালায় সেগুলোর (EBS volume, data transfer, CloudWatch detailed monitoring)।

#রেসিপি: launch template

একটা instance চালু করতে group-এর জানতে হয় কোন AMI, কোন instance type, কোন security group, কোন key pair, কোন IAM role, কোন user data, কোন EBS volume। এই রেসিপিটাই launch template, যেটা লেসন ৪.৩-এ বিস্তারিত দেখেছ: নম্বর দেওয়া, বদলানো যায় না এমন version, একটা default version, আর $Default / $Latest। ASG একটা template আর একটা version ধরে রাখে; নিরাপদ নিয়ম হলো $Default (বা নির্দিষ্ট একটা নম্বর) দেওয়া, আর নতুন version জেনে-বুঝে promote করা।

launch template আসার আগে ছিল launch configuration। এগুলো এখন legacy, আর AWS ধাপে ধাপে এদের বিদায় দিচ্ছে:

পুরনো account-গুলো নিজেদের আগের launch configuration চালাতে পারে, কিন্তু AWS সবাইকে migrate করতে বলছে। আর launch configuration যা কখনো পারত না, পরীক্ষার প্রশ্ন ঠিক সেটাই চায়:

#Load balancer-এর সাথে ASG

বেশিরভাগ ASG থাকে একটা Application বা Network Load Balancer-এর পেছনে। group-এর সাথে একটা target group জুড়ে দাও (লেসন ৬.২ আর ৬.৩), তারপর থেকে:

1. register হয় নিজে নিজে

   group যে instance-ই চালু করুক, service-এ ঢোকার সময় সেটা target group-এ register হয়ে যায়। হাতে করে কখনো load balancer-এ instance যোগ করতে হয় না, আর যেখানে প্রতি ঘণ্টায় instance আসে-যায়, সেখানে এটাই আসল সুবিধা।

2. terminate-এর আগে deregister

   group যখন scale in করে বা কোনো instance বদলায়, আগে সেটাকে deregister করে। load balancer নতুন request পাঠানো বন্ধ করে, আর চলতি request-গুলো শেষ করতে দেয় deregistration delay পর্যন্ত (connection draining, default ৩০০ সেকেন্ড, লেসন ৬.৪)। তারপরই instance terminate হয়। scale in-এর সময় user-রা error দেখলে deregistration delay বাড়াও।

3. group চাইলে load balancer-এর health check মানতে পারে

   load balancer তো আগে থেকেই প্রতিটা target পরীক্ষা করে (যেমন প্রতি ৩০ সেকেন্ডে GET /health)। ASG-কেও বলা যায় ওই রায় মেনে নিতে। মানবে কি না, সেটাই health check type, আর পুরো বিষয়টায় সবচেয়ে বেশি ভুল হয় ঠিক এখানেই।

#Health check type

সব instance শুরু করে সুস্থ হিসেবে। চালু থাকা কোনো একটা উৎস যখন বলে instance unhealthy, তখনই সে অসুস্থ, আর group তাকে terminate করে নতুন একটা চালায়:

মূল কথাটা হলো: default EC2 type-এ group শুধু জানে মেশিনটা বেঁচে আছে কি না। আটকে যাওয়া web server, crash করা application process বা ভরে যাওয়া disk user-কে error দেয়, কিন্তু instance থাকে running, status check-ও পাস। load balancer গোলমালটা দেখে traffic পাঠানো বন্ধ করে, অথচ ASG instance-টাকে সুস্থই রেখে দেয়: একটা zombie, যার টাকা তুমি দিয়েই যাচ্ছ। ELB health check type চালু করলে load balancer-এর রায়ও যোগ হয় (EC2 check-ও চালু থাকে), ফলে group instance-টা terminate করে বদলে দেয়।

আরও কয়েকটা খুঁটিনাটি জানা ভালো:

• যে instance running অবস্থা ছেড়ে যায়, সেটা সাথে সাথে বদলানো হয়। status check ফেল করলে আগে কয়েক মিনিট ধৈর্য ধরা হয়, যদি AWS নিচের সমস্যাটা ঠিক করে ফেলে।
• একসাথে অনেক instance অসুস্থ হলে group ধাপে ধাপে বদলায় (default-এ একবারে desired capacity-র সর্বোচ্চ ১০%, প্রতিটা ধাপ warm-up শেষ করা পর্যন্ত অপেক্ষা করে), যাতে একটা ভাঙা health check page এক ধাক্কায় পুরো fleet মুছে না দেয়।
• health check-এর হাতে না মরে কোনো instance-এ কাজ করতে চাইলে সেটাকে standby-তে রাখো (এই লেসনেই পরে আছে), নয়তো HealthCheck আর ReplaceUnhealthy process দুটো suspend করো।

#Health check grace period

নতুন instance-এর বুট হতে আর application চালু হতে সময় লাগে, আর সেই সময়টায় load balancer-এর check ফেল করে। health check grace period হলো instance service-এ ঢোকার পর ব্যর্থ health check-এর ওপর ব্যবস্থা নেওয়ার আগে group কতক্ষণ অপেক্ষা করবে।

• Console-এ default ৩০০ সেকেন্ড। CLI আর SDK-তে default ০, মানে বন্ধ। CLI দিয়ে বানানো, ELB type-ওয়ালা একটা group, যার application চালু হতে চার মিনিট লাগে, সে প্রতিটা নতুন instance তৈরি হওয়ার আগেই terminate করে দেবে, অনন্তকাল।
• আসল start-up সময়ের চেয়ে একটু বেশি দাও। বেশি লম্বা দিলে সত্যিই নষ্ট একটা নতুন instance ততক্ষণ বেঁচে থাকবে।
• এটা খাটে নতুন চালু হওয়া instance-এ, standby থেকে ফেরা instance-এ, আর হাতে attach করা instance-এ।
• যে instance stop হয়ে গেছে, তাকে এটা কখনো বাঁচায় না: grace period থাকুক বা না থাকুক, সেটা সাথে সাথে বদলানো হয়।
• এমন একটা launch lifecycle hook থাকলে, যেটা instance পুরো তৈরি না হওয়া পর্যন্ত আটকে রাখে, grace period ০ রাখলেও চলে।

#ASG ঠিকমতো না চললে

#Scaling policy

desired capacity বদলায় তিনটার যেকোনো একটা কারণে: তুমি বদলাও (manual scaling), কোনো schedule বদলায়, অথবা metric দেখে কোনো policy বদলায়। হাতে যা যা আছে:

একসাথে কয়েকটা policy চালু থাকতে পারে। প্রত্যেকে নিজের হিসাবে capacity চায়, আর group নেয় সবচেয়ে বড়টা: যেকোনো একটা policy বললেই scale out করে, আর scale in করে শুধু যখন সবাই রাজি।

#Target tracking

একটা metric আর একটা target মান বেছে নাও, যেমন গড় CPU ৫০%। Auto Scaling তখন হিসাব করে কয়টা instance থাকলে metric target-এ থাকবে। ৪টা instance গড়ে ৭৫% CPU-তে চললে আর target ৫০% হলে, একই কাজ ৫০% করে ভাগ করতে লাগবে ৪ × ৭৫ ÷ ৫০ = ৬টা instance, তাই desired যায় ৬-এ। load অর্ধেক হলে গড় আবার ৫০%-এর কাছে না আসা পর্যন্ত instance সরাতে থাকে।

পর্দার আড়ালে Auto Scaling দুটো alarm বানায়: একটা scale-out alarm, যেটা metric কয়েক মিনিট target-এর ওপরে থাকলেই সাড়া দেয় (এক মিনিটের ৩টা data point), আর একটা scale-in alarm, যেটা অনেক বেশি অপেক্ষা করে (১৫টা data point)। ধীরে scale in করাটা ইচ্ছাকৃত: তাড়াতাড়ি capacity সরালে user কষ্ট পায়, একটু বেশি যোগ হলে খরচ হয় সামান্য। চাইলে কোনো policy-র scale-in বন্ধও করা যায়, যেমন deployment-এর সময়, আর capacity কমানোর কাজটা অন্য কাউকে দেওয়া যায়।

ভালো metric হলো সেগুলো, যেগুলো প্রতিটা instance কতটা ব্যস্ত তার অনুপাতে ওঠানামা করে:

target tracking-এ যে metric চলে না, কারণ instance যোগ করলেও সেগুলো কমে না: load balancer-এর মোট RequestCount, response-এর latency, আর SQS queue-তে থাকা message-এর কাঁচা সংখ্যা। মোটকে প্রতি instance-এ ভাগ করো (প্রতি target-এ request, প্রতি instance-এ backlog), তখন চলবে।

দুটো কাজের কথা। detailed monitoring (১ মিনিট) চালু না করলে EC2 CPU পাঠায় প্রতি ৫ মিনিটে, আর policy তার data যত দ্রুত আসে তার চেয়ে দ্রুত সাড়া দিতে পারে না, তাই scaling group-এ এটা চালু রাখো। আর খুব লাফিয়ে ওঠা traffic-এর জন্য target tracking কয়েক সেকেন্ড পরপর পাঠানো high-resolution custom metric-ও ব্যবহার করতে পারে, তখন এক মিনিটেরও অনেক কমে সাড়া দেয়।

simulator-এ এগুলো চালিয়ে দেখো: “max-এর চেয়েও বেশি” দেখায় policy যখন max-এর চেয়ে বেশি চায় তখন কী হয় (load না কমা পর্যন্ত CPU target-এর ওপরে থাকে); “হঠাৎ flash sale”-এ ৬ মিনিটের start-up দিলে দেখবে ধীর একটা AMI user-দের কতক্ষণ অপেক্ষা করায়; আর একই spike-এ warm-up ০ দিলে দেখবে runaway scaling, যেটা একটু পরেই বুঝিয়ে বলা হয়েছে।

#CloudWatch alarm দিয়ে step আর simple scaling

এখানে CloudWatch alarm-টা তুমি বানাও, যেমন “group-এর গড় CPU পরপর ২ মিনিট 70%-এর ওপরে”, আর তার সাথে একটা policy জুড়ে দাও। সাধারণত এক জোড়া বানানো হয়: উঁচু alarm-এ একটা scale-out policy আর নিচু alarm-এ একটা scale-in policy (“30%-এর নিচে, ১টা সরাও”)।

• Step scaling দেখে metric সীমা কতটা ছাড়িয়েছে, আর সেই মাপে একটা ধাপ বেছে নেয়: 70–85% → ১টা যোগ, 85% বা তার বেশি → ৩টা যোগ। adjustment হতে পারে কয়টা instance, একটা নির্দিষ্ট capacity, বা group-এর একটা শতাংশ। প্রতিটা নতুন ছাড়িয়ে যাওয়ায় সাথে সাথে সাড়া দেয়, আর warm-up-এ থাকা instance-গুলোকে আগেই যোগ হওয়া capacity ধরে, তাই মাত্রা ছাড়িয়ে যায় না।
• Simple scaling-এর থাকে একটাই adjustment (“২টা যোগ করো”), তারপর আবার কিছু করার আগে cooldown শেষ হওয়া পর্যন্ত বসে থাকে। load বাড়তেই থাকলে এজন্য এটা ধীর, আর সেই কারণেই AWS এটা না নিতে বলে।

#Scheduled action

scheduled action একটা নির্দিষ্ট সময়ে min, max আর/অথবা desired বদলে দেয়, একবার (“১১ নভেম্বর সকাল ৮টায় min ২০”) অথবা cron expression আর time zone দিয়ে বারবার (“প্রতি শুক্রবার ১৬:৪৫-এ min ১০”)। load যে আসছে, সেটা যখন তুমি জানো, তখন এটাই: action ভিড়ের আগেই capacity বাড়িয়ে দেয়, আর আরেকটা action পরে min আবার নামিয়ে আনে। scheduled action কোনো cooldown-এর অপেক্ষা না করে সাথে সাথে শুরু হয়, আর এর ওপরেও dynamic policy কাজ চালিয়ে যায়।

#Predictive scaling

predictive scaling ইতিহাস থেকে ধরনটা শিখে load আসার আগেই scale করে:

• forecast শুরু করতে metric-এর অন্তত ২৪ ঘণ্টার data লাগে, আর সে সর্বোচ্চ ১৪ দিন পর্যন্ত দেখে (পুরো দুই সপ্তাহ পেলে forecast সবচেয়ে ভালো হয়)।
• সামনের ৪৮ ঘণ্টার ঘণ্টাভিত্তিক forecast বানায়, প্রতি ৬ ঘণ্টায় নতুন করে।
• শুরু হয় forecast only mode-এ, যাতে তুমি forecast-কে বাস্তবের সাথে মিলিয়ে দেখতে পারো; তারপর যাও forecast and scale-এ।
• প্রতিটা forecast ঘণ্টার শুরুতে launch করে, অথবা একটা pre-launch buffer (SchedulingBufferTime) দিলে আরও আগে, যাতে ঘণ্টা শুরু হওয়ার সময় instance তৈরি থাকে।
• এটা শুধু scale out করে। কখনো capacity সরায় না, তাই এর সাথে একটা target tracking policy জুড়ে দাও, যেটা scale in করবে (আর forecast যা দেখেনি, এমন হঠাৎ ঘটনাও সামলাবে)।
• default-এ max ছাড়াতে পারে না; চাইলে নিজে নিজে max বাড়ানোর অনুমতি দেওয়া যায় (MaxCapacityBreachBehavior), কিন্তু বাড়ানো max ততদিন থেকে যায় যতদিন না তুমি নিজে কমাও।

যেখানে খাপ খায়: অফিস-সময়ের application, দৈনিক batch-এর সময়, আর যে application চালু হতে অনেক মিনিট লাগে। যেখানে খাপ খায় না: এলোমেলো, অনিয়মিত traffic, আর এমন mixed group যার instance type-গুলোর আকারে অনেক পার্থক্য।

#Queue দেখে scaling: প্রতি instance-এ backlog

যে worker fleet একটা SQS queue থেকে কাজ পড়ে, তাদের scale করা উচিত প্রতি instance-এ backlog দেখে, queue-র দৈর্ঘ্য দেখে না। দেখা যাওয়া message-এর কাঁচা সংখ্যা worker-এর সংখ্যার অনুপাতে বদলায় না, তাই target tracking এটা ব্যবহার করতে পারে না। প্রতি instance-এ backlog পারে:

1. কতটা দেরি মেনে নেওয়া যায় ঠিক করো: একটা message সর্বোচ্চ ধরো ২০ সেকেন্ড অপেক্ষা করতে পারবে।
2. processing time মাপো: একটা worker একটা message শেষ করে ০.২ সেকেন্ডে, মানে প্রতি সেকেন্ডে ৫টা।
3. প্রতি instance-এ target backlog = মেনে নেওয়া দেরি ÷ processing time = ২০ ÷ ০.২ = ১০০টা message।
4. queue-তে ১,৮০০টা message থাকলে policy চাইবে ১,৮০০ ÷ ১০০ = ১৮টা instance।

এটা custom metric হিসেবে পাঠাতে পারো, নয়তো target tracking-কে metric math দিয়ে হিসাব করতে দাও: queue-র দেখা যাওয়া message-এর সংখ্যা ভাগ group-এর in-service instance-এর সংখ্যা। processing time বদলালে (বড় ছবি, ধীর কোনো dependency), target আবার দেখো।

#Cooldown আর warm-up

group instance যোগ করার পর সেগুলো কাজে লাগতে একটু সময় লাগে: launch হয়, বুট হয়, application চালু হয়, load balancer-এ register হয়, তারপর traffic নেয়। এই সময়টায় policy যদি metric দেখতেই থাকে, সে পুরনো, উঁচু মানটাই দেখবে আর আরও instance যোগ করবে। এটা সামলাতে দুটো setting আছে, আর পরীক্ষা এই দুটো গুলিয়ে দিতে খুব পছন্দ করে।

warm-up ঠিক কী বদলায়:

• instance warm-up-এ থাকার সময় group আবার scale out করে শুধু যদি বাকি instance-গুলোর metric এখনো target-এর ওপরে থাকে, আর warm-up-এ থাকাগুলোকে capacity-র অংশ ধরে। তাই পরপর কয়েকটা alarm মিলে একটা বুদ্ধিমান scale out হয়, স্তূপ জমে না।
• নতুন instance-গুলোর warm-up শেষ না হওয়া পর্যন্ত scale in আটকে থাকে।
• scheduled action, অসুস্থ instance বদলানো আর হাতে করা পরিবর্তন কখনো এই দুটোর কোনোটার জন্য অপেক্ষা করে না।

#Runaway scaling

Runaway scaling মানে আগের instance-গুলো কাজ শুরু করার আগেই group একটার পর একটা instance চালু করে যাচ্ছে। চেনা কারণটা হলো: নতুন instance-গুলো লম্বা একটা user data script চালায় (package install, asset download, compile), CPU থাকে অনেক বেশি। warm-up না থাকলে, বা script-এর চেয়ে অনেক কম থাকলে, তাদের ব্যস্ত CPU group-এর গড়ে ঢুকে পড়ে, scale out-এর ঠিক পরেই গড় আরও খারাপ হয়, আর policy আরও যোগ করে। group দৌড়ে max-এ পৌঁছায়, বাড়তিটার টাকা তুমি দাও, আর পরে scale in করে সেটা ফেরাতে ১৫ মিনিট বা তার বেশি লাগে।

সমাধান, সবচেয়ে ভালোটা আগে:

1. instance-কে দ্রুত তৈরি করো। software আগে থেকে বসানো একটা ready-to-serve (golden) AMI ব্যবহার করো (লেসন ৪.৩), আর user data ছোট রাখো। এতে সবকিছুই কমে: warm-up, grace period আর user-দের কাজে লাগতে যত সময়।
2. default instance warm-up দাও, service-এ ঢোকা থেকে traffic নেওয়া পর্যন্ত আসল সময়টা।
3. simple scaling-এর জন্য cooldown বাড়াও।
4. launch lifecycle hook ব্যবহার করো, যাতে instance পুরো তৈরি হলে তবেই service-এ ঢোকে।

#Instance-এর lifecycle

ASG-র ভেতরের একটা instance সাধারণ EC2 অবস্থাগুলোর ওপর আরও কিছু নিজস্ব অবস্থার মধ্য দিয়ে যায়:

#Lifecycle hook

lifecycle hook launch বা terminate-এর সময় instance-কে থামিয়ে রাখে, যাতে তুমি নিজের কোনো কাজ চালাতে পারো:

• Launching hook (autoscaling:EC2_INSTANCE_LAUNCHING): load balancer-এ register হওয়ার আগে instance অপেক্ষা করে Pending:Wait-এ। একটা script software install করে, cache ভরে, self-test চালায়, তারপর complete-lifecycle-action ডাকে CONTINUE দিয়ে। ABANDON দিলে group instance-টা terminate করে আবার চেষ্টা করে।
• Terminating hook (autoscaling:EC2_INSTANCE_TERMINATING): deregister হওয়ার পর instance অপেক্ষা করে Terminating:Wait-এ। সাধারণ কাজ: log S3-তে কপি করা, হাতের job শেষ করা বা ফেরত দেওয়া, service registry বা DNS থেকে নাম সরানো, শেষ একটা backup নেওয়া। terminating hook-এ দুটো result-এর শেষেই terminate হয়; hook-টা যতটা পারে ততটা চেষ্টা।
• hook একটা event পাঠায় EventBridge-এ (বা SNS বা SQS-এ notification), যেটা একটা Lambda function, একটা SSM Run Command বা একটা script চালু করতে পারে। instance নিজেও instance metadata থেকে নিজের target lifecycle অবস্থা পড়ে নিতে পারে।
• Heartbeat timeout: default ১ ঘণ্টা। কেউ action শেষ না করলে সময় ফুরালে default result (ABANDON বা CONTINUE) কাজ করে। script চাইলে record-lifecycle-action-heartbeat দিয়ে অপেক্ষা বাড়াতে পারে, সর্বোচ্চ ৪৮ ঘণ্টা বা ১০০টা heartbeat, যেটা আগে আসে।

#Standby, detach আর scale-in protection

• Standby (enter-standby): patch দিতে বা সমস্যা খুঁজতে instance-কে service থেকে সরিয়ে রাখো। load balancer থেকে সরে যায়, health check হয় না। তুমি ঠিক করো desired একটা কমবে, নাকি তার জায়গায় নতুন একটা চালু হবে। exit-standby তাকে ফিরিয়ে আনে (grace period আবার খাটে)।
• Detach (detach-instances): instance-কে চিরতরে group থেকে বের করে দাও। সে সাধারণ instance হিসেবে চলতে থাকে; চাইলে group তার জায়গায় নতুন একটা চালাক, নয়তো desired কমাও। Attach ঠিক উল্টোটা করে।
• Scale-in protection (set-instance-protection, বা group-এর সব নতুন instance-এর জন্য একসাথে): scale in এই instance-কে বাছবে না, যেমন সে যখন লম্বা কোনো job চালাচ্ছে। তবে অসুস্থ হলে বদলানো, Spot interruption বা হাতে terminate থেকে এটা বাঁচায় না।

#Scale in-এ কোন instance যাবে

group scale in করলে কোন instance যাবে, সেটা ঠিক করে termination policy। default policy এই ক্রমে কাজ করে:

1. সবার আগে Availability Zone-এর ভারসাম্য। যে AZ-এ সবচেয়ে বেশি instance আছে (আর অন্তত একটা protection ছাড়া), সেটা বাছো। তুমি যে termination policy-ই দাও, এই নিয়ম সবসময় প্রথমে।
2. পুরনো configuration। ওই AZ-এর ভেতরে আগে সেই instance, যেটা launch configuration থেকে চালু, তারপর বর্তমানটার বদলে অন্য কোনো launch template থেকে, তারপর বর্তমান template-এর সবচেয়ে পুরনো version থেকে।
3. পরের billing hour-এর সবচেয়ে কাছে যে, তবুও সমান হলে এলোমেলোভাবে একটা। (এখন বেশিরভাগ EC2 প্রতি সেকেন্ডে bill হয়, তাই এই নিয়মের গুরুত্ব আগের চেয়ে কম।)

mixed instances group-এ group আগে ঠিক করে On-Demand সরাবে না Spot (ঠিক করা অনুপাত বজায় রাখতে), আর কোন instance allocation strategy-র সাথে সবচেয়ে ভালো মেলে।

অন্য predefined policy: OldestInstance, NewestInstance, OldestLaunchTemplate, OldestLaunchConfiguration, ClosestToNextInstanceHour, AllocationStrategy, অথবা Lambda function দিয়ে বানানো custom termination policy। অসুস্থ instance policy-র ধারই ধারে না: সেগুলো সোজা বদলানো হয়।

#Fleet-কে টাটকা আর দ্রুত রাখা

• Instance refresh ধাপে ধাপে instance বদলায়, যেমন patch করা AMI-সহ নতুন launch template version promote করার পরে। তুমি একটা minimum healthy percentage দাও (default ৯০%), আর চাইলে ১০০%-এর ওপরে একটা maximum, যাতে terminate-এর আগে launch করে; আগে থেকেই মিলে যাওয়া instance বাদ দিতে পারে, checkpoint-এ থামতে পারে, আর health check ফেল করলে নিজে নিজে rollback করতে পারে।
• Instance maintenance policy: group যত instance বদলায় (অসুস্থ instance, rebalance), সবগুলোর জন্য একই min/max healthy percentage, যেমন “আগে launch, পরে terminate, কখনো ১০০%-এর নিচে না”।
• Maximum instance lifetime: প্রতিটা instance ধরো ৭ দিন পরপর বদলে দাও (কমপক্ষে ১ দিন), যাতে কিছুই মাসের পর মাস patch ছাড়া না চলে।
• Warm pool: group-এর পাশে আগে থেকে তৈরি করে রাখা কিছু instance, stopped (তখন টাকা দাও শুধু তাদের EBS volume-এর), hibernated বা running অবস্থায়। scale out হলে শূন্য থেকে বুট না করে pool থেকে একটা তুলে নেয়, ফলে যে application চালু হতে অনেক সময় লাগে, তার কয়েক মিনিট বেঁচে যায়।
• Process suspend করা: কোনো সমস্যা খুঁজতে গিয়ে আলাদা আলাদা process থামিয়ে রাখা যায় (Launch, Terminate, HealthCheck, ReplaceUnhealthy, AZRebalance, AlarmNotification, ScheduledActions, AddToLoadBalancer, InstanceRefresh)।

#Mixed instances: On-Demand আর Spot একসাথে

একটা mixed instances policy (শুধু launch template দিয়ে) একটা group-কে কয়েক ধরনের instance type আর দুই ধরনের purchase option একসাথে চালাতে দেয়। Spot নিজে কী, তা লেসন ৪.৪-এ দেখেছ: প্রায় ৯০% পর্যন্ত ছাড়, সাথে দুই মিনিটের interruption notice। ASG-তে mix-টা তুমি ঠিক করো দুটো সংখ্যা দিয়ে:

হাতে-কলমে উদাহরণ। base ২, base-এর ওপরে ২৫% On-Demand, desired ১০। প্রথম ২টা On-Demand। বাকি ৮টা ভাগ হয় ২৫% On-Demand (২টা) আর ৭৫% Spot (৬টা)। মোট: ৪টা On-Demand আর ৬টা Spot। desired ৪ হলে হতো ২ + (২-এর ২৫% → মোটামুটি ১টা On-Demand, বাকিটা Spot)।

group কীভাবে instance type আর pool বাছে (একটা pool মানে একটা AZ-এ একটা instance type):

• Spot allocation strategy: price-capacity-optimized recommended: এমন pool বাছে যেগুলো সস্তাও, আবার interrupt হওয়ার সম্ভাবনাও সবচেয়ে কম। capacity-optimized (আর -prioritized) শুধু capacity দেখে। কিছু না বললে API ব্যবহার করে lowest-price, কিন্তু AWS এটা recommend করে না: এতে interruption-এর ঝুঁকি সবচেয়ে বেশি।
• On-Demand allocation strategy: prioritized (তোমার দেওয়া type-এর ক্রম, তোমার Reserved Instance যে type ঢাকে সেখানে instance ফেলতে কাজে লাগে) অথবা lowest-price।
• অনেক ধরনের instance type দাও (অথবা vCPU আর memory দিয়ে attribute-ভিত্তিক বাছাই), কয়েকটা AZ জুড়ে। pool যত বেশি, একটার ঘাটতিতে ক্ষতি তত কম।
• Spot-এর maximum price দিয়ো না: এতে শুধু interruption বাড়ে। টাকা সবসময় দাও তখনকার Spot দামেই।

Capacity rebalancing। একটা Spot instance interrupt করার আগে EC2 একটা rebalance recommendation পাঠায় (ঝুঁকি বেড়েছে এমন একটা সংকেত, সাধারণত দুই মিনিটের notice-এর আগেই)। capacity rebalancing চালু থাকলে group আগে একটা ভালো pool-এ নতুন instance চালু করে, সেটা health check পাস করা পর্যন্ত অপেক্ষা করে, তারপর ঝুঁকিতে থাকা instance-টা terminate করে, তোমার terminating lifecycle hook থাকলে সেটার মধ্য দিয়ে (দুই মিনিটের কমে শেষ করো)। এই সময় কিছুক্ষণের জন্য max-কে desired-এর ১০% পর্যন্ত ছাড়িয়ে যেতে পারে। এটা না থাকলে group একটা Spot instance বদলায় সেটা interrupt হওয়ার পরে, তাই কয়েক মিনিট capacity কম থাকে।

#মেঝের দাম: Reserved Instance আর Savings Plan

Auto Scaling টাকা বাঁচায় যে instance লাগছে না সেগুলো সরিয়ে। কিন্তু minimum capacity কখনো যায় না: ওই instance-গুলো দিনে ২৪ ঘণ্টা, বছরে ৩৬৫ দিন চলে। যা সবসময় চলে তার জন্য On-Demand দামে টাকা দেওয়াটা দামি পথ। মেঝেটা একটা commitment দিয়ে ঢাকো (লেসন ৪.৪), আর তার ওপরের ওঠানামার অংশটা On-Demand বা Spot-এ চলতে দাও।

1. প্রশ্নটা

   Triangle Sunglasses website চলছে একটা Application Load Balancer-এর পেছনের Auto Scaling group-এর EC2 instance-এ। টাকা বাঁচাতে group আগে থেকেই load balancer দিয়ে যাওয়া traffic দেখে scale করছে। high availability-র জন্য তার minimum capacity ২ করা হয়েছে। requirement মেনে খরচ আরও কীভাবে কমাবে? option: ALB সরিয়ে Elastic IP ব্যবহার করো; দুটো EC2 instance reserve করো; minimum capacity ১ করো; minimum capacity ০ করো।

2. প্রশ্নে লুকানো requirement-টা পড়ো

   “high availability-র জন্য minimum capacity ২” মানে traffic থাকুক বা না থাকুক, অন্তত দুটো instance সারাক্ষণ চলছে। এটা একটা স্থির ভিত্তি, লম্বা মেয়াদের commitment-এর একদম পাঠ্যবইয়ের উদাহরণ।

3. উত্তর: দুটো instance reserve করো

   group-এর instance type আর Region মিলিয়ে দুটো Reserved Instance কেনো (১ বা ৩ বছর, প্রায় ৭২% পর্যন্ত ছাড়), অথবা একই খরচের একটা Savings Plan (Compute Savings Plan প্রায় ৬৬% পর্যন্ত, EC2 Instance Savings Plan প্রায় ৭২% পর্যন্ত, আর পরে instance type বদলালেও নমনীয়)। দুটো requirement-ই টিকে থাকে: min ২ high availability রাখে, আর সবসময় চালু অংশটার খরচ অনেক কমে যায়। minimum-এর ওপরের instance-গুলো On-Demand (বা Spot)-এই থাকে।

4. অন্য option-গুলো কেন ভুল

   • ALB সরিয়ে Elastic IP: একটা Elastic IP একবারে একটাই instance-কে দেখায়। কোনো load balancing নেই, নিজে নিজে failover নেই, তাই availability শেষ, আর group ALB traffic দেখে scale-ও করতে পারবে না।
   • Minimum ১: সস্তা, কিন্তু একটা instance মানে single point of failure। সেটা crash করলে নতুনটা বুট না হওয়া পর্যন্ত site বন্ধ।
   • Minimum ০: traffic না থাকলে কোনো instance-ই থাকবে না, প্রথম visitor-রা error পাবে। কোনো অর্থেই highly available না।

প্রশ্নটা আরেকটা জিনিস ধরে নিয়েছে: দুটো instance তখনই highly available, যখন তারা দুটো আলাদা AZ-এ থাকে। group-কে অন্তত দুটো AZ-এর subnet দাও, ASG প্রতিটায় একটা করে বসাবে।

#এক নজরে পরীক্ষার ধরন

#System design-এ ASG কীভাবে ব্যবহার হয়

• Web আর API tier: তিনটা AZ জুড়ে private subnet-এ stateless instance-এর একটা ASG, public subnet-এর একটা ALB-এর পেছনে, CPU বা প্রতি target-এ request দেখে scale করে। session থাকে ElastiCache বা DynamoDB-তে (Chapter ৭), কখনো instance-এ না, তাই যেকোনো instance যেকোনো সময় terminate করা যায়।
• Worker fleet: instance-গুলো SQS থেকে job পড়ে আর প্রতি instance-এ backlog দেখে scale করে, প্রায়ই বেশিরভাগটা Spot-এ, capacity rebalancing-সহ।
• নিজে নিজে সেরে ওঠা single server: যে পুরনো application cluster করা যায় না, সেও ১-এর একটা ASG থেকে স্বয়ংক্রিয় বদল পায়, সাথে launch lifecycle hook-এ Elastic IP বা DNS update।
• Immutable deployment: নতুন AMI বানাও, একটা launch template version বানাও, instance refresh চালাও (অথবা নতুন একটা ASG বানিয়ে traffic সরাও)। instance-কে কখনো জায়গায় দাঁড়িয়ে patch করা হয় না।
• খরচের স্তর: Reserved Instance বা Savings Plan ঢাকে minimum, তার ওপরের base ঢাকে On-Demand, peak সামলায় Spot, আর জানা peak-এর জন্য আগেই তৈরি থাকে scheduled আর predictive scaling।
• EC2-এর বাইরে Application Auto Scaling একই target tracking, step আর scheduled ধারণা দেয় ECS service, DynamoDB table, Aurora replica, Lambda provisioned concurrency আর আরও অনেক কিছুকে।

#নিজে করে দেখো

# 1. A group of 2 to 6 instances across three private subnets, behind an existing target group,
#    using launch template web-lt (lesson 4.3) at its default version
aws autoscaling create-auto-scaling-group --auto-scaling-group-name web-asg \
  --launch-template 'LaunchTemplateName=web-lt,Version=$Default' \
  --min-size 2 --max-size 6 --desired-capacity 2 \
  --vpc-zone-identifier "subnet-0aaa1111,subnet-0bbb2222,subnet-0ccc3333" \
  --target-group-arns "$TG_ARN" \
  --health-check-type ELB --health-check-grace-period 300 \
  --default-instance-warmup 180

# 2. Target tracking: keep average CPU at 50%
aws autoscaling put-scaling-policy --auto-scaling-group-name web-asg \
  --policy-name cpu-50 --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "PredefinedMetricSpecification": {"PredefinedMetricType": "ASGAverageCPUUtilization"},
    "TargetValue": 50.0 }'

#    ...or keep about 1,000 requests per instance per minute
aws autoscaling put-scaling-policy --auto-scaling-group-name web-asg \
  --policy-name req-1000 --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "PredefinedMetricSpecification": {"PredefinedMetricType": "ALBRequestCountPerTarget",
      "ResourceLabel": "app/web-alb/50dc6c495c0c9188/targetgroup/web-tg/943f017f100becff"},
    "TargetValue": 1000.0 }'

# 3. Scheduled actions: more capacity for the Friday sale, back to normal at night
aws autoscaling put-scheduled-update-group-action --auto-scaling-group-name web-asg \
  --scheduled-action-name friday-sale --recurrence "45 16 * * 5" --time-zone "Asia/Dhaka" \
  --min-size 4 --desired-capacity 4
aws autoscaling put-scheduled-update-group-action --auto-scaling-group-name web-asg \
  --scheduled-action-name friday-night --recurrence "0 2 * * 6" --time-zone "Asia/Dhaka" \
  --min-size 2

# 4. Predictive scaling, forecast only to start with
aws autoscaling put-scaling-policy --auto-scaling-group-name web-asg \
  --policy-name predict-cpu --policy-type PredictiveScaling \
  --predictive-scaling-configuration '{
    "MetricSpecifications": [{"TargetValue": 50,
      "PredefinedMetricPairSpecification": {"PredefinedMetricType": "ASGCPUUtilization"}}],
    "Mode": "ForecastOnly", "SchedulingBufferTime": 600 }'

# 5. A terminating lifecycle hook (5-minute timeout), and how a script completes it
aws autoscaling put-lifecycle-hook --auto-scaling-group-name web-asg \
  --lifecycle-hook-name save-logs \
  --lifecycle-transition autoscaling:EC2_INSTANCE_TERMINATING \
  --heartbeat-timeout 300 --default-result CONTINUE
aws autoscaling complete-lifecycle-action --auto-scaling-group-name web-asg \
  --lifecycle-hook-name save-logs --instance-id i-0abc1234def567890 \
  --lifecycle-action-result CONTINUE

# 6. Watch what the group is doing, and why
aws autoscaling describe-scaling-activities --auto-scaling-group-name web-asg --max-items 5 \
  --query "Activities[].[StartTime,StatusCode,Description,Cause]"
aws autoscaling describe-auto-scaling-instances \
  --query "AutoScalingInstances[].[InstanceId,AvailabilityZone,LifecycleState,HealthStatus]"

# 7. Protect, park and refresh
aws autoscaling set-instance-protection --auto-scaling-group-name web-asg \
  --instance-ids i-0abc1234def567890 --protected-from-scale-in
aws autoscaling enter-standby --auto-scaling-group-name web-asg \
  --instance-ids i-0abc1234def567890 --should-decrement-desired-capacity
aws autoscaling exit-standby --auto-scaling-group-name web-asg --instance-ids i-0abc1234def567890
aws autoscaling start-instance-refresh --auto-scaling-group-name web-asg \
  --preferences '{"MinHealthyPercentage": 90, "InstanceWarmup": 180}'

# 8. Mixed instances: base 2 On-Demand, the rest 75% Spot, several types, capacity rebalancing
aws autoscaling update-auto-scaling-group --auto-scaling-group-name web-asg --capacity-rebalance \
  --mixed-instances-policy '{
    "LaunchTemplate": {"LaunchTemplateSpecification": {"LaunchTemplateName": "web-lt", "Version": "$Default"},
      "Overrides": [{"InstanceType": "m7i.large"}, {"InstanceType": "m6i.large"}, {"InstanceType": "c7i.large"}]},
    "InstancesDistribution": {"OnDemandBaseCapacity": 2, "OnDemandPercentageAboveBaseCapacity": 25,
      "SpotAllocationStrategy": "price-capacity-optimized"} }'

#সারসংক্ষেপ

মূল কথাগুলো

• Auto Scaling group সুস্থ instance-এর সংখ্যা desired-এ ধরে রাখে, সবসময় min আর max-এর মাঝে, নষ্ট instance বদলে দেয়, একটা Region-এর AZ জুড়ে ছড়িয়ে রাখে আর rebalance করে। group নিজে ফ্রি; টাকা দাও instance-এর।
• instance চালু হয় একটা launch template থেকে। Launch configuration legacy: ২০২৩ থেকে নতুন instance type নেই, আর অক্টোবর ২০২৪ থেকে খোলা account-এ বানানোই যায় না। On-Demand/Spot mix আর version-এর জন্য launch template লাগে।
• load balancer থাকলে instance নিজে নিজে register আর deregister হয়। default health check type EC2 (মেশিন বেঁচে আছে কি না); ELB চালু করো, যাতে application ভেঙে পড়া instance-ও বদলায়। grace period (console-এ ৩০০ s, CLI-তে ০) নতুন instance-কে চালু হওয়ার সময় দেয়।
• Target tracking (recommended) প্রতি instance-এর একটা metric-কে target-এর কাছে রাখে: CPU, ALBRequestCountPerTarget, network, অথবা SQS-এর প্রতি instance-এ backlog-এর মতো custom metric। দ্রুত scale out করে, ধীরে scale in। মোট সংখ্যা, latency আর queue-র কাঁচা দৈর্ঘ্য খারাপ metric।
• Step আর simple scaling তোমার CloudWatch alarm-এ চলে; জানা সময় সামলায় scheduled action; predictive scaling সর্বোচ্চ ১৪ দিনের ইতিহাস থেকে ৪৮ ঘণ্টার forecast করে, শুরু হয় forecast only mode-এ, আর কখনো scale in করে না।
• cooldown (৩০০ s) খাটে simple scaling-এ। target tracking আর step scaling ব্যবহার করে default instance warm-up, যেটা দিতে AWS জোর দিয়ে বলে। runaway scaling থামে ঠিক warm-up (simple scaling-এ cooldown) আর একটা ready-to-serve AMI দিয়ে।
• Lifecycle hook instance-কে থামায় launch-এ (Pending:Wait) বা terminate-এ (Terminating:Wait, default timeout ১ ঘণ্টা)। Standby instance-কে সরিয়ে রাখে, detach বের করে দেয়, scale-in protection scale in থেকে বাঁচায়।
• default termination policy: আগে AZ-এর ভারসাম্য, তারপর পুরনো configuration (সবচেয়ে পুরনো template version), তারপর billing hour-এর সবচেয়ে কাছে যে। Instance refresh, maximum instance lifetime আর warm pool fleet-কে টাটকা আর দ্রুত রাখে।
• mixed instances policy ঠিক করে একটা On-Demand base আর তার ওপরে একটা শতাংশ; Spot-এর জন্য price-capacity-optimized আর capacity rebalancing নাও।
• minimum capacity সারাক্ষণ চলে: এটাকে Reserved Instance বা Savings Plan দিয়ে ঢাকো (Triangle Sunglasses: দুটো instance reserve করো), আর অন্তত দুটো AZ জুড়ে ছড়াও।

নিজেকে যাচাই করো: Auto Scaling group আর scaling policy৩০টি প্রশ্ন