Load Balancing Algorithm: কোন server request পাবে
Load Balancing Algorithms
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- Round robin, weighted ও least-connections
- Hash-based routing ও skew
- Workload অনুযায়ী algorithm পরীক্ষা
সমস্যা দিয়ে শুরু
তিন server-এ সমান request যাচ্ছে, তবু একটির CPU সবসময় বেশি। কিছু request ২০ milliseconds, কিছু export দশ সেকেন্ড চলে। Request count সমান হওয়া মানে কাজ সমান নয়। Load-balancing algorithm workload ও backend capacity-এর অনুমান নিয়ে সিদ্ধান্ত নেয়; সেই অনুমান ভুল হলে distribution সুন্দর দেখালেও latency খারাপ হয়।
সহজ করে বুঝি
Round robin পর্যায়ক্রমে backend বেছে নেয়। Weighted round robin বেশি ক্ষমতার node-কে বেশি share দেয়। Least connections কম active connection-এর node বেছে নিতে পারে; কিন্তু HTTP/2-এ একটি connection বহু concurrent stream বহন করায় count সব workload-এ load-এর ভালো মাপ নয়। Random two choices দুটি candidate-এর মধ্যে তুলনা করে কম cost-এ ভালো distribution দিতে পারে। IP বা user-key hashing affinity দেয়, তবে বড় tenant বা shared NAT hotspot তৈরি করতে পারে।
পরিচিত একটি উপমা
তিন cashier-এ পালা করে customer পাঠালে সারির সংখ্যা সমান হয়। একজনের বিশাল trolley থাকলে পরের customer-কে ছোট line-এ পাঠানো ভালো হতে পারে। কিন্তু line-এ একজন wholesale buyer আর পাঁচজন ছোট buyer-এর কাজের পরিমাণ আলাদা। দৃশ্যমান count শুধু proxy signal।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart TD R[Incoming request] --> S[Select healthy candidates] S --> A[Round robin or weighted policy] A --> N1[App small] A --> N2[App large] N1 --> M[Measure latency and saturation] N2 --> M M --> S
আগে healthy candidate set তৈরি হয়, তারপর algorithm destination বেছে নেয়। Weight capacity assumption প্রকাশ করে। নিচের feedback arrow monitoring বোঝায়; প্রতিটি request-এ CPU synchronously পড়তে হবে এমন নয়। Latency, active work ও error একসঙ্গে দেখে weight বদলান। Autoscaling হলে membership change algorithm-এর distribution-এ প্রভাব ফেলে।
PHP ও Laravel-এ প্রয়োগ
Laravel route fragment controlled staging-এ কোন backend response দিয়েছে বুঝতে সাহায্য করে। services.app_instance.id config-এ nonsecret label দিন। Production public response-এ internal hostnames প্রকাশ না করে protected telemetry ব্যবহার করুন। Code algorithm configure করে না; proxy-level selection observe করে।
use Illuminate\Support\Facades\Route;
Route::get('/balance-demo', function () {
return response()->json([
'instance' => config('services.app_instance.id', 'unknown'),
'handled_at' => now()->toIso8601String(),
])->header('Cache-Control', 'no-store');
});সুবিধা, সীমাবদ্ধতা ও trade-off
Round robin সহজ, homogeneous short requests-এ baseline হিসেবে ভালো। Weighted policy unequal nodes সামলায়, কিন্তু ভুল weight imbalance বাড়ায়। Least-connections দীর্ঘ connection workload-এ সহায়ক হতে পারে, তবে connection ও actual work mismatch মাপুন। Hash routing cache locality বাড়ায়; node বদলালে remapping ও skew বাড়তে পারে। Session affinity correctness-এর বিকল্প নয়; backend crash-এ shared session বা recovery path লাগবে।
সাধারণ ভুল
- Cached response দেখে backend distribution মাপা।
- Warm-up না হওয়া নতুন node-কে সঙ্গে সঙ্গে full weight দেওয়া।
- Sticky session-এ user distribution সবসময় uniform ভাবা।
আরও একটু গভীরে
Algorithm-এর সিদ্ধান্তের unit connection নাকি request সেটি জরুরি। L4 connection একবার assign হলে connection-এর সব traffic একই backend-এ থাকে। L7 প্রতিটি request route করতে পারে, implementation অনুযায়ী upstream reuse হয়। WebSocket-এর মতো long-lived session-এ rebalance সাধারণ short request-এর মতো হয় না। Graceful draining এবং connection lifetime distribution planning-এ রাখুন।
মনে রাখুন
Algorithm-এর নামের চেয়ে workload assumption গুরুত্বপূর্ণ। Equal counts-এর পাশাপাশি cost, latency ও saturation দেখুন। Cache, keep-alive ও long-lived connection experiment-এর ফল বদলায়।
নিজে চেষ্টা করুন
একটি staging workload-এ ছোট read ও বড় report মেশান। Round robin এবং weighted policy-তে প্রতি instance request count, active work ও p95 latency তুলনা করুন। Load ও hardware assumption লিখে রাখুন; ফলকে সব system-এর benchmark বলবেন না।
নিজের বোঝা যাচাই করুন
1. Round robin কাজ সমান করে?
Request বা connection assignment সমান করতে পারে; cost সমান করে না। বড় export আর ছোট read একই unit হিসেবে গোনা হতে পারে।
2. Least connections সবসময় সেরা?
না। Multiplexing ও variable request cost connection count-কে দুর্বল signal করতে পারে। বাস্তব workload-এ পরীক্ষা দরকার।
3. Hash routing-এর সুবিধা কী?
এক key একই backend-এ গেলে locality বা affinity বাড়ে। কিন্তু popular key ও unequal tenant size hotspot সৃষ্টি করতে পারে।
4. Weight কোথা থেকে নেব?
Capacity test, resource limit ও measured saturation থেকে initial estimate নিন। Hardware name দেখে universal ratio ধরে নেবেন না।
5. HTTP cache experiment নষ্ট করে কেন?
Edge cache থেকে response এলে backend selection হয় না। Demo route-এ no-store এবং representative uncached workload দিয়ে পরীক্ষা করুন।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।