লোড ব্যালেন্সিং
একাধিক সার্ভারের মধ্যে ট্রাফিক বিতরণ — স্কেলেবল সিস্টেমের ভিত্তি।
ভাবুন একটি ব্যাংকে শুধু একজন ক্যাশিয়ার আছেন। সবাইকে দীর্ঘ লাইনে দাঁড়াতে হবে। এখন যদি ৫ জন ক্যাশিয়ার থাকেন এবং একজন গাইড সবাইকে আলাদা আলাদা ক্যাশিয়ারের কাছে পাঠান — কাজ অনেক দ্রুত হবে। সেই গাইডই হলো Load Balancer।
Load Balancing কী?
Load Balancing হলো একটি প্রক্রিয়া যেখানে একাধিক সার্ভারের মধ্যে আগত ট্রাফিক/রিকোয়েস্ট সমভাবে বিতরণ করা হয়। যে সিস্টেম এই কাজ করে তাকে বলে Load Balancer।
কেন Load Balancing দরকার?
- Scalability: ট্রাফিক বাড়লে নতুন সার্ভার যোগ করা যায়।
- High Availability: এক সার্ভার down হলেও সিস্টেম চলতে থাকে।
- Performance: Response time কম হয়।
- Failover: অসুস্থ সার্ভারে রিকোয়েস্ট পাঠানো বন্ধ।
- Maintenance সহজ: এক সার্ভার মেরামতের সময় অন্যরা চলে।
Load Balancing অ্যালগরিদম
১. Round Robin
প্রতিটি রিকোয়েস্ট পালা করে একেক সার্ভারে যায় — সার্ভার ১, ২, ৩, ১, ২, ৩...।
- সুবিধা: খুব সহজ।
- অসুবিধা: সার্ভারের ক্ষমতা/বর্তমান লোড বিবেচনা করে না।
২. Weighted Round Robin
শক্তিশালী সার্ভারকে বেশি weight দেওয়া হয়। যেমন server A (weight 3), server B (weight 1) — A তিনটি, B একটি রিকোয়েস্ট পাবে।
৩. Least Connections
যে সার্ভারে এই মুহূর্তে সবচেয়ে কম active connection আছে তার কাছে রিকোয়েস্ট পাঠানো হয়।
- সুবিধা: বর্তমান লোড বিবেচনা করে।
- ব্যবহার: long-running connection (যেমন database)।
৪. Least Response Time
যে সার্ভার সবচেয়ে দ্রুত response দিচ্ছে তার কাছে পাঠানো হয়।
৫. IP Hash
ক্লায়েন্টের IP-এর hash দেখে সবসময় একই সার্ভারে পাঠানো হয়।
- সুবিধা: Session persistence (sticky session)।
৬. Random
র্যান্ডম একটি সার্ভার বেছে নেওয়া হয়। সাধারণ কিন্তু অনুমানযোগ্য নয়।
Layer 4 বনাম Layer 7 Load Balancer
Layer 4 (Transport)
- IP ও port দেখে রাউট করে
- TCP/UDP লেভেলে কাজ করে
- HTTP header দেখতে পারে না
- খুব দ্রুত (less processing)
- উদাহরণ: HAProxy (TCP mode), AWS NLB
Layer 7 (Application)
- HTTP header, URL, cookie দেখে রাউট করে
- Smart routing — /api → API server, /img → CDN
- SSL termination করতে পারে
- একটু ধীর (বেশি processing)
- উদাহরণ: NGINX, AWS ALB, Cloudflare
Load Balancer-এর ধরন
Hardware Load Balancer
F5, Citrix-এর মতো ফিজিকাল ডিভাইস। দামি কিন্তু খুব দ্রুত। বড় কর্পোরেটে ব্যবহৃত।
Software Load Balancer
NGINX, HAProxy, Envoy — সফটওয়্যার ভিত্তিক। সস্তা, কনফিগার করা সহজ।
Cloud Load Balancer
AWS ELB/ALB/NLB, GCP Load Balancer, Azure Load Balancer — ক্লাউড সেবা।
DNS Load Balancing
DNS-এ একাধিক IP দিয়ে round-robin বা geo-based routing করা হয়।
Health Check
Load balancer প্রতি কয়েক সেকেন্ডে সার্ভারগুলোকে ping করে দেখে তারা ঠিক আছে কিনা।
- Active health check: Periodically HTTP request পাঠায় (যেমন
/health)। - Passive health check: ব্যর্থ রিকোয়েস্ট দেখে সার্ভার unhealthy চিহ্নিত করে।
- Unhealthy সার্ভারে নতুন রিকোয়েস্ট পাঠানো হয় না।
Sticky Session (Session Persistence)
একই ক্লায়েন্টকে সবসময় একই সার্ভারে পাঠানো — যাতে session ডেটা হারিয়ে না যায়।
- উদাহরণ: ই-কমার্সের শপিং কার্ট সার্ভার মেমরিতে থাকলে।
- আধুনিক বিকল্প: Session ডেটা Redis-এ রাখলে sticky session লাগে না।
বাস্তব উদাহরণ
- Facebook: বিশ্বজুড়ে অসংখ্য load balancer।
- Netflix: Geo-DNS + Application LB।
- Cloudflare: DNS LB + edge LB।
- Banking: Hardware LB (F5) — high security।
সাধারণ ভুল ধারণা
- "একটি LB-ই যথেষ্ট": না, LB নিজেই single point of failure হতে পারে। Active-passive বা active-active deploy করুন।
- "Round Robin সবসময় ভালো": না, সার্ভারের ক্ষমতা ভিন্ন হলে weighted ভালো।
- "Layer 7 সবসময় ভালো": না, বেশি ট্রাফিকে Layer 4 দ্রুত।
সিস্টেম ডিজাইনে Best Practices
- সবসময় health check enable রাখুন।
- LB-কেই duplicate করুন (HA pair)।
- Stateless সার্ভার বানান (Redis-এ session রাখুন)।
- SSL termination LB-তে করুন — backend-এ কাজ কমান।
- Auto-scaling-এর সাথে integrate করুন।
📌 চ্যাপ্টার সারমর্ম
- Load Balancer একাধিক সার্ভারে ট্রাফিক বিতরণ করে।
- Round Robin, Least Connections, IP Hash — কমন অ্যালগরিদম।
- Layer 4 দ্রুত, Layer 7 smart।
- Health check unhealthy সার্ভার চিহ্নিত করে।
- HA-এর জন্য LB-কেই duplicate করুন।