Load balancing — L4 বনাম L7, algorithm আর health check

১ · Load balancer কেন — চারটি কাজ

পর্ব ১৩-এ দেখেছেন, একটি বড় সার্ভারের বদলে অনেকগুলো ছোট, একই রকম, stateless সার্ভার রাখাই বড় সেবার পথ। কিন্তু তখনই একটি প্রশ্ন ওঠে: ব্যবহারকারীর ফোন কোন সার্ভারে যাবে? ফোন তো দশটি ঠিকানা মনে রাখতে পারে না, আর কোনটি এই মুহূর্তে বিকল, তাও জানে না। মাঝখানে যে বসে এই সিদ্ধান্ত নেয়, সে load balancer (সংক্ষেপে LB).

L7 load balancer প্রায়ই TLS termination, compression আর routing-ও করে — এগুলো reverse proxy-র কাজ (পর্ব ১১)। এই পর্বের প্রশ্ন সংকীর্ণ কিন্তু গভীর: কোন অনুরোধ কোন সার্ভারে যাবে, আর কোন সার্ভার এখন অনুরোধ নেওয়ার যোগ্য? Network-এর দিক — ECMP আর packet-স্তরের কাজ — Computer Networks কোর্সের Data center নেটওয়ার্ক পর্বে।

২ · Load balancer কোথায় বসে — DNS থেকে client-এর ভেতর পর্যন্ত

“Load balancer” কোনো একটি বাক্স নয়; একটি অনুরোধের পথে কয়েক জায়গায় ভাগের সিদ্ধান্ত হয়, প্রতিটি আলাদা মাপে:

একটি সাধারণ বড় সেবায় সব স্তর একসাথে থাকে। নিচের ছবিটি এই পর্বের মানচিত্র — বাকি অংশগুলো এর এক একটি বাক্স খুলে দেখবে:

দুই স্তর কেন? L4 দ্রুত আর সরল — একটি জোড়া লাখো সংযোগ সামলায়, ভাঙেও কম। L7 প্রতি অনুরোধে বেশি CPU খরচ করে, তাই তাদের অনেকগুলো লাগে, আর তাদের মধ্যে ভাগ করে L4. ছোট সেবায় একটি managed L7 LB বা দুটি Nginx-ই যথেষ্ট। ভেতরের call-এ client বা পাশের sidecar নিজেই বাছতে পারে — service mesh-এর একটি মূল কাজ; backend-তালিকা কোথা থেকে আসে, তা পর্ব ৪৭ (Monolith বনাম microservices)-এর বিষয়।

৩ · L4 বনাম L7 — কে কী দেখে, কী পারে, কী দামে

“L4” আর “L7” নাম OSI স্তর থেকে, তবে পণ্যভেদে অর্থ একটু আলাদা — একই HAProxy একটি port-এ L4, আরেকটিতে L7. আসল প্রশ্ন: সিদ্ধান্তের সময় LB কতটুকু দেখে, আর কত ঘন ঘন সিদ্ধান্ত নেয়? TLS খোলার লাভ (certificate এক জায়গায়, handshake-এর CPU backend থেকে সরে) আর দাম (key-সহ LB নিরাপত্তার কেন্দ্র; ভেতরে আবার এনক্রিপ্ট না করলে ভেতরের নেটওয়ার্ককে বিশ্বাস) পর্ব ১১-এ দেখেছেন।

একটি অনুরোধ L4 আর L7-এর ভেতর দিয়ে

ছবি ১৪.১-এর পথটি এবার ধাপে ধাপে দেখুন। প্রতিটি ধাপে দুটি সারি পাশাপাশি — L4 কী দেখছে, আর L7 কী দেখছে। “পরে” চাপুন:

দীর্ঘজীবী সংযোগের ফাঁদ — HTTP/2 আর gRPC-তে অসম ভার

HTTP/1.1-এ অনেক client-এর অনেক ছোট সংযোগ — connection-level ভাগেই ভার মোটামুটি সমান হতো। HTTP/2 এক সংযোগে অনেক অনুরোধ একসাথে চালায় (multiplexing), আর gRPC (পর্ব ৯)-এ একটি client সাধারণত একটি সংযোগ ঘণ্টার পর ঘণ্টা রাখে, সব RPC তার আলাদা stream-এ। ফলে L4-এর “একটি সংযোগ = একটি সিদ্ধান্ত” হয়ে যায় “একটি client-এর সব অনুরোধ = একটি backend”.

Autoscaling-এ আরও খারাপ: backend ৬ থেকে ১২ হলেও পুরোনো সংযোগ পুরোনো backend-এই বাঁধা, নতুন ৬টি প্রায় কিছুই পায় না। Kubernetes-এর সাধারণ Service (kube-proxy) সংযোগ-স্তরে ভাগ করে বলে gRPC-তে এই সমস্যা সেখানে বহুল আলোচিত। প্রতিকার:

• HTTP/2-বোঝা L7 proxy (Envoy, Nginx-এর gRPC proxy, cloud-এর application LB) প্রতিটি stream আলাদা ভাগ করে; দাম আরও একটি hop আর CPU.
• Client-side load balancing: gRPC লাইব্রেরি সব backend-এর সাথে সংযোগ রেখে RPC পালা করে পাঠায় (যেমন round_robin policy); দাম হালনাগাদ backend-তালিকা (পর্ব ৪৭)।
• সংযোগের সর্বোচ্চ বয়স: সার্ভার কয়েক মিনিট পরপর, এলোমেলো দেরিসহ, HTTP/2-এর GOAWAY পাঠায়; client আবার জোড়ে, নতুন backend-ও ভাগ পায়। gRPC-তে এটি max connection age ধাঁচের সেটিং; WebSocket-এও একই কৌশল (পর্ব ১০)।

৪ · Algorithm — round robin থেকে power of two choices

প্রতিটি নতুন অনুরোধে (L4-এ নতুন সংযোগে) প্রশ্ন একটাই: সুস্থ backend-গুলোর মধ্যে কে? প্রতিটি algorithm-এ দেখুন — কী তথ্য লাগে, তা কত টাটকা, আর ভুল হলে কী ঘটে।

Round robin — পালা করে

১, ২, ৩, … ১০, আবার ১. শুধু একটি counter লাগে। সব সার্ভার একই রকম আর অনুরোধ প্রায় সমান হলে চমৎকার। দুর্বলতা: কে ধীর, কোন অনুরোধ ভারী, কে এখন ব্যস্ত — কিছুই জানে না; দুই সেকেন্ডের রিপোর্ট-অনুরোধে আটকে থাকা সার্ভারও পালা এলে নতুন কাজ পায়।

Weighted round robin — বড় সার্ভারের বেশি পালা

যন্ত্র মেশানো থাকলে প্রতিটির একটি ওজন — দ্বিগুণ শক্তিশালী সার্ভার দ্বিগুণ পালা। সরল উপায়ে ৫:১:১ মানে a-কে পরপর ৫টি, তারপর b, c; ওজন ২০:২০:১ হলে একজন পরপর ২০টি। Nginx-এর upstream module একটি smooth weighted round robin পদ্ধতি ব্যবহার করে (প্রকাশিত commit অনুযায়ী ২০১২ সালের দিকে যুক্ত), যা একই অনুপাত রেখে পালা ছড়িয়ে দেয়:

1. প্রতিটি সার্ভারের একটি “চলতি ওজন” (current) আছে, শুরুতে ০।
2. প্রতিটি বাছাইয়ে সবার current-এ নিজের ওজন যোগ হয়।
3. যার current সবচেয়ে বেশি, সে জেতে (সমান হলে তালিকায় আগেরজন)।
4. বিজয়ীর current থেকে সবার ওজনের যোগফল বাদ যায়।

প্রতি বাছাইয়ে মোট যোগ আর বিয়োগ সমান, তাই current-গুলোর যোগফল সবসময় ০; মোট ওজনের সমান বাছাইয়ে প্রত্যেকে ঠিক নিজের ওজনের সমান বার জেতে। নিচের কোড ৫:১:১-এর প্রথম ১৪টি বাছাই ছাপে আর পরিচিত ক্রমের সাথে মেলায়:

// Smooth weighted round robin (the method Nginx's upstream module uses for weights)
// versus naive WRR that sends `weight` requests in a row to each server.
function smooth(weights, picks, show) {
  const cur = weights.map(() => 0), total = weights.reduce((a, b) => a + b), out = [];
  for (let k = 0; k < picks; k++) {
    let best = 0;
    for (let i = 0; i < weights.length; i++) {
      cur[i] += weights[i];                        // every server gains its weight
      if (cur[i] > cur[best]) best = i;            // highest current weight wins (first one on ties)
    }
    const before = cur.join(",");
    cur[best] -= total;                            // the winner pays back the total
    out.push("abc"[best]);
    if (show && k < 7) console.log("pick " + (k + 1) + ": [" + before + "] -> " + out[k] + " -> [" + cur.join(",") + "]");
  }
  return out;
}
function naive(weights, picks) {
  const cycle = weights.flatMap((w, i) => Array(w).fill("abc"[i]));
  return Array.from({ length: picks }, (_, k) => cycle[k % cycle.length]);
}
function longestRun(s) {                           // most picks of the same server in a row
  let best = 1, run = 1;
  for (let i = 1; i < s.length; i++) { run = s[i] === s[i - 1] ? run + 1 : 1; best = Math.max(best, run); }
  return best;
}
const s = smooth([5, 1, 1], 14, true), nv = naive([5, 1, 1], 14);
console.log("smooth 5:1:1  " + s.join(" ") + "   longest run " + longestRun(s));
console.log("naive  5:1:1  " + nv.join(" ") + "   longest run " + longestRun(nv));
console.log("first 7 equal a a b a c a a? " + (s.slice(0, 7).join(" ") === "a a b a c a a"));
const s2 = smooth([20, 20, 1], 41, false), n2 = naive([20, 20, 1], 41);
console.log("weights 20:20:1 over 41 picks: longest run smooth " + longestRun(s2) + ", naive " + longestRun(n2) +
  "; smooth counts a/b/c = " + ["a", "b", "c"].map(x => s2.filter(y => y === x).length).join("/"));

pick 1: [5,1,1] -> a -> [-2,1,1]
pick 2: [3,2,2] -> a -> [-4,2,2]
pick 3: [1,3,3] -> b -> [1,-4,3]
pick 4: [6,-3,4] -> a -> [-1,-3,4]
pick 5: [4,-2,5] -> c -> [4,-2,-2]
pick 6: [9,-1,-1] -> a -> [2,-1,-1]
pick 7: [7,0,0] -> a -> [0,0,0]
smooth 5:1:1  a a b a c a a a a b a c a a   longest run 4
naive  5:1:1  a a a a a b c a a a a a b c   longest run 5
first 7 equal a a b a c a a? true
weights 20:20:1 over 41 picks: longest run smooth 1, naive 20; smooth counts a/b/c = 20/20/1

Random — এলোমেলো

প্রতিটি অনুরোধে একটি এলোমেলো সুস্থ সার্ভার। কোনো ভাগ করা অবস্থা লাগে না, তাই একশোটি LB-instance সমন্বয় ছাড়াই চলে। দীর্ঘ মেয়াদে ভাগ সমান, কিন্তু স্বল্প মেয়াদে এলোমেলো ঢেউ থাকে।

Least connections আর least outstanding requests

যার হাতে এই মুহূর্তে সবচেয়ে কম চলমান কাজ, নতুন কাজ তাকে। সবচেয়ে সুন্দর ধর্ম: সে নিজে থেকেই গতির সাথে মানিয়ে নেয়। পর্ব ৪-এর Little-এর সূত্র L = λ × W — একই হারে কাজ পেলে ধীর সার্ভারের W বড়, তাই চলমান কাজ L-ও বেশি, আর সে স্বাভাবিকভাবেই কম নতুন কাজ পায়। L7-এ keep-alive আর HTTP/2-এর কারণে সংযোগ গোনা অর্থহীন, তাই গোনা হয় চলমান অনুরোধ (Envoy-তে “least request”). দুর্বলতা দুটি: অনেক LB পুরোনো তথ্য দেখলে সবাই একই “সবচেয়ে ফাঁকা” সার্ভারে ঝাঁপায়, আর দ্রুত ত্রুটি ফেরানো সার্ভার সবচেয়ে “ফাঁকা” দেখায় (ভাবনার প্রশ্ন ০২)।

Least response time আর EWMA

সাম্প্রতিক latency-ও দেখা — যেমন latency-র EWMA (নতুন মাপকে বেশি গুরুত্ব দেওয়া চলমান গড়) কম যার, তাকে। ধীর হতে থাকা সার্ভার দ্রুত কম ভার পায়। ঝুঁকি: পুরোনো মাপে দোল খাওয়া, আর দ্রুত ত্রুটিকে “দ্রুত” ভাবা — তাই সাধারণত ত্রুটির হার আর power of two choices-এর সাথে মিলিয়ে ব্যবহার হয়।

Power of two random choices — দুটি দেখে ভালোটি

এলোমেলোভাবে মাত্র দুটি সার্ভার দেখে কম ব্যস্তটিকে দেওয়া। প্রায় random-এর মতো সরল, ফল প্রায় least connections-এর কাছাকাছি, আর পুরোনো তথ্যে তার চেয়েও টেকসই; খরচ প্রতি অনুরোধে O(1). Envoy-এর least request সমান ওজনে এভাবেই চলে (ডিফল্টে দুটি বাছাই); Nginx-এ random two least_conn, HAProxy-তে balance random(2) ধাঁচের বিকল্প আছে (সংস্করণভেদে আলাদা)।

Hash — একই key, একই সার্ভার

IP hash, user ID বা cache key-র hash থেকে সার্ভার বাছা — লক্ষ্য একই জিনিস একই জায়গায়, যাতে cache কাজে লাগে। দাম: জনপ্রিয় key বা NAT-CGNAT-এর পেছনের অনেক ব্যবহারকারী (পর্ব ৭) একটি সার্ভার গরম করে; আর hash mod N-এ N বদলালে প্রায় সব key ঘর বদলায়। প্রতিকার consistent hashing (পর্ব ১৬); session-এর sticky session পর্ব ১৫-এ।

৫ · সংখ্যায় তুলনা — বিষম গতির সার্ভার, পুরোনো তথ্য আর দুটি বাছাইয়ের গণিত

ধরা যাক ১০টি সার্ভার, গতি আলাদা: দুটি ১.৫, দুটি ১.২৫, চারটি ১, দুটি পুরোনো ০.৭৫ — মোট ক্ষমতা ১১ একক কাজ প্রতি ms. প্রতিটি সার্ভার একবারে একটি অনুরোধে কাজ করে, বাকিরা সারিতে অপেক্ষা করে। অনুরোধ আসে এলোমেলোভাবে (Poisson), ক্ষমতার ৬৫% চাপে; ৯০% ছোট (গড় ৬ একক), ১০% বড় (গড় ৪৬)। সব algorithm একই অনুরোধ-ধারা পায়; শেষ দুটি সারিতে LB সারির দৈর্ঘ্য দেখে ৫০ ms পুরোনো অবস্থায় — অনেক LB-instance থাকলে যা স্বাভাবিক।

// 10 servers with different speeds, one FIFO worker each; the SAME request trace for every algorithm.
function mulberry32(a) { return () => { a = (a + 0x6D2B79F5) | 0; let t = Math.imul(a ^ (a >>> 15), 1 | a);
  t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296; }; }
const speed = [1.5, 1.5, 1.25, 1.25, 1, 1, 1, 1, 0.75, 0.75];      // work units per ms
const n = speed.length, cap = speed.reduce((a, b) => a + b), rho = 0.65, N = 50000;
const rnd = mulberry32(14), exp = m => -m * Math.log(1 - rnd());
const lambda = rho * cap / 10;                       // requests per ms; mean job = 10 units
const trace = []; let t = 0;
for (let i = 0; i < N; i++) {                        // Poisson arrivals; 90% small jobs, 10% big
  t += exp(1 / lambda); trace.push([t, rnd() < 0.9 ? exp(6) : exp(46)]);
}
function run(name, pick, staleMs = 0) {              // staleMs: the LB sees queue lengths this old
  const r = mulberry32(7), fin = speed.map(() => []), ptr = speed.map(() => 0), lat = [];
  let maxQ = 0, view = null, next = 0;
  trace.forEach(([at, size], i) => {
    const q = fin.map((f, s) => { while (ptr[s] < f.length && f[ptr[s]] <= at) ptr[s]++; return f.length - ptr[s]; });
    if (at >= next) { view = q.slice(); next = at + staleMs; }
    const s = pick(i, view, r), last = fin[s].length ? fin[s][fin[s].length - 1] : 0;
    const done = Math.max(at, last) + size / speed[s];   // wait behind the queue, then get served
    fin[s].push(done); lat.push(done - at); maxQ = Math.max(maxQ, q[s] + 1);
  });
  lat.sort((a, b) => a - b);
  const mean = lat.reduce((a, b) => a + b) / N, p99 = lat[Math.ceil(0.99 * N) - 1];  // nearest rank
  console.log(name.padEnd(27) + mean.toFixed(1).padStart(7) + p99.toFixed(1).padStart(9) + String(maxQ).padStart(6));
}
const LC = (i, q) => { let b = i % n; for (let k = 1; k < n; k++) { const s = (i + k) % n; if (q[s] < q[b]) b = s; } return b; };
const P2 = (i, q, r) => { const a = Math.floor(r() * n); let b = Math.floor(r() * (n - 1)); if (b >= a) b++; return q[b] < q[a] ? b : a; };
console.log("capacity " + cap + " units/ms, offered load " + rho * 100 + "%, " + N + " requests");
console.log("algorithm                  mean ms   p99 ms  maxQ");
run("Round robin", i => i % n);
run("Random", (i, q, r) => Math.floor(r() * n));
run("Least connections", LC);
run("Power of two choices", P2);
run("Least conn, 50 ms stale", LC, 50);
run("Power of two, 50 ms stale", P2, 50);

capacity 11 units/ms, offered load 65%, 50000 requests
algorithm                  mean ms   p99 ms  maxQ
Round robin                  206.1   1944.5   166
Random                       135.2   1377.4   165
Least connections             11.9    124.1     6
Power of two choices          22.0    187.4    10
Least conn, 50 ms stale       53.6    364.3    45
Power of two, 50 ms stale     31.7    232.1    17

দুটি বাছাই ধাপে ধাপে

ছয়টি সার্ভার, প্রতিটির পাশে এই মুহূর্তে চলমান অনুরোধের সংখ্যা। তিনটি নতুন অনুরোধ আসছে। লাল চিহ্ন দেওয়া দুটি এলোমেলোভাবে বাছা — “পরে” চাপুন:

কেন দুটি বাছাই এত শক্তিশালী — একটি সরল যুক্তি

প্রশ্নটির গাণিতিক রূপ “balls into bins” (বল আর বাক্স): n টি বল (অনুরোধ) n টি বাক্সে (সার্ভার), কেউ বেরোয় না। সবচেয়ে ভরা বাক্সে কতগুলো?

• একটি বাছাই (random): একটি বাক্সে অন্তত k টি বল পড়ার সম্ভাবনা ≤ C(n, k) × (১/n)^k ≤ ১/k!, তাই যেকোনো বাক্সে ≤ n/k!, যা ১-এর নিচে নামে যখন k! > n. এখান থেকেই পরিচিত ফল: সর্বোচ্চ প্রায় ln n / ln ln n (উচ্চ সম্ভাবনায়)।
• দুটি বাছাই: β_i = অন্তত i টি বল আছে এমন বাক্সের ভাগ। একটি বল (i + ১) উচ্চতায় বসে শুধু যখন দুটি বাছাই-ই অন্তত i উচ্চতায় পড়ে — সম্ভাবনা প্রায় β_i^২, তাই মোটামুটি β_i+1 ≲ β_i^২। বল মোট n টি, তাই β_২ ≤ ১/২। প্রতি ধাপে বর্গ: β_i ≤ (১/২)^{২^(i−২)} — দ্বিগুণ-সূচকীয় পতন, ১/n-এর নিচে যখন i ≈ log₂ log₂ n + ২।

এই যুক্তির নিখুঁত প্রমাণ দেন Azar, Broder, Karlin ও Upfal (“Balanced Allocations”, ১৯৯৪): d টি বাছাইয়ে সর্বোচ্চ প্রায় ln ln n / ln d + O(১)। ১ থেকে ২-এ উন্নতি সূচকীয়, ২ থেকে ৩-এ শুধু একটি ধ্রুবক গুণ। Michael Mitzenmacher তাঁর PhD গবেষণায় (UC Berkeley, ১৯৯৬) একে চলমান সারির মডেলে নেন (“supermarket model”): বড় n-এ অন্তত i টি কাজ আছে এমন সারির ভাগ random-এ প্রায় λⁱ, দুটি বাছাইয়ে প্রায় λ^{(২^i − ১)} (λ = utilization; প্রায় একই সময়ে Vvedenskaya, Dobrushin ও Karpelevich-ও স্বাধীনভাবে এমন ফল পান)। λ = ০.৯, i = ৫: random-এ প্রায় ০.৫৯, দুটি বাছাইয়ে প্রায় ০.০৩৮ — সীমায় পাওয়া মান, ছোট fleet-এ সংখ্যা আলাদা।

তত্ত্বটি নিজে মিলিয়ে দেখুন — একসাথে n টি অনুরোধ n টি সার্ভারে, d = ১, ২, ৩:

// Balls into bins: n requests go to n servers, all at once (no request finishes).
// Each request looks at d random servers and joins the least loaded (d = 1: plain random).
function mulberry32(a) { return () => { a = (a + 0x6D2B79F5) | 0; let t = Math.imul(a ^ (a >>> 15), 1 | a);
  t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296; }; }
console.log("n          max load d=1  d=2  d=3 | ln n/ln ln n  log2(ln n)");
for (const n of [1000, 100000, 1000000]) {
  const maxLoad = [];
  for (const d of [1, 2, 3]) {
    const r = mulberry32(2026 + d), bins = new Uint32Array(n);
    for (let i = 0; i < n; i++) {
      let best = Math.floor(r() * n);
      for (let k = 1; k < d; k++) { const c = Math.floor(r() * n); if (bins[c] < bins[best]) best = c; }
      bins[best]++;
    }
    let mx = 0;
    for (let i = 0; i < n; i++) if (bins[i] > mx) mx = bins[i];
    maxLoad.push(mx);
  }
  const L = Math.log(n), LL = Math.log(L);
  console.log(String(n).padEnd(11) + String(maxLoad[0]).padStart(13) + String(maxLoad[1]).padStart(5) +
    String(maxLoad[2]).padStart(5) + " |" + (L / LL).toFixed(2).padStart(13) + (LL / Math.LN2).toFixed(2).padStart(12));
}

n          max load d=1  d=2  d=3 | ln n/ln ln n  log2(ln n)
1000                   5    3    3 |         3.57        2.79
100000                 7    3    3 |         4.71        3.53
1000000                9    4    3 |         5.26        3.79

৬ · Health check — কখন বাদ, কখন ফেরত, আর কত অনুরোধের দামে

Algorithm বাছে শুধু “সুস্থ” সার্ভারের মধ্যে। কে সুস্থ, তা LB জানে দুই উপায়ে:

আলাদা fall আর rise একরকম hysteresis: একবারের হোঁচটে বাদ নয়, একবারের সাফল্যে ফেরতও নয় — নইলে সীমানার সার্ভার বারবার আসা-যাওয়া করত (flapping). দাম সময়: সার্ভার ঝুলে গেলে প্রতিটি probe timeout পর্যন্ত অপেক্ষা করে, আর বিকলতা দুটি probe-এর মাঝে যেকোনো মুহূর্তে শুরু হতে পারে:

শেষ সূত্রটি ধরে নেয় ভার সমান ভাগ আর কোনো retry নেই। এখন সংখ্যা বসিয়ে দেখুন — তিনটি active setting, তারপর passive check, আর শেষে check-এর নিজের খরচ:

// Health-check timing. Model: a check starts every `inter` seconds; against a HUNG server
// each check waits `timeout` before it counts as failed; `fall` failures in a row = DOWN,
// `rise` successes in a row = UP again. Failure time is uniform between two checks.
function detect(c) {
  const worst = c.fall * c.inter + c.timeout;            // failed just after a check had started
  const avg = c.inter / 2 + (c.fall - 1) * c.inter + c.timeout;
  return { worst, avg, back: c.rise * c.inter };         // back UP at most rise x inter after the fix
}
const QPS = 5000, servers = 10, each = QPS / servers;  // even spread across servers
console.log("total " + QPS + " QPS on " + servers + " servers = " + each + " QPS each");
console.log("active check setting              detect avg  worst | failed avg  worst | UP after");
const settings = [
  ["inter 2s, timeout 1s, fall 3, rise 2", { inter: 2, timeout: 1, fall: 3, rise: 2 }],
  ["inter 5s, timeout 2s, fall 3, rise 2", { inter: 5, timeout: 2, fall: 3, rise: 2 }],
  ["inter 1s, timeout 0.5s, fall 2, rise 3", { inter: 1, timeout: 0.5, fall: 2, rise: 3 }],
];
for (const [name, c] of settings) {
  const d = detect(c);
  console.log(name.padEnd(39) + (d.avg + " s").padStart(7) + (d.worst + " s").padStart(8) + " |" +
    String(d.avg * each).padStart(8) + String(d.worst * each).padStart(7) + " |" + (d.back + " s").padStart(6));
}
const reqTimeout = 1;                                   // the LB's own per-request timeout (s)
for (const k of [5, 20]) {                              // passive: k bad answers in a row in real traffic
  const fast = k / each, hung = reqTimeout + k / each;
  console.log("passive, " + String(k).padStart(2) + " errors in a row: fast errors " + (fast * 1000) + " ms (~" + k +
    " failed); hung server " + hung + " s (~" + Math.round(hung * each) + " failed)");
}
const lbNodes = 20, fleet = 500;                       // cost side: every LB node checks every server
console.log("check load: " + lbNodes + " LB nodes x " + fleet + " servers / 2 s = " + lbNodes * fleet / 2 + " checks/s");

total 5000 QPS on 10 servers = 500 QPS each
active check setting              detect avg  worst | failed avg  worst | UP after
inter 2s, timeout 1s, fall 3, rise 2       6 s     7 s |    3000   3500 |   4 s
inter 5s, timeout 2s, fall 3, rise 2    14.5 s    17 s |    7250   8500 |  10 s
inter 1s, timeout 0.5s, fall 2, rise 3     2 s   2.5 s |    1000   1250 |   3 s
passive,  5 errors in a row: fast errors 10 ms (~5 failed); hung server 1.01 s (~505 failed)
passive, 20 errors in a row: fast errors 40 ms (~20 failed); hung server 1.04 s (~520 failed)
check load: 20 LB nodes x 500 servers / 2 s = 5000 checks/s

ফেরার সময়ের ফাঁদ — slow start

সদ্য চালু সার্ভারের cache আর connection pool খালি, JIT চলছে — warm-up. অথচ least connections-এর চোখে সে-ই সবচেয়ে আকর্ষণীয় (০টি কাজ!), তাই প্রথম মুহূর্তেই প্রায় সব নতুন অনুরোধ তার ঘাড়ে — একটি ছোট thundering herd. Slow start-এ ফেরা সার্ভারের ওজন কয়েক সেকেন্ড ধরে শূন্যের কাছ থেকে পূর্ণ মানে তোলা হয়। HAProxy-র slowstart শুধু আগে বিকল দেখা সার্ভারে প্রযোজ্য, LB নিজে চালু হওয়ার সময় নয়; Envoy-তেও এমন বিকল্প আছে (সংস্করণভেদে আলাদা)।

ধরা যাক: মোট ২,০০০ RPS, চারটি সার্ভারে ৫০০ করে; check প্রতি ২ সেকেন্ডে, timeout ১ সেকেন্ড, fall ৩, rise ২; slow start ৩০ সেকেন্ড, ওজন সরলরেখায় বাড়ে।

ভালো health check কী যাচাই করে

• অগভীর বনাম গভীর: “process বেঁচে আছে” প্রায় কিছুই বলে না; সব dependency যাচাই করা deep health check বিপজ্জনক — database একটু ধীর হলেই সব সার্ভার একসাথে ফেল, LB সবাইকে বাদ দেয় (correlated failure). ভালো মাঝামাঝি: সার্ভার নিজের কাজে প্রস্তুত কি না — thread pool ফাঁকা, config লোড হয়েছে।
• Liveness আর readiness আলাদা: Kubernetes-এ liveness probe ব্যর্থ হলে container restart, readiness probe ব্যর্থ হলে শুধু traffic থেকে সরানো; dependency-র সমস্যায় restart-এ লাভ নেই, তাই liveness অগভীর।
• সবাই অসুস্থ হলে? অনেক LB fail open করে — health না মেনে সবার মধ্যে ভাগ, কারণ “সবাই বিকল” সাধারণত check-এরই ভুল। Envoy-তে সুস্থের হার একটি সীমার (লেখার সময়ে ডিফল্ট ৫০%) নিচে নামলে এই “panic” মোড চালু হয়।
• Check-এর পথ আর আসল পথ এক: একই port, TLS আর proxy-স্তর — নইলে check সফল, ব্যবহারকারী ব্যর্থ। Failure detection-এর তত্ত্ব পর্ব ৪৪ (Membership আর failure detection)-এ।

৭ · Deploy আর connection draining — কেউ টের না পেয়ে সার্ভার বদলানো

সরাসরি process বন্ধ করলে হাতের প্রতিটি অনুরোধ মাঝপথে ভাঙে। Connection draining (কিছু পণ্যে “deregistration delay”) এর প্রতিকার — বন্ধ হতে যাওয়া কাউন্টারে “আর নতুন লাইন নয়” বোর্ড, কিন্তু লাইনের যাত্রীদের টিকিট দেওয়া শেষ:

1. Drain চিহ্ন: LB-কে বলা হয় সার্ভারটিকে আর নতুন অনুরোধ না দিতে (HAProxy-র runtime API-তে set server be_cart/cart2 state drain ধাঁচের কমান্ড; Kubernetes-এ pod terminating হলে readiness হারিয়ে endpoint তালিকা থেকে সরে)।
2. অপেক্ষা: চলমান অনুরোধ শেষ হওয়া পর্যন্ত, তবে একটি সর্বোচ্চ সময়সীমা পর্যন্ত (ধরা যাক ৩০ সেকেন্ড) — দীর্ঘ upload বা স্থায়ী সংযোগের জন্য যা যথেষ্ট নাও হতে পারে।
3. ভদ্রভাবে বন্ধ: সার্ভার নতুন সংযোগ নেওয়া থামায়, keep-alive সংযোগে “Connection: close” বা HTTP/2-এর GOAWAY পাঠায়, হাতের কাজ শেষ করে বেরোয়।
4. নতুন সংস্করণ, check, slow start: চালু হয়ে health check-এ পরপর rise বার সফল, তারপর ধীরে পূর্ণ ভারে; তারপর পরের সার্ভার।

Rolling deploy-এর অঙ্ক — কতগুলো একসাথে সরানো যায়

N টি সার্ভার u ভাগ ব্যস্ত থাকলে k টি সরালে বাকিদের ব্যস্ততা u × N ÷ (N − k). ধরা যাক ১০টি, ৭০% ব্যস্ত: একটি সরালে ≈ ৭৭.৮%, দুটি সরালে ৮৭.৫% — queueing-এর বিপজ্জনক এলাকার কাছে। তাই deploy কম ভিড়ে, অল্প কয়েকটি করে, বা আগে নতুন কপি যোগ করে (Kubernetes-এর maxSurge আর maxUnavailable, ডিফল্ট ২৫% করে)। Blue-green আর canary পর্ব ৫৩ (Deployment আর release)-এ; canary routing পর্ব ১১-এ।

সব একসাথে — একটি HAProxy-ধাঁচের config

নিচের config পড়ার জন্য — একটি উদাহরণ। HAProxy-র directive আর ডিফল্ট সংস্করণভেদে আলাদা (যেমন http-check send নতুন সংস্করণের লেখার ধরন), তাই বাস্তবে নিজের সংস্করণের অফিসিয়াল ডকুমেন্টেশনে মিলিয়ে নিন।

# Illustrative only: a simplified L7 setup for the "cart" service.
# Directive names and defaults differ between HAProxy versions - check the docs.
defaults
    mode http
    timeout connect 2s
    timeout client  30s
    timeout server  5s
    timeout check   1s                 # extra read timeout for health checks
    retries 2
    option redispatch                  # a retry may go to a different server

frontend fe_https
    bind :443 ssl crt /etc/haproxy/certs/shop.pem alpn h2,http/1.1
    default_backend be_cart

backend be_cart
    balance leastconn                  # or: roundrobin, random(2), source
    option httpchk
    http-check send meth GET uri /healthz ver HTTP/1.1 hdr Host shop.example
    http-check expect status 200
    default-server check inter 2s fall 3 rise 2 slowstart 30s
    server cart1 10.0.3.11:8080 weight 100
    server cart2 10.0.3.12:8080 weight 100
    server cart3 10.0.3.13:8080 weight 50     # older, smaller machine
    server cart4 10.0.3.14:8080 weight 100

৮ · Load balancer নিজে পড়ে গেলে — VRRP, anycast, DSR আর global load balancing

সব traffic যে দরজা দিয়ে যায়, সেটি নিজেই single point of failure — একটি LB-যন্ত্রের পেছনে একশোটি সার্ভার রাখলেও availability ওই একটি যন্ত্রের সমান। দুটি প্রচলিত নকশা:

Active-passive জোড়া — VRRP আর virtual IP

দুটি LB, একটি সক্রিয়, অন্যটি প্রস্তুত (active-passive); VIP থাকে সক্রিয়টির কাছে। VRRP (RFC 2338, ১৯৯৮; এখনকার v3 — RFC 5798, ২০১০)-এ সক্রিয় যন্ত্র নিয়মিত ঘোষণা পাঠায়, ডিফল্টে প্রতি সেকেন্ডে। পরপর প্রায় তিনটি না এলে standby master হয়ে VIP নেয়, আর gratuitous ARP পাঠিয়ে switch-কে জানায় — কয়েক সেকেন্ডে failover; Linux-এ keepalived পরিচিত বাস্তবায়ন। দুর্বলতা: standby বসে থাকে, সক্রিয়টির ক্ষমতাই সীমা; connection table-এর তথ্য কপি না হলে চলমান সংযোগ ভাঙে; আর মাঝের link কাটলে দুজনেই VIP দাবি করতে পারে — split-brain (পর্ব ৪৩)।

Active-active — anycast আর ECMP

অনেকগুলো L4 নোড একসাথে একই VIP BGP দিয়ে router-কে ঘোষণা করে (active-active); router ECMP-এ প্রতিটি flow-এর 5-tuple hash করে কোনো একটি নোডে পাঠায়। নোড পড়লে তার ঘোষণা উঠে যায়, flow-গুলো বাকিদের মধ্যে ভাগ হয় — standby নেই, ক্ষমতা বাড়াতে শুধু নোড যোগ। সমস্যা: নতুন নোড আগের সংযোগ চেনে না। প্রতিকার — সব নোড একই consistent hashing টেবিল থেকে backend বাছে, তাই প্রায় সব সংযোগ একই backend পায়; Google-এর Maglev (NSDI ২০১৬) এর প্রকাশিত উদাহরণ (Data center নেটওয়ার্ক; পর্ব ১৬)।

Direct server return — উত্তর LB দিয়ে না ফেরানো

অনুরোধ ছোট, উত্তর বড়। DSR-এ L4 LB শুধু অনুরোধ পৌঁছায়; backend loopback-এ VIP রেখে উত্তর সরাসরি client-কে পাঠায়, তাই LB বয় traffic-এর ছোট অংশ। দাম: LB উত্তর দেখে না — L7-কাজ বা TLS termination অসম্ভব, সেটআপ জটিল।

Global load balancing — region-এর মধ্যে ভাগ

একাধিক region থাকলে প্রথম ভাগ DNS বা anycast-এ — GeoDNS কাছের region দেয়, health-aware DNS বিকল region সরায়; TTL কেন failover ধীর করে, পর্ব ৭-এ দেখেছেন। নিয়ম: global স্তর মোটা দাগে (region), ভেতরের L4–L7 সূক্ষ্ম দাগে (সার্ভার)। পুরো region হারানো পর্ব ৫১ (Failover আর disaster recovery)-এর বিষয়; স্থির content edge-এই থামে (পর্ব ১৭)।

৯ · AI-এর যুগে load balancing-নকশা যাচাই

“Scalable” নকশা চাইলে AI প্রায়ই লেখে “একটি load balancer বসান, round robin দিন”, সাথে Kafka, Redis আর microservices. LB-র প্রশ্নে তার সাধারণ ভুল:

AI-এর দেওয়া load balancing-নকশা হাতে পেলে — যাচাইয়ের চেকলিস্ট

• LB নিজে redundant, আর তার failover-এর সময় জানি
• Algorithm বাছা হয়েছে গতি, অনুরোধের আকার আর LB-instance-এর সংখ্যা ধরে; simulator বা ছোট load test-এ মিলিয়েছি
• ধরা পড়ার সময় আর ব্যর্থ অনুরোধ নিজে হিসাব করেছি; check খুব গভীর নয়, আর সবাই বিকল হলে LB কী করে জানি
• HTTP/2, gRPC বা WebSocket-এ অনুরোধ-স্তরে ভাগ বা সংযোগের সর্বোচ্চ বয়স আছে
• Deploy-এ draining, slow start আর u × N ÷ (N − k)-এর হিসাব করেছি; ডিফল্ট ডকুমেন্টেশনে মিলিয়েছি