Serverless: function lifecycle, cold start ও concurrency
Serverless Architecture
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- Function lifecycle ও statelessness বোঝা
- Cold start ও concurrency budget চিনতে পারা
- Queue-driven PHP কাজের সীমা নির্ধারণ
সমস্যা দিয়ে শুরু
প্রতি রাতে অল্প সময়ের জন্য invoice PDF তৈরি হয়। সারাদিন server idle থাকছে। Function-based execution ব্যবহার করলে idle capacity পরিচালনার কাজ কমতে পারে। কিন্তু checkout traffic spike-এ হাজার function একসঙ্গে database connection খুললে database বন্ধও হতে পারে। Serverless capacity elastic হতে পারে; downstream capacity এবং execution contract একইভাবে সীমাহীন নয়।
সহজ করে বুঝি
Serverless-এ server আছে, তবে provisioning ও lifecycle-এর বড় অংশ platform সামলায়। Function invocation সাধারণত short-lived execution context পায়; local disk বা memory পরের invocation-এ থাকবে ধরে নেওয়া যায় না। Cold start initialization latency যোগ করতে পারে। Timeout, memory, concurrency, payload size ও PHP runtime support platform-specific। PHP চালাতে supported runtime বা container integration দরকার; Laravel core নিজে cloud function provision করে না।
পরিচিত একটি উপমা
দোকানের নিজস্ব সারাদিনের courier-এর বদলে প্রয়োজনমতো courier বুক করার মতো। Delivery না থাকলে লোক বসিয়ে রাখতে হয় না। কিন্তু একসঙ্গে হাজার parcel পাঠাতে চাইলে packing desk ও destination capacity তবু সীমিত থাকে।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart LR U[Upload event] --> Q[Durable queue] Q --> F[PHP function worker] F --> O[Object storage] F --> D[(Invoice database)] F --> X[Failure queue]
Upload event durable queue-তে যায়, সেখান থেকে function কাজ নেয়। Function output object storage-এ এবং status database-এ রাখে। Temporary filesystem শুধু intermediate file-এর জন্য। Failure policy শেষে message আলাদা inspection path-এ যায়। Concurrency cap database connection budget-এর সঙ্গে মিলবে; automatic retry হলে একই invoice duplicate তৈরি ঠেকাতে হবে।
PHP ও Laravel-এ প্রয়োগ
Laravel job-এর handle method fragment; Invoice model-এ unique business identifier আছে এবং output disk configured। বাস্তব cloud adapter, timeout ও queue trigger আলাদা setup। এখানে processing-এর ধারণা দেখানো হয়েছে; retry race ঠেকাতে database state transition বা unique operation record আরও লাগবে।
use App\Models\Invoice;
use Illuminate\Support\Facades\Storage;
$invoice = Invoice::query()->findOrFail($this->invoiceId);
if ($invoice->document_path !== null) {
return;
}
$path = "invoices/{$invoice->id}.txt";
Storage::disk('s3')->put($path, $invoice->number);
$invoice->update(['document_path' => $path]);সুবিধা, সীমাবদ্ধতা ও trade-off
Bursty independent work-এ function operational simplicity দিতে পারে। Steady high usage, long execution বা latency-sensitive synchronous flow-এ সবসময় cost বা performance ভালো হবে না। A warm context optimization, correctness contract নয়। Platform concurrency cap queue latency বাড়ায়, কিন্তু downstream overload ঠেকাতে সাহায্য করে। Pricing-এর invocation, duration ও network অংশ একসঙ্গে হিসাব করুন।
সাধারণ ভুল
- Local disk-এ একমাত্র invoice রাখা।
- Retry মানেই exactly-once execution ধরা।
- Cloud function support ছাড়া PHP source deploy করলেই চলবে ভাবা।
আরও একটু গভীরে
Connection reuse supported runtime-এ উপকারী হলেও leaked tenant state warm execution-এ বিপজ্জনক। Initialization-এ secret fetch ও dependency boot time মাপুন। Long job ছোট resumable chunk-এ ভাঙা যেতে পারে। Checkpoint durable storage-এ রাখুন; provider timeout-এর পরে execution outcome অনিশ্চিত হলে reconciliation দরকার। Provider-specific limits documentation থেকে deployment-এর আগে যাচাই করুন।
মনে রাখুন
Serverless operation ভাগ করে দেয়; state, retries, concurrency ও downstream budget নিজেকেই design করতে হয়।
নিজে চেষ্টা করুন
Invoice generation-এর cold এবং warm latency আলাদা মাপার পরিকল্পনা লিখুন। Database connection budget থেকে concurrency cap নির্ধারণ করুন। একই queue message দুইবার এলে কোন business invariant ভাঙতে পারে তা খুঁজুন।
নিজের বোঝা যাচাই করুন
1. Serverless-এ server নেই?
Server আছে; lifecycle পরিচালনার interface বদলায়। Infrastructure responsibility-এর কিছু অংশ platform নেয়।
2. Local file কি স্থায়ী?
ধরে নেওয়া যাবে না। Durable output external storage-এ রাখুন; ephemeral disk intermediate কাজের উপযোগী।
3. Auto scale কি database-ও scale করে?
না। Function concurrency বাড়লে connection pressure বাড়ে। আলাদা database capacity এবং throttling দরকার।
4. Cold start কী?
নতুন execution environment initialization-এর অতিরিক্ত সময়। বাস্তব runtime ও dependency দিয়ে মাপতে হবে।
5. Retry হলে invoice একবারই হবে?
না। Duplicate বা unknown outcome হতে পারে। Stable business key, conditional update ও reconciliation design দরকার।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।