Vertical বনাম Horizontal Scaling, আর High Availability

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

• scalability, elasticity, agility, high availability আর fault tolerance, প্রতিটা এক লাইনে আলাদা করে বলতে পারবে।
• EC2-তে vertical scaling (scale up/down) বোঝাতে পারবে: resize কীভাবে হয়, কেন downtime লাগে, এর ছাদ কোথায়, আর কখন এটাই ঠিক পথ।
• horizontal scaling (scale out/in) বোঝাতে পারবে: কেন load balancer আর stateless server লাগে, আর session state নিয়ে কী করতে হয়।
• অন্তত দুটো Availability Zone জুড়ে high availability design করতে পারবে, active-active বা passive standby দিয়ে, আর লুকিয়ে থাকা single point of failure খুঁজে বের করতে পারবে।
• একটা AZ হারালেও app যেন টিকে থাকে, তার জন্য ২, ৩ বা আরও বেশি AZ-এ কতটা capacity লাগবে (AZ জুড়ে N+1) হিসাব করতে পারবে।
• পরীক্ষার keyword দেখে ঠিক উত্তর চিনতে পারবে: Auto Scaling group, Multi-AZ, load balancer, নাকি বড় instance।

#কাছাকাছি শোনায় এমন পাঁচটা শব্দ

Chapter ৬ দুটো service নিয়ে: Elastic Load Balancing (ELB) আর EC2 Auto Scaling। দুটোরই কাজ কয়েকটা নির্দিষ্ট গুণ এনে দেওয়া, আর পরীক্ষার প্রশ্ন এই গুণগুলোর নাম খুব মেপে মেপে ব্যবহার করে। তাই আগে শব্দগুলো পরিষ্কার করে নাও।

Scalability-র বিষয় হলো চাপ। High availability-র বিষয় হলো ব্যর্থতা। দুটো জড়িয়ে আছে, কারণ দুটোই সাধারণত ছড়িয়ে রাখা কয়েকটা server দিয়ে বানানো হয়, কিন্তু একটা থাকলেই অন্যটা থাকবে এমন না: একটা AZ-এ চারটা server ভালো scale করে, কিন্তু একসাথে মরে; আবার অন্য AZ-এ standby-সহ একটা primary database highly available, কিন্তু primary যতটুকু পারে তার বেশি চাপ নিতে পারে না।

#Vertical scaling: আরও বড় instance

Vertical scaling (scale up, বা scale down) মানে একটা instance-এর মাপ বদলানো: বেশি vCPU, বেশি memory, বেশি network bandwidth। EC2-তে তুমি instance type বদলাও, যেমন t3.large (2 vCPU, 8 GiB) থেকে r7i.4xlarge (16 vCPU, 128 GiB)।

#EC2-তে resize কীভাবে হয়

1. instance stop করো

   EBS-backed instance-এর type বদলানো যায় শুধু সেটা stopped থাকলে। এই মুহূর্ত থেকে application বন্ধ। (instance type আর family লেসন ৪.১-এ দেখেছ।)

2. instance type বদলাও

   মানানসই একটা type বেছে নাও: একই architecture (x86 বা Arm), সমর্থিত AMI আর driver, আর যথেষ্ট EBS attachment। EBS volume থেকে যায়। stop করলে instance store-এর data মুছে যায়, আর Elastic IP না হলে public IPv4 address বদলে যায়।

3. আবার start করো

   AWS নতুন মাপে instance-টাকে নতুন hardware-এ বসায়। boot, application চালু হওয়া, cache গরম হওয়া, সব মিলিয়ে কয়েক মিনিট। পরে scale down করতেও একই stop, বদল, start, একই outage।

#ছাদ কোথায়

Vertical scaling কোথাও না কোথাও গিয়ে থামবেই। EC2-তে পরিসর বিশাল, কিন্তু অসীম না:

সবচেয়ে বড় size-গুলো বানানো দানবীয় in-memory database-এর জন্য, দাম আকাশছোঁয়া, আর তবুও এটা একটা AZ-এ একটা machine। চাহিদা এর চেয়েও বাড়লে কেনার মতো আর বড় কিছু নেই।

#কখন vertical scaling-ই ঠিক পথ

RDS-এও instance class বদলানো একরকম stop-start ধরনের কাজ। Multi-AZ চালু থাকলে RDS আগে standby-কে বদলায়, তারপর failover করে, তাতে outage ছোট হয়ে প্রায় একটা failover-এর সমান হয়। Aurora Serverless v2 আরও এক ধাপ এগিয়ে: restart ছাড়াই জায়গায় বসে capacity বাড়ায়-কমায়, মানে vertical scaling-কেই elastic বানিয়ে দেয়। এগুলো database chapter-এ আবার আসবে।

#Horizontal scaling: আরও বেশি instance

Horizontal scaling (scale out, বা scale in) মানে instance-এর সংখ্যা বদলানো। একটা বড় server-এর বদলে একই রকম অনেকগুলো চালাও, কাজটা তাদের মধ্যে ভাগ করে দাও। আজকের web application এভাবেই বড় হয়, আর cloud-এ এটা সহজ: একই launch template (লেসন ৪.৩) থেকে এক-দুই মিনিটে হুবহু একটা instance চালু হয়ে যায়।

এর জন্য তিনটা জিনিস লাগে:

1. সামনে একটা load balancer। user-কে দশটা IP address দেওয়া যায় না। সে পায় একটা নাম, আর load balancer প্রতিটা request কোনো সুস্থ instance-এ পাঠায়। AWS-এ এটা ELB (লেসন ৬.২ থেকে ৬.৪)।
2. instance যোগ-বিয়োগ করার কেউ। AWS-এ এটা Auto Scaling group (ASG) (লেসন ৬.৫)। নষ্ট instance-ও সে বদলে দেয়।
3. Stateless server। যেকোনো instance যেন যেকোনো request-এর উত্তর দিতে পারে। কোনো server যদি user-এর session বা upload করা ফাইল নিজের কাছে রাখে, পরের request অন্য server-এ গেলে সে কিছুই পায় না, আর scale in হলে data-টাই ফেলে দেওয়া হয়।

state-এর সমাধান হলো সেটা server থেকে বের করে আনা: session যাবে ElastiCache বা DynamoDB-তে, ফাইল S3 বা EFS-এ, data database-এ। web tier একবার stateless হয়ে গেলে একশোতম server যোগ করাও দ্বিতীয়টা যোগ করার মতোই সহজ। (Sticky session একটা শর্টকাট, তবে ঝামেলা আছে, লেসন ৬.৪-এ দেখবে।)

Horizontal scaling-এরও দাম আছে: application-কে এর জন্য বানাতে হয়, আর shared অংশগুলো (database, cache) হয়ে ওঠে পরের scale করার মাথাব্যথা।

#High availability: অন্তত দুটো AZ

Availability Zone হলো এক বা একাধিক data centre, যার নিজস্ব বিদ্যুৎ, ঠান্ডা রাখার ব্যবস্থা আর network আছে, Region-এর অন্য AZ থেকে কয়েক কিলোমিটার দূরে, আর তাদের সাথে দ্রুত, কম latency-র fibre দিয়ে জোড়া (লেসন ১.২)। AZ কালেভদ্রে নষ্ট হয়, কিন্তু বিদ্যুৎ, cooling, network আর মানুষের ভুল, এসব ঘটেই। AWS-এ high availability মানে application অন্তত দুটো AZ-এ চালানো, যাতে একটা হারালে পুরোটা বন্ধ না হয়।

#Active-active আর passive standby

দুটোই highly available। Active-active চলে horizontal scaling-এর হাত ধরে; আর যে database primary কয়েকটা writer হিসেবে চলতে পারে না, তার সাধারণ উত্তর passive standby।

#High availability আর fault tolerance এক জিনিস না

দুটো AZ-এ, প্রতিটায় দুটো করে instance নিয়ে একটা web tier highly available: একটা AZ গেলেও চলতে থাকে। কিন্তু প্রতিটা AZ যদি 60%-এ চলছিল, টিকে থাকা দুজনের এখন লাগবে 120%, আর Auto Scaling group নতুন instance না আনা পর্যন্ত user ধীর page দেখবে। Fault tolerant design ব্যর্থতার পরও পুরো capacity ধরে রাখে, মানে সারাক্ষণ যথেষ্ট বাড়তি capacity চালু রাখতে হয়। পরীক্ষা সাধারণত “fault tolerant” আর “একটা AZ নষ্ট হলেও টিকে থাকো”, দুটোকেই Multi-AZ-এর ইঙ্গিত হিসেবে ধরে, কিন্তু প্রশ্নে যদি থাকে “কোনো degradation ছাড়া” বা “performance-এ কোনো প্রভাব ছাড়া”, তখন সে চাইছে ব্যর্থতার হিসাব ধরে মাপ ঠিক করো (পরের অংশ)।

#Single point of failure

Single point of failure (SPOF) হলো এমন যেকোনো একটা অংশ, যেটা নষ্ট হলেই পুরো system বন্ধ। Multi-AZ কাজে লাগে তখনই, যখন প্রতিটা tier multi-AZ। সাধারণ লুকানো SPOF:

• সব instance একটা AZ-এ, সামনে load balancer থাকলেও।
• একদম ঠিকঠাক multi-AZ web tier-এর পেছনে single-AZ database।
• AZ a-তে একটাই NAT gateway, যেটা সব AZ-এর private subnet ব্যবহার করে (লেসন ৩.৪): AZ a গেলে AZ b-এর সুস্থ instance-ও internet হারায়। প্রতি AZ-এ একটা করে NAT gateway রাখো।
• একটাই EC2 instance proxy, bastion বা cron server হিসেবে, যার ওপর app নির্ভর করে।
• shared data রাখা একটা EBS volume (একটা AZ) বা EFS One Zone।

#একটা AZ-এর ব্যর্থতা ধরে মাপ: AZ জুড়ে N+1

ধরো application-এর peak-এ Pটা instance লাগে, আর সেটা চলে Nটা AZ-এ। একটা AZ হারালে থাকে N − 1টা। ব্যর্থতার সময় কিছু scale না করেই পুরো capacity রাখতে চাইলে (AWS একে বলে static stability), প্রতিটা AZ-এ লাগবে:

প্রতি AZ-এ instance = P ÷ (N − 1), ওপরের দিকে round করে, আর মোট = প্রতি AZ × N।

এই table-এ দুটো শিক্ষা লুকিয়ে আছে:

• ২টা AZ হলে একটা হারানো মানে অর্ধেক capacity হারানো, তাই কোনো degradation ছাড়া টিকতে হলে fleet দ্বিগুণ করতে হয়। ৩টা AZ-এ হারাও তিন ভাগের এক ভাগ, বাড়তি লাগে মাত্র 50%। AZ যত বেশি, এই বিমা তত সস্তা, এজন্যই production design-এ প্রায়ই তিনটা AZ থাকে।
• বাড়তি capacity না থাকলে Auto Scaling নতুন instance না আনা পর্যন্ত টিকে থাকা server-গুলো 100%-এর ওপরে চলে। এতে কয়েক মিনিট লাগে, আর নির্ভর করে বাকি AZ-গুলোতে ঠিক তখন capacity পাওয়া যায় কি না, যখন বাকি সবাইও সেখানেই instance চালু করছে।

একটা হিসাব করে দেখি। একটা দোকানের peak-এ ৯টা instance লাগে, চলে ৩টা AZ-এ। প্রতিটা AZ-এ লাগবে ৯ ÷ ২ = ৪.৫, মানে ৫টা, মোট ১৫টা। স্বাভাবিক সময়ে peak-এ প্রতিটা চলে ৯ ÷ ১৫ = 60%-এ। একটা AZ গেলে থাকে ১০টা, চলে ৯ ÷ ১০ = 90%-এ: ব্যস্ত, কিন্তু সবাইকে সার্ভ করছে। একই ৯টা যদি ৩ + ৩ + ৩ করে রাখা হতো, টিকে থাকা ৬টা চলত 150%-এ।

পুরনো N+1 নিয়মও (যা লাগে তার চেয়ে একটা বাড়তি) ঠিক এই চিন্তা, শুধু একেকটা server-এর বদলে পুরো AZ ধরে।

#Elasticity: দিনের বাঁকা রেখা ধরে চলা

বেশিরভাগ application-এর একটা দৈনিক ছন্দ আছে: রাতে চুপচাপ, দিনে ব্যস্ত, সন্ধ্যায় peak। স্থির capacity হয় বেশিরভাগ সময় বেশি, নয়তো peak-এ কম। একটা instance resize করে outage ছাড়া এই রেখা অনুসরণ করা যায় না। scaling policy-সহ একটা Auto Scaling group পারে, আর এটাই তাকে elastic বানায়: মোটামুটি যতটুকু ব্যবহার করো ততটুকুরই টাকা দাও, আর ভাবনার চেয়ে বড় peak এলে আরও instance চালু হয় (group-এর maximum পর্যন্ত)।

#AWS-এ কোনটা কোথায় দেখা যায়

#কোথায় গোলমাল হয়

#System design-এ কীভাবে কাজে লাগে

• AWS-এ একটা web application-এর default চেহারা: অন্তত দুটো (প্রায়ই তিনটা) AZ জুড়ে একটা load balancer, সেই AZ-গুলোতে stateless instance-এর একটা Auto Scaling group, session ElastiCache বা DynamoDB-তে, ফাইল S3-তে, আর একটা Multi-AZ database। প্রতিটা tier একটা AZ হারিয়েও টিকে থাকে; web tier scale-ও করে।
• stateless tier-গুলো scale out করো, stateful কেন্দ্রটা scale up করো (আর তার সামনে read replica বা caching বসাও), যতদিন না data layer নতুন করে ভাবার সময় আসে।
• কয়টা AZ, ভেবেচিন্তে ঠিক করো। HA-র জন্য দুটো সর্বনিম্ন; তিনটা হলে AZ হারিয়ে টিকে থাকা সস্তা হয়, production-এ এটাই বেশি দেখা যায়।
• availability-কে একটা সংখ্যায় লেখো। ব্যবসা যদি 99.99% চায় (বছরে প্রায় ৫২ মিনিট), কয়েক মিনিটের resize-ওয়ালা একটা instance দিয়ে সেটা হবে না; multi-AZ active-active দিয়ে হবে।

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

এই command-গুলো AWS CLI-র, ID-গুলো বানানো। এগুলো টাকা লাগে এমন resource বানায়: শেষে মুছে ফেলো।

একটা Region-এ তোমার account কোন কোন AZ ব্যবহার করতে পারে দেখো (AZ-এর নাম একেক account-এ একেক physical zone-এ map হয়; zone ID সবার জন্য একই):

aws ec2 describe-availability-zones --region us-east-1 \
  --query "AvailabilityZones[].[ZoneName,ZoneId,State]" --output table

একটা instance scale up করো: stop, type বদল, start, আর downtime নিজের চোখে দেখো।

aws ec2 stop-instances --instance-ids i-0abc1234def567890
aws ec2 wait instance-stopped --instance-ids i-0abc1234def567890
aws ec2 modify-instance-attribute --instance-id i-0abc1234def567890 --instance-type Value=t3.large
aws ec2 start-instances --instance-ids i-0abc1234def567890
aws ec2 describe-instances --instance-ids i-0abc1234def567890 \
  --query "Reservations[].Instances[].[InstanceType,PublicIpAddress]"

খেয়াল করো, public IP বদলে গেছে (Elastic IP না হলে)।

দুটো AZ জুড়ে scale out করো (লেসন ৬.৫-এর একটু আগাম স্বাদ): আগে থেকে থাকা একটা launch template থেকে একটা Auto Scaling group, প্রতি AZ-এ একটা subnet দিয়ে।

aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name web-asg \
  --launch-template LaunchTemplateName=web-lt,Version='$Latest' \
  --min-size 2 --max-size 6 --desired-capacity 2 \
  --vpc-zone-identifier "subnet-0aaa1111bbbb2222c,subnet-0ddd3333eeee4444f"

# দেখো দুটো instance দুই AZ-এ ভাগ হয়েছে
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names web-asg \
  --query "AutoScalingGroups[].Instances[].[InstanceId,AvailabilityZone,HealthStatus]"

# হাতে scale out, তারপর আবার scale in
aws autoscaling set-desired-capacity --auto-scaling-group-name web-asg --desired-capacity 4
aws autoscaling set-desired-capacity --auto-scaling-group-name web-asg --desired-capacity 2

মুছে ফেলো: aws autoscaling delete-auto-scaling-group --auto-scaling-group-name web-asg --force-delete।

একটা single-AZ RDS instance-কে highly available বানাও (passive standby):

aws rds modify-db-instance --db-instance-identifier shop-db --multi-az --apply-immediately

#সারসংক্ষেপ

মূল কথাগুলো

• Scalability বেশি চাপ সামলায়; elasticity চাহিদা দেখে নিজে থেকে capacity যোগ-বিয়োগ করে; agility মিনিটে resource এনে দেয়; high availability ব্যর্থতার পরও টিকে থাকে; fault tolerance টিকে থাকে কারও চোখে না পড়েই।
• Vertical scaling (up/down) = বড় instance। EC2-তে stop/start লাগে (downtime), একটা ছাদে ঠেকে (আজ 32 TiB, 1,920 vCPU), আর থাকে একটা AZ-এ একটা machine হয়েই। database, cache আর legacy app-এর জন্য ঠিক।
• Horizontal scaling (out/in) = load balancer-এর পেছনে বেশি instance, যোগ-বিয়োগ করে Auto Scaling group। server stateless হতে হবে; session রাখো ElastiCache বা DynamoDB-তে।
• High availability = অন্তত দুটো AZ। Active-active (ASG + ELB) failover করে কয়েক সেকেন্ডে; passive standby (RDS Multi-AZ) প্রায় ১–২ মিনিটে।
• প্রতিটা single point of failure খুঁজে বের করো: একটা AZ, single-AZ database, একটাই NAT gateway, একটা বিশেষ server।
• কোনো degradation ছাড়া একটা AZ হারিয়ে টিকতে চাইলে প্রতি AZ-এ রাখো P ÷ (N − 1): ২টা AZ = 100% বাড়তি, ৩টা AZ = 50% বাড়তি।
• পরীক্ষা: stateless / web tier / spike → ASG; data centre হারিয়েও টেকো / fault tolerant → Multi-AZ; database-এর আরও memory লাগবে → scale up।

নিজেকে যাচাই করো: scaling আর high availability৩০টি প্রশ্ন