ECS Scaling আর Event-driven Task

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

• ECS-এ scaling-এর দুই স্তর বুঝিয়ে বলতে: একটা service-এ কয়টা task, আর সেই task-গুলো যে capacity-র ওপর চলে (EC2 instance বা Fargate)।
• Application Auto Scaling দিয়ে ECS Service Auto Scaling বসাতে: CPU, memory বা ALB-র request per target-এর ওপর target tracking, step scaling, scheduled scaling, আর পাশের খবর হিসেবে predictive scaling; একটা target tracking policy কোন desired count বসাবে, সেটা হিসাব করতে।
• Container instance-এর জন্য CPU দেখে চলা Auto Scaling group কেন ভুল হাতিয়ার, আর managed scaling, target capacity আর managed termination protection সহ capacity provider কীভাবে সেটা ঠিক করে, বুঝিয়ে বলতে; CapacityProviderReservation হিসাব করতে।
• Base আর weight দিয়ে একটা capacity provider strategy লিখতে, Fargate আর Fargate Spot মেশাতে, আর Fargate Spot interruption সামলাতে (দুই মিনিটের সতর্কবার্তা, SIGTERM, stopTimeout)।
• Event থেকে task চালাতে: S3 upload-এ একটা EventBridge rule, একটা EventBridge Scheduler schedule, আর SQS worker-এর একটা service, যেটা backlog per task দেখে বাড়ে-কমে।
• Task state change event-এর ওপর EventBridge rule বসিয়ে থেমে যাওয়া task ধরতে, আর SNS দিয়ে সতর্কবার্তা পাঠাতে।

#Scaling-এর দুই স্তর

লেসন ১৪.২-এ তুমি ঢাকার একটা online shop-এর checkout API চালিয়েছিলে একটা ECS service হিসেবে: একটা task definition, task-এর একটা desired count, সামনে একটা ALB। সাধারণ দিনে দুটো task-ই যথেষ্ট। ঈদের sale-এর প্রথম রাতে মোটেও না।

Container application-এর scaling ঘটে দুই স্তরে, আর পরীক্ষা দেখে তুমি এই দুটো আলাদা রাখতে পারো কিনা:

Fargate-এ দ্বিতীয় স্তরটাই নেই: প্রতিটা task AWS থেকে নিজের capacity পায়, তাই তুমি শুধু task বাড়াও-কমাও। এজন্যই Fargate-এ auto scaling বসানো অনেক সহজ। EC2-তে শুধু task বাড়ালে চলে না: instance ভরে গেলে নতুন task-এর যাওয়ার জায়গাই থাকে না।

#ECS Service Auto Scaling

ECS Service Auto Scaling একটা service-এর desired task-এর সংখ্যা নিজে নিজে বাড়ায়-কমায়। কাজটা ECS নিজে করে না: সে ব্যবহার করে Application Auto Scaling, সেই একই service, যেটা DynamoDB table, Aurora replica আর Lambda-র provisioned concurrency বাড়ায়-কমায়।

তুমি service-টাকে একটা scalable target হিসেবে register করো, তিনটা জিনিস দিয়ে:

• scalable dimension ecs:service:DesiredCount,
• একটা minimum capacity (যেমন ২টা task, যাতে একটা task বিকল হলেও service টিকে থাকে; যে worker ঘুমিয়ে থাকতে পারে, তার জন্য ০-ও চলে),
• একটা maximum capacity (খরচ আর নিরাপত্তার ছাদ, যেমন ২০টা task)।

তারপর এক বা একাধিক scaling policy লাগাও। ECS প্রতি মিনিটে service-এর গড় CPU আর memory CloudWatch-এ পাঠায়, আর policy-গুলো সেগুলো বা অন্য যেকোনো CloudWatch metric দেখে কাজ করে।

#Target tracking scaling

Note বলছে এটাই সবচেয়ে বেশি ব্যবহৃত policy, AWS-ও এটারই পরামর্শ দেয়: তুমি বলে দাও “সব task-এর গড় CPU ৭০%-এ ধরে রাখো”, বাকিটা Application Auto Scaling করে, ঠিক ঘরের thermostat-এর মতো। সে তোমার হয়ে দুটো CloudWatch alarm বানায় আর চালায় (ওগুলোতে হাত দিও না): একটা scale-out alarm, যেটা target-এর ওপরে টানা ৩টা এক-মিনিটের data point দেখলে সাড়া দেয়, আর একটা scale-in alarm, যেটা নিচে ১৫টা data point-এর অপেক্ষা করে।

ECS service-এর জন্য তৈরি করা predefined metric তিনটা:

চাইলে একটা custom metric বা একটা metric math expression-ও track করা যায় (এই লেসনের পরের দিকের SQS উদাহরণ), শর্ত একটাই: task-এর সংখ্যার অনুপাতে সেটা ওঠানামা করতে হবে।

Target tracking কয়টা task চায়? মোটামুটি অনুপাত মেনে:

নতুন desired count = এখন চালু task × এখনকার metric ÷ target, ওপরের দিকে রাউন্ড করা।

Note-এর ৭০% CPU target ধরে: ২টা task ৯০%-এ → ২ × ৯০ ÷ ৭০ = ২.৫৭ → ৩টা task। চাপ বাড়তেই থাকলে, ৩টা task ৮৫%-এ → ৩.৬ → ৪টা task। Scale out করার সময় সে সবসময় ওপরের দিকে রাউন্ড করে: capacity একটু বেশি হলে সামান্য টাকা যায়, কম হলে যায় ক্রেতা।

এর আচরণের কয়েকটা নিয়ম:

• সে শুরু করে চালু task-এর সংখ্যা থেকে, desired count থেকে না। Task বসানো না গেলে সে desired count-এর ওপর আরও চাপাতে থাকে না (লাগামছাড়া scaling হয় না)।
• Scale-out দ্রুত, scale-in ইচ্ছে করেই ধীর। Scale-in ১৫টা কম data point-এর অপেক্ষা করে, আর একটা task সরায় তখনই, যখন বাকিরা target-এর বেশ নিচে থাকবে (সাধারণত ১০%-এর বেশি নিচে)।
• Cooldown ECS service-এ default ৩০০ সেকেন্ড। Scale-out cooldown চলাকালীন শুধু বড় scale-out হতে পারে; scale-in cooldown চলাকালীন কোনো scale-in হয় না, কিন্তু scale-out ঠিকই হতে পারে।
• একটা service-এ কয়েকটা policy থাকলে (ধরো CPU আর request): যেকোনো একটা policy বেশি চাইলেই scale out হয়, আর scale in হয় শুধু সবাই রাজি হলে।
• চাইলে একটা policy-র scale-in বন্ধ করে অন্য উপায়ে task সরাতে পারো।
• EC2-তে CPU ১০০%-এর ওপরেও দেখাতে পারে। Metric-টা ব্যবহার হওয়া CPU-কে task-এর reserve করা CPU-র সাথে তুলনা করে; EC2-তে hard limit ছাড়া একটা container instance-এর অলস CPU ধার নিতে পারে। Fargate-এ একটা task যতটা চেয়েছে, তার বেশি ব্যবহার করতে পারে না।

নিজের সংখ্যা দিয়ে চেষ্টা করো। শেষ সারি, instance প্রতি কয়টা task, এই স্তরটাকে পরের স্তরের সাথে জুড়ে দেয়:

#Step scaling

Step scaling-এ CloudWatch alarm তুমি নিজে বানাও (“২ মিনিট ধরে গড় CPU ৭০%-এর ওপরে”), আর metric সেটা কতটা ছাড়িয়ে গেছে, সেই অনুযায়ী ধাপ ঠিক করো: ৭০–৮৫% → ১টা task যোগ, ৮৫%-এর ওপরে → ২টা task যোগ, কিংবা চালু task-এর একটা শতাংশ যোগ। Scale-in-এর জন্য দ্বিতীয় একটা policy আর দ্বিতীয় একটা নিচের alarm লাগে।

এটা বেছে নাও যখন পুরো নিয়ন্ত্রণ চাও: হঠাৎ ভিড়ে খুব দ্রুত সাড়া (high-resolution metric আর এক data point-এর alarm), বড় লঙ্ঘনে বড় লাফ, কিংবা scale out আর scale in-এর জন্য আলাদা নিয়ম। দাম হলো alarm আর ধাপগুলো তোমাকেই বানাতে আর ঘষামাজা করতে হয়; এজন্যই default উত্তর target tracking। (Simple scaling, মানে লেসন ৬.৫-এর সেই পুরোনো “একবার যোগ করো, তারপর অপেক্ষা” policy, EC2 Auto Scaling group-এ আছে; ECS-এর জন্য step scaling নাও।)

#Scheduled scaling

একটা scheduled action একটা নির্দিষ্ট তারিখ-সময়ে minimum আর maximum capacity বদলে দেয়, একবার বা time zone সহ একটা cron schedule মেনে। এটা আগে থেকে জানা পরিবর্তনের জন্য: ঈদের sale শুরু রাত ৮টায়, ক্রিকেটের ফাইনাল দুপুর ২টায়, অফিস শুরু সকাল ৯টায়। সন্ধ্যা ৭:৪৫-এ min ১০ করো, প্রথম ক্রেতা আসার আগেই task-গুলো চালু আর তৈরি থাকবে; রাত ২টায় min আবার ২ করো। Target tracking এই সীমার ভেতরে কাজ করতেই থাকে, তাই sale আন্দাজের চেয়ে বড় হলেও max পর্যন্ত task যোগ করে। Scheduled action কোনো cooldown-এর অপেক্ষা না করে নিজের সময়েই চলে।

#Scaling আর deployment

একটা ECS deployment চলার সময় (নতুন task definition-এ rolling update, লেসন ১৪.২) Application Auto Scaling service-এর scale-in বন্ধ রাখে, যাতে deployment যে task-গুলোর ভরসায় আছে, সেগুলো সরিয়ে না ফেলে। Scale-out চলতে থাকে, তাই deployment-এর মাঝে হঠাৎ ভিড় এলেও সামলানো যায়। Deployment-এর সময় একদমই scaling না চাইলে scalable target-এ dynamic scaling থামিয়ে রাখো (DynamicScalingInSuspended আর DynamicScalingOutSuspended), পরে আবার চালু করো।

#নিচের EC2 capacity বাড়ানো-কমানো

EC2 launch type-এ task-গুলোর দরকার register করা container instance-এ খালি CPU আর memory reservation। Service Auto Scaling যদি instance-এর ধারণক্ষমতার চেয়ে বেশি task চায়, তোমার আরও instance লাগবে।

#পুরোনো উপায়: CPU দেখে একটা Auto Scaling group

Slide প্রথম উপায়টা দেখায়: container instance-গুলোকে একটা Auto Scaling group-এ রাখো, আর instance-এর CPU utilization-এর ওপর একটা scaling policy দাও, যাতে সময়ের সাথে instance যোগ হয়। কিছু না থাকার চেয়ে ভালো, কিন্তু এটা ভুল জিনিস মাপে:

• ECS task বসায় reservation দেখে: যে task ১ vCPU reserve করেছে, সে ওই vCPU-র মাত্র ১০% ব্যবহার করলেও পুরোটা আটকে রাখে। একটা instance ভরা থাকতে পারে (আরেকটা task-এর জায়গা নেই), অথচ তার CPU ৪০%। ASG দেখে ৪০%, চুপ করে বসে থাকে, আর নতুন task বসানো যায় না।
• ASG জানেই না কোন task বসার অপেক্ষায় আছে, অথচ ঠিক এই সংকেতটাই তোমার দরকার।
• Scale-in-এর সময় ASG নিজের termination policy মেনে instance বাছে, আর এমন instance-ও বন্ধ করে দিতে পারে যেখানে task চলছে।

#Capacity provider দিয়ে cluster auto scaling

একটা capacity provider একটা ECS cluster-কে capacity-র একটা উৎসের সাথে জোড়ে। EC2-র জন্য তুমি একটা Auto Scaling group capacity provider বানাও (প্রতি capacity provider-এ একটা ASG), cluster-এর সাথে যুক্ত করো, আর দুটো feature চালু করো।

Managed scaling (ECS cluster auto scaling)। ECS Auto Scaling group-এ একটা target tracking policy বানায়, আর সেটা চালায় নিজের হিসাব করা একটা metric দিয়ে:

CapacityProviderReservation = দরকারি instance (M) ÷ চালু instance (N) × ১০০

M গোনে সব task কী চায়, যেগুলো এখনো বসানো হয়নি সেগুলো সহ: capacity provider থাকলে যে task জায়গা পায় না, সে ব্যর্থ না হয়ে PROVISIONING অবস্থায় অপেক্ষা করে। ECS metric-টা CloudWatch-এ পাঠায় (namespace AWS/ECS/ManagedScaling), আর সেটাকে তোমার target capacity-তে ধরে রাখে:

• Target capacity ১০০% (default): কোনো বাড়তি instance নেই। ১০০%-এর ওপরে গেলে group বাড়ে, নিচে নামলে কমে। প্রতিটা scale-out-এ একটা instance boot হওয়ার অপেক্ষা।
• Target capacity ১০০%-এর নিচে: বাড়তি জায়গা। ৮০%-এ ECS রাখে N = M ÷ ০.৮, তাই ৮টা instance দরকার হলে চালায় ১০টা, আর নতুন task সাথে সাথে একটা তৈরি instance-এ বসে যায়। অলস instance-গুলোর টাকাও তুমি দাও।

Managed scaling-এর আরও কিছু setting: minimum আর maximum scaling step size (একবারে কয়টা instance যোগ হবে; default ১ আর ১০,০০০), আর instance warm-up period (নতুন instance metric-এ গোনা হওয়ার আগে default ৩০০ সেকেন্ড)। Group শূন্যে থাকলে আর task-এর capacity দরকার হলে ECS শুরুতেই ২টা instance চালু করে। ECS group-এর নিজের min আর max কখনো বদলায় না, তাই max যথেষ্ট উঁচু রাখতে হবে।

Managed termination protection। যে instance-এ task চলছে, তার প্রত্যেকটায় ECS instance scale-in protection চালু রাখে, আর সরায় শুধু সেই instance থেকে, যেখানে কোনো task নেই (daemon task ধরা হয় না)। ফলে ASG শুধু খালি instance-ই বন্ধ করতে পারে। এর জন্য managed scaling আর Auto Scaling group-এ scale-in protection চালু থাকা লাগে। তার ওপর managed instance draining (default-এ চালু) যেকোনো কারণে ASG একটা instance বন্ধ করার আগে তার service task-গুলো অন্যত্র সরিয়ে নেয়।

একটা হিসাব করে দেখো: ১০টা task, প্রতি instance-এ ২টা ধরে, তাই M = ৫। চালু আছে ৪টা instance: reservation = ৫ ÷ ৪ × ১০০ = ১২৫%, ১০০%-এর target-এর ওপরে, তাই group বেড়ে ৫ হয়। পরে service কমে ৬টা task-এ নামে: M = ৩, N = ৫, reservation ৬০%, তাই group কমে ৩-এ নামে, আর managed termination protection থাকায় শুধু খালি instance-গুলোই যায়।

#Capacity provider strategy: base আর weight

একটা capacity provider strategy ECS-কে বলে দেয় একটা service বা একটা RunTask call-এর task কোথায় বসবে। এটা পুরোনো “launch type” বাছাইয়ের জায়গা নিয়েছে, capacity বাছার আধুনিক উপায় এটাই। Fargate-এর দুটো তৈরি capacity provider আছে, FARGATE আর FARGATE_SPOT, এগুলো শুধু cluster-এর সাথে যুক্ত করলেই হয়। Strategy-র প্রতিটা item-এ থাকে:

• base: এই provider-এ অন্তত কয়টা task চলবে। একটা strategy-তে শুধু একটা provider-এরই base থাকতে পারে। Base পূরণ হয় সবার আগে।
• weight: base-এর পর বাকি task-গুলো weight-এর অনুপাতে ভাগ হয়। Weight ০ হলে base-এর পরের ভাগ থেকে সেই provider কিছুই পায় না। AWS-এর docs বলে weight ০-এর provider task বসাতেই পারে না, তাই যে provider-এ base রাখছ, তাকে অন্তত weight ১ দিয়ো, নিচের উদাহরণের মতো।

উদাহরণ: FARGATE base ২, weight ১; FARGATE_SPOT weight ৩। Desired count ৬ হলে: প্রথম ২টা task যায় Fargate-এ (base); বাকি ৪টা ভাগ হয় ১ : ৩-এ, মানে আরও ১টা Fargate-এ আর ৩টা Fargate Spot-এ। ফল: ৩টা Fargate-এ, ৩টা Fargate Spot-এ। ১০টা task হলে: ২ + (৮-কে ১ : ৩-এ ভাগ = ২ আর ৬), মানে ৪টা Fargate-এ আর ৬টা Spot-এ।

যে নিয়মগুলো মনে রাখার মতো:

• একটা strategy-তে ২০টা পর্যন্ত capacity provider থাকতে পারে, কিন্তু সেখানে থাকবে হয় Fargate provider, নয় Auto Scaling group provider, দুটো একসাথে কখনো না। তবে একটা cluster-এ দুই ধরনই থাকতে পারে, আলাদা আলাদা service ব্যবহার করবে।
• একটা cluster-এর একটা default capacity provider strategy থাকতে পারে, যেটা ব্যবহার হয় যখন service বা task strategy বা launch type কোনোটাই বলে না।
• একটা service-কে launch type থেকে capacity provider strategy-তে নিতে নতুন deployment লাগে (force new deployment)।
• EC2-তে একই ভাবনায় মেশানো যায় দুটো Auto Scaling group: একটা On-Demand instance-এর, base সহ, আরেকটা Spot Instance-এর, বেশি weight সহ (Spot Instance, লেসন ৪.৪)।

#Fargate Spot

Fargate Spot task চালায় Fargate-এর অব্যবহৃত capacity-তে, Fargate-এর দামের চেয়ে সর্বোচ্চ ৭০% কমে। দাম চলে দীর্ঘমেয়াদি যোগান-চাহিদা মেনে; কোনো নিলাম-দর নেই। বিনিময়ে AWS capacity ফেরত নিতে পারে:

• দুই মিনিটের সতর্কবার্তা। ECS EventBridge-এ একটা task state change event পাঠায় (stop code SpotInterruption, কারণ “Your Spot Task was interrupted.”) আর container-গুলোকে একটা SIGTERM।
• ভদ্রভাবে বন্ধ হওয়া। Application-কে SIGTERM ধরতে হবে, নতুন কাজ নেওয়া বন্ধ করতে হবে, হাতের কাজ শেষ করতে বা checkpoint রাখতে হবে, তারপর বের হতে হবে। Container-এর stopTimeout পেরোলে (default ৩০ সেকেন্ড, Fargate-এ সর্বোচ্চ ১২০ সেকেন্ড) ECS পাঠায় SIGKILL; যা শেষ হয়নি, task-এর ephemeral storage সহ, সব হারায়।
• বদলি task। Service টের পায় একটা task কম, আর Fargate Spot-এই নতুন একটা চালু করে, যদি Spot capacity থাকে। ECS নিজে থেকে নিয়মিত Fargate-এ চলে যায় না, তাই capacity-র টানাটানির সময় Spot task-গুলো অনুপস্থিত থেকে যেতে পারে; যে service-এর একমাত্র task Spot-এ, সে capacity ফেরা পর্যন্ত বন্ধ। নিয়মিত Fargate-এ base রাখা ঠিক এজন্যই।
• কোথায় চলে। x86-এ Linux task (platform version ১.৩.০ বা পরের) আর 64-bit Arm, ARM64-এ (১.৪.০ বা পরের); Windows container-এ না। Fargate Spot একটা ECS-এর feature; Fargate-এ চলা EKS pod এটা ব্যবহার করতে পারে না (লেসন ১৪.৪)।

ভালো মানায়: ALB-র পেছনের stateless web task, নিয়মিত Fargate-এ base সহ; idempotent queue worker (থেমে যাওয়া worker-এর message queue-তে ফিরে আসে); CI build agent; checkpoint রাখা batch job। মানায় না: memory-তে state রাখা একটা মাত্র task, যে লম্বা কাজ মাঝখান থেকে আবার শুরু করা যায় না, আর হঠাৎ capacity হারানো যার একদমই চলবে না।

#Event-driven ECS task

সব container load balancer-এর পেছনে দিনরাত চলা service না। অনেক কাজ শুরু হওয়া উচিত কিছু একটা ঘটেছে বলে, একবার চলে থেমে যাওয়া উচিত: টাকা লাগে শুধু যতক্ষণ task চলে। এখানে কোনো service নেই, desired count-ও নেই; কেউ একজন তোমার হয়ে ECS-এর RunTask API call করে।

#EventBridge rule দিয়ে task চালু

Slide-এর উদাহরণ: একজন client একটা S3 bucket-এ object upload করে; S3 Amazon EventBridge-এ একটা event পাঠায়; একটা rule সেটা মেলায়, আর তার target হলো একটা Fargate cluster-এ “ECS task চালাও”; নতুন task S3 থেকে object-টা নেয়, process করে, ফল রাখে DynamoDB-তে।

যা যা config করতে হয়:

1. S3-এর event EventBridge-এ পাঠাও

   Bucket-এ EventBridge notification চালু করো (লেসন ১০.৭)। পুরোনো ধাঁচের S3 event notification যায় শুধু SQS, SNS আর Lambda-তে; ECS task তাদের গন্তব্য না, এজন্যই মাঝখানে EventBridge বসে।

2. Rule লেখো

   source: aws.s3, detail-type: Object Created, bucket-এর নাম আর ধরো prefix raw/-এর ওপর একটা event pattern। EventBridge নিজে বিস্তারিত আছে লেসন ১৯.৫-এ।

3. Target-কে cluster-এর দিকে তাক করো

   Target type ECS task: cluster, task definition, launch type বা capacity provider strategy, আর Fargate হলে network configuration (subnet, security group), যেটা বাধ্যতামূলক, কারণ Fargate task awsvpc ব্যবহার করে। একটা input transformer container override দিয়ে bucket আর key-কে container-এ environment variable হিসেবে পাঠাতে পারে। TaskCount দিয়ে প্রতি event-এ কয়েকটা task চালু করা যায়।

4. প্রত্যেককে তার নিজের role দাও

   EventBridge-এর এমন একটা role লাগে, যেটা সে নিতে পারে, আর যাতে আছে ecs:RunTask আর task-এর execution role ও task role-এর জন্য iam:PassRole। Task নিজে S3 পড়তে আর DynamoDB-তে লিখতে ব্যবহার করে তার task role (ECS-এর তিন role, লেসন ১৪.২)। EventBridge-এর role আর task-এর role এক জিনিস না।

#EventBridge Scheduler দিয়ে নির্দিষ্ট সময়ের task

Slide-এর দ্বিতীয় ছবি: একটা schedule (“প্রতি ১ ঘণ্টায়”) একটা ECS task চালায়, যেটা S3-এর data নিয়ে batch processing করে। এটা দুই উপায়ে করা যায়:

নতুন schedule-এর জন্য AWS এখন EventBridge Scheduler-এর পরামর্শ দেয় (ECS console থেকেও scheduled task বানানো যায়, তবে Scheduler console-এ বিকল্প বেশি)। পরীক্ষার জন্য, “একটা ECS task schedule মেনে চালাও (cron)” → ECS task target সহ EventBridge (যেকোনো রূপে)। Cron চালানোর জন্য কোনো server লাগে না, সারাদিন ঘুমিয়ে থাকা desired count ১-এর service-ও লাগে না।

উদাহরণ: একটা garment রপ্তানিকারক প্রতি রাতে ঢাকার সময় ১টায় বেতনের হিসাব করে। Asia/Dhaka time zone-এ cron(0 1 * * ? *) schedule Fargate-এ payroll task চালায়; সে S3 থেকে দিনের হাজিরা পড়ে, বেতনের slip আবার S3-এ লেখে, ২০ মিনিট পর বের হয়ে যায়। ২৪ ঘণ্টা চলা একটা server-এর বদলে দিনে ২০ মিনিটের Fargate।

#Queue worker: SQS দেখে বাড়া-কমা একটা ECS service

Slide-এর তৃতীয় ধরন: message আসে একটা SQS queue-তে, আর worker task-এর একটা ECS service queue poll করে; queue বড় হলে ECS Service Auto Scaling task যোগ করে। ওপরের দুটোর মতো না, এটা দিনরাত চলা service: worker-রা চালু থাকে আর message টেনে নেয় (SQS task চালু করে না; সে pull-based, লেসন ১৩.১)।

কোন metric? CPU না: network-এর অপেক্ষায় থাকা worker-দের CPU কম দেখায়, অথচ queue ফুলে-ফেঁপে ওঠে। আবার শুধু queue-র দৈর্ঘ্যও না: ApproximateNumberOfMessagesVisible-এর ওপর একটা target tracking policy জানেই না আগে থেকে কয়টা worker আছে, তাই queue কমতে থাকলেও task যোগ করতেই থাকে, কাজের দরকারের চেয়ে অনেক বেশি। ব্যবহার করো backlog per task, ঠিক লেসন ১৩.১-এর backlog per instance-এর মতো:

• Backlog per task = ApproximateNumberOfMessagesVisible (AWS/SQS থেকে) ÷ RunningTaskCount (ECS/ContainerInsights থেকে)।
• Target = সর্বোচ্চ গ্রহণযোগ্য অপেক্ষা ÷ একটা message process করতে গড় সময়।

ভাগটা target tracking policy নিজেই metric math দিয়ে করে নেয়; কোনো custom metric বা code লাগে না। শর্ত একটা: RunningTaskCount পাঠানো হয় শুধু cluster-এ Container Insights চালু থাকলে; না থাকলে expression-এর ভাজক নেই, service কখনো scale করে না।

AWS-এর নিজের উদাহরণ: গ্রহণযোগ্য latency ১০ সেকেন্ড, message প্রতি ০.১ সেকেন্ড → target প্রতি task-এ ১০০টা message। ১,৫০০টা message আর ১০টা task → প্রতি task-এ ১৫০ → service ৫টা task বাড়িয়ে ১৫-তে যায়।

লম্বা কাজ করা worker-এর জন্য task scale-in protection ব্যবহার করো: worker একটা কাজ শুরু করার সময় ECS agent endpoint ($ECS_AGENT_URI/task-protection/v1/state) দিয়ে ProtectionEnabled চালু করে, তখন scale-in বা deployment তাকে বন্ধ করবে না; কাজ শেষে সে flag-টা তুলে নেয়। Protection default-এ ২ ঘণ্টা থাকে, সর্বোচ্চ ৪৮ ঘণ্টা। Protection ছাড়াও কোনো message হারায় না: থেমে যাওয়া worker তার message কখনো delete করেনি, তাই visibility timeout-এর পর সেটা আবার দেখা দেয়।

#EventBridge দিয়ে থেমে যাওয়া task ধরা

ECS প্রতিটা task-এর জীবনের খবর EventBridge-এ পাঠায় ECS Task State Change event হিসেবে (আর অন্য resource-এর জন্য ECS Container Instance State Change আর ECS Service Action event)। কোনো task থামলে event-এ থাকে lastStatus: STOPPED, একটা stoppedReason, আর একটা stop code:

Slide-এর ধরন: একটা EventBridge rule, যার event pattern থেমে যাওয়া task মেলায় (source aws.ecs, detail-type ECS Task State Change, lastStatus STOPPED, তোমার cluster-এর ARN), একটা SNS topic চালু করে, আর সেটা administrator-কে email করে। SNS-এর বদলে একটা Lambda function chat channel-এ লিখতে, ticket খুলতে বা ব্যর্থ batch job আবার চালাতে পারে।

{
  "source": ["aws.ecs"],
  "detail-type": ["ECS Task State Change"],
  "detail": {
    "clusterArn": ["arn:aws:ecs:ap-southeast-1:111122223333:cluster/payroll-example"],
    "lastStatus": ["STOPPED"],
    "stopCode": ["EssentialContainerExited", "TaskFailedToStart"]
  }
}

Stop code দিয়ে ছাঁকা জরুরি: না হলে প্রতিটা scale-in আর প্রতিটা deployment রাত ৩টায় কাউকে না কাউকে ঘুম থেকে তুলবে।

#কোথায় গড়বড় হয়

#System design-এ ECS scaling

• Web আর API service: CPU বা ALBRequestCountPerTarget-এর ওপর target tracking, AZ জুড়ে অন্তত ২ বা তার বেশি minimum, জানা ঘটনার আগে একটা scheduled action, আর database যতটা নিতে পারে সেই মাপের max।
• আগে Fargate, যখন capacity-র স্তর সামলাতে চাও না; capacity provider সহ EC2, যখন নির্দিষ্ট instance type, GPU, খুব ঘন করে task বসানো বা Reserved Instance দরকার (লেসন ১৪.২); আর ECS Managed Instances, যখন patch করার ঝামেলা ছাড়া EC2-র বিকল্পগুলো চাও।
• খরচ: নিয়মিত capacity-তে একটা base, সাথে weight দিয়ে Spot-এর একটা ভাগ (Fargate Spot বা Spot Instance); স্থির base-এর জন্য Compute Savings Plans (লেসন ৪.৪)।
• Asynchronous কাজ: producer SQS-এ রাখে, একটা ECS worker service backlog per task দেখে বাড়ে-কমে, আর Spot worker চলে, কারণ task থামলেও message টিকে থাকে।
• Event-driven job: S3 বা ব্যবসার event EventBridge দিয়ে প্রতি event-এ একটা task চালু করে; schedule cron server-এর জায়গা নেয়। Lambda-র সাথে তুলনা করো (chapter ১৫): Lambda দ্রুত চালু হয় আর network-এর কোনো setup লাগে না; ECS task ১৫ মিনিটের বেশি চলে, বেশি memory নেয়, যেকোনো container image চালায়।
• Operations: অপ্রত্যাশিত থামা EventBridge দিয়ে জানাও, Container Insights-এ চোখ রাখো, আর ECS-এর বানানো scaling resource-এ (policy, alarm, tag) হাত দিও না।

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

একটা service-কে auto scaling-এর জন্য register করো, একটা target tracking policy দাও, Fargate Spot সহ একটা capacity provider strategy বসাও, আর event-driven অংশগুলো বানাও। Output ছোট করে দেখানো।

# 1. Service-কে scalable target হিসেবে register করো: ২ থেকে ২০টা task
aws application-autoscaling register-scalable-target \
  --service-namespace ecs --scalable-dimension ecs:service:DesiredCount \
  --resource-id service/shop-example/checkout --min-capacity 2 --max-capacity 20

# 2. Target tracking: গড় CPU ৭০%-এ ধরে রাখো
aws application-autoscaling put-scaling-policy --policy-name cpu70 \
  --service-namespace ecs --scalable-dimension ecs:service:DesiredCount \
  --resource-id service/shop-example/checkout --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 70.0,
    "PredefinedMetricSpecification": {"PredefinedMetricType": "ECSServiceAverageCPUUtilization"},
    "ScaleOutCooldown": 60, "ScaleInCooldown": 300 }'
# { "PolicyARN": "arn:aws:autoscaling:ap-southeast-1:111122223333:scalingPolicy:...",
#   "Alarms": [ { "AlarmName": "TargetTracking-service/shop-example/checkout-AlarmHigh-..." },
#               { "AlarmName": "TargetTracking-service/shop-example/checkout-AlarmLow-..." } ] }

# 3. Scheduled action: ঈদের sale-এর আগে min ১০টা task, ঢাকার সময়ে
aws application-autoscaling put-scheduled-action --service-namespace ecs \
  --scalable-dimension ecs:service:DesiredCount --resource-id service/shop-example/checkout \
  --scheduled-action-name eid-sale --schedule "at(2026-03-19T19:45:00)" \
  --timezone "Asia/Dhaka" --scalable-target-action MinCapacity=10,MaxCapacity=40

# 4. কী করল দেখো
aws application-autoscaling describe-scaling-activities --service-namespace ecs \
  --resource-id service/shop-example/checkout --max-items 2
# "Description": "Setting desired count to 3.",
# "Cause": "monitor alarm TargetTracking-...-AlarmHigh-... in state ALARM triggered policy cpu70"

# 5. EC2-র capacity provider: managed scaling আর termination protection সহ একটা ASG
aws ecs create-capacity-provider --name shop-asg-cp \
  --auto-scaling-group-provider 'autoScalingGroupArn=arn:aws:autoscaling:ap-southeast-1:111122223333:autoScalingGroup:...:autoScalingGroupName/shop-asg-example,managedScaling={status=ENABLED,targetCapacity=90},managedTerminationProtection=ENABLED'

# 6. Fargate cluster-এর provider আর default strategy: Fargate-এ base ২, তারপর Spot-এর সাথে ১ : ৩
aws ecs put-cluster-capacity-providers --cluster trips-example \
  --capacity-providers FARGATE FARGATE_SPOT \
  --default-capacity-provider-strategy capacityProvider=FARGATE,base=2,weight=1 \
      capacityProvider=FARGATE_SPOT,weight=3

aws ecs describe-tasks --cluster trips-example --tasks 0f1e2d3c4b5a69788796a5b4c3d2e1f0 \
  --query 'tasks[].{cp:capacityProviderName,status:lastStatus}'
# [ { "cp": "FARGATE_SPOT", "status": "RUNNING" } ]

# 7. প্রতি রাতে ঢাকার সময় ১টায় payroll task চালাও
aws scheduler create-schedule --name payroll-nightly \
  --schedule-expression "cron(0 1 * * ? *)" --schedule-expression-timezone "Asia/Dhaka" \
  --flexible-time-window Mode=OFF --target file://payroll-target.json

# 8. কোনো task অপ্রত্যাশিতভাবে থামলে admin-কে email করো
aws events put-rule --name ecs-task-stopped --event-pattern file://stopped-pattern.json
aws events put-targets --rule ecs-task-stopped \
  --targets Id=1,Arn=arn:aws:sns:ap-southeast-1:111122223333:ops-alerts-example

payroll-target.json-এ থাকে Arn হিসেবে cluster-এর ARN, একটা RoleArn, যেটা EventBridge Scheduler নিতে পারে (ecs:RunTask আর iam:PassRole সহ), আর EcsParameters-এ task definition, LaunchType বা একটা capacity provider strategy, সাথে subnet আর security group। stopped-pattern.json হলো ওপরে দেখানো event pattern। S3 trigger-এর জন্য aws s3api put-bucket-notification-configuration --bucket photos-example --notification-configuration '{"EventBridgeConfiguration": {}}' EventBridge-এ পাঠানো চালু করে, আর ধাপ ৮-এর মতো একটা rule, ECS target সহ, resize task চালায়।

#সারসংক্ষেপ

মূল কথা

• ECS বাড়ে-কমে দুই স্তরে: task (ECS Service Auto Scaling) আর, EC2 launch type-এ, instance (একটা Auto Scaling group, সবচেয়ে ভালো হয় capacity provider চালালে)। Fargate-এ শুধু task-এর স্তর, তাই Fargate-এর scaling সহজ।
• ECS Service Auto Scaling min আর max সহ ecs:service:DesiredCount-এর ওপর Application Auto Scaling ব্যবহার করে। Policy-র ধরন: target tracking (ECSServiceAverageCPUUtilization, ECSServiceAverageMemoryUtilization, ALBRequestCountPerTarget, বা custom/metric math), step scaling (তোমার alarm, তোমার ধাপ), scheduled scaling (জানা সময়); নভেম্বর ২০২৪ থেকে predictive scaling।
• Target tracking মোটামুটি চায় চালু × metric ÷ target, ওপরের দিকে রাউন্ড করা; দ্রুত বাড়ে, ধীরে কমে (ECS-এ default cooldown ৩০০ সেকেন্ড), max কখনো পেরোয় না, আর deployment চলাকালীন scale in করে না।
• CPU দেখে চলা ASG বসাতে-না-পারা task দেখতে পায় না। Managed scaling সহ capacity provider CapacityProviderReservation = M ÷ N × ১০০-কে একটা target capacity-র সাথে মেলায় (১০০% = বাড়তি নেই; ৮০% = বাড়তি instance)। অপেক্ষায় থাকা task বসে থাকে PROVISIONING-এ। Managed termination protection শুধু খালি instance বন্ধ করে।
• একটা capacity provider strategy task বসায় আগে base দিয়ে (শুধু একটা provider-এ), তারপর weight দিয়ে (অনুপাত)। Fargate আর ASG provider এক strategy-তে থাকতে পারে না।
• Fargate Spot: সর্বোচ্চ ৭০% সস্তা, EventBridge event আর SIGTERM দিয়ে দুই মিনিটের সতর্কবার্তা, stopTimeout-এর পর SIGKILL (default ৩০ সেকেন্ড, সর্বোচ্চ ১২০), নিয়মিত Fargate-এ নিজে থেকে যায় না; শুধু Linux।
• Event-driven task: একটা EventBridge rule event-এ task চালায় (S3 upload, EventBridge notification চালু থাকলে); EventBridge Scheduler যেকোনো time zone-এ cron বা rate schedule মেনে task চালায়। EventBridge-এর role-এ লাগে ecs:RunTask আর iam:PassRole; কাজটা চলে task role দিয়ে।
• SQS worker: একটা ECS service, যেটা বাড়ে-কমে backlog per task দেখে = queue-র গভীরতা ÷ RunningTaskCount (লাগে Container Insights), লম্বা কাজের জন্য task scale-in protection সহ।
• থেমে যাওয়া task: ECS Task State Change-এর ওপর একটা EventBridge rule, lastStatus STOPPED সহ (stop code দিয়ে ছাঁকা) → SNS email বা Lambda।

নিজেকে যাচাই করো: ECS scaling আর event-driven task৩১টি প্রশ্ন