Serverless architecture — API, fan-out, idempotency আর কখন নয়

১ · একটি পুরো serverless web app

পর্ব ৬৯-এ একটি একক function দেখেছেন, আর পর্ব ৭০-এ দেখেছেন queue আর event bus. এবার সব একসাথে জোড়া হবে। একটি কাল্পনিক উদাহরণ ধরি: “বাগানের আম”, রাজশাহীর কয়েকজন আমচাষির ছোট একটি অনলাইন দোকান। দোকানে ছবি আছে, অর্ডার আছে, আর মোবাইল-পেমেন্টের একটি কাল্পনিক gateway আছে। মে থেকে জুলাই ভিড়, বাকি নয় মাস প্রায় ফাঁকা। দলে একজনই developer, তিনি রাত জেগে server দেখতে চান না।

নিচের ছবিটি এই পর্বের মানচিত্র। একবার মন দিয়ে দেখে নিন। পরের প্রতিটি অংশ এই ছবির কোনো একটি তীর নিয়ে কথা বলবে।

একটি কথা পরিষ্কার করে নেওয়া দরকার। Serverless আর FaaS এক জিনিস নয়, যদিও অনেকে একই অর্থে বলেন। FaaS হলো function চালানোর সেবা। Serverless বৃহত্তর শব্দ, যাতে object storage, queue বা ব্যবহার-অনুযায়ী বিলের database-ও পড়ে। সংজ্ঞা নিয়ে মতভেদ আছে, যেমন serverless container-কে কেউ এই দলে ধরেন, কেউ ধরেন না।

২ · API gateway: দরজার দারোয়ান

ছবির ডানদিকের পথটি ধরুন। ব্রাউজারের প্রতিটি API request আগে API gateway-তে আসে। এটি একটি managed reverse proxy. Function-এ কোড পৌঁছানোর আগেই অনেক কাজ এখানে সেরে ফেলা যায়, তাতে বিলও বাঁচে। নকশার তত্ত্ব আছে System Design-এর API gateway পর্বে। এখানে দেখব চালানোর দিকটি।

একটি হিসাব। ধরি rate সেকেন্ডে ১০০, burst ২০০। অর্থাৎ বালতিতে সর্বোচ্চ ২০০টি token থাকে, আর প্রতি সেকেন্ডে ১০০টি নতুন token ঢোকে। বালতি ভরা অবস্থায় এক সেকেন্ডে ৫০০টি request এলো। ওই সেকেন্ডে ব্যবহারযোগ্য token হলো ২০০ + ১০০ = ৩০০। তাই ৩০০টি যাবে, আর ২০০টি 429 পাবে। পরের সেকেন্ডে বালতি খালি থেকে শুরু, তাই তখন আর ১০০টির বেশি যাবে না। Burst মানে একবারের জমানো সঞ্চয়, স্থায়ী গতি নয়। আরও দেখুন rate limiting পর্বে।

Gateway-র আরেকটি গুণ, request-এর আকৃতি যাচাই। ভুল JSON ফেরত দিতে function চালাতে হয় না। তবে ব্যবসার নিয়ম, যেমন “এই অর্ডার কি এই ব্যবহারকারীর?”, function-এর ভেতরেই থাকবে। Gateway-র body আকার আর সময়ের সীমাও মনে রাখুন। লেখার সময়ে অনেক সেবায় সীমা কয়েক MB আর কয়েক সেকেন্ড থেকে কয়েক মিনিটের মধ্যে, provider-ভেদে আলাদা। এই কারণেই বড় ফাইল gateway দিয়ে পাঠানো হয় না।

৩ · Thumbnail pipeline, fan-out আর fan-in

চাষি একটি আমের ছবি তুললেন, ফোনের ক্যামেরায় ২ MB. দোকানের তালিকায় এত বড় ছবি দেখালে গ্রামের ধীর নেটে পাতা খুলবে না। তাই তিন মাপ দরকার: ১৫০, ৪৮০ আর ১০৮০ পিক্সেল। কাজটি কয়েক সেকেন্ডের, তাই ব্যবহারকারীকে অপেক্ষায় রাখা ঠিক নয়। নিচের stepper-এ একটি upload-এর পুরো যাত্রা দেখুন।

{ "name": "mango-42.jpg", "type": "image/jpeg" }

200 OK
{ "url": "https://example-bucket.../uploads/mango-42.jpg?sig=FAKE",
  "expires_in": 300 }

PUT uploads/mango-42.jpg
Content-Type: image/jpeg
Content-Length: 2000000

200 OK

{ "event": "ObjectCreated",
  "key": "uploads/mango-42.jpg",
  "size": 2000000,
  "etag": "9a1f..." }

receive count = 1
done sizes    = {}
resize 150 ... 480 ... 1080

thumbs/mango-42-150.jpg     18 KB
thumbs/mango-42-480.jpg     95 KB
thumbs/mango-42-1080.jpg   310 KB

photo: mango-42
status: READY
done sizes = {150, 480, 1080}

Fan-out আর fan-in

Fan-out মানে একটি ঘটনা থেকে অনেকগুলো সমান্তরাল কাজ। লঞ্চঘাটে একটি লঞ্চ ভিড়লে কুলিরা একসাথে মাল নামান, একজন একজন করে নয়। Fan-in মানে সবার ফল এক জায়গায় জড়ো করে পরের ধাপ শুরু করা। পথ তিনটি:

• Queue-তে অনেক বার্তা: Function প্রতি মাপের জন্য একটি বার্তা পাঠায়। সবচেয়ে সরল। Fan-in নিজে লিখতে হয়।
• Pub/sub: একটি event একাধিক subscriber-এর queue-তে যায়। একজন ছবি ছোট করে, আরেকজন ছবি যাচাই করে। একে অপরকে চেনে না। তত্ত্ব আছে pub/sub পর্বে।
• Workflow engine-এর parallel ধাপ: Fan-in সে নিজেই করে। সহজ, তবে প্রতি ধাপে বিল আসতে পারে। এ কথায় পরে ফিরব।

Fan-in-এর ফাঁদ। তিনটি কাজের জন্য remaining = 3 রেখে প্রতিটি শেষে ১ কমালেন। একটি বার্তা দুবার এলে কাউন্টার দুবার কমবে, আর কাজ অসম্পূর্ণ থাকতেই READY হয়ে যাবে। সংখ্যা না কমিয়ে set-এ নাম যোগ করুন: done = {150, 480}. একই নাম দুবার যোগ করলে set বদলায় না। তারপর set-এর আকার ৩ হলে READY. কাউন্টার idempotent নয়, set idempotent.

৪ · Idempotency: একই event দুবার এলে

এবার দোকানের সবচেয়ে সংবেদনশীল তীর। পেমেন্ট gateway webhook পাঠাল: অর্ডার ord-1042, ১,২০০ টাকা পরিশোধিত। Function জমা করল, কিন্তু উত্তর পৌঁছানোর আগেই নেট কেটে গেল। Gateway ভাবল পৌঁছায়নি, তাই আবার পাঠাল। যাচাই না থাকলে চাষির খাতায় ২,৪০০ টাকা উঠবে।

Cloud-এর queue, event আর webhook প্রায় সবই at-least-once. তাই নিয়মটি এক লাইনের: duplicate আটকানোর চেষ্টা নয়, duplicate-কে নিরীহ বানান। এই গুণটিই idempotency. হাতিয়ার হলো idempotency token, যাকে অনেক API-তে idempotency key বলে। এটি প্রতিটি কাজের একটি স্থায়ী পরিচয়, যেমন event id, যা retry-তে বদলায় না।

কিন্তু “আগে দেখে নিই আছে কি না, তারপর লিখি” যথেষ্ট নয়। দুটি copy একই মুহূর্তে এলে দুজনেই দেখবে নেই, আর দুজনেই লিখবে। সমাধান conditional write: পড়া আর লেখা database-এর ভেতরে একটিই অবিভাজ্য কাজ। শর্তটি হলো: key না থাকলেই লেখা, নইলে পুরো কাজ ব্যর্থ। নিচের trace-এ দেখুন।

1def handler(event):2  ok = transact(put(event.id, if_absent),3                add(balance, event.taka))4  if not ok: count("duplicate")5  return "done"

এবার সিমুলেটর। চারবারে পাঁচটি delivery আসে। শেষ দলে একই event-এর দুটি copy একই মুহূর্তে। তারপর দ্বিতীয় অংশে দেখবেন, দুটি লেখার মাঝে crash হলে কী হয়।

// Seller balance under duplicate delivery. Prices in taka.
// Each inner list arrives at the SAME moment (two function copies at once).
const taka = { "evt-71": 1200, "evt-72": 850, "evt-73": 400 };
const deliveries = [["evt-71"], ["evt-72"], ["evt-71"], ["evt-73", "evt-73"]];

function run(name, write) {
  const table = new Set();
  let balance = 0, blocked = 0;
  for (const group of deliveries) {
    const seen = group.map((id) => table.has(id));  // every copy reads first
    group.forEach((id, i) => {                      // then every copy writes
      if (write(table, id, seen[i])) balance += taka[id]; else blocked++;
    });
  }
  console.log(name.padEnd(17), "balance", String(balance).padStart(5), " blocked", blocked);
}
const putIfAbsent = (t, id) => (t.has(id) ? false : (t.add(id), true));

run("no check",        (t, id) => { t.add(id); return true; });
run("read then write", (t, id, seen) => { if (seen) return false; t.add(id); return true; });
run("conditional put", (t, id) => putIfAbsent(t, id));
console.log("correct balance", 1200 + 850 + 400);

// Crash between two steps, then the queue delivers the event again.
function crashThenRetry(sameTransaction) {
  const table = new Set();
  let balance = 0;
  // first try: the key is saved, then the function dies before crediting
  if (!sameTransaction) table.add("evt-71");   // a transaction saves nothing
  // retry
  if (putIfAbsent(table, "evt-71")) balance += taka["evt-71"];
  return balance;
}
console.log("crash, two separate writes:", crashThenRetry(false));
console.log("crash, one transaction    :", crashThenRetry(true));

no check          balance  4050  blocked 0
read then write   balance  2850  blocked 1
conditional put   balance  2450  blocked 2
correct balance 2450
crash, two separate writes: 0
crash, one transaction    : 1200

বিভিন্ন database-এ conditional write

নিচে একটি উদাহরণ। এটি এখানে চালানো হয়নি, আউটপুট নমুনা।

# উদাহরণ: DynamoDB-তে key না থাকলেই লেখা
aws dynamodb put-item --table-name payments \
  --item '{"pk":{"S":"evt-71"},"taka":{"N":"1200"}}' \
  --condition-expression "attribute_not_exists(pk)"

# নমুনা আউটপুট, দ্বিতীয়বার চালালে (version-ভেদে আলাদা হতে পারে):
# An error occurred (ConditionalCheckFailedException) when calling
# the PutItem operation: The conditional request failed

-- উদাহরণ: PostgreSQL-এ একই কাজ
INSERT INTO payments (event_id, taka)
VALUES ('evt-71', 1200)
ON CONFLICT (event_id) DO NOTHING;
-- প্রভাবিত row 0 হলে duplicate.

Firestore-এ create আর Cosmos DB-তে একই id-র create-ও প্রায় একইভাবে ব্যর্থ হয়। Object storage-এও লেখার শর্ত আছে, যেমন If-None-Match: * header, তবে সমর্থন provider-ভেদে দেখে নিন।

চারটি বাস্তব সিদ্ধান্ত:

• Key কোথা থেকে? ব্যবসার পরিচয় থেকে, যেমন পেমেন্টের transaction id. Queue-র message id প্রায়ই ভালো নয়, কারণ উৎস আবার পাঠালে নতুন id হতে পারে। Client থেকে আসা API request-এ client নিজে একটি token বানিয়ে পাঠায়।
• Record কতদিন? Retry-র সর্বোচ্চ সময়ের চেয়ে বেশি। TTL দিয়ে পুরোনো key মুছুন, যেমন ৭ দিন।
• বাইরের কাজ? SMS বা অন্য API transaction-এ ঢোকে না। তাদের কাছেও idempotency key পাঠান। না থাকলে “অন্তত একবার” না “সর্বোচ্চ একবার”, সেটি বেছে নিতে হয়।
• উত্তরও মনে রাখুন। API-র ক্ষেত্রে দ্বিতীয় request-কে আগের একই ফল দিন। Key-এর পাশে response রেখে দেওয়া যায়।

৫ · Partial batch failure: শুধু ব্যর্থগুলোই আবার

Queue থেকে function সাধারণত একসাথে অনেক বার্তা নেয়, ধরুন ১০টি। এতে খরচ কমে। কিন্তু ৯টি সফল আর ১টি ব্যর্থ হলে কী হবে? ডিফল্ট আচরণে পুরো batch ব্যর্থ ধরা হয়, আর ১০টি বার্তাই আবার আসে। মানে ৯টি ঠিক কাজ আবার। সবচেয়ে খারাপ দিকটি হলো, একটি নষ্ট ছবি থাকলে পুরো দলটিই সীমায় পৌঁছে dead-letter queue-তে যেতে পারে।

এই একটি নষ্ট বার্তাই poison message. বাসের ছাদে একটি বেঁধে-না-রাখা বস্তা যেন পুরো বাসকে আটকে রেখেছে। সমাধান partial batch failure: function শুধু ব্যর্থ বার্তার পরিচয় ফেরত দেয়, বাকিগুলো মুছে যায়। Lambda-তে নিয়মটি হলো event source-এ ReportBatchItemFailures চালু করে এই আকারে উত্তর দেওয়া:

{ "batchItemFailures": [ { "itemIdentifier": "msg-07" } ] }

অন্য provider-এ রূপ ভিন্ন, যেমন প্রতিটি বার্তা আলাদা করে ack বা complete করা। ধারণা একই। নিচের সিমুলেটরে ১০টি ছবির একটি batch আছে। img-07 নষ্ট, সে কখনো সফল হবে না। বাকিগুলো ২০% সময় ব্যর্থ হয়। সর্বোচ্চ তিনবার পাঠানো হবে।

// One batch of 10 images. img-07 is corrupt, others fail 20% of the time.
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 ids = Array.from({ length: 10 }, (_, i) => "img-0" + i);
const CORRUPT = "img-07", MAX_RECEIVE = 3;

function simulate(partial) {
  const rnd = mulberry32(71), done = new Set(), dlq = [], tries = {};
  let pending = ids.slice(), calls = 0;
  console.log(partial ? "\nretry only failed items" : "\nretry the whole batch");
  for (let round = 1; pending.length; round++) {
    const failed = [];
    for (const id of pending) {
      calls++; tries[id] = (tries[id] || 0) + 1;
      if (id !== CORRUPT && rnd() > 0.2) done.add(id); else failed.push(id);
    }
    console.log(` round ${round}: sent ${pending.length}, failed [${failed.join(" ")}]`);
    const again = partial ? failed : (failed.length ? pending : []);
    pending = again.filter((id) => tries[id] < MAX_RECEIVE);
    dlq.push(...again.filter((id) => tries[id] >= MAX_RECEIVE));
  }
  const usable = ids.filter((id) => done.has(id)).length;
  const lost = dlq.filter((id) => done.has(id)).length;
  console.log(` resize calls ${calls}, finished ${usable}/10, dead-letter ${dlq.length}`
    + ` (${lost} of them had already finished)`);
  console.log(` fan-in: album ${usable === 10 ? "READY" : "PARTIAL"}`);
}
simulate(false);
simulate(true);

retry the whole batch
 round 1: sent 10, failed [img-01 img-05 img-06 img-07]
 round 2: sent 10, failed [img-07]
 round 3: sent 10, failed [img-03 img-06 img-07 img-08]
 resize calls 30, finished 9/10, dead-letter 10 (9 of them had already finished)
 fan-in: album PARTIAL

retry only failed items
 round 1: sent 10, failed [img-01 img-05 img-06 img-07]
 round 2: sent 4, failed [img-07]
 round 3: sent 1, failed [img-07]
 resize calls 15, finished 9/10, dead-letter 1 (0 of them had already finished)
 fan-in: album PARTIAL

Dead-letter queue কোনো ডাস্টবিন নয়, এটি মেরামতের খাতা। এর গভীরতায় alert রাখুন, ঠিক করার পর বার্তাগুলো আবার মূল queue-তে পাঠান (redrive), আর আগে নিশ্চিত হোন handler idempotent. একটি পরিচিত নিয়ম: queue-র visibility timeout function-এর timeout-এর কয়েক গুণ রাখুন। AWS-এর নথি অন্তত ৬ গুণের পরামর্শ দেয়, নইলে চলন্ত কাজের বার্তা আবার দেখা দিয়ে অকারণ duplicate বানায়।

৬ · এক route এক function, নাকি একটি বড় function? আর database

দোকানে ১২টি API route. প্রতিটির জন্য আলাদা function, নাকি একটি function-এর ভেতরেই ছোট web app? দ্বিতীয়টিকে অনানুষ্ঠানিকভাবে Lambdalith বলা হয়। এটি community-র শব্দ, কোনো মান নয়, আর বিতর্কটি এখনো চলছে। কোনো পক্ষকেই চিরন্তন সঠিক ধরবেন না।

একটি মধ্যপথ প্রচলিত: ব্যবসার ক্ষেত্র ধরে ভাগ। অর্ডারের সব route এক function-এ, পেমেন্ট আলাদা, কারণ তার অনুমতি আর ঝুঁকি আলাদা। ভারী worker সবসময় আলাদা, কারণ তার memory আর timeout আলাদা। ছোট দলে “বাগানের আম”-এর জন্য তিনটি function যথেষ্ট: API, পেমেন্ট webhook, আর ছবির worker.

Database-এর কঠিন হিসাব

Function যতগুলো একসাথে চলে, database connection-ও ততগুলো হতে পারে, কারণ প্রতিটি instance নিজের connection রাখে। ধরুন ঈদের আগের সন্ধ্যায় ৫০০টি instance একসাথে চলছে, আর database-এর max_connections ২০০। এই connection storm-এ ৩০০টি instance সংযোগই পাবে না। প্রচলিত connection pool-ও সাহায্য করে না, কারণ প্রতিটি instance-এর pool আলাদা। পথ তিনটি:

• Database proxy: মাঝখানে বসে অনেক function-এর connection অল্প কিছু আসল connection-এ ভাগ করে। উদাহরণ RDS Proxy, বা নিজে চালানো PgBouncer. Connection pinning হলে লাভ কমে। বিস্তারিত পর্ব ২২-এ।
• HTTP-ভিত্তিক database: DynamoDB, Firestore বা Cosmos DB-তে স্থায়ী connection-এর সমস্যাটি প্রায় নেই। বিনিময়ে মডেল আগেই query ধরে সাজাতে হয়, দেখুন পর্ব ২৩।
• Serverless database: Aurora Serverless, Azure SQL-এর serverless স্তর বা Neon-এর মতো সেবা ক্ষমতা নিজে বাড়ায়-কমায়। শূন্যে নামা আর জাগতে সময় লাগা নিয়ে শর্ত সেবাভেদে আলাদা, লেখার সময়ের নথি দেখে নিন। “Serverless” নাম মানেই শূন্য বিল নয়।

Function-এ concurrency-র সীমা রাখা database রক্ষার সহজ উপায়। ১৫০-এ সীমা দিলে বাকিরা queue-তে অপেক্ষা করে বা 429 পায়, database পড়ে না। Serverless স্তর দ্রুত বাড়ে, কিন্তু সবচেয়ে ধীর টুকরোর গতিই পুরো ব্যবস্থার গতি।

৭ · চালানো: observability, deployment, test আর নিরাপত্তা

Observability: টুকরোগুলোর পথ জোড়া

Server-এ ঢুকে দেখার সুযোগ নেই, আর একটি কাজ ছড়িয়ে আছে gateway, দুটি function আর queue-তে। তাই প্রতিটি কাজে একটি correlation ID লাগে, যা structured log-এ থাকবে। HTTP-তে traceparent নিজে থেকে যেতে পারে, কিন্তু queue-র ওপারে সাধারণত নিজেকে পাঠাতে হয় message attribute-এ। Batch-এ একটি function অনেক বার্তা ধরলে এক parent মানায় না, তখন span link কাজে লাগে। বিস্তারিত পর্ব ৬৫-তে।

কয়েকটি metric অবশ্যই দেখুন: function-এর error আর throttle, p95 সময়, cold start-এর হার, queue-র সবচেয়ে পুরোনো বার্তার বয়স, আর dead-letter queue-র গভীরতা। শেষ দুটি সবচেয়ে জরুরি, কারণ async ব্যবস্থায় ব্যবহারকারী কোনো error দেখেন না, শুধু ছবিটি আসে না। Log-এর বিলও দেখুন, প্রতি request-এ লম্বা log লিখলে তা function-এর বিলকেও ছাড়াতে পারে।

Deployment

Azure-এ Bicep আর Google Cloud-এ Terraform বা gcloud-ও প্রচলিত। নিচে ছবির worker-এর একটি SAM উদাহরণ। এতে অংশ ৫-এর দুটি নিয়ম খেয়াল করুন: partial batch response, আর timeout ৬০ সেকেন্ডের ৬ গুণ visibility timeout.

# উদাহরণ, চালানো হয়নি। Deploy করলে খরচ হতে পারে।
AWSTemplateFormatVersion: "2010-09-09"
Transform: AWS::Serverless-2016-10-31
Resources:
  ThumbWorker:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: python3.13
      Handler: app.handler
      CodeUri: src/
      MemorySize: 1024
      Timeout: 60
      ReservedConcurrentExecutions: 20
      Events:
        Uploads:
          Type: SQS
          Properties:
            Queue:
              Fn::GetAtt: [ThumbQueue, Arn]
            BatchSize: 10
            FunctionResponseTypes:
              - ReportBatchItemFailures
  ThumbQueue:
    Type: AWS::SQS::Queue
    Properties:
      VisibilityTimeout: 360
      RedrivePolicy:
        deadLetterTargetArn:
          Fn::GetAtt: [ThumbDlq, Arn]
        maxReceiveCount: 3
  ThumbDlq:
    Type: AWS::SQS::Queue

Local test: কোনটি কোথায়

Cloud-কে পুরোপুরি ল্যাপটপে আনা যায় না, তাই স্তর ভাগ করে test করুন।

• ব্যবসার লজিক: Handler থেকে আলাদা সাধারণ function রাখুন, আর সাধারণ unit test লিখুন। এতে cloud লাগে না, আর এখানেই বেশিরভাগ test থাকা উচিত।
• Handler: নমুনা event JSON দিয়ে চালান। sam local invoke, Azure-এর func start বা Google-এর Functions Framework এই কাজে লাগে। Duplicate event আর batch-এ একটি নষ্ট বার্তা, এই দুটি test আবশ্যক।
• সেবার সাথে সংযোগ: Emulator কাজে লাগে, তবে অনুমতি, সীমা আর সময়ের আচরণ হুবহু মেলে না। তাই আসল IAM আর আসল event-এর জন্য একটি স্বল্পস্থায়ী test stack-ই ভরসা। কাজ শেষে stack মুছে দিন, আর budget alert রাখুন।

নিরাপত্তার জমি

OS patch এখন provider-এর দায়, তাতে নিরাপত্তা শেষ হয় না, শুধু জায়গা বদলায় (shared responsibility). Server একটি থাকলে দরজা একটি, কিন্তু এখানে প্রতিটি trigger একটি দরজা।

৮ · মোট খরচ: serverless বনাম সবসময় চালু container

পর্ব ১৯-এ শুধু compute-এর crossover দেখেছিলেন। এবার পুরো ব্যবস্থার হিসাব। সব দামই অনুমান, পড়ার সময় provider-এর pricing পাতা দেখে নিন। Serverless-এ প্রতি মিলিয়ন request-এ compute আর call $২.২০, gateway $১.০০, log $০.৩০; মোট $৩.৫০। Container-এ দুটি zone-এর জন্য সর্বনিম্ন ২টি task, প্রতিটি মাসে $২৮.৮০, আর load balancer $২০। একটি task সেকেন্ডে ১৫টি request নেয়। Fleet peak-এর মাপে স্থির। Database দুই দিকেই একই, তাই বাদ।

হাতে হিসাব। Container-এর সর্বনিম্ন বিল ২০ + ২ × ২৮.৮০ = $৭৭.৬০। Serverless সেখানে পৌঁছায় ৭৭.৬০ ÷ ৩.৫০ ≈ ২২.২ মিলিয়ন request-এ, গড়ে সেকেন্ডে প্রায় ৮.৬টি। Peak ২ গুণ হলে ১৭.১ req/s, দুটি task-এর ৩০-এর মধ্যে, তাই হিসাব ঠিক আছে।

// Monthly bill for one API: serverless vs always-on containers. ASSUMED prices.
const P = {
  gwPerM: 1.0, fnPerM: 2.2, logPerM: 0.3,      // $ per million requests
  taskMonth: 28.8, taskRps: 15, minTasks: 2,   // containers, two zones
  lbMonth: 20,                                 // load balancer, flat
};
const rps = (m) => m * 1e6 / (30 * 86400);     // m = million requests a month
const serverless = (m) => m * (P.gwPerM + P.fnPerM + P.logPerM);
const tasks = (m, peak) =>
  Math.max(P.minTasks, Math.ceil(rps(m) * peak / P.taskRps));
const containers = (m, peak) => P.lbMonth + tasks(m, peak) * P.taskMonth;

console.log("M req/mo  avg rps  serverless  containers(peak x2)  tasks");
for (const m of [0.1, 1, 5, 10, 22, 23, 30, 60, 100, 300]) {
  console.log(
    String(m).padStart(8), rps(m).toFixed(1).padStart(8),
    ("$" + serverless(m).toFixed(0)).padStart(11),
    ("$" + containers(m, 2).toFixed(0)).padStart(20),
    String(tasks(m, 2)).padStart(6));
}
// From which load is serverless dearer for good? Fleet is sized for the peak.
console.log("\npeak/avg  serverless stays dearer from");
for (const peak of [2, 3, 4, 5, 10]) {
  let last = 0;
  for (let m = 0.1; m <= 2000; m += 0.1) {
    if (serverless(m) <= containers(m, peak)) last = m;
  }
  const text = last > 1999 ? "never (up to 2000M)" : (last + 0.1).toFixed(1) + "M";
  console.log(String(peak).padStart(8), " ", text);
}

M req/mo  avg rps  serverless  containers(peak x2)  tasks
     0.1      0.0          $0                  $78      2
       1      0.4          $4                  $78      2
       5      1.9         $18                  $78      2
      10      3.9         $35                  $78      2
      22      8.5         $77                  $78      2
      23      8.9         $81                  $78      2
      30     11.6        $105                  $78      2
      60     23.1        $210                 $135      4
     100     38.6        $350                 $193      6
     300    115.7       $1050                 $481     16

peak/avg  serverless stays dearer from
       2   22.2M
       3   30.4M
       4   88.1M
       5   never (up to 2000M)
      10   never (up to 2000M)

এই হিসাবের বাইরে কী রইল? মানুষের সময়। ধরুন একজন engineer-এর এক ঘণ্টার দাম $১০, আর container fleet patch, scaling আর image-এর পেছনে মাসে ৫ ঘণ্টা বাড়তি লাগে। তাহলে container-এর দিকে $৫০ যোগ হয়, আর crossover (৭৭.৬০ + ৫০) ÷ ৩.৫০ ≈ ৩৬.৫ মিলিয়নে সরে যায়। অন্যদিকে autoscaling চালু থাকলে container-এর কার্যকর peak কমে, ফল উল্টো দিকে সরে। Adam Eivy-র “Be Wary of the Economics of ‘Serverless’ Cloud Computing” (IEEE Cloud Computing, ২০১৭) ঠিক এই সতর্কতাই দেয়: ব্যবহার-অনুযায়ী দাম সবসময় কম দাম নয়। বিলের খুঁটিনাটি পরের FinOps মডিউলে আসছে।

৯ · কখন serverless নয়, আর lock-in-এর বাস্তবতা

তিনটি পরিস্থিতিতে আগে থেমে ভাবুন:

• দীর্ঘ কাজ: Function-এর সময়সীমা আছে। লেখার সময়ে Lambda-তে সর্বোচ্চ ১৫ মিনিট, অন্য সেবায় ভিন্ন। ঘণ্টার পর ঘণ্টার কাজ টুকরো করা যায়, তবে তখন checkpoint আর সমন্বয়ের ঝামেলা আপনার।
• দিনরাত সমান উঁচু load: অলস সময় না থাকলে scale to zero-র কোনো লাভ নেই, আর প্রতি request-এর দাম চড়ে যায়। অংশ ৮-এর peak ২ গুণের সারি দেখুন।
• কম ও স্থির latency: Cold start শত মিলিসেকেন্ড থেকে কয়েক সেকেন্ড যোগ করতে পারে। Provisioned concurrency কমায়, তবে তখন অলস সময়েরও বিল আসে। Real-time গেম বা trading-এর মতো কাজে স্থায়ী process-ই ভালো।

এক রাতের কাজ দিয়ে সিদ্ধান্তটি ধাপে ধাপে দেখি। দোকান এখন কয়েকটি জেলার বাজারের দর নিয়ে রাতে একটি পূর্বাভাসের হিসাব চালাতে চায়। কাজটি একটানা ৫ ঘণ্টার, লাগে ৮ GB memory, আর একটি process-এর ভেতরে সব ডেটা থাকে।

1job: 5 h, 8 GB, nightly2fits function limit (15 min)?3can it split into chunks?4price: function vs container5spot + checkpoint?6decide; trigger stays serverless

একটি প্রকাশ্য উদাহরণ

২০২৩ সালের মার্চে Amazon Prime Video-র একটি দল নিজেদের প্রযুক্তি ব্লগে লিখেছিল, তাদের অডিও-ভিডিও মান যাচাইয়ের একটি টুল serverless টুকরো থেকে এক process-এ সরিয়ে আনা হয়েছে। তাদের লেখা অনুযায়ী মূল ব্যবস্থাটি বানানো ছিল workflow সেবা আর function দিয়ে, মাঝের ফ্রেম জমা থাকত object storage-এ। তাদের বলা কারণ দুটি: প্রতিটি stream-এর প্রতি সেকেন্ডে অনেক workflow state transition-এর খরচ, আর object storage-এ অসংখ্য call-এর খরচ। স্কেলের সীমাতেও আটকেছিল। সব এক process-এ এনে ফ্রেম memory-তেই পাঠানো হয়, container-এ চলে, আর তারা খরচ ৯০%-এর বেশি কমার কথা জানায়। মূল লেখাটি পরে সেই ঠিকানা থেকে সরানো হয়েছে বলে জানা যায়, তাই সংখ্যাগুলো তাদের দাবি হিসেবেই পড়ুন।

এর মানে “serverless খারাপ” নয়। এটি একটি কাজের গল্প, যেখানে বিশাল ডেটা টুকরোগুলোর মাঝে ঘুরছিল। ওই একই টুকরোগুলো ছোট পরিমাণে পরীক্ষার জন্য বেশ ভালো ছিল বলেও বোঝা যায়। নকশা কাজের আকারের সাথে বদলাতে পারে।

Vendor lock-in: কী আসলে আটকে যায়

Lock-in হ্যাঁ বা না নয়, এটি বের হওয়ার দাম। Function-এর ব্যবসার কোড সরানো তুলনামূলক সহজ। আসল আঠা অন্য জায়গায়: event-এর আকৃতি, IAM নিয়ম, workflow-এর ভাষা, NoSQL-এর ডেটা মডেল, আর data gravity.

সব আড়াল করতে গেলে পড়বেন lowest common denominator-এর ফাঁদে, আর আড়ালটিও ফাঁক দিয়ে বেরোবে (leaky abstraction). দীর্ঘ আলোচনা আসছে পর্ব ৭৪-এ। ক্যাটারিংয়ের ঠিকাদার বদলাতে খরচ আছে, তবু আপনি নিশ্চয়ই নিজের জন্য চুলা, বাসন আর পিঁয়াজের গুদাম বানিয়ে ঠিকাদার-ভয় কাটাবেন না।

১০ · AI-এর যুগে serverless নকশা

AI কয়েক সেকেন্ডে পুরো template লিখে দেয়, আর তা deploy-ও হয়ে যায়। কিন্তু serverless-এর ভুল প্রায়ই স্বাভাবিক দিনে দেখা যায় না, ধরা পড়ে retry-র দিনে বা বিলের দিনে। AI-এর সাধারণ ভুলগুলো: function-এর role-এ dynamodb:* আর Resource: "*", public bucket, environment variable-এ secret, অস্তিত্বহীন property, বাতিল runtime, read-then-write “idempotency”, batch-এ partial response ভুলে যাওয়া, একই bucket-এ ফল লেখা, আর খরচের কোনো কথা না বলা। কখনো সে test stack মোছার ধ্বংসাত্মক কমান্ডও কোনো সতর্কতা ছাড়াই দেয়।

AI-এর লেখা serverless template যাচাইয়ের চেকলিস্ট

• প্রতিটি property আর runtime অফিসিয়াল নথিতে মিলিয়েছি, আর template validate করেছি
• Deploy-এর আগে change set বা terraform plan-এর পরিবর্তন পড়েছি
• IAM-এ কোনো * নেই, আর bucket public নয়
• Duplicate event আর নষ্ট বার্তা দিয়ে handler test করেছি
• Trigger আর ফল এক জায়গায় নয়, concurrency-র সীমা আছে, dead-letter queue-তে alert আছে
• Budget alert চালু, আর খরচ নিজে হিসাব করেছি
• কোনো secret prompt-এ দিইনি, আর মোছার কমান্ড আগে পড়ে স্বল্পস্থায়ী পরিবেশে চালিয়েছি