Cloud load balancer — L4, L7, target group আর TLS termination

১ · Managed load balancer কেন — নিজের Nginx থেকে পরের ধাপ

পর্ব ১৭-তে autoscaling একই app-এর অনেক কপি চালাল। কিন্তু ব্যবহারকারী তো একটি ঠিকানাই চেনেন। সেই ঠিকানা থেকে অনুরোধ সুস্থ কপিগুলোর মধ্যে ভাগ করার কাজই load balancing. কাল্পনিক একটি অনলাইন বাজার অ্যাপ ধরুন, নাম bazaar. এর সামনে একটি load balancer (সংক্ষেপে LB) বসাব।

Algorithm আর তত্ত্ব এখানে আবার লিখছি না। সংক্ষেপে: L4 LB দেখে IP আর port, দ্রুত সংযোগ ভাগ করে, HTTP-এর ভেতরটা পড়ে না। L7 LB HTTP পড়ে, তাই host, path আর header দেখে সিদ্ধান্ত নেয়। Round robin, least connections আর অন্য algorithm-এর পূর্ণ আলোচনা আছে System Design · Load balancing পর্বে। এখানে প্রশ্ন একটাই: cloud-এ এটি কীভাবে চালাবেন, ঠিক করবেন আর তার দাম দেবেন।

পর্ব ১৪-তে আপনি একটি VM-এ Nginx দিয়ে নিজের reverse proxy চালিয়েছেন। সেটি ভালো শুরু, কিন্তু ওই VM নিজেই একটি একক ব্যর্থতার বিন্দু। Managed LB-তে সমস্যাটি বদলে যায়।

২ · চারটি অংশ — listener, rule, target group, health check

প্রতিটি provider-এর নাম আলাদা হলেও গঠন প্রায় একই। আগে নিরপেক্ষ শব্দগুলো চিনে নিন।

• Listener: একটি protocol আর port-এ শোনে, যেমন HTTPS 443. LB-র দরজা।
• Rule: এই host বা path এলে অনুরোধ কোন দলে যাবে, তার নিয়ম। কোনো rule না মিললে চলে default action.
• Target group: অনুরোধ গ্রহণকারীদের একটি দল। সদস্য হতে পারে VM, container-এর IP, এমনকি function. Autoscaling group নতুন VM-কে এখানেই যোগ করে।
• Health check: LB নিয়মিত প্রতিটি target-কে যাচাই করে। সুস্থরাই অনুরোধ পায়।

Subnet আর VPC-র বিস্তারিত পর্ব ২৫-এ, আর target-এ শুধু LB-কে ঢুকতে দেওয়ার firewall নিয়ম পর্ব ২৭-এ আসবে। এবার একটি অনুরোধ ধরে পুরো পথটি দেখুন।

shop.example.com  -> lb-demo.example.net
lb-demo.example.net A 198.51.100.20
                    A 198.51.100.21   (অন্য zone)

client 203.0.113.10:51000 -> 198.51.100.20:443
TLS handshake, SNI = shop.example.com
certificate পাঠানো হলো, অনুরোধ খোলা হলো

GET /api/orders   Host: shop.example.com
rule 10  /api/admin/*  মিলল না
rule 20  /api/*        মিলল -> tg-api

api-1  10.0.1.21:8080  unhealthy, বাদ
api-2  10.0.2.21:8080  healthy, এবার এর পালা

from 10.0.1.5   (LB-র ঠিকানা)
X-Forwarded-For: 203.0.113.10
HTTP/1.1 200 OK  -> LB -> client

তিন provider-এর নাম

৩ · Host আর path routing — rule কীভাবে মেলে

একটি LB-র পেছনে অনেক service রাখার চাবি হলো rule. Host routing দেখে domain: img.example.com এক দলে, shop.example.com আরেক দলে। Path routing দেখে URL-এর পথ: /api/* এক দলে, বাকিটা অন্য দলে। দুটি একসাথেও মেলানো যায়।

AWS ALB-র rule-এর একটি উদাহরণ। ছোট priority নম্বর আগে মেলে। ARN-গুলো shell variable-এ রাখা আছে, আর আপনার account ছাড়া এটি চলবে না।

aws elbv2 create-rule \
  --listener-arn "$LISTENER_ARN" \
  --priority 20 \
  --conditions Field=path-pattern,Values='/api/*' \
  --actions Type=forward,TargetGroupArn="$API_TG_ARN"

নিচের ছোট engine একই যুক্তি চালায়: rule-গুলো priority অনুযায়ী সাজানো হয়, প্রথম যেটি মেলে সেটিই শেষ কথা, আর কিছু না মিললে default. চালিয়ে শেষ তিনটি লাইন খেয়াল করুন।

// Listener rules: lowest priority number first, first match wins, else default.
const rules = [
  { pr: 10, host: "*",               path: "/api/admin/*", tg: "tg-admin" },
  { pr: 20, host: "*",               path: "/api/*",       tg: "tg-api" },
  { pr: 30, host: "img.example.com", path: "*",            tg: "tg-images" },
  { pr: 40, host: "*.example.com",   path: "/shop/*",      tg: "tg-shop" },
];
const DEFAULT_TG = "tg-web";

function glob(pattern, text) {     // * = any characters, ? = exactly one character
  const body = pattern.replace(/[.+^${}()|[\]\\]/g, "\\$&")
                      .replace(/\*/g, ".*").replace(/\?/g, ".");
  return new RegExp("^" + body + "$").test(text);
}
function route(host, path) {
  const h = host.toLowerCase();    // host names ignore case, paths do not
  for (const r of [...rules].sort((a, b) => a.pr - b.pr)) {
    if (glob(r.host, h) && glob(r.path, path)) return ["rule " + r.pr, r.tg];
  }
  return ["default", DEFAULT_TG];
}

const requests = [
  ["www.example.com", "/"],            ["www.example.com", "/api/orders"],
  ["SHOP.example.com", "/api/admin/users"], ["img.example.com", "/logo.png"],
  ["www.example.com", "/shop/cart"],   ["www.example.com", "/api"],
  ["www.example.com", "/API/orders"],  ["other.test", "/shop/cart"],
];
for (const [host, path] of requests) {
  const [why, tg] = route(host, path);
  console.log((host + path).padEnd(34) + why.padEnd(9) + "-> " + tg);
}

আরেকটি ফাঁদ হলো ক্রম। Rule 10 আর 20 অদলবদল করলে /api/admin/users আগেই /api/*-এ মিলে যাবে, আর tg-admin কখনো কোনো অনুরোধ পাবে না। তাই নির্দিষ্ট rule আগে, সাধারণ rule পরে। এটি শুধু routing-এর ভুল নয়; admin পথে আলাদা নিরাপত্তা থাকলে সেটিও পাশ কাটানো যেতে পারে।

৪ · Health check — target-এর অবস্থা কীভাবে বদলায়

LB ব্যবহারকারীর হয়ে নিয়মিত একটি পরীক্ষা অনুরোধ পাঠায়, যেমন GET /healthz. উত্তরের ওপর target-এর অবস্থা বদলায়। Health check-এর তত্ত্ব, slow start আর ভালো check-এর নকশা আছে System Design · Health check অংশে। এখানে আসল সেটিংগুলো দেখব।

এই মানগুলো উদাহরণ; provider-এর default আলাদা হতে পারে। মূল শব্দটি হলো “পরপর”। একবার ব্যর্থ হয়ে পরেরবার সফল হলে ব্যর্থতার গণনা শূন্যে ফেরে। নিচের state machine সেটিই দেখায়। P মানে check সফল, F মানে ব্যর্থ।

// Health-check state machine: one check every 10 s.
const INTERVAL = 10, HEALTHY_T = 3, UNHEALTHY_T = 2;

function run(title, results, start) {
  let state = start, okRun = 0, badRun = 0;
  console.log("--- " + title + " (start: " + start + ")");
  [...results].forEach((r, i) => {
    if (r === "P") { okRun++; badRun = 0; } else { badRun++; okRun = 0; }
    const before = state;
    if (state !== "healthy" && okRun >= HEALTHY_T) state = "healthy";
    if (state !== "unhealthy" && badRun >= UNHEALTHY_T) state = "unhealthy";
    const changed = state !== before ? "  <-- " + before + " -> " + state : "";
    const t = String((i + 1) * INTERVAL).padStart(3);
    console.log("t=" + t + "s " + r + "  ok=" + okRun + " bad=" + badRun + changed);
  });
  console.log("final: " + state + ", gets traffic: " + (state === "healthy"));
}

run("new target", "PPP", "initial");
run("crash, then recovery", "PFFFPPP", "healthy");
run("flapping", "FPFPFPFP", "healthy");

এবার সময়ের হিসাব। ধরুন interval I, timeout T, unhealthy threshold U. শেষ সফল check-এর ঠিক পরে app আটকে গেলে U-সংখ্যক check পাঠাতে হয়, আর শেষটির timeout পর্যন্ত অপেক্ষা করতে হয়। তাই সবচেয়ে খারাপ ক্ষেত্রে বাদ পড়তে লাগে U × I + T সময়। আমাদের মানে 2 × 10 + 5 = 25 সেকেন্ড। নিচের ঘটনায় ৪টি target মোট ৫০০ req/s সামলাচ্ছে, তাই প্রতিটি পাচ্ছে ১২৫ req/s, আর web-2 আটকে যাচ্ছে t = 3 সেকেন্ডে।

Interval কমালে নষ্ট কমে, কিন্তু একটি ধীর মুহূর্তেই সুস্থ target বাদ পড়তে পারে। এটি trade-off. আসল অবস্থা দেখতে তিন provider-এর কমান্ড নিচে আছে; নাম আর resource group নমুনা।

aws elbv2 describe-target-health --target-group-arn "$API_TG_ARN"

az network application-gateway show-backend-health \
  --resource-group rg-demo --name agw-demo

gcloud compute backend-services get-health api-backend --global

৫ · TLS আর client-এর আসল IP

TLS-এর handshake আর certificate chain আছে Computer Networks · TLS আর HTTPS পর্বে। Cloud LB-তে প্রশ্ন হলো, TLS কোথায় শেষ হবে। তিনটি নকশা আছে।

Certificate manager সেবা certificate নেওয়া, রাখা আর নবায়নের কাজ সহজ করে। উদাহরণ: AWS Certificate Manager, Azure Key Vault-এর সাথে Application Gateway, Google Cloud Certificate Manager. পর্ব ১৪-তে certbot দিয়ে যে কাজ নিজে করেছেন, এখানে সেটি অনেকটাই স্বয়ংক্রিয়। তবে DNS যাচাই ঠিক না থাকলে নবায়ন আটকে যেতে পারে, তাই মেয়াদের alert রাখুন। SNI-র কারণে একই listener-এ একাধিক domain-এর certificate চলে। সাধারণত port 80-র listener-এ একটিই rule থাকে: HTTPS-এ redirect.

Target কেন client-এর IP দেখে না

L7 LB নিজের ঠিকানা থেকে নতুন সংযোগ করে। তাই app-এর চোখে সব অনুরোধ আসে LB-র private IP থেকে। Rate limit, audit আর অবস্থান-ভিত্তিক কাজে এটি সমস্যা। সমাধান দুটি।

• X-Forwarded-For (L7): LB HTTP header-এ client-এর IP যোগ করে। মান হয় একটি তালিকা, যেমন X-Forwarded-For: 198.18.0.7, 203.0.113.10. Client নিজেও এই header পাঠাতে পারে, তাই বাঁ দিকের মান বিশ্বাসযোগ্য নয়। আপনার বিশ্বস্ত LB সবচেয়ে ডানে যা যোগ করেছে, সেটিই ভরসা। মানক Forwarded header (RFC 7239, ২০১৪) একই কাজ করে, তবে X-Forwarded-For বেশি প্রচলিত।
• Proxy protocol (L4): TCP সংযোগের একদম শুরুতে একটি ছোট শিরোনাম বসে, যেখানে আসল IP আর port থাকে। HTTP না হলেও চলে। দুই পক্ষকেই এটি বুঝতে হয়; target প্রস্তুত না থাকলে সেই বাড়তি bytes তার কাছে ভাঙা অনুরোধ।

৬ · Cross-zone balancing আর sticky session

LB-র একটি অংশ প্রতিটি zone-এ থাকে, আর DNS client-দের মোটামুটি সমান ভাগে তাদের কাছে পাঠায়। ধরুন দুই zone-এ target সমান নয়। AZ-a-তে ২টি, AZ-b-তে ৮টি। মোট ১০০০ req/s.

Zone পার হওয়ার ৫০% এলো এভাবে: AZ-a-র ৫০০ অনুরোধের ৮/১০ ভাগ অর্থাৎ ৪০০টি যায় AZ-b-তে, আর AZ-b-র ৫০০-এর ২/১০ ভাগ অর্থাৎ ১০০টি যায় AZ-a-তে। মোট ৫০০, মানে অর্ধেক। এবার সিমুলেশনে মিলিয়ে দেখি, যেখানে প্রতিটি অনুরোধ এলোমেলোভাবে একটি zone-এ পড়ে।

// Zone a has 2 targets, zone b has 8. 1000 req/s for 100 s.
let seed = 18;
function rand() {                  // mulberry32: small seeded PRNG
  seed = (seed + 0x6D2B79F5) | 0;
  let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
  t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
  return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
}
const SECONDS = 100, TOTAL = 1000 * SECONDS;
const makeTargets = () => [
  ...Array.from({ length: 2 }, (_, i) => ({ id: "a" + (i + 1), zone: "a", n: 0 })),
  ...Array.from({ length: 8 }, (_, i) => ({ id: "b" + (i + 1), zone: "b", n: 0 })),
];

function simulate(crossZone) {
  const targets = makeTargets(), turn = { a: 0, b: 0 };
  let crossing = 0;
  for (let i = 0; i < TOTAL; i++) {
    const node = rand() < 0.5 ? "a" : "b";   // DNS: each LB node gets about half
    const pool = crossZone ? targets : targets.filter(t => t.zone === node);
    const t = pool[turn[node]++ % pool.length]; // round robin inside the pool
    t.n++;
    if (t.zone !== node) crossing++;
  }
  const rps = targets.map(t => t.n / SECONDS);
  console.log("cross-zone " + (crossZone ? "ON " : "OFF"));
  console.log("  a1 " + rps[0].toFixed(1) + "  a2 " + rps[1].toFixed(1) +
              "  b1 " + rps[2].toFixed(1) + "  b8 " + rps[9].toFixed(1) + " req/s");
  console.log("  busiest/quietest = " + (Math.max(...rps) / Math.min(...rps)).toFixed(2));
  console.log("  crossing zones   = " + (100 * crossing / TOTAL).toFixed(1) + "%");
}
simulate(false);
simulate(true);

Default provider আর LB-র ধরন-ভেদে আলাদা। লেখার সময়ে ALB-তে এটি সাধারণত চালু, NLB-তে সাধারণত বন্ধ থাকে, আর চালু করলে zone-পার data-র খরচ লাগতে পারে। সবচেয়ে ভালো সমাধান হলো সব zone-এ target সমান রাখা। Autoscaling group-কে সব zone-এ সমানভাবে ছড়িয়ে রাখা সেই কাজেই সাহায্য করে।

Sticky session — কেন এড়ানো ভালো

Sticky session মানে একজন ব্যবহারকারীকে একই target-এ বারবার পাঠানো, সাধারণত LB-র দেওয়া cookie দিয়ে। Session যদি VM-এর memory-তে থাকে, তাহলে এটি দ্রুত সমাধান। কিন্তু দাম আছে।

• অসম ভার: কিছু ভারী ব্যবহারকারী একই target-এ আটকে থাকেন, আর নতুন target অনেকক্ষণ ফাঁকা থাকে।
• Target গেলে session হারায়: VM মরলে সেই ব্যবহারকারীর কার্ট বা login মুছে যায়।
• Scale-in আর deploy কঠিন: Target সরাতে গেলে সক্রিয় ব্যবহারকারীরা আটকে থাকেন।

ভালো পথ হলো app-কে stateless রাখা। Session যাক Redis-এর মতো বাইরের store-এ (পর্ব ২৩) বা database-এ। তখন যেকোনো target যেকোনো অনুরোধ নিতে পারে, আর autoscaling সহজ হয়। পুরোনো অ্যাপ এখনই বদলানো না গেলে sticky সাময়িক সমাধান হতে পারে, তবে সেটি ঋণ হিসেবেই লিখে রাখুন।

৭ · Draining, idle timeout, আর 502 ও 504 কোথা থেকে আসে

Connection draining — শাটার অর্ধেক নামানো

Connection draining-এ (AWS-এ deregistration delay) target নতুন অনুরোধ পাওয়া বন্ধ করে, আর চলমান অনুরোধ শেষ করার সময় পায়। সময়সীমা শেষ হলে বাকি সংযোগ কাটা হয়। নিচে একটি rolling deploy, সীমা ধরে নিয়েছি ৬০ সেকেন্ড। ক্রমটি খেয়াল করুন।

সময়সীমা হওয়া উচিত আপনার সবচেয়ে লম্বা স্বাভাবিক অনুরোধের চেয়ে একটু বেশি। খুব বড় রাখলে deploy ধীর হয়; ছোট API-র জন্য কয়েক মিনিট অপ্রয়োজনীয় হতে পারে। Autoscaling-এর scale-in-এও একই নিয়ম, আর rolling, blue-green আর canary কৌশল আসবে পর্ব ৫৯-এ।

Idle timeout আর লুকানো 502

LB আর target-এর মাঝে সংযোগ পুনর্ব্যবহার হয়, যাকে বলে keep-alive. কেউ সংযোগ ফাঁকা রাখলে একসময় বন্ধ করে দেয়। Idle timeout হলো সেই ফাঁকা থাকার সীমা। LB-র নিজের একটি সীমা আছে, target-এরও আছে। ফাঁদটি এখানে।

৫ সেকেন্ড ফাঁকা থাকার পর app সংযোগটি বন্ধ করছে। ঠিক সেই মুহূর্তে LB ভাবছে সংযোগ ভালো আছে, আর তাতে অনুরোধ পাঠাচ্ছে। উত্তরে আসে RST, আর ব্যবহারকারী পান 502. এটি হয় মাঝেমধ্যে, ভার কম থাকলেও। আপাত কোনো কারণ দেখা যায় না। নিয়ম হলো target-এর keep-alive LB-র idle timeout-এর চেয়ে বড় রাখা, যাতে সংযোগ বন্ধের সিদ্ধান্ত LB-ই নেয়।

এই অর্থগুলো সাধারণ; provider-ভেদে সূক্ষ্ম পার্থক্য আছে। Nginx-এর 504-এর যে যুক্তি পর্ব ১৪-তে দেখেছেন, এখানেও তা-ই, শুধু proxy-টি এখন managed.

WebSocket আর gRPC

WebSocket একটি HTTP অনুরোধ দিয়ে শুরু হয়ে দীর্ঘ সময় খোলা থাকে। বড় L7 LB-গুলো সাধারণত এটি সমর্থন করে, কিন্তু সংযোগ ফাঁকা থাকলে idle timeout তাকে কাটে। তাই app নিয়মিত ping পাঠায়, সময়সীমার চেয়ে ছোট ব্যবধানে। আর deploy-এর সময় draining সীমায় খোলা সংযোগ কাটা পড়ে, তাই client-এ reconnect থাকতে হয়।

gRPC চলে HTTP/2-তে। L7 LB-কে এটি পেছনের দিকেও বুঝতে হয়, আর সব LB-তে সমর্থন সমান নয়; provider-এর ডকুমেন্টেশন দেখুন। একটি দীর্ঘজীবী সংযোগে অনেক অনুরোধ চলে, তাই L4 LB ভাগ করে সংযোগ, অনুরোধ নয়। এতে ভার অসম হয়, যা বিস্তারিত আছে System Design · L4 বনাম L7 অংশে।

৮ · Regional, global আর internal load balancer

বেশিরভাগ LB regional: একটি region-এর zone-গুলোতে ভার ভাগ করে। Region-ই বিপদে পড়লে এটি বাঁচাতে পারে না। Global load balancing ব্যবহারকারীকে কাছের বা সুস্থ region-এ পাঠায়। পথ দুটি।

উদাহরণ: Google Cloud-এর global Application Load Balancer একটি anycast IP দেয়। Azure Front Door global L7 সেবা। AWS-এ ALB আর NLB regional, আর Global Accelerator অথবা DNS তাদের সামনে বসে। Region নকশার যুক্তি আছে পর্ব ০৫-এ, আর VRRP ও anycast-এর তত্ত্ব System Design-এর এই অংশে।

Internal load balancer

সব LB ইন্টারনেটের দিকে নয়। Internal LB-র ঠিকানা private, শুধু VPC বা জোড়া network থেকে পৌঁছানো যায়। সাধারণ নকশা: বাইরের LB → web স্তর → internal LB → api স্তর। এতে api-র autoscaling-এ web-এর কিছু বদলাতে হয় না, শুধু একটি স্থির DNS নাম থাকে। Private হলেই নিরাপদ নয়; এখানেও TLS আর firewall নিয়ম ভাবতে হবে। Kubernetes-এ একই ধারণা ফিরে আসবে পর্ব ৪৫ আর ৪৬-এ।

৯ · খরচ আর log — বিল আর debugging

LB-র বিল সাধারণত কয়েকটি মাত্রায় হয়: চলার ঘণ্টা, ব্যবহারের একক (AWS-এ LCU, Azure-এর Application Gateway-তে capacity unit), প্রক্রিয়াকৃত data, আর zone-পার বা বাইরে যাওয়া traffic. কোনো কোনো মডেলে নতুন সংযোগ, সক্রিয় সংযোগ, bytes আর rule মূল্যায়নের মধ্যে যেটি সবচেয়ে বড়, সেটির ওপর একক গোনা হয়। নিচের দাম পুরোপুরি ধরে নেওয়া; আসল দাম provider-এর pricing পাতায় দেখুন।

এখান থেকে একটি কার্যকর শিক্ষা। ১০টি ছোট service-এর প্রতিটির আলাদা LB হলে শুধু ঘণ্টার খরচই 10 × $21.60 = $216. একটি LB-তে host আর path rule দিয়ে ভাগ করলে সেই অংশ $21.60-এই থাকে। তবে এক LB-তে সব রাখলে একটি ভুল rule সবাইকে ছোঁয়, অর্থাৎ blast radius বড় হয়। বিস্তারিত বিল পর্ব ৭২-এ।

LB-র log — প্রথম সাক্ষী

LB-র access log বলে অনুরোধটি কোন target-এ গেল, কত সময় লাগল, আর দুই পক্ষের status কী। অনেক provider-এ এটি নিজে চালু করতে হয়, আর object storage-এ জমার খরচ আলাদা। সবচেয়ে কাজের জোড়াটি হলো LB-র status আর target-এর status. দুটি মিললে উত্তরটি app-এর। Target-এর ঘরে - থাকলে LB target থেকে উত্তর পায়নি। নিচের log সরলীকৃত; আসল ফরম্যাটে আরও অনেক কলাম থাকে।

set -euo pipefail
# Simplified LB access log. Columns:
# 1 time  2 client  3 target  4 lb_sec  5 target_sec  6 lb_status  7 target_status  8 method  9 path
log=$(mktemp); trap 'rm -f "$log"' EXIT
cat > "$log" <<'LOG'
10:00:01 203.0.113.10:51000 10.0.1.11:8080 0.001 0.042 200 200 GET /api/orders
10:00:01 203.0.113.11:51001 10.0.2.21:8080 0.001 -1 502 - GET /api/orders
10:00:02 203.0.113.12:51002 10.0.1.12:8080 0.001 0.051 200 200 GET /api/orders
10:00:02 203.0.113.13:51003 10.0.2.21:8080 0.001 -1 502 - POST /api/pay
10:00:03 203.0.113.14:51004 10.0.1.11:8080 0.001 0.310 500 500 POST /api/pay
10:00:03 203.0.113.15:51005 10.0.2.22:8080 0.001 0.047 200 200 GET /shop/cart
10:00:04 203.0.113.16:51006 10.0.2.21:8080 0.001 -1 502 - GET /shop/cart
10:00:05 203.0.113.17:51007 10.0.1.12:8080 0.001 -1 504 - GET /api/report
10:00:36 203.0.113.18:51008 10.0.1.12:8080 0.001 -1 504 - GET /api/report
10:01:06 203.0.113.19:51009 10.0.1.12:8080 0.001 28.400 200 200 GET /api/report
10:01:07 203.0.113.20:51010 - -1 -1 503 - GET /
LOG
echo "== requests by lb_status and target_status =="
awk '{print $6, $7}' "$log" | sort | uniq -c
echo "== errors made by the LB, by target =="
awk '$6 >= 500 && $7 == "-" {print $6, $3}' "$log" | sort | uniq -c | sort -k1,1nr -k2,2n
echo "== slowest answers from a target =="
awk '$5 >= 0 {print $5, $3, $9}' "$log" | sort -k1,1nr | head -3

১০ · AI-এর যুগে load balancer-এর config যাচাই

AI কয়েক সেকেন্ডে LB-র Terraform বা CLI লিখে দিতে পারে। কিন্তু এখানকার ভুল চোখে পড়ে না, কারণ জিনিসটি “চলে”। সমস্যা ধরা পড়ে ভিড়ে, deploy-এর সময়ে, অথবা বিলে।

AI-এর দেওয়া LB config হাতে পেলে — যাচাইয়ের চেকলিস্ট

• terraform plan বা dry-run পড়েছি, আর কোনো অপ্রত্যাশিত destroy নেই
• প্রতিটি argument official docs-এ মিলিয়েছি, আর অন্তত দুটি zone আছে
• Target-এর firewall শুধু LB-কে ঢুকতে দেয়; কোনো private key config-এ নেই
• Rule-এর ক্রম হাতে মিলিয়েছি, আর খালি পথ যেমন /api পরীক্ষা করেছি
• Target-এর keep-alive LB-র idle timeout-এর চেয়ে বড়
• একটি target থামিয়ে throwaway পরিবেশে বাদ পড়া আর ফিরে আসা দেখেছি
• Access log চালু, আর budget alert রাখা হয়েছে