Serverless function — trigger, cold start, concurrency আর সীমা

১ · Function কী — handler, event আর context

পর্ব ১৯-এ VM, container, PaaS আর FaaS-এর তুলনা দেখেছেন: ছোট, অনিয়মিত, event-চালিত কাজে FaaS মানায়। সেই তুলনা এখানে আর নয়। এই মডিউলে আমরা ভেতরে ঢুকব: function কীভাবে চলে, কোথায় আটকায়, আর কীভাবে চালাবেন।

একটি function-এর তিনটি অংশ চিনে নিন:

• Handler: আপনার লেখা যে ফাংশনটি platform ডাকে। Provider জানে কোন ফাইলের কোন নাম, যেমন app.handler.
• Event: কী ঘটেছে তার তথ্য, সাধারণত JSON আকারে। HTTP হলে path আর body, storage হলে bucket আর object-এর নাম।
• Context: এই call-এর তথ্য: request id, কত সময় বাকি, function-এর নাম। Provider-ভেদে নাম আলাদা।

একবার handler চালানোকে বলে invocation, বা সংক্ষেপে invoke. নিচের কোডে কোনো cloud নেই: আমরা নিজেই platform সেজে handler-কে তিনটি নমুনা event দিয়ে ডাকছি। পাতার ভেতরেই চালানো যায়, কোনো account লাগে না।

# A handler called locally with sample events. No cloud, no account needed.
import json

PRICE = {"tea": 15, "samosa": 10}   # outside the handler: runs once, during init
calls = 0                           # lives as long as this environment lives

class Context:                      # a stand-in for what the platform passes in
    request_id = "local-0001"
    remaining_ms = 2900

def order_total(items):             # pure logic: no cloud, easy to unit test
    return sum(PRICE[i["name"]] * i["qty"] for i in items)

def handler(event, context):
    global calls
    calls += 1
    try:
        total = order_total(json.loads(event["body"])["items"])
        status, out = 200, {"total": total}
    except (KeyError, ValueError) as e:
        status, out = 400, {"error": type(e).__name__}
    print(json.dumps({"id": context.request_id, "call": calls, "status": status}))
    return {"statusCode": status, "body": json.dumps(out)}

samples = [
    {"body": '{"items": [{"name": "tea", "qty": 2}, {"name": "samosa", "qty": 3}]}'},
    {"body": '{"items": [{"name": "biryani", "qty": 1}]}'},
    {"body": "not json"},
]
for event in samples:
    print(handler(event, Context()))

{"id": "local-0001", "call": 1, "status": 200}
{'statusCode': 200, 'body': '{"total": 60}'}
{"id": "local-0001", "call": 2, "status": 400}
{'statusCode': 400, 'body': '{"error": "KeyError"}'}
{"id": "local-0001", "call": 3, "status": 400}
{'statusCode': 400, 'body': '{"error": "JSONDecodeError"}'}

২ · Trigger — function-কে কে ডাকে

Function নিজে থেকে চলে না। যে জিনিসটি তাকে ডাকে, তাকে বলে trigger, আর event-এর উৎসকে event source. চারটি ধরন প্রায় সব কাজ ঢেকে দেয়। প্রতিটির ডাকার ধরন আলাদা, আর সেটিই পরে সীমায় পড়লে ফল ঠিক করে।

Asynchronous আর queue-র ক্ষেত্রে ডেলিভারি সাধারণত অন্তত একবার। অর্থাৎ একই event দুবারও আসতে পারে, তাই handler-কে idempotent রাখতে হয়। বিস্তারিত আসবে পর্ব ৭০ আর ৭১-এ।

৩ · Environment-এর জীবন — init, invoke, freeze, reuse, shutdown

প্রতি call-এ কি নতুন করে সব তৈরি হয়? না। Platform একটি execution environment বানায়: আপনার কোড, runtime আর একটু memory-সহ একটি আলাদা ঘর, যা প্রায়ই একটি microVM বা sandbox-এ থাকে। সেই ঘর পরের call-গুলোতেও কাজে লাগে।

• Init: Environment তৈরি, runtime চালু, আর আপনার handler-এর বাইরের কোড চলা: import, config পড়া, client তৈরি।
• Invoke: Handler একটি event নিয়ে চলে, উত্তর দেয়।
• Freeze: কাজ শেষে platform environment থামিয়ে রাখে। Memory থাকে, কিন্তু CPU পায় না। তাই পেছনের thread বা timer-ও থেমে যায়। ফিরে আসা সাধারণত খুব দ্রুত।
• Reuse: পরের event এলে থামানো environment জেগে ওঠে। একে অনেকে warm start বলেন।
• Shutdown: অনেকক্ষণ অলস থাকলে, বা platform-এর নিজের কারণে, environment মুছে যায়। কতক্ষণ পরে, তার কোনো নিশ্চয়তা নেই।

নিচের stepper-এ একই function-এ তিনটি request. সময়গুলো অনুমিত। calls আর database connection-এর ঘর দুটি খেয়াল করুন।

৪ · Cold start — সময় কোথায় যায়, আর কতবার হয়

Cold start নিয়ে দুটি আলাদা প্রশ্ন আছে। একটি cold start কত লম্বা, আর কত request-এ কতবার হয়। প্রথমটি কমাতে নিচের টেবিল।

কারণ কমানোর পরেও দুটি বড় কৌশল আছে, আর দুটিরই দাম আছে।

একসময় অনেকে প্রতি কয়েক মিনিটে নকল “ping” পাঠিয়ে function জাগিয়ে রাখতেন। এটি এক environment-কেই জাগায়, ভিড়ের সময় দ্বিতীয়টিকে নয়, তাই ভরসা করার মতো কৌশল নয়।

এবার দ্বিতীয় প্রশ্ন: কতবার? এটি নির্ভর করে traffic আর provider কতক্ষণ অলস environment রাখেন তার ওপর। নিচের সিমুলেটরে প্রতিটি সারি ২০,০০০ request-এর একটি আলাদা run. অলস সীমা ১০ মিনিট আর environment-এর আয়ু ২ ঘণ্টা ধরা হয়েছে। দুটিই অনুমিত, provider এসব সংখ্যা সাধারণত নিশ্চিত করে বলেন না।

// Cold-start share vs traffic. ASSUMED: idle timeout 600 s, environment life 2 h.
const IDLE = 600, LIFE = 7200, RUN = 0.2, COLD_MS = 800, WARM_MS = 15, N = 20000;
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; }; }
function simulate(rate) {                  // rate = requests per second
  const rnd = mulberry32(42);
  let t = 0, cold = 0, peak = 0, free = [], busy = [];  // each env: [freeAt, bornAt]
  for (let i = 0; i < N; i++) {
    t += -Math.log(1 - rnd()) / rate;      // random gaps between requests
    busy = busy.filter((e) => (e[0] > t ? true : (free.push(e), false)));
    free = free.filter(([at, born]) => t - at < IDLE && t - born < LIFE);
    const env = free.pop();                // newest idle environment, if any
    if (!env) cold++;
    busy.push([t + RUN + (env ? 0 : COLD_MS / 1000), env ? env[1] : t]);
    peak = Math.max(peak, busy.length);
  }
  return { share: cold / N, peak };
}
console.log("traffic  req/hour  cold share  e^(-rate*idle)  max envs  p99 ms");
const rows = [["1/hour", 1 / 3600], ["6/hour", 1 / 600], ["1/min", 1 / 60],
              ["10/min", 1 / 6], ["1/s", 1], ["10/s", 10], ["100/s", 100]];
for (const [name, r] of rows) {
  const { share, peak } = simulate(r);
  const pct = (share * 100).toFixed(share < 0.01 ? 3 : 1) + "%";
  const p99 = share >= 0.01 ? COLD_MS + WARM_MS : WARM_MS; // 1% slow requests set p99
  console.log(name.padEnd(7), String(Math.round(r * 3600)).padStart(9), pct.padStart(11),
    Math.exp(-r * IDLE).toFixed(4).padStart(15), String(peak).padStart(9), String(p99).padStart(7));
}

traffic  req/hour  cold share  e^(-rate*idle)  max envs  p99 ms
1/hour          1       84.8%          0.8465         2     815
6/hour          6       36.9%          0.3679         2     815
1/min          60      0.990%          0.0000         2      15
10/min        600      0.260%          0.0000         3      15
1/s          3600      0.105%          0.0000         5      15
10/s        36000      0.065%          0.0000        12      15
100/s      360000      0.535%          0.0000       107      15

৫ · বিল — request, GB-second, আর memory যে CPU-ও কেনে

বিদ্যুৎ বিলে ওয়াট আর ঘণ্টা গুণ করে ইউনিট হয়: বড় হিটার অল্পক্ষণ, বা ছোট বাতি অনেকক্ষণ, বিল একই হতে পারে। FaaS-এ একই কাজ করে GB-second: memory × সময়। এর সাথে যোগ হয় প্রতি call-এর একটি ছোট ফি।

সময় কত ছোট এককে গোল করা হয়, সেটিও বিল বদলায়। Lambda একসময় ১০০ ms-এর ধাপে গোল করত, ২০২০ সালে ১ ms-এ নামে। ১২০ ms-এর function তখন ২০০ ms-এর বিল পেত: ওপরের $৩৬ হতো $৬০।

Memory বাড়ালে CPU-ও বাড়ে

অনেক platform-এ আপনি CPU আলাদা বাছেন না। Memory বাছলে তার অনুপাতে CPU আসে, যেমন মোবাইল প্যাকেজে ডেটা কিনলে সাথে মিনিটও আসে। লেখার সময়ে Lambda-র নথিতে আছে, প্রায় ১,৭৬৯ MB-তে একটি পূর্ণ vCPU-র সমান ক্ষমতা। তাই একটি ভুল ধারণা ভাঙে: “কম memory মানে কম বিল” সবসময় সত্য নয়। Memory দ্বিগুণ করলে দাম দ্বিগুণ, কিন্তু CPU-নির্ভর কাজের সময় অর্ধেক হলে বিল একই থাকে, আর উত্তর আসে দ্বিগুণ দ্রুত।

নিচের মডেলে দুই ধরনের কাজ। একটি CPU-তে ব্যস্ত ছবি ছোট করার কাজ, একক thread-এ, ৪০০ MB-র কাছাকাছি memory চায়। আরেকটি API, যা বেশিরভাগ সময় database-এর উত্তরের অপেক্ষায়। সংখ্যাগুলো একটি অনুমিত মডেল, আপনার function-এর মাপ নয়।

// Memory setting vs duration and cost. ALL numbers are ASSUMED round values.
const GB_S = 0.00002, PER_REQ = 0.0000002, FULL_CPU_MB = 1769, TIMEOUT = 30;
const SIZES = [128, 256, 512, 768, 1024, 1536, 1769, 2048, 3008];
const jobs = [
  { name: "image resize (CPU heavy)", cpu: 1.2, wait: 0.05, needMB: 400 },
  { name: "API call (mostly waiting)", cpu: 0.02, wait: 0.15, needMB: 100 },
];
function run(job, mb) {
  const share = Math.min(1, mb / FULL_CPU_MB);   // CPU grows with memory, up to one core
  const pressure = 1 + (job.needMB / mb) ** 2;   // tight memory means more garbage collection
  const sec = (job.cpu / share) * pressure + job.wait;
  const usd = (mb / 1024) * sec * GB_S + PER_REQ;
  return { mb, sec, perM: usd * 1e6 };
}
for (const job of jobs) {
  console.log(job.name + "\n    MB  duration s  $ per million");
  const rows = SIZES.map((mb) => run(job, mb));
  const ok = rows.filter((r) => r.sec <= TIMEOUT);
  const cheapest = ok.reduce((a, b) => (b.perM < a.perM ? b : a));
  for (const r of rows) {
    const mark = r === cheapest ? "  <- cheapest" : r.sec > TIMEOUT ? "  timeout" : "";
    console.log(String(r.mb).padStart(6), r.sec.toFixed(3).padStart(11),
      r.perM.toFixed(2).padStart(14) + mark);
  }
  const near = ok.filter((r) => r.perM <= cheapest.perM * 1.1);
  const fast = near.reduce((a, b) => (b.sec < a.sec ? b : a));
  console.log(`  fastest within 10% of cheapest: ${fast.mb} MB, ${fast.sec.toFixed(3)} s\n`);
}

image resize (CPU heavy)
    MB  duration s  $ per million
   128     178.591         446.68  timeout
   256      28.587         143.13
   512       6.727          67.47
   768       3.564          53.66
  1024       2.439          48.99
  1536       1.526          45.97
  1769       1.311          45.51  <- cheapest
  2048       1.296          52.03
  3008       1.271          74.88
  fastest within 10% of cheapest: 1769 MB, 1.311 s

API call (mostly waiting)
    MB  duration s  $ per million
   128       0.595           1.69  <- cheapest
   256       0.309           1.75
   512       0.222           2.42
   768       0.197           3.15
  1024       0.185           3.90
  1536       0.173           5.39
  1769       0.170           6.08
  2048       0.170           7.00
  3008       0.170          10.19
  fastest within 10% of cheapest: 256 MB, 0.309 s

৬ · Concurrency — ভিড় কখন ফেরত যায়

পর্ব ৬৮-এর Little's law এখানেও খাটে: একসাথে কত call চলছে, অর্থাৎ concurrency = rate × duration. সেকেন্ডে ১০০ call, প্রতিটি ০.৪ s হলে ৪০টি। Lambda-র সাধারণ মডেলে এক environment একসাথে একটি call-ই নেয়, তাই ৪০টি environment লাগে। Azure Functions আর Cloud Run functions-এ এক instance সেটিং অনুযায়ী একসাথে অনেক request নিতে পারে, তাই সেখানে instance কম লাগে, তবে কোডকে একসাথে অনেক কাজ সামলানোর উপযোগী হতে হয়।

সীমা তিনটি স্তরে আসে:

• Account-এর সীমা: একটি region-এ মোট concurrency-র quota. লেখার সময়ে Lambda-র ডিফল্ট প্রায়ই ১,০০০, তবে নতুন account-এ কম হতে পারে, আর আবেদন করে বাড়ানো যায়। ঈদের আগের দিন আবেদন করবেন না।
• Reserved concurrency: এক function-এর জন্য একটি সংখ্যা ঠিক করা। এটি দুই কাজ করে: ওই function-এর জন্য জায়গা নিশ্চিত রাখে, আবার সেটিই তার ছাদ। বিয়েবাড়িতে বরপক্ষের জন্য ২০টি টেবিল আলাদা রাখার মতো: অন্যরা বসবে না, কিন্তু বরপক্ষও ২১তম টেবিল পাবে না। Lambda-তে মান শূন্য করলে function পুরো থেমে যায়, যা জরুরি অবস্থায় কাজের। Azure আর Google-এ ছাদের কাজটি করে maximum instance-এর সেটিং।
• Scale-up গতি: ছাদ অনেক ওপরে হলেও নতুন environment একসাথে অসীম ওঠে না। Provider-ভেদে গতি আলাদা, আর এই সংখ্যা বদলেছেও: লেখার সময়ে Lambda-র নথিতে প্রতি function প্রতি ১০ সেকেন্ডে ১,০০০ পর্যন্ত বাড়ার কথা আছে। এই পর্বে আমরা ছোট অনুমিত সংখ্যা নিচ্ছি।

সীমা পার হলে platform বাড়তি call ফিরিয়ে দেয়, যাকে বলে throttling. নিচে ছোট সংখ্যায় ঈদের টিকিট কাউন্টারের মতো একটি ভিড়: ছাদ ৬, প্রতি call ঠিক ১ s, শুরুতে ২টি warm environment, প্রতি সেকেন্ডে সর্বোচ্চ ২টি নতুন environment. Cold start-এর দেরি এই হিসাবে বাদ।

এবার বড় আকারে, seeded PRNG দিয়ে: স্বাভাবিক সময়ে সেকেন্ডে ৫০ call, ১০ থেকে ৩০ সেকেন্ডে ১,০০০ call, প্রতিটি ০.৪ s. নতুন environment সেকেন্ডে সর্বোচ্চ ১০০টি, আর তার cold start ১ s. তিনটি নীতির তুলনা হয়েছে।

// A spike against a concurrency limit. Tick 0.1 s, seeded PRNG, all numbers ASSUMED.
const RUN = 0.4, COLD = 1.0, TICK = 0.1, RAMP = 100;   // RAMP: new environments per second
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 rateAt = (s) => (s >= 10 && s < 30 ? 1000 : 50); // the spike lasts 20 s
function sim(limit, useQueue, show) {
  const rnd = mulberry32(7);
  let free = 25, busy = [], wait = 0, peak = 0, ok = 0, cold = 0, lost = 0, w = [0, 0, 0];
  for (let k = 0; k < 500; k++) {
    const s = k * TICK;
    busy = busy.filter((d) => (d > s + 1e-9 ? true : (free++, false)));
    const fresh = Math.round(rateAt(s) * TICK * (0.8 + 0.4 * rnd()));
    const n = fresh + wait; let budget = RAMP * TICK; wait = 0; w[0] += fresh;
    for (let i = 0; i < n; i++) {
      if (free > 0) { free--; busy.push(s + RUN); ok++; w[1]++; }
      else if (busy.length < limit && budget-- >= 1) {
        busy.push(s + COLD + RUN); ok++; cold++; w[1]++; }
      else if (useQueue) wait++;
      else { lost++; w[2]++; }
    }
    peak = Math.max(peak, wait);
    if (show && k % 50 === 49) {
      console.log(`${(k - 49) / 10}-${(k + 1) / 10}`.padStart(6),
        ...w.map((v) => String(v).padStart(8)), String(busy.length).padStart(8));
      w = [0, 0, 0]; }
  }
  return [ok, cold, lost, peak];
}
console.log("  secs  arrived  started  refused  running");
sim(300, false, true);
console.log("\npolicy              served  cold  refused  peak queue");
for (const [name, lim, q] of [["limit 300", 300, false], ["limit 1000", 1000, false], ["limit 300 + queue", 300, true]])
  console.log(name.padEnd(17), ...sim(lim, q, false).map((v, i) => String(v).padStart([8, 5, 8, 11][i])));

  secs  arrived  started  refused  running
   0-5      247      247        0       21
  5-10      255      255        0       19
 10-15     5045     2255     2790      300
 15-20     5158     3750     1408      300
 20-25     5160     3750     1410      300
 25-30     4890     3750     1140      300
 30-35      251      251        0       20
 35-40      250      250        0       22
 40-45      251      251        0       19
 45-50      251      251        0       18

policy              served  cold  refused  peak queue
limit 300            15010   275     6748           0
limit 1000           19258   451     2500           0
limit 300 + queue    21758   275        0        6748

৭ · সীমা, timeout আর database connection

প্রতিটি platform-এ কিছু শক্ত সীমা আছে। নিচের সংখ্যাগুলো লেখার সময়ের উদাহরণ, মুখস্থ করার জন্য নয়। Plan আর generation-ভেদে আলাদা, আর বদলায়। নকশার আগে নিজের provider-এর নথি দেখুন।

Timeout সর্বোচ্চে রাখবেন না। ধরুন API-র gateway ৩০ সেকেন্ডে হাল ছেড়ে দেয়, আর function-এর timeout ১৫ মিনিট। Database আটকে গেলে gateway আগেই error দেবে, অথচ function চলতে থাকবে, concurrency ধরে রাখবে, বিল বাড়াবে। নিয়মটি হলো: function-এর timeout ডাকা পক্ষের চেয়ে কম, আর database call-এর timeout function-এর চেয়ে কম। context-এ বাকি সময় দেখে কাজ গুটিয়ে ফেলাও ভালো অভ্যাস।

Connection reuse আর connection storm

পর্ব ২২-এ দেখেছেন, database connection দামি আর max_connections সীমিত। Function-এ সমস্যাটি আরও তীব্র, কারণ প্রতিটি environment নিজের জন্য আলাদা। Pool ভাগ করে নেওয়ার কেউ নেই। প্রথম নিয়ম: connection handler-এর ভেতরে প্রতিবার খুলবেন না। বাইরে রাখুন, অলস অবস্থায় মরে গেলে আবার খুলুন।

# উদাহরণ — psycopg আর একটি আসল database লাগে, এই পাতায় চলবে না
import psycopg

DSN = fetch_secret("shop/db")              # your secret-manager call, runs during init
conn = None                                # survives warm invokes, one per environment

def get_conn():
    global conn
    if conn is None or conn.closed:        # a frozen connection may have died
        conn = psycopg.connect(DSN, connect_timeout=2)
    return conn

def handler(event, context):
    with get_conn().cursor() as cur:
        cur.execute("SELECT stock FROM item WHERE id = %s", (event["id"],))
        return {"stock": cur.fetchone()[0]}

এতে warm call-এ connection-এর খরচ বাঁচে। কিন্তু দ্বিতীয় সমস্যা থেকে যায়: ১ environment = ১ connection. ৮০০টি environment মানে ৮০০টি connection, আর database-এর সীমা ধরুন ৩০০। Platform খুশিমনে স্কেল করল, database পড়ে গেল। এটি একধরনের connection storm. Database ধীর হলে duration বাড়ে, Little's law-এ concurrency বাড়ে, আরও environment ওঠে, আরও connection চায়, আর error-এ retry যোগ হয়। চাপ নিজেকেই বাড়ায়।

প্রতিরক্ষার স্তরগুলো একসাথে ব্যবহার করুন:

• ছাদ: Reserved concurrency-কে database-এর নিরাপদ সীমার নিচে রাখুন। ভিড় throttling-এ আটকাবে, database-এ নয়।
• মাঝখানে proxy: Database proxy, যেমন RDS Proxy বা PgBouncer ধরনের সেবা, অনেক client-এর জন্য অল্প connection ভাগ করে।
• সামনে queue: লেখার কাজ queue-তে রাখলে function ধীরগতিতে database-এ ঢালে।
• ভিন্ন database: HTTP-ভিত্তিক data API বা managed NoSQL-এ এই connection-এর সমস্যা অনেক কম। পর্ব ২৩ দেখুন।

HTTP call-এর ক্ষেত্রেও একই কথা: SDK client handler-এর বাইরে বানালে TLS connection warm call-এ আবার কাজে লাগে।

৮ · Package, log, trace আর local test

Zip না container image

Image মানেই সবসময় ধীর cold start নয়, কারণ provider দরকারি অংশ আগে আনেন। তবুও মেপে দেখুন। নিচের উদাহরণটি AWS SAM-এর একটি ছোট template, যেখানে এই পর্বের প্রায় সব সিদ্ধান্ত এক জায়গায় লেখা। ছাদ আর timeout কোডের সাথে version control-এ থাকে। Terraform-এও একই জিনিস করা যায়। চালালে account লাগবে, খরচ হতে পারে, আর পরীক্ষা শেষে sam delete দিয়ে মুছতে হবে।

AWSTemplateFormatVersion: "2010-09-09"
Transform: AWS::Serverless-2016-10-31
Resources:
  ReportFunction:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: python3.13
      Handler: app.handler
      CodeUri: src/
      MemorySize: 512
      Timeout: 20
      ReservedConcurrentExecutions: 50
      Tracing: Active
      Events:
        Hourly:
          Type: Schedule
          Properties:
            Schedule: rate(1 hour)

Log আর trace

SSH করার মতো কোনো server নেই। তাই log আর metric-ই আপনার চোখ। Stdout-এ লেখা log সাধারণত নিজে থেকেই provider-এর log সেবায় যায়। প্রতিটি লাইনে request id বা correlation ID রাখুন। Platform-ও প্রতি invoke-এর পরে একটি হিসাব লেখে। নিচের লাইনগুলো AWS Lambda-র ধরনের, নমুনা আউটপুট — version-ভেদে আলাদা হতে পারে:

START RequestId: 11111111-2222-3333-4444-555555555555
{"level":"info","order":"ord-1042","msg":"report built"}
END RequestId: 11111111-2222-3333-4444-555555555555
REPORT RequestId: 11111111-2222-3333-4444-555555555555  Duration: 62.41 ms  Billed Duration: 805 ms  Memory Size: 512 MB  Max Memory Used: 96 MB  Init Duration: 742.10 ms

এই একটি লাইনেই অনেক উত্তর। Init Duration থাকা মানে এটি cold start. Max Memory Used ৯৬ MB, অথচ দেওয়া ৫১২ MB: সম্ভবত অনেক বেশি, তবে আগে CPU-র দিকটি মেপে দেখুন। যে metric-গুলো নিয়মিত দেখবেন: invocation, error, duration-এর p99, throttle, concurrency, আর asynchronous-এ event-এর বয়স।

একটি request gateway, function, queue আর আরেকটি function পার হলে শুধু log-এ পথ ধরা কঠিন। সেখানে কাজে লাগে distributed tracing: পর্ব ৬৫-এর OpenTelemetry, বা provider-এর সেবা (AWS X-Ray, Azure Application Insights, Google Cloud Trace). Cold start আলাদা span হিসেবে দেখা গেলে ধীর request-এর কারণ সাথে সাথে বোঝা যায়। মনে রাখবেন, function freeze হয় বলে পেছনে জমে থাকা trace বা log আগেই পাঠিয়ে দিতে হয়।

Local test

তিন স্তরে পরীক্ষা করুন, আর প্রতিটি স্তরের সীমা জানুন:

1. Unit test: handler.py-র মতো, হিসাব আলাদা pure ফাংশনে রেখে সরাসরি। দ্রুত, কোনো cloud লাগে না। এখানেই বেশিরভাগ পরীক্ষা হওয়া উচিত।
2. Local emulator: AWS SAM CLI-র sam local invoke, Azure Functions Core Tools, Google-এর Functions Framework. আসল provider-এর নমুনা event ফাইল দিয়ে চালান। এগুলো কোড চালায়, কিন্তু IAM, সীমা আর network-এর আসল আচরণ দেখায় না।
3. ছোট cloud পরিবেশ: আলাদা, throwaway একটি পরিবেশে অল্প কিছু integration test. আসল permission আর trigger শুধু এখানেই ধরা পড়ে। Budget alert রাখুন, কাজ শেষে মুছে ফেলুন।

৯ · নিরাপত্তা, আর edge-এর WebAssembly

Function-এ OS patch আপনার কাজ নয়, কিন্তু কোড, library আর permission আপনারই। সবচেয়ে কার্যকর অভ্যাসটি সহজ: প্রতিটি function-এর জন্য একটি আলাদা role, আর তাতে least privilege. সব function-কে এক বড় role দিলে একটির একটি ত্রুটি পুরো account-এর সমস্যা হতে পারে। নিচের policy একটি thumbnail function-এর: শুধু uploads/ পড়ে, শুধু thumbs/-এ লেখে। পর্ব ৩২-এ এর মূল্যায়ন দেখেছেন। Log-এ লেখার অনুমতি আলাদা, আর সেটিও নিজের log group-এ সীমিত রাখুন।

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-bucket/uploads/*"
    },
    {
      "Effect": "Allow",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::example-bucket/thumbs/*"
    }
  ]
}

• Event-কে অবিশ্বাস করুন: Function যেকোনো পথ দিয়ে ডাক পেতে পারে। HTTP body হোক বা queue-র বার্তা, ব্যবহারের আগে যাচাই করুন।
• Secret কোডে নয়: Secret manager থেকে আনুন, আর init-এ cache করুন। Environment variable-এ সরাসরি সংবেদনশীল মান রাখার ঝুঁকি নিয়ে পর্ব ৩৩ দেখুন।
• কে ডাকতে পারে: Function-এর resource policy-তে শুধু সঠিক trigger থাকুক। পাবলিক URL রাখলে authentication আর আলাদা WAF-এর কথা ভাবুন।
• Library: পর্ব ৪১-এর মতো version বেঁধে scan করুন। Provider বন্ধ হওয়া runtime-কে একসময় সরিয়ে দেন, তাই runtime version-ও নিয়মিত দেখুন।

Edge-এ WebAssembly, সংক্ষেপে

Edge function ব্যবহারকারীর কাছের CDN বিন্দুতে চলে। সেখানে প্রতি request-এ একটি microVM ওঠানোও ভারী, তাই কিছু platform হালকা sandbox ব্যবহার করে: একই process-এ V8 isolate (Cloudflare Workers-এর পরিচিত মডেল), বা WebAssembly module. শুরু হয় মিলিসেকেন্ড বা তার কম সময়ে, তাই cold start প্রায় চোখে পড়ে না। দাম হলো কড়া সীমা: কম সময়, কম memory, সব library চলে না, আর database অনেক দূরে থাকতে পারে। URL বদলানো, লগইন যাচাই, A/B পরীক্ষার মতো ছোট কাজে এটি ভালো। ভারী কাজ region-এর function-এই থাক। Isolation-এর তুলনা Operating Systems কোর্সে আর edge-এর নকশা System Design কোর্সে পাবেন।

১০ · AI-এর যুগে serverless

AI কয়েক সেকেন্ডে একটি চলা function লিখে দেয়। কিন্তু “চলে” মানে এই নয় যে ভিড়ে টিকবে, বা বিল সামলাবে। নিচের ভুলগুলো এই বিষয়ে খুব পরিচিত।

AI-এর লেখা function হাতে পেলে — চেকলিস্ট

• Rate × duration হাতে হিসাব করে database-এর সীমার সাথে মিলিয়েছি
• Concurrency-র ছাদ আছে, আর timeout ডাকা পক্ষের চেয়ে কম
• Role-এ * নেই, প্রতিটি action-এর কারণ বলতে পারি
• Trigger আর লেখার জায়গা আলাদা, loop হবে না
• একই event দুবার চালিয়ে দেখেছি, ফল ঠিক আছে
• Memory কয়েকটি মানে মেপেছি, অনুমানে নয়
• Secret কোডে নেই; সীমা আর দাম বর্তমান নথিতে মিলিয়েছি
• Throwaway পরিবেশে চালিয়েছি, budget alert আছে, পরিষ্কার করার ধাপ জানি