Elastic Beanstalk

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

• Elastic Beanstalk developer-দের কোন সমস্যার সমাধান করে সেটা বোঝাতে, আর “নিজে সব করা বনাম AWS-এর হাতে ছেড়ে দেওয়া”-র রেখায় হাতে বানানো EC2 আর Lambda-র মাঝখানে একে বসাতে।
• Application, application version আর environment কী, environment-এর নাম, URL আর tier কী, আর আজকের দিনে Beanstalk কোন কোন platform চালায়, সেটা বলতে।
• একটা environment CloudFormation দিয়ে তোমার account-এ কী কী বানায়, টাকা কীসের জন্য দিতে হয়, আর configuration option, .ebextensions ও platform hook দিয়ে কীভাবে নিরাপদে বদলাতে হয়, সেটা বলতে।
• Single-instance আর load-balanced environment-এর মধ্যে বাছতে, আর কেন production database environment-এর ভেতরে রাখা উচিত না, সেটা ব্যাখ্যা করতে।
• Worker tier কীভাবে SQS ব্যবহার করে বোঝাতে: daemon, visibility timeout, retry, dead-letter queue আর cron.yaml।
• পাঁচটা deployment policy আর blue/green-কে downtime, capacity, সময় আর rollback দিয়ে তুলনা করতে, batch আর একসাথে সর্বোচ্চ কয়টা instance চলবে সেটা হিসাব করতে, আর নতুন version নষ্ট হলে কোনটা কী করে সেটা আগেই বলে দিতে।

#Developer-এর সমস্যাটা কী

#প্রতিটা web app-এর একই কলকবজা লাগে

গত তিনটা লেসনে আমরা একই ধরনের system বারবার বানিয়েছি। “এখন কটা বাজে?” site (লেসন ৯.১) আর কাপড়ের দোকান (লেসন ৯.২)-এর জন্য তুমি কয়েকটা AZ জুড়ে Auto Scaling group-এর সামনে একটা load balancer বসিয়েছ, health check দিয়েছ, tier থেকে tier-এ security group জুড়েছ, আর একটা database রেখেছ। WordPress blog-এর জন্য (লেসন ৯.৩) যোগ হলো shared storage, আর শিখলে কীভাবে দ্রুত instance চালু করতে হয়।

বেশিরভাগ web application-এর জন্য এই design-টাই ঠিক, আর সমস্যাটা ঠিক এখানেই। যে developer শুধু চায় তার code চলুক, তাকেও এগুলো করতে হয়:

• infrastructure বানানো আর চালানো: VPC-র সিদ্ধান্ত, security group, load balancer, launch template, Auto Scaling group;
• site না ভেঙে প্রতিটা instance-এ নতুন code পৌঁছানোর একটা উপায় বের করা;
• database, load balancer-এর listener, health check আর alarm configure করা;
• scaling নিয়ে ভাবা: কোন metric, কোন সীমা, কোন কোন AZ;
• আর এই সবকিছু প্রতিটা application আর প্রতিটা environment-এ (dev, test, prod) একইভাবে করা, যাতে “test-এ তো চলেছিল” কথাটার কোনো মানে থাকে।

প্রতিটা দল নিজের মতো করে, প্রতিবার একটু আলাদাভাবে, হাতে একই ALB + ASG কাঠামো বানাত। AWS Elastic Beanstalk হলো এর উত্তরে AWS-এর সমাধান: application deploy করার একটা developer-কেন্দ্রিক উপায়, যেখানে তুমি code তুলে দাও আর Beanstalk ওই চেনা architecture-টা তোমার জন্য বানিয়ে চালিয়ে দেয়।

#EC2 আর Lambda-র মাঝখানে Beanstalk কোথায়

Beanstalk হলো একটা PaaS (Platform as a Service, লেসন ১.১): application-এর code আর তার setting তুমি সামলাও, নিচের platform সামলায় AWS। “সব আমি করি” থেকে “প্রায় কিছুই আমি করি না” পর্যন্ত একটা রেখায় বসালে ব্যাপারটা পরিষ্কার হয়।

Notes-এ Beanstalk বাছার তিনটা কারণ আছে:

1. দ্রুত deployment: code কয়েক মিনিটের মধ্যে সোজা production-এর মতো একটা environment-এ চলে যায়।
2. পুরো নিয়ন্ত্রণ: serverless-এর মতো Beanstalk তোমাকে তালাবন্ধ করে রাখে না। সে যে EC2 instance আর load balancer বানায়, সেগুলো তোমার account-এই দেখা যায়, আর instance-এ login করে তুমি বদলাতেও পারো। (এর একটা শর্ত আছে, পরের অংশে বলছি।)
3. বিনা পয়সার service: Beanstalk নিজের জন্য কোনো টাকা নেয় না; টাকা দিতে হয় শুধু তার বানানো resource-গুলোর।

#খরচ কত

Elastic Beanstalk নিজে বিনা পয়সার। বিল হলো তার বানানো জিনিসগুলোর যোগফল: EC2 instance (default-এ On-Demand, configure করলে Spot বা Savings Plan, লেসন ৪.৪), load balancer, EBS volume, application version আর log রাখার S3 storage, CloudWatch alarm, আর যোগ করলে একটা RDS database। দুটো environment মানে দ্বিগুণ খরচ, এটা এই লেসনের পরের দিকে blue/green deployment-এ কাজে লাগবে।

#Application, version আর environment

#তিনটা মূল উপাদান

• Application: একটা software-এর সাথে যা যা জড়িত, সব রাখার একটা নাম দেওয়া পাত্র: তার version, environment আর saved configuration। এটা নিজে কিছু চালায় না, খরচও নেই।
• Application version: তোমার code-এর একটা নির্দিষ্ট build, একটা source bundle (zip বা WAR file), যেটা Beanstalk v42-এর মতো একটা label দিয়ে S3-এ রাখে। Version-গুলো application-এর, কোনো একটা environment-এর না; তাই একই version আগে test-এ, পরে prod-এ deploy করা যায়। Default quota হলো সব application মিলিয়ে প্রতি Region-এ ১,০০০টা application version; একটা version lifecycle policy পুরনোগুলো নিজে থেকে মুছে দেয়।
• Environment: AWS resource-এর একটা সেট, যেটা একবারে একটাই application version চালায়। সাধারণত একটা application-এর কয়েকটা environment থাকে: shop-dev, shop-test, shop-prod। প্রত্যেকটার নিজের configuration, নিজের resource আর নিজের URL।

এদের চারপাশে থাকে saved configuration (environment-এর setting-এর template, বারবার ব্যবহার করা যায়) আর environment যে platform-এ চলে সেটা। কাজের ধারা সবসময় একই: application বানাও, একটা version upload করো, একটা environment চালু করো, তারপর সেটা সামলাও; release দিতে নতুন version upload করে environment-এ deploy করো।

#Environment-এর নাম, URL আর tier

Environment বানানোর সময় তুমি ঠিক করো:

• একটা environment name, application-এর ভেতরে অদ্বিতীয়, যেমন shop-prod;
• একটা domain prefix (CNAME prefix), পুরো Region-এ অদ্বিতীয়। Environment-এর URL হয় shop-prod.us-east-1.elasticbeanstalk.com। Load-balanced environment-এ এটা একটা DNS নাম যেটা load balancer-কে দেখায়; single-instance environment-এ দেখায় instance-এর Elastic IP-কে। সাধারণত এর সামনে তুমি নিজের নাম বসাও, www.example.com, Route 53-এর এমন একটা alias record দিয়ে যার target environment-টা (লেসন ৮.২), অথবা environment URL-এর দিকে একটা CNAME দিয়ে;
• একটা tier: web server (user-এর HTTP বা HTTPS-এর উত্তর দেয়) অথবা worker (একটা SQS queue থেকে কাজ নিয়ে করে, নিজের কোনো public URL নেই)। নিচে tier নিয়ে আলাদা অংশ আছে।

#কোন কোন platform চালানো যায়

Platform হলো instance-এর ওপরের software-এর স্তূপ: operating system, ভাষার runtime, web server বা proxy, আর Beanstalk-এর agent-গুলো। এখনকার list (অক্টোবর ২০২৬):

• Docker (Amazon Linux 2023-এ Docker) আর ECS running on Amazon Linux 2023 (একটা instance-এ কয়েকটা container, একটা ECS agent সামলায়; “multi-container Docker”-এর জায়গা এটাই নিয়েছে);
• Go, Java (Amazon Corretto-তে সাধারণ Java app), Tomcat (WAR file হিসেবে Java web app);
• .NET Core on Linux আর .NET on Windows Server (IIS);
• Node.js, PHP, Python, Ruby।

কাজের ক্ষেত্রে কয়েকটা শব্দ জরুরি:

• Platform branch হলো একটা বড় ধারা, যেমন “Node.js 22 running on 64bit Amazon Linux 2023”। তার ভেতরের platform version-এর নম্বর major.minor.patch, যেমন 6.11.12।
• Managed platform update নতুন minor আর patch version সাপ্তাহিক দুই ঘণ্টার একটা maintenance window-এ নিজে থেকে বসিয়ে দেয়, immutable update দিয়ে, তাই capacity কখনো কমে না। Console থেকে বানানো environment-এ এটা default-এই চালু। নতুন branch-এ এটা কখনো যায় না; কোনো branch অবসরে গেলে সরতে হয় তোমাকেই, সাধারণত blue/green deployment দিয়ে।
• Docker হলো বেরোনোর দরজা: তোমার ভাষা বা stack list-এ না থাকলে container-এ ভরে দাও।

#Beanstalk তোমার account-এ কী বানায়

#একটা environment, একটা CloudFormation stack

Beanstalk-এর নিজের কোনো লুকানো server নেই। প্রতিটা environment-এর জন্য সে একটা AWS CloudFormation template লেখে আর তোমার account-এ একটা stack বানায় (CloudFormation হলো AWS-এর infrastructure-as-code service, course-এর শেষের দিকে এর নিজের chapter আছে)। Notes সোজা করে বলেছে: Beanstalk ভেতরে ভেতরে CloudFormation ব্যবহার করে। একটা load-balanced web server environment-এ সাধারণত থাকে:

• একটা S3 bucket, নাম elasticbeanstalk-<region>-<account-id> (প্রতি Region-এ একটা, তোমার সব application মিলে ব্যবহার করে), তাতে তোমার source bundle আর log;
• security group: একটা load balancer-এর জন্য, আরেকটা instance-গুলোর জন্য, যেটা শুধু load balancer থেকে আসা traffic ঢুকতে দেয় (লেসন ৯.২-এর tier থেকে tier-এ জোড়া);
• একটা Elastic Load Balancer: console আর EB CLI থেকে default-এ Application Load Balancer (Network আর Classic-ও বাছা যায়, আর কয়েকটা environment একটা ALB ভাগ করেও নিতে পারে);
• একটা launch template আর তোমার বাছা AZ-গুলো জুড়ে একটা Auto Scaling group, default-এ minimum ১ আর maximum ৪টা instance;
• scaling চালানোর CloudWatch alarm। Default trigger হলো instance থেকে বের হওয়া network traffic (৫ মিনিট ধরে ৬ MB-র বেশি হলে scale out, ২ MB-র কম হলে scale in); বেশিরভাগ দল এটা বদলে CPU বা request count করে নেয়;
• single-instance environment-এ load balancer-এর বদলে একটা Elastic IP;
• চাইলে একটা RDS DB instance (নিচে “Database-কে environment-এর বাইরে রাখো” দেখো)।

Beanstalk-এর দুটো IAM role-ও লাগে: একটা service role, যেটা দিয়ে Beanstalk তোমার হয়ে অন্য service-কে call করে, আর একটা instance profile, যেটা দিয়ে instance-গুলো S3 থেকে bundle পড়ে, log upload করে আর health জানায়। প্রথমবার ব্যবহারের সময় console আর EB CLI দুটোই বানিয়ে দেয়।

#Configuration বদলানো: option, .ebextensions আর platform hook

একটা environment-এর সবকিছুই কোনো না কোনো namespace-এর একটা configuration option, যেমন aws:autoscaling:asg → MinSize, বা aws:elasticbeanstalk:command → DeploymentPolicy। Option চারটা জায়গায় বসানো যায়, আর তালিকার যে জায়গা আগে একটা option বসিয়েছে, সেটাই জেতে:

1. সরাসরি environment-এর ওপর (console, EB CLI, API);
2. তোমার লাগানো একটা saved configuration;
3. source bundle-এর ভেতরের configuration file;
4. default মান।

Source bundle-এর ভেতর থেকে instance আর environment দুটোই নিজের মতো করা যায়:

• .ebextensions/*.config (YAML বা JSON): option_settings, install করার packages, লেখার files, চালানোর commands আর container_commands, এমনকি CloudFormation-এর ভাষায় বাড়তি Resources (একটা SQS queue, একটা DynamoDB table);
• .platform/hooks/ (prebuild, predeploy, postdeploy) আর .platform/confighooks/: Amazon Linux 2023 platform-এ deployment-এর নির্দিষ্ট মুহূর্তে চলা script; .platform/nginx/ দিয়ে proxy-র configuration বদলানো যায়;
• তোমার app চালু করার command-এর জন্য একটা Procfile, আর feature flag বা database endpoint-এর মতো setting-এর জন্য environment property (environment variable)।

#পুরো নিয়ন্ত্রণ, তবে একটা শর্তে

OS-এ ঢোকার সুযোগ সত্যিই আছে: eb ssh দিয়ে একটা instance-এ login করে যা খুশি বদলাতে পারো। কিন্তু instance-গুলো ফেলে দেওয়ার জিনিস। Auto Scaling-এর scale-in, একটা ব্যর্থ health check, একটা immutable deployment বা একটা managed platform update এদের সরিয়ে platform-এর AMI আর তোমার source bundle থেকে বানানো নতুন instance বসায়, আর হাতে যা যা বদলেছিলে সব উধাও। Stack-এর resource-এর বেলায়ও একই কথা: load balancer বা security group তাদের নিজের console-এ বদলালে, environment-এর পরের update সেগুলো আবার আগের মতো করে দিতে পারে।

তাই “পুরো নিয়ন্ত্রণ” মানে: যা খুশি বদলাও, যদি বদলটা তোমার source bundle-এ বা environment-এর configuration-এ থাকে। লেসন ৪.৩-এ AMI আর user data নিয়ে এই শিক্ষাটাই পেয়েছিলে: রেসিপিতে যা নেই, নতুন করে চালু করলে তা টেকে না।

#Single-instance নাকি load-balanced

Slide এদের বলে দুটো deployment mode; console আর API-তে এরা environment type।

একটা চেনা ধাঁচ: প্রতিটা developer বা প্রতিটা feature branch-এর জন্য একটা করে সস্তা single-instance environment, আর staging আর production-এর জন্য load-balanced environment; সবগুলোতে একই application version চলে।

#Database-কে environment-এর বাইরে রাখো

HA mode-এর slide-এ environment-এর ভেতরে একটা RDS primary আর standby দেখানো আছে, আর সত্যিই Beanstalk environment-এর অংশ হিসেবে একটা RDS database বানাতে পারে (MySQL, PostgreSQL, Oracle বা SQL Server)। তখন সে connection-এর তথ্য তোমার code-কে environment property হিসেবে দেয়: RDS_HOSTNAME, RDS_PORT, RDS_DB_NAME, RDS_USERNAME, RDS_PASSWORD। একে বলে coupled database, প্রথম test-এর জন্য বেশ কাজের।

Production-এ কিন্তু এটা একটা ফাঁদ, কারণ coupled database environment-এর আয়ুর সাথে বাঁধা:

• Environment terminate হলে stack নিজের বানানো সব মুছে দেয়। Database মানে তার deletion policy: Delete (default), Snapshot (শেষ একটা snapshot নিয়ে তারপর মোছা) অথবা Retain (চালু রেখে দেওয়া)।
• Blue/green-এ দুটো environment লাগে, আর দুটোকেই একই production database-এর সাথে কথা বলতে হয়। যে database ওদের একটার নিজের, সেটা এভাবে ভাগ করা যায় না।
• অন্য environment, অন্য application বা একটা reporting tool এটা পরিষ্কারভাবে ব্যবহার করতে পারে না, আর RDS console-এ বদলানো setting environment-এর নিজের setting দিয়ে মুছে যায়।

সমাধান হলো এটাকে decouple করা: RDS database (Multi-AZ, লেসন ৭.১) Beanstalk-এর বাইরে বানাও, বা চালু database-কে Retain policy দিয়ে decouple করো, তারপর environment property বা AWS Secrets Manager দিয়ে environment-কে endpoint-টা দাও, আর database-এর security group-এ instance-গুলোর security group-কে অনুমতি দাও। Deletion policy বদলটা আগে আলাদা একটা update হিসেবে চালাও, decouple করো দ্বিতীয় update-এ: দুটো একসাথে পাঠালে পুরনো policy-টাই জেতে।

#Web server tier আর worker tier

#Web server environment

Web server environment হলো এতক্ষণ যা দেখলে: তার একটা URL আছে, সে internet থেকে load balancer দিয়ে HTTP আর HTTPS request পায়, আর Auto Scaling group-এর instance-গুলোতে সেগুলো চালায়। তার কাজ user-কে দ্রুত উত্তর দেওয়া।

কিছু কাজ একটা request-এর মধ্যে আঁটে না: একটা video convert করা, বড় একটা report বানানো, ছবি ছোট করা, একগাদা email পাঠানো, ধীর কোনো partner API-কে call করা। Web request-এর ভেতরে করলে প্রতিটা কাজ user-কে বসিয়ে রাখে, একটা web server আটকে রাখে, আর ভিড়ের সময় যে request-গুলোর দ্রুত হওয়ার কথা, সেগুলোকেও না খাইয়ে মারে।

#Worker environment আর তার SQS daemon

Worker environment এই কাজগুলো পেছনে বসে করে। তার কোনো public URL নেই। টুকরোগুলো এরকম:

1. Web tier AWS SDK দিয়ে একটা Amazon SQS queue-তে একটা message রাখে, যেমন {"video": 42}, আর সাথে সাথে user-কে উত্তর দিয়ে দেয় (প্রায়ই HTTP 202 Accepted)। SQS হলো AWS-এর managed message queue, এর পুরো একটা chapter পরে আসছে (chapter ১৩); এখানে শুধু মূল কথাটুকু লাগবে।
2. Queue-টা Beanstalk তোমার জন্য বানিয়ে দেয় (একটা autogenerated standard queue), অথবা তোমার আগের কোনো queue ব্যবহার করে, standard বা FIFO।
3. প্রতিটা worker instance-এ Beanstalk চালায় SQS daemon (sqsd)। সে queue থেকে message টেনে নেয়, আর প্রতিটার জন্য http://localhost/-এ port 80-তে একটা HTTP POST পাঠায় (path বদলানো যায়); message-এর body হয় request-এর body, আর SQS-এর তথ্য থাকে X-Aws-Sqsd-* header-এ।
4. তাই তোমার worker code আসলে একটা সাধারণ web handler। সে 200 OK ফেরত দিলে daemon message-টা মুছে দেয়। অন্য যেকোনো status, বা কোনো উত্তরই না আসা, মানে ব্যর্থতা, আর message আবার চেষ্টার জন্য ফিরে আসে।

এটাই decoupling: web tier এক ধাক্কায় আসা upload-এর ঢেউ সাথে সাথে নিয়ে নিতে পারে, জমে থাকা কাজ ধরে রাখে queue, আর worker-রা নিজের গতিতে সেটা শেষ করে, চাপে ভেঙে পড়ে না। Worker নষ্ট হলেও message টিকে থাকে, সেটাই পরের অংশের বিষয়।

#Timeout, retry আর dead-letter queue

• Visibility timeout (default ৩০০ সেকেন্ড, সর্বোচ্চ ১২ ঘণ্টা): একটা daemon message পেলে SQS এতক্ষণ সেটা বাকি সবার কাছ থেকে লুকিয়ে রাখে। এর মধ্যে কাজ শেষের খবর না এলে message আবার দৃশ্যমান হয় আর অন্য কোনো worker সেটা পায়। এটা তোমার সবচেয়ে লম্বা কাজের চেয়ে বেশি রাখো, নাহলে ধীর কাজ দুবার হবে।
• Error visibility timeout: তোমার code error ফেরত দেওয়ার পর পরের চেষ্টার আগে message কতক্ষণ লুকানো থাকবে।
• Inactivity timeout: তোমার code-এর উত্তরের জন্য daemon কতক্ষণ অপেক্ষা করবে; লম্বা কাজের জন্য visibility timeout-এর সাথে এটাও বাড়াও।
• Max retries (default ১০, ১ থেকে ১০০): এতবার ব্যর্থ হলে message চলে যায় একটা dead-letter queue-তে (DLQ)। Autogenerated queue হলে DLQ তোমার জন্য বানানোই থাকে; নিজের queue হলে SQS-এ নিজে configure করতে হয়। DLQ না থাকলে সবসময় ব্যর্থ হওয়া একটা message তার retention period (default ৪ দিন) শেষ না হওয়া পর্যন্ত ঘুরতেই থাকে।
• SQS message পৌঁছায় অন্তত একবার (at-least-once): setting ঠিক থাকলেও একটা message দুবার process হতে পারে (যেমন কাজ শেষ করার ঠিক পরেই instance মরে গেলে)। তাই কাজগুলো idempotent রাখো, যাতে দুবার চললেও ক্ষতি না হয়।

#cron.yaml দিয়ে নিয়মিত কাজ

Worker-এর source bundle-এ একটা cron.yaml file নির্দিষ্ট সময়ের কাজ ঠিক করে দেয়: একটা নাম, একটা URL path আর একটা cron expression (সময় ধরা হয় Coordinated Universal Time-এ)। সময় হলে প্রতিটা কাজ queue-তে তোলে ঠিক একটা instance, leader; instance-গুলো একটা DynamoDB table-এ লিখে leader বেছে নেয়, আর leader মরে গেলে আরেকজন দায়িত্ব নেয়। তারপর অন্য যেকোনো কাজের মতোই যেকোনো worker message-টা process করে। FIFO queue-তে periodic task চলে না।

version: 1
cron:
  - name: "nightly-report"
    url: "/tasks/report"
    schedule: "0 2 * * *"

#Worker-দের scaling

Worker environment-এর নিজের একটা Auto Scaling group আছে। তার default scaling trigger web environment-এর মতোই সাধারণ instance metric, কিন্তু worker-এর আসল সংকেত হলো queue: instance-প্রতি কতগুলো message অপেক্ষা করছে। SQS-এর ApproximateNumberOfMessagesVisible metric-কে instance-এর সংখ্যা দিয়ে ভাগ করে তার ওপর একটা CloudWatch alarm বা target tracking policy দাও, লেসন ৬.৫-এর “backlog per instance” পদ্ধতি। যে worker ধীর কোনো বাইরের API-র জন্য অপেক্ষা করে, তার queue বাড়তে পারে আর CPU একই সময়ে কম থাকতে পারে, তাই CPU ধরে scaling কখনো সাড়াই দেবে না।

#নতুন version deploy করা

তুমি v2 upload করে এমন একটা environment-এ deploy করলে যেটা v1 চালাচ্ছে। v2 কীভাবে instance-গুলোতে পৌঁছাবে, সেটাই deployment policy, প্রতিটা environment-এ আলাদা করে ঠিক করা (option DeploymentPolicy, namespace aws:elasticbeanstalk:command)। তৈরি policy আছে পাঁচটা। Notes-এ আছে চারটা; পঞ্চমটা, traffic splitting, পরীক্ষায় সমান গুরুত্বের। Blue/green কোনো policy-ই না, দুটো environment দিয়ে করা একটা কৌশল; সেটা পরের অংশে।

#All at once

Beanstalk একই সময়ে প্রতিটা instance-এ v2 বসায়। Application server-গুলো restart হয়, তাই কিছুক্ষণ কোনো instance-ই কাজে থাকে না।

• সবচেয়ে দ্রুত deployment, বাড়তি instance নেই, বাড়তি খরচ নেই।
• Deployment-এর সময় downtime। v2 নষ্ট হলে পুরো fleet নষ্ট: তুমি হাতে v1 আবার deploy না করা পর্যন্ত পুরো outage।
• Development আর test-এ, বা যেখানে অল্প সময়ের outage মেনে নেওয়া যায়, সেখানে চালাও। এটাই Beanstalk-এর default policy, শুধু EB CLI দিয়ে বানানো load-balanced environment শুরু হয় rolling দিয়ে।

#Rolling

Beanstalk instance-গুলোকে কয়েকটা batch-এ ভাগ করে, আর একবারে একটা batch update করে। প্রতিটা batch-এর বেলায় সে instance-গুলো load balancer থেকে সরায় (চালু connection শেষ হতে দিয়ে), v2 বসায়, health check পাস করা পর্যন্ত অপেক্ষা করে, তারপর ফিরিয়ে আনে।

• Downtime নেই, কিন্তু পুরো deployment জুড়ে capacity এক batch কম থাকে; ভিড়ের সময় হলে আগে থেকে হিসাব রাখো।
• Batch size হয় instance-এর শতকরা ভাগ, নয়তো একটা নির্দিষ্ট সংখ্যা।
• কিছুক্ষণ v1 আর v2 পাশাপাশি user-দের সেবা দেয়, তাই দুটোকেই একই database schema আর API-তে চলতে হবে।
• Command timeout-এর মধ্যে একটা batch health check পাস না করলে deployment থেমে যায়: শেষ হওয়া batch-গুলো v2-এ, বাকিরা v1-এ। নিজে থেকে rollback হয় না; জানা ভালো একটা version আবার deploy করতে হয়।
• Single-instance environment-এ চলে না।

হিসাব: ৮টা instance, batch size ২৫% = প্রতি batch-এ ২টা instance = ৪টা batch, আর deployment-এর সময় ৮টার মধ্যে মাত্র ৬টা (৭৫%) কাজ করে। Batch size ৫০% হলে ২টা batch, দ্রুত, কিন্তু কাজ করে ৮টার মধ্যে মাত্র ৪টা।

#Rolling with additional batch

Rolling-এর মতোই, শুধু Beanstalk আগে নতুন instance-এর একটা বাড়তি batch চালু করে, v2 সহ। তারপর পুরনো instance-গুলোর ওপর দিয়ে rolling চলে, আর শেষে এক batch পরিমাণ instance মুছে দেয়।

• পুরো সময় পুরো capacity: কাজে থাকা instance-এর সংখ্যা কখনো আসলটার নিচে নামে না। Rolling-এ হারানো capacity যখন গায়ে লাগবে, তখন এটা চালাও।
• খরচ একটু বেশি (deployment যতক্ষণ, বাড়তি batch ততক্ষণ চলে), আর deployment rolling-এর চেয়ে লম্বা।
• একদম প্রথম (নতুন) batch-টাই fail করলে ক্ষতি সামান্য, কারণ পুরনো কোনো instance-এ হাত পড়েনি; পরের কোনো batch fail করলে অবস্থা ব্যর্থ rolling deployment-এর মতোই আধা-আধি। Rollback হাতে আবার deploy করে।
• হিসাব: ৮টা instance, batch ২৫% → Beanstalk যোগ করে ২টা, তাই একসাথে চলে ১০টা পর্যন্ত instance, আর সবসময় কাজে থাকে ৮টা।

#Immutable

Beanstalk পুরনো instance-গুলোতে হাতই দেয় না। তার বদলে:

1. একই load balancer-এর পেছনে একটা অস্থায়ী Auto Scaling group বানায়, আর তাতে v2 সহ একটা instance চালু করে।
2. ওই instance health check পাস করলে আসল group-এর সমান সংখ্যক instance চালু করে।
3. সবগুলো সুস্থ হলে নতুন instance-গুলো আসল Auto Scaling group-এ সরিয়ে নেয়, তারপর পুরনো instance আর অস্থায়ী group মুছে দেয়।

বৈশিষ্ট্য:

• শূন্য downtime, পুরো capacity, আর প্রতিটা v2 instance একদম নতুন: আধা-update হওয়া কোনো instance নেই, v1-এর কোনো বাড়তি জঞ্জালও না।
• কিছুক্ষণের জন্য environment দ্বিগুণ instance চালায় (৮টা হয়ে যায় ১৬টা), তাই বড় fleet-এ EC2 On-Demand quota দেখে নাও। একটা environment-এর ভেতরের policy-গুলোর মধ্যে এটাই সবচেয়ে ধীর, আর instance-গুলো জমানো burst credit হারায়।
• Rollback দ্রুত আর নিজে থেকে: নতুন instance health check-এ fail করলে Beanstalk অস্থায়ী group-টা মুছে দেয়। আসল instance-গুলো একবারের জন্যও v1 চালানো থামায়নি।
• এর জন্য enhanced health reporting লাগে, আর single-instance environment-এও এটা চলে।

Notes-এ immutable-কে বলা হয়েছে “পুরো নতুন একটা ASG; test পাস করলে পুরনোটা মুছে দেয়”। আরও ঠিকভাবে বললে, আসল ASG-টা টিকে থাকে: নতুন instance-গুলো তার ভেতরে সরানো হয়, আর মোছা হয় অস্থায়ী group আর পুরনো instance-গুলো।

#Traffic splitting

Traffic splitting হলো Beanstalk-এর ভেতরেই বানানো একটা canary deployment:

1. Immutable-এর মতোই Beanstalk একটা অস্থায়ী Auto Scaling group-এ পুরো এক সেট নতুন instance চালু করে।
2. Load balancer request-এর একটা শতকরা ভাগ নতুন instance-এ পাঠায় (NewVersionPercent, default ১০%), একটা evaluation time ধরে (default ৫ মিনিট, ৩ থেকে ৬০০)।
3. নতুন instance-গুলো সুস্থ থাকলে সব traffic তাদের দিকে সরে, তারা আসল ASG-তে যোগ দেয়, আর পুরনো instance আর অস্থায়ী group মুছে যায়। অসুস্থ হলে, বা তুমি থামিয়ে দিলে, Beanstalk সব traffic v1-এ ফিরিয়ে আনে আর নতুন instance মুছে দেয়।

নষ্ট v2 দেখতে পারে শুধু canary-র ভাগের user-রা, আর rollback নিজে থেকেই হয়। Traffic splitting-এর জন্য Application Load Balancer লাগে, ভাগটা সে করে অনেকটা লেসন ৬.৩-এর weighted target group-এর মতো, আর single-instance environment-এ এটা চলে না।

#পাঁচটা policy পাশাপাশি

পাঁচটা তৈরি policy-র কোনোটাই DNS বদলায় না; বদলায় শুধু blue/green।

ঠিকঠাক আর নষ্ট দুই রকম v2 দিয়েই প্রতিটা policy চালিয়ে দেখো:

#Blue/green: দ্বিতীয় একটা environment আর URL অদলবদল

সবচেয়ে নিরাপদ release পুরো পুরনো environment-টাকে traffic ফেরত নেওয়ার জন্য তৈরি রাখে। এটাই blue/green, আর Beanstalk-এ এটা হাতে করা একটা কৌশল, কোনো deployment policy না:

1. Blue (shop-prod) v1 দিয়ে production চালাচ্ছে।
2. তুমি তাকে clone করো, বা নতুন একটা environment বানাও, নাম green (shop-green), আর সেখানে v2 deploy করো। Green-এর নিজের URL, load balancer আর instance আছে।
3. User-রা blue-তে থাকা অবস্থায় তুমি green-কে তার নিজের URL দিয়ে যাচাই করো।
4. বেছে নাও Swap environment URLs (eb swap, বা SwapEnvironmentCNAMEs API)। Beanstalk দুটো environment-এর CNAME record অদলবদল করে: shop-prod.us-east-1.elasticbeanstalk.com এখন দেখায় green-এর load balancer।
5. কিছু গোলমাল হলে আবার অদলবদল করো। Blue কখনো থামেনি।

Blue/green চালাও যখন কোনো deployment policy দিয়ে কাজটা হয় না: নতুন platform branch-এ যাওয়া, এমন setting বদলানো যেটা জায়গায় দাঁড়িয়ে বদলানো যায় না, বা যখন ফেরার সবচেয়ে দ্রুত পথ হিসেবে পুরনো environment অক্ষত রাখতে চাও।

সাবধানতাগুলো:

• DNS caching। অদলবদল একটা DNS record বদলায়, তাই user সরে ঠিক ততটা দ্রুত, যত দ্রুত resolver-রা পুরনো উত্তর ছাড়ে। কিছু user record-এর TTL পর্যন্ত (লেসন ৮.১) blue-তেই যেতে থাকে, আর কিছু resolver ও client TTL-এর চেয়েও বেশি সময় cache রাখে। AWS-এর পরামর্শ: পুরনো DNS record-এর মেয়াদ না ফুরানো পর্যন্ত পুরনো environment terminate কোরো না। ফেরার অদলবদলেও একই দেরি।
• তোমার নিজের domain-কেও সাথে যেতে হবে। www.example.com যদি Route 53-এ environment-এর দিকে একটা alias হয় (বা environment URL-এর দিকে একটা CNAME), সেটা অদলবদলের সাথে চলে যায়। কেউ যদি সেটা সরাসরি blue-র load balancer-এর DNS নামে লাগিয়ে থাকে, তাহলে অদলবদলে তোমার user-দের কিছুই বদলায় না।
• ভাগ করা database। দুটো environment-কেই Beanstalk-এর বাইরের একই database ব্যবহার করতে হবে (আগের coupled database সমস্যা)।
• খরচ। দুটো চালু থাকা পর্যন্ত দুটো পুরো environment-এর দাম দাও।

DNS-এর বদলে সাথে সাথে, প্রতি request-এ বদল চাইলে environment-এর ভেতরে traffic splitting চালাও, অথবা ধীরে ধীরে DNS-স্তরে সরাতে দুই environment-এর সামনে Route 53-এর weighted record (লেসন ৮.৩) দাও।

#Health আর নিজে থেকে rollback

#Basic আর enhanced health

প্রতিটা environment একটা health-এর রং দেখায়: সবুজ (OK), হলুদ (warning), লাল (degraded বা severe), বা ধূসর (অজানা, বা update চলছে)।

• Basic health ব্যবহার করে load balancer-এর health check (single instance হলে EC2 status check) আর প্রতি ৫ মিনিটে পাঠানো কয়েকটা CloudWatch metric।
• Enhanced health প্রতিটা instance-এ একটা health agent যোগ করে, যে প্রতি ১০ সেকেন্ডে Beanstalk-কে OS metric, web server log (request-এর সংখ্যা, 4xx আর 5xx-এর হার, latency) আর deployment-এর অবস্থা জানায়; status হয় Ok, Warning, Degraded, Severe-এর মতো, সাথে প্রত্যেকটার একটা “cause”। Console-এ বানানো environment-এ এটা default-এই চালু, CloudWatch-এ এর metric না পাঠালে বিনা পয়সার, আর immutable deployment ও managed platform update-এর জন্য এটা লাগবেই। eb health এটা সরাসরি দেখায়।

একটা ঠিকঠাক health check URL দাও (/health-এর মতো একটা path, যেটা সত্যিই app-টা চালিয়ে দেখে)। না দিলে একটা instance TCP connection নিতে পারলেই সুস্থ ধরা হয়, হয়তো app চালু হওয়ার আগেই।

#Deployment fail করলে কী হয়

Deployment-এর সময় প্রতিটা batch (বা নতুন instance-এর প্রতিটা দল) command timeout-এর মধ্যে সুস্থ হতে হবে (default ৬০০ সেকেন্ড, তার ওপর Beanstalk নিজে থেকে আরও ৪ মিনিট যোগ করে)। Enhanced health-এ একটা web instance-কে দুই মিনিটে টানা ১২টা check পাস করতে হয়। তারপর:

• All at once, rolling, rolling with additional batch: deployment যেখানে ছিল সেখানেই fail করে থামে। নিজে থেকে কিছু ফেরানো হয় না; প্রতিটা instance-এর deployment ID দেখায় কে কোন version চালাচ্ছে, আর rollback করতে তুমি একটা ভালো version আবার deploy করো।
• Immutable: Beanstalk অস্থায়ী Auto Scaling group মুছে দেয়; ব্যর্থ instance-গুলোর log এক ঘণ্টা S3-এ থাকে, যাতে কারণটা দেখতে পারো।
• Traffic splitting: Beanstalk সব traffic পুরনো instance-এ ফিরিয়ে আনে আর নতুনগুলো মুছে দেয়।
• দুটো setting এই আচরণ বদলায়: Healthy threshold কম মানে (যেমন Warning) instance-কে পাস করতে দেয়, আর Ignore health check health না দেখেই deploy করে। দুটোই গতির বিনিময়ে নিরাপত্তা ছেড়ে দেয়।

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

#System design-এ Beanstalk

• এটা ৯.১–৯.৩-এর architecture-ই, প্যাকেট করা। AZ জুড়ে ALB, health check সহ ASG, tier থেকে tier-এ জোড়া security group: হাতে যা design করেছিলে, Beanstalk ঠিক সেটাই বানায়। তোমার design-এর কাজ সরে যায় setting বাছাইয়ে: minimum ২ বা বেশি, multi-AZ subnet, load-এর সাথে মেলে এমন scaling metric, একটা health check URL।
• Instance-গুলো stateless রাখো। All at once ছাড়া প্রতিটা deployment policy instance বদলায় বা নতুন করে চালায়, তাই session যাবে ElastiCache বা DynamoDB-তে (লেসন ৯.২), upload যাবে S3 বা EFS-এ (লেসন ৯.৩), আর database থাকবে environment-এর বাইরে।
• ঝুঁকি দেখে policy বাছো। Dev: all at once বা single instance। Production web: immutable বা traffic splitting, আর খরচ বেশি গুরুত্বপূর্ণ হলে rolling with additional batch। Platform branch বদল আর ঝুঁকির বদল: blue/green।
• Tier দিয়ে ভাগ করো। দ্রুত request web tier-এ, ধীর কাজ SQS হয়ে worker tier-এ, যেটা queue-র গভীরতা দেখে scale করে। আলাদা আলাদা path দিয়ে কয়েকটা application একই queue-র ধাঁচ ব্যবহার করতে পারে।
• কখন ছেড়ে যেতে হবে, জানো। অনেকগুলো container-ওয়ালা microservice সাধারণত Beanstalk ছাড়িয়ে ECS বা EKS-এ যায় (chapter ১৪); event-চালিত জোড়াতালির কাজে Lambda বেশি মানায় (chapter ১৫); CloudFormation বা CDK দিয়ে পুরো infrastructure-as-code বানালে Beanstalk যা করে সবই পাবে, খাটুনি বেশি, নিয়ন্ত্রণও বেশি।

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

একটা project folder-এ EB CLI (pip install awsebcli) দিয়ে:

# 1. Create the application (asks for Region and platform) and a cheap dev environment
eb init shop --platform node.js --region us-east-1
eb create shop-dev --single                 # one instance + Elastic IP, no load balancer

# 2. A production environment with an Application Load Balancer
eb create shop-prod --elb-type application

# 3. Ship a new version, watch health, read logs, log in
eb deploy shop-prod                         # zips, uploads to S3 as a new version, deploys
eb health shop-prod                         # enhanced health, refreshed live
eb logs shop-prod
eb ssh shop-prod                            # OS access (changes made here do not survive)

# 4. Environment properties (environment variables) for the app
eb setenv DB_HOST=shop-db.abc123.us-east-1.rds.amazonaws.com FEATURE_X=on

# 5. Blue/green: clone, deploy v2 to the clone, test it, swap the URLs
eb clone shop-prod --clone_name shop-green
eb deploy shop-green
eb swap shop-prod --destination_name shop-green

# 6. A worker environment for background jobs
eb create shop-worker --tier worker

AWS CLI দিয়ে একই কাজ:

# Upload a version from S3 and deploy it with the Immutable policy
aws elasticbeanstalk create-application-version --application-name shop \
  --version-label v42 --source-bundle S3Bucket=my-builds-bucket,S3Key=shop-v42.zip
aws elasticbeanstalk update-environment --environment-name shop-prod --version-label v42 \
  --option-settings Namespace=aws:elasticbeanstalk:command,OptionName=DeploymentPolicy,Value=Immutable

# Real high availability: at least two instances
aws elasticbeanstalk update-environment --environment-name shop-prod \
  --option-settings Namespace=aws:autoscaling:asg,OptionName=MinSize,Value=2

# Health, events and the URL swap
aws elasticbeanstalk describe-environment-health --environment-name shop-prod --attribute-names All
aws elasticbeanstalk describe-events --environment-name shop-prod --max-items 20
aws elasticbeanstalk swap-environment-cnames \
  --source-environment-name shop-prod --destination-environment-name shop-green

# What did the environment create? (the stack is named after the environment ID)
aws elasticbeanstalk describe-environment-resources --environment-name shop-prod

Source bundle-এর ভেতরে একটা configuration file, .ebextensions/01-deploy.config:

option_settings:
  aws:elasticbeanstalk:command:
    DeploymentPolicy: TrafficSplitting
  aws:elasticbeanstalk:trafficsplitting:
    NewVersionPercent: "10"
    EvaluationTime: "5"
  aws:elasticbeanstalk:application:
    Application Healthcheck URL: /health
packages:
  yum:
    ImageMagick: []

আর একটা platform hook, যেটা নতুন version চালু হওয়ার আগে প্রতিটা instance-এ চলে, .platform/hooks/predeploy/01-migrate.sh:

#!/bin/bash
# Runs after the bundle is extracted, before the app starts serving
cd /var/app/staging && npm run migrate

#সারসংক্ষেপ

মূল কথাগুলো

• Elastic Beanstalk একটা developer-কেন্দ্রিক PaaS: তুমি code upload করো, সে CloudFormation দিয়ে তোমার account-এ চেনা ALB + ASG + EC2 architecture বানিয়ে চালায়। Beanstalk বিনা পয়সার; দাম দাও resource-এর। এটা serverless না।
• পুরো নিয়ন্ত্রণ: instance-এ login করা যায়, কিন্তু instance বদলে যায়, তাই স্থায়ী বদল রাখো .ebextensions, .platform hook আর configuration option-এ।
• Application (পাত্র) → application version (S3-এ source bundle, quota প্রতি Region-এ ১,০০০) → environment (একবারে একটা version, নিজের URL name.region.elasticbeanstalk.com, tier)।
• Platform: Docker আর ECS on Amazon Linux 2023, Go, Java (Corretto), Tomcat, .NET (Linux আর Windows/IIS), Node.js, PHP, Python, Ruby। Managed platform update: minor আর patch, সাপ্তাহিক window, immutable।
• Single instance (Elastic IP, load balancer নেই, dev) বনাম load-balanced (ALB, multi-AZ ASG, prod; minimum ≥ ২)। RDS environment-এর বাইরে রাখো; coupled database default-এ environment-এর সাথে মুছে যায়।
• Web tier user-কে উত্তর দেয়; worker tier কাজ নেয় SQS থেকে: sqsd daemon localhost-এ POST করে, 200 → মোছা; visibility timeout কাজের চেয়ে লম্বা; max retries → DLQ; নির্দিষ্ট সময়ের কাজে cron.yaml; scale করো queue-র গভীরতা দেখে।
• পাঁচটা policy: all at once (দ্রুত, downtime), rolling (capacity এক batch কম, হাতে rollback), rolling with additional batch (পুরো capacity, বাড়তি batch), immutable (অস্থায়ী ASG, কিছুক্ষণ দ্বিগুণ, নিজে থেকে সস্তা rollback), traffic splitting (canary %, ALB, নিজে থেকে rollback)।
• Blue/green = দ্বিতীয় environment + swap environment URLs (CNAME অদলবদল); DNS cache-এর মেয়াদ না ফুরানো পর্যন্ত পুরনোটা রাখো; নিজের domain-কে environment-এর দিকে তাক করো, load balancer-এর দিকে না।
• Enhanced health (প্রতি ১০ সেকেন্ডে agent) immutable আর managed update-এর জন্য লাগবেই; ব্যর্থ rolling deployment-এ হাতে আবার deploy করতে হয়।

নিজেকে যাচাই করো: Elastic Beanstalk৩০টি প্রশ্ন