Load Balancing, Health Check আর TCP বনাম UDP

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

• load balancer আসলে কী করে, আর server-দের কাঁধ থেকে কোন কোন কাজ নামিয়ে নেয়, তা বুঝিয়ে বলতে পারবে: একটা DNS নাম, ভার ভাগ করা, health check, TLS offload, stickiness, কয়েকটা AZ জুড়ে চালু থাকা, আর public আর private traffic আলাদা রাখা।
• নিজে load balancer চালানোর চেয়ে managed Elastic Load Balancer কেন সাধারণত ভালো, আর এটা কোন কোন service-এর সাথে জোড়া লাগে, তা বলতে পারবে।
• চার ধরনের ELB (CLB, ALB, NLB, GWLB) layer আর protocol দেখে আলাদা করতে পারবে, আর কোনটা আগের প্রজন্মের তা জানবে।
• health check সাজাতে পারবে (protocol, port, path, interval, timeout, threshold, success code), ALB আর NLB-এর এখনকার default মাথায় রেখে, আর একটা গোলমাল ধরা পড়তে কত সময় লাগবে তা হিসাব করতে পারবে।
• target-এর health state পড়তে পারবে, fail-open কী তা বোঝাতে পারবে, আর “running কিন্তু unhealthy” instance-এর সমস্যা খুঁজে বের করতে পারবে।
• instance-গুলোকে এমনভাবে আটকাতে পারবে যাতে তারা শুধু load balancer-এর security group থেকেই traffic নেয়, ALB আর NLB দুটোতেই।
• client-কে কেন load balancer-এর DNS নামই ব্যবহার করতে হয়, আর TCP না UDP, এটা কীভাবে ঠিক করে দেয় কোন load balancer চলবে, তা ব্যাখ্যা করতে পারবে।

#load balancer আসলে কী

লেসন ৬.১-এর শেষে আমাদের application চলছিল কয়েকটা EC2 instance-এ, অন্তত দুটো Availability Zone জুড়ে। তাহলে একটা সোজা প্রশ্ন ওঠে: user-রা কোন address-এ connect করবে? একটা instance-এর IP দিলে সব traffic ওই একটার ঘাড়েই পড়বে, আর সেটাই হয়ে যাবে single point of failure। আবার IP-এর একটা তালিকা দিলে প্রতিটা client-কে নিজে একটা বেছে নিতে হবে, সেটা মরে গেলে টের পেতে হবে, তারপর আরেকটায় যেতে হবে।

এই সমস্যার সমাধানই load balancer। এটা একটা server (AWS-এ আসলে অনেকগুলো server-এর একটা দল, যেটা তুমি কখনো দেখো না), যেটা তোমার instance-দের সামনে বসে থাকে, প্রতিটা client connection নিজে নেয়, আর প্রতিটা request পেছনের কয়েকটা server-এর কোনো একটার কাছে পাঠিয়ে দেয়। পেছনের এই server-গুলোকে বলে target। client-রা কথা বলে শুধু load balancer-এর সাথেই।

#load balancer কেন লাগে

#managed load balancer কেন: Elastic Load Balancing

চাইলে তুমি একটা EC2 instance-এ HAProxy বা Nginx বসিয়ে নিজেই load balancer চালাতে পারো। কিন্তু তখন তার সব ঝামেলাও তোমার: এখন সেটাই তোমার single point of failure, তাই দুটো AZ-এ দুটো লাগবে, একটা থেকে আরেকটায় failover করার ব্যবস্থা লাগবে, patch দিতে হবে, traffic বাড়লে scale করতে হবে, certificate, log, monitoring সব তোমার।

Elastic Load Balancing (ELB) হলো এর managed রূপ:

• AWS নিশ্চয়তা দেয় যে এটা চলবে: তোমার বেছে নেওয়া AZ-গুলো জুড়ে চলে, নষ্ট node বদলে দেয়, আর traffic বদলালে নিজের ক্ষমতা নিজেই বাড়ায়-কমায়।
• upgrade, maintenance আর high availability সব AWS-এর দায়িত্ব। পুরো একটা server দেখাশোনার বদলে তুমি পাও অল্প কয়েকটা setting (listener, rule, target group, health check)।
• AWS-এর বাকি service-গুলোর সাথে জোড়া (পরের অংশে দেখবে)।
• খরচ: শুধু বিল দেখলে একটা instance-এ চালানো ছোট্ট নিজের proxy ELB-এর চেয়ে সস্তা মনে হতে পারে (us-east-1-এ একটা ALB শুরু হয় মাসে মোটামুটি $16 থেকে, ব্যবহার অনুযায়ী capacity-র খরচ এর বাইরে)। কিন্তু availability-র জন্য দ্বিতীয় instance যোগ করো আর এটা চালাতে যে ঘণ্টাগুলো যায় সেগুলো গোনো, তাহলে সব মিলিয়ে managed service-ই প্রায় সবসময় সস্তা পড়ে। পরীক্ষার প্রশ্নে “least operational overhead” দেখলে উত্তর ELB-এর দিকে।

#ELB-এর পরিবার

AWS চার ধরনের managed load balancer দেয়:

আসল কথাটা হলো layer। ALB প্রতিটা HTTP request খুলে তার path, header আর host name পড়তে পারে। NLB কখনো ভেতরে তাকায় না: শুধু IP address আর port দেখে connection আর datagram পাঠিয়ে দেয়, এই জন্যই সে এত দ্রুত। GWLB পুরো IP packet একদল appliance-এর কাছে পাঠায়। প্রত্যেকটা নিয়ে গভীরে যাব লেসন ৬.৩-এ; আপাতত layer আর protocol মনে রাখো।

• Internet-facing না internal: GWLB ছাড়া সব ধরনই internet-facing (public DNS নাম, public IP-ওয়ালা node, public subnet-এ) বা internal (শুধু private IP, VPC আর তার সাথে জোড়া network-এর ভেতর থেকে পৌঁছানো যায়) হিসেবে বানানো যায়। চেনা three-tier design-এ দুটোই থাকে: web tier-এর জন্য internet-facing ALB, আর application tier-এর সামনে একটা internal ALB।
• AZ: ALB-কে অন্তত দুটো AZ-এর subnet-এ বসাতেই হয়। NLB একটা AZ-এও চলে, তবে production-এ দুই বা তার বেশি AZ-ই রাখা উচিত।

#ELB কাদের সাথে জোড়া লাগে

load balancer একা কাজ করে না; সে traffic নিয়ে অন্য service-কে দেয়, আর certificate, নাম আর সুরক্ষার জন্য আরও কয়েকটা service ব্যবহার করে।

#Health check

load balancer চোখ বন্ধ করে traffic পাঠায় না। সে প্রত্যেক target-কে বারবার জিজ্ঞেস করে “তুমি কি সামলাতে পারবে?”, আর যারা বারবার হ্যাঁ বলে, শুধু তাদেরকেই request দেয়। health check সাজানো হয় target group-এ, মানে listener যে target-গুলোর দলে traffic পাঠায় সেখানে (target group নিয়ে বিস্তারিত লেসন ৬.৩-এ)।

#কী পরীক্ষা করা হয়

health check হলো ছোট্ট একটা request, যেটা load balancer একটা নির্দিষ্ট সময় পরপর প্রত্যেক target-কে পাঠায়:

• Protocol: ALB-এর জন্য HTTP বা HTTPS (একটা HTTP GET); NLB-এর জন্য TCP, HTTP বা HTTPS। TCP check শুধু প্রমাণ করে port-টা connection নিচ্ছে; HTTP check প্রমাণ করে application আসলেই উত্তর দিচ্ছে।
• Port: default হলো traffic port, মানে target যে port-এ request পায় সেটাই। চাইলে অন্য port দিতে পারো, যেমন 8080-এর মতো আলাদা একটা admin port।
• Path: HTTP/HTTPS check-এর জন্য কোন URL চাওয়া হবে। default হলো /, কিন্তু /health-এর মতো আলাদা একটা endpoint অনেক ভালো: হালকা, login লাগে না, আর app-এর যা যা সত্যিই লাগে (database connection, disk-এর জায়গা) সেগুলো দেখে নিতে পারে।
• Success code: কোন কোন HTTP status code পেলে healthy ধরা হবে। বাকি যেকোনো code, বা timeout-এর মধ্যে কোনো উত্তর না আসা মানেই ফেল।

#সময় আর threshold

সবচেয়ে জরুরি দুটো হিসাব:

• Unhealthy threshold × interval ≈ নষ্ট একটা target কতক্ষণ ধরে traffic পেতে থাকে। ALB-এর default-এ ২ × ৩০ সে = মোটামুটি ৬০ সেকেন্ড (target error না দিয়ে যদি আটকে থাকে, তাহলে সাথে ৫ সেকেন্ডের timeout যোগ হবে)।
• Healthy threshold × interval ≈ ঠিক হওয়া target আবার traffic পেতে কতক্ষণ অপেক্ষা করে: ৫ × ৩০ সে = ১৫০ সেকেন্ড।

ফেরত আসা ইচ্ছে করেই বাদ পড়ার চেয়ে ধীর, যাতে যে server বারবার crash করে আবার চালু হয়, সে service-এ ঢোকা-বের হওয়ার দোলায় না থাকে। একটা ব্যতিক্রম: target প্রথমবার register হলে ALB-তে healthy হতে তাকে একটা check পাস করলেই চলে।

#হাতে-কলমে হিসাব: দ্রুত failover-এর জন্য টিউন করা

একটা checkout service-এ প্রতি instance প্রতি সেকেন্ডে ৫০টা request পায়। কোনো instance আটকে গেলে ALB তাকে বাদ দেওয়ার আগে কয়টা request ফেল করবে?

• Default-এ (interval ৩০ সে, timeout ৫ সে, unhealthy threshold ২): সবচেয়ে খারাপ অবস্থায় ২ × ৩০ + ৫ = ৬৫ সে, তাই প্রায় ৫০ × ৬৫ = ৩,২৫০টা request ফেল।
• interval ১০ সে, timeout ৫ সে, unhealthy threshold ২ করলে: সবচেয়ে খারাপ অবস্থায় ২ × ১০ + ৫ = ২৫ সে, তাই প্রায় ১,২৫০টা।

ঘনঘন check দিলে সমস্যা আগে ধরা পড়ে, কিন্তু target-এর ওপর একটু বেশি চাপ পড়ে, আর একবার ধীর উত্তর এলেই ভালো একটা instance বাদ পড়ার সম্ভাবনা বাড়ে। বেশিরভাগ টিম latency-র ব্যাপারে স্পর্শকাতর service-এ interval ১০–১৫ সেকেন্ডে নামায়, বাকি জায়গায় default রাখে। client-এরও উচিত idempotent request আবার চেষ্টা করা, কারণ ধরা পড়ার ওই সময়টুকুতে কিছু request সবসময়ই নষ্ট target-এ গিয়ে পড়ে।

#Target-এর health state

target group-এর Targets tab-এ (EC2 console → Load Balancing → Target Groups) প্রত্যেক target-এর state দেখা যায়:

NLB-তে আরেকটা আছে, unhealthy.draining: unhealthy একটা target কিছুক্ষণের জন্য তার পুরোনো connection-গুলো চালিয়ে যায়, কিন্তু নতুন কোনোটা পায় না।

#সব target unhealthy হলে: fail open

একটা target group-এর সব target যদি একসাথে unhealthy হয় (চালু থাকা প্রতিটা AZ-এ), load balancer fail open করে: তবুও সবাইকে request পাঠায়, যেন সবাই healthy। যুক্তিটা হলো, কাউকে traffic না পাঠানো মানে নিশ্চিত outage, অথচ নষ্ট হয়ে থাকতে পারে health check নিজেই (/health path-এর নাম বদলে গেছে, check-এর ভেতরে থাকা কোনো dependency বন্ধ, কোনো security group বদলেছে)। target group খালি থাকলেও NLB fail open করে।

তাই “সব target unhealthy কিন্তু user-রা তবুও সেবা পাচ্ছে” কোনো bug না; এটা fail-open, আর এটা জোরালো ইঙ্গিত যে app না, health check-এর setting-ই ভুল। NLB-তে যখন শুধু একটা AZ-এ কোনো healthy target থাকে না, তখন ওই AZ-এর load balancer IP DNS থেকে সরিয়ে দেওয়া হয়, যাতে client-রা আর সেখানে না যায়।

#“running কিন্তু unhealthy”: সমস্যা খোঁজা

#Security group: শুধু load balancer-কেই বিশ্বাস করো

সবচেয়ে নিরাপদ design-এ internet থেকে কোনো instance-এ পৌঁছানোর পথ load balancer ছাড়া আর একটাও থাকে না। এটা বানাতে লাগে দুটো security group (লেসন ৩.৫):

IP range না দিয়ে security group reference কেন?

• load balancer scale করার সময় আর node বদলানোর সময় তার node-গুলোর IP address বদলে যায়। যে rule-এ sg-alb লেখা, সেটা ওই group লাগানো যেকোনো interface-এর সাথে মেলে, IP যাই হোক।
• instance-এ 0.0.0.0/0 rule থাকলে কেউ instance-এর address পেয়ে গেলেই (ভুল করে রাখা একটা public IP, বা peering করা কোনো network) load balancer, তার TLS, WAF rule আর log, সব এড়িয়ে সরাসরি ঢুকে যেতে পারে।
• VPC CIDR দিলে 0.0.0.0/0-এর চেয়ে ভালো, কিন্তু তবুও VPC-র বাকি সব machine ঢুকতে পারে।

#Network Load Balancer আর security group

বহু বছর NLB-এর কোনো security group-ই ছিল না। সে client-এর IP সোজা target পর্যন্ত পৌঁছে দিত, তাই instance-এর security group-এ খুলতে হতো client-দের IP range (প্রায়ই 0.0.0.0/0), সাথে health check-এর জন্য NLB-এর নিজের private IP। “শুধু NLB হয়ে এসো” বলার কোনো উপায় ছিল না।

আগস্ট ২০২৩ থেকে NLB-এ security group লাগানো যায়, আর একই chaining চলে: NLB-এর group client ছাঁকে, আর target-রা NLB-এর group-কে reference করে। যা মনে রাখতে হবে:

• security group লাগাতে হবে NLB বানানোর সময়েই। security group ছাড়া বানানো NLB-তে পরে আর কখনো লাগানো যায় না; নতুন NLB বানাতে হবে। অন্তত একটা থাকলে পরে যত খুশি বদলাতে পারো।
• Health check NLB-এর outbound rule মানে, inbound rule না। খেয়াল রাখো outbound rule যেন target-এর health check port আটকে না দেয়।
• target-দের NLB-এর group থেকে traffic port আর health check port দুটোই খুলতে হবে, client IP preservation চালু থাকলেও।
• interface VPC endpoint দিয়ে আসা traffic-এ NLB-এর inbound rule খাটবে কিনা, সেটা তুমি ঠিক করতে পারো।
• GWLB-এর কোনো security group নেই; সেখানে ছাঁকার কাজ appliance-দের।

#IP না, DNS নাম দিয়ে পৌঁছাও

প্রতিটা load balancer একটা DNS নাম পায়, যেমন my-alb-1234567890.us-east-1.elb.amazonaws.com। এই নামের পেছনে থাকে load balancer-এর node-গুলো, চালু থাকা প্রতিটা AZ-এ অন্তত একটা করে। ALB-তে (আর CLB-তে) AWS যখন load balancer বড়-ছোট করে আর node বদলায়, তখন নামের পেছনের IP address বদলে যায়; record-গুলোর TTL মাত্র ৬০ সেকেন্ড, যাতে client-রা তাড়াতাড়ি নতুন IP ধরতে পারে।

তাই:

• সবসময় DNS নাম দিয়ে connect করো, একবার দেখে নেওয়া কোনো IP দিয়ে কখনো না।
• নিজের domain-কে এর দিকে দেখাও একটা Route 53 alias record দিয়ে (subdomain-এর জন্য CNAME-ও চলে, কিন্তু zone apex-এ না)। alias record নিয়ে chapter ৮-এ।
• কোনো customer যদি নিজের firewall-এর allow list-এ বসানোর জন্য fixed IP চায়, তাহলে উত্তর প্রতি AZ-এ একটা Elastic IP-ওয়ালা NLB, বা ALB-এর সামনে Global Accelerator। দুটো নিয়েই লেসন ৬.৩-এ।

#TCP বনাম UDP: একটু ঝালিয়ে নেওয়া

কোন load balancer নেবে, সেটা ঠিক করতে আগে জানতে হবে তোমার traffic কী ধরনের। internet-এর প্রায় সব data দুটো transport protocol-এর কোনো একটায় চলে। System Design course-এর TCP, UDP আর TLS লেসনে এগুলো গভীরভাবে আছে; এই chapter-এর জন্য যতটুকু লাগে, তা এখানে।

ব্যবহারগুলো এভাবে ভাগ হলো কেন:

• Web browsing: একটা ছবি না এলে বিরক্ত লাগে, কিন্তু code-এর একটা লাইন হারালে পুরো page ভেঙে যায়, তাই web চলে TCP-তে (HTTP/3 ব্যতিক্রম, নিচে দেখো)।
• Database: ব্যাংকের টাকা পাঠানোয় একটা byte-ও হারানো চলবে না। TCP।
• File transfer আর email: ফাইল বা email-এর মাঝখান থেকে একটা শব্দ উধাও হয়ে যাওয়া মেনে নেওয়া যায় না। TCP।
• Live video call (Zoom, Meet): এক-দুটো frame হারালে ছবিটা এক মুহূর্ত আটকায়, তুমি পাত্তাও দাও না। কিন্তু হারানো frame আবার আনতে গিয়ে যদি call কয়েক সেকেন্ড জমে থাকে, যেমনটা TCP করত, সেটা অনেক বেশি বিরক্তিকর। UDP।
• VoIP: শব্দে ছোট্ট একটু ফাঁক থাকলে সমস্যা নেই; কিন্তু দেরি হলে কথা বলাই অসম্ভব। UDP।
• Online multiplayer game: খেলোয়াড়ের অবস্থান কয়েক millisecond-এর মধ্যে পৌঁছাতে হয়; পুরোনো অবস্থান এমনিতেই কোনো কাজের না। UDP।
• DNS: ছোট্ট একটা প্রশ্ন আর ছোট্ট একটা উত্তর; handshake করলে সময় দ্বিগুণ লাগত। port 53-এ UDP (বড় উত্তর আর zone transfer-এ TCP)।

#load balancer-এর এতে কী আসে যায়

• ALB শুধু HTTP আর HTTPS বোঝে (যেগুলো TCP-র ওপর চলে)। তার কোনো UDP listener নেই, তাই game-এর UDP traffic, VoIP বা DNS সে বইতে পারে না।
• NLB কাজ করে layer 4-এ: সে TCP, UDP আর TLS listener সমর্থন করে (একই port-এ TCP_UDP-ও)। payload খোলে না; শুধু IP আর port দেখে, তাই খুব কম latency-তে প্রতি সেকেন্ডে লক্ষ লক্ষ request সামলাতে পারে। নভেম্বর ২০২৫ থেকে সে QUIC traffic-ও পার করে দিতে পারে, connection ID দেখে একটা session-কে একই target-এ রাখে, phone network বদলালেও (এটা নতুন feature; এখনকার পরীক্ষার প্রশ্ন TCP আর UDP-তেই বেশি জোর দেয়)।
• UDP target-দের health check হয় TCP, HTTP বা HTTPS দিয়ে, কারণ যেকোনো UDP service-কে “বেঁচে আছ?” জিজ্ঞেস করার সাধারণ কোনো উপায় নেই। ছোট্ট একটা check endpoint চালাও, যেটা জানাবে UDP service ঠিকঠাক চলছে কিনা।

#system design-এ load balancer কীভাবে ব্যবহার হয়

• প্রতিটা web tier: দুই-তিনটা AZ-এর public subnet-এ একটা internet-facing ALB, private subnet-এ instance বা container, আর instance-দের security group ALB-এর group-কে reference করে। AWS-এর প্রায় প্রতিটা architecture diagram-এর এটাই মূল কাঠামো।
• ভেতরের tier: web tier আর application tier-এর মাঝে একটা internal load balancer, যাতে প্রতিটা tier আলাদাভাবে scale করে আর আলাদাভাবে নষ্ট হয়।
• Load balancer + Auto Scaling group: ASG instance যোগ করে আর সরায়; load balancer তাদের register করে আর নষ্টগুলোকে বাদ দেয়; ASG ELB health check দেখে যে instance চলছে কিন্তু কাজ করছে না, তাকে বদলে দেয় (লেসন ৬.৫)।
• Deployment: কয়েকটা target deregister করো, update করো, আবার register করো; health check নিশ্চিত করে শুধু চলনসই version-ই traffic পায়। blue/green deployment-এ দুটো target group-এর মধ্যে traffic সরানো হয়।
• HTTP ছাড়া অন্য service: game server, message broker, VoIP gateway আর database বসে NLB-এর পেছনে।
• load balancer যেটা ঠিক করে না: application যদি session data memory-তে রাখে, তাহলে request ভাগ করলেই login আর cart ভেঙে যায়। stickiness একটা চটজলদি জোড়াতালি (লেসন ৬.৪); session-কে instance-এর বাইরে রাখাই আসল সমাধান (chapter ৯)।

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

# 1. Two security groups: the ALB open to the internet, the instances open only to the ALB
SG_ALB=$(aws ec2 create-security-group --group-name sg-alb --description "ALB" \
  --vpc-id $VPC --query GroupId --output text)
aws ec2 authorize-security-group-ingress --group-id $SG_ALB --protocol tcp --port 443 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress --group-id $SG_ALB --protocol tcp --port 80  --cidr 0.0.0.0/0

SG_APP=$(aws ec2 create-security-group --group-name sg-app --description "web instances" \
  --vpc-id $VPC --query GroupId --output text)
aws ec2 authorize-security-group-ingress --group-id $SG_APP --protocol tcp --port 80 \
  --source-group $SG_ALB              # a security group reference, not a CIDR

# 2. A target group with an explicit health check
TG=$(aws elbv2 create-target-group --name web-tg --protocol HTTP --port 80 --vpc-id $VPC \
  --health-check-protocol HTTP --health-check-path /health \
  --health-check-interval-seconds 10 --health-check-timeout-seconds 5 \
  --healthy-threshold-count 3 --unhealthy-threshold-count 2 \
  --matcher HttpCode=200 \
  --query "TargetGroups[0].TargetGroupArn" --output text)

# 3. An internet-facing ALB in public subnets of two AZs, and a listener
ALB=$(aws elbv2 create-load-balancer --name web-alb --type application --scheme internet-facing \
  --subnets $PUB_A $PUB_B --security-groups $SG_ALB \
  --query "LoadBalancers[0].LoadBalancerArn" --output text)
aws elbv2 create-listener --load-balancer-arn $ALB --protocol HTTP --port 80 \
  --default-actions Type=forward,TargetGroupArn=$TG

# 4. Register two instances (launched in private subnets with sg-app) and watch their health
aws elbv2 register-targets --target-group-arn $TG --targets Id=$I1 Id=$I2
aws elbv2 describe-target-health --target-group-arn $TG \
  --query "TargetHealthDescriptions[].[Target.Id,TargetHealth.State,TargetHealth.Reason]" --output table

# 5. Use the DNS name (never the IPs behind it)
DNS=$(aws elbv2 describe-load-balancers --load-balancer-arns $ALB \
  --query "LoadBalancers[0].DNSName" --output text)
dig +short $DNS                       # the IPs here can change over time
curl -s http://$DNS/                  # repeat: responses come from different instances

# 6. Break one target and watch it go unhealthy (on that instance)
sudo systemctl stop httpd             # about 2 × 10 s later describe-target-health shows unhealthy
sudo systemctl start httpd            # about 3 × 10 s later it is healthy again

# 7. An NLB with a security group (must be chosen at creation) and a UDP listener
NLB=$(aws elbv2 create-load-balancer --name game-nlb --type network --scheme internet-facing \
  --subnets $PUB_A $PUB_B --security-groups $SG_NLB \
  --query "LoadBalancers[0].LoadBalancerArn" --output text)
aws elbv2 create-target-group --name game-udp --protocol UDP --port 7777 --vpc-id $VPC \
  --health-check-protocol TCP --health-check-port 8080      # UDP targets get a TCP/HTTP check

#সারসংক্ষেপ

মূল কথাগুলো

• load balancer client-দের দেয় একটা DNS নাম, request ভাগ করে অনেক target-এর মধ্যে, তাদের health check করে, TLS খোলে, চাইলে user-কে sticky রাখে, কয়েকটা AZ জুড়ে চলে, আর instance-দের private রাখে।
• ELB managed: AWS চালায়, scale করে, patch দেয়, চালু রাখে। নিজের proxy fleet-এর চেয়ে knob কম, খাটুনি অনেক কম। EC2, ASG, ECS, Lambda, ACM, CloudWatch, Route 53, WAF আর Global Accelerator-এর সাথে জোড়া লাগে।
• ধরন: CLB (আগের প্রজন্ম, সরে যাও), ALB (layer 7, HTTP/HTTPS/gRPC/WebSocket), NLB (layer 4, TCP/UDP/TLS, static IP, চরম performance), GWLB (layer 3, পথের মাঝে appliance)।
• WAF লাগে ALB-তে (আর CloudFront, API Gateway, AppSync, Cognito, App Runner, Verified Access, Amplify-তে), CLB বা NLB-তে না।
• Health check: protocol, port, path, success code। Default: interval ৩০ সে, unhealthy threshold ২, healthy threshold ৫; timeout ৫ সে (ALB) বা ১০ সে / ৬ সে (NLB TCP-HTTPS / HTTP); success code 200 (ALB) বা 200–399 (NLB)।
• ধরা পড়ার সময় ≈ unhealthy threshold × interval (default-এ ≈ ৬০ সে); ফেরত আসার সময় ≈ healthy threshold × interval (≈ ১৫০ সে)।
• State: initial, healthy, unhealthy, unused, draining, unavailable (NLB-তে unhealthy.draining-ও)। সব target unhealthy হলে load balancer fail open করে।
• “running কিন্তু unhealthy” → app crash, security group check-এর port আটকাচ্ছে, ভুল path বা redirect, বা app ধীরে চালু হচ্ছে।
• instance app-এর port খোলে শুধু load balancer-এর security group থেকে। ২০২৩ থেকে NLB-তে security group চলে, কিন্তু শুধু বানানোর সময় লাগালে।
• DNS নাম ব্যবহার করো: ALB-এর IP বদলায়। fixed IP লাগলে → Elastic IP-ওয়ালা NLB বা Global Accelerator।
• TCP = handshake, নির্ভরযোগ্য, ঠিক ক্রমে (web, database, ফাইল, email)। UDP = handshake নেই, গ্যারান্টি নেই, দ্রুত (DNS, VoIP, game, live media)। ALB UDP পারে না; NLB পারে।

নিজেকে যাচাই করো: load balancing-এর মূল কথা৩০টি প্রশ্ন