পাঠ ০৭ · ৫৭-এর মধ্যে · মডিউল ২
Home / Courses / Cloud Computing & DevOps / সার্ভারলেস কম্পিউট

সার্ভারলেস কম্পিউট (FaaS) পরিচিতি

Serverless compute (FaaS) intro
৮ মিনিট পড়া শুরু · Beginner Python কোডসহ সম্পূর্ণ বাংলায়

এই পাঠে যা শিখবেন

  • FaaS আসলে কী এবং কেন এটিকে "সার্ভার-বিহীন" বলা হয় (আসলে সার্ভার আছে, শুধু আপনি সেটি দেখেন/ম্যানেজ করেন না)
  • ইভেন্ট-ট্রিগার মডেল — HTTP রিকোয়েস্ট, ফাইল আপলোড, কিউ মেসেজ কীভাবে একটি ফাংশন চালু করে
  • L05-এর VM ও PaaS-এর সাথে বিলিং ও অপারেশনাল পার্থক্য
  • কখন সার্ভারলেস আদর্শ, কখন নয় — এবং Python দিয়ে একটি বাস্তব কস্ট-ক্রসওভার হিসাব

১ · সার্ভারলেস / FaaS কী

সার্ভারলেস / FaaSFunction as a Serviceএকটিমাত্র ফাংশন লেখেন, প্রোভাইডার সমস্ত ইনফ্রাস্ট্রাকচার (সার্ভার, OS, স্কেলিং) সম্পূর্ণ সামলায় — কোড শুধু একটি ট্রিগারের প্রতিক্রিয়ায় চালু হয়, বিলিং হয় প্রতি ইনভোকেশন/এক্সিকিউশন-টাইম অনুযায়ী। (Function as a Service) মডেলে আপনি একটিমাত্র ফাংশন লেখেন — বাকি সব, সার্ভার প্রভিশনিং থেকে OS প্যাচিং থেকে স্কেলিং পর্যন্ত, প্রোভাইডারের দায়িত্ব। "সার্ভারলেস" নামটি একটু বিভ্রান্তিকর — সার্ভার আসলে আছে, শুধু আপনার কাছে সম্পূর্ণ অদৃশ্য।

ট্রিগার-ভিত্তিক এক্সিকিউশন
কোড শুধুই একটি ইভেন্টের (HTTP রিকোয়েস্ট, ফাইল আপলোড, কিউ মেসেজ) প্রতিক্রিয়ায় চালু হয়।
স্বয়ংক্রিয় স্কেলিং
শূন্য থেকে হাজারো একযোগে ইনভোকেশন পর্যন্ত — নিজে কোনো ASG/লোড ব্যালেন্সার কনফিগার করতে হয় না।
শূন্য আইডল কস্ট
কোনো ইনভোকেশন না হলে কোনো বিল নেই — VM-এর মতো ২৪/৭ চার্জ নেই।
প্রোভাইডার-ম্যানেজড রানটাইম
OS প্যাচিং, রানটাইম আপগ্রেড, আন্ডারলাইং হার্ডওয়্যার — সবকিছুর দায়িত্ব প্রোভাইডারের।

২ · L05-এর VM ও PaaS-এর সাথে পার্থক্য

L05-এ দেখা VM সবসময় চালু থাকে (always-on) — ব্যবহার হোক বা না হোক, প্রতি ঘণ্টায় বিল আসে। PaaS একটু হালকা (OS/রানটাইম প্ল্যাটফর্ম সামলায়), কিন্তু আপনার অ্যাপ্লিকেশন তখনও একটি persistently running প্রসেস হিসেবে চলে, তাই আপটাইমের জন্য বিল আসে। FaaS এই দুটো থেকেই আলাদা — কোনো প্রসেস অলস বসে থাকে না, আপনি শুধু প্রকৃত এক্সিকিউশনের জন্য টাকা দেন।

বিলিং মডেলের মূল পার্থক্য

VM (L05): ঘণ্টাপ্রতি বিল, ব্যবহার হোক বা না হোক — ধরুন মাসে $১৪.৪০ নির্দিষ্ট।
PaaS: অ্যাপ চালু থাকা সময়ের জন্য বিল — এখনও একটি চলমান প্রসেস।
FaaS: শুধু প্রতিটি ইনভোকেশন/এক্সিকিউশন-টাইমের জন্য বিল — আইডল সময়ের কোনো খরচ নেই, কিন্তু ইনভোকেশন সংখ্যা যত বাড়বে, মোট খরচও তত রৈখিকভাবে বাড়বে।

৩ · কোথায় সার্ভারলেস আদর্শ, কোথায় নয়

বিক্ষিপ্ত/অনিয়মিত ট্রাফিক
যে কাজ কখনো ঘন ঘন, কখনো একেবারেই চলে না — VM-কে ২৪/৭ চালু রাখা অপচয়।
ইভেন্ট-ড্রিভেন গ্লু লজিক
একটি সার্ভিসের ইভেন্টকে আরেকটির অ্যাকশনে রূপান্তর করা ছোট ফাংশন।
ব্যাকগ্রাউন্ড জব
শিডিউলড ক্লিনআপ, ছোট ডেটা-প্রসেসিং টাস্ক — যা সবসময় চলার দরকার নেই।
কখন সার্ভারলেস আদর্শ নয়

দীর্ঘস্থায়ী (long-running) বা ক্রমাগত-উচ্চ-ট্রাফিক (steady-high-traffic) ওয়ার্কলোডে সার্ভারলেসের প্রতি- ইনভোকেশন খরচ যোগ হতে হতে একসময় একটি সবসময়-চালু VM-এর নির্দিষ্ট খরচকে ছাড়িয়ে যায় — নিচের কোড সেলে ঠিক এই ক্রসওভার পয়েন্টটি হিসাব করব। এই সিদ্ধান্ত-কাঠামো আরও পূর্ণাঙ্গভাবে L08-এ দেখব।

৪ · খরচ তুলনা — সার্ভারলেস বনাম সবসময়-চালু VM

ধরা যাক একটি সার্ভারলেস ফাংশনের দাম প্রতি ১০ লক্ষ (মিলিয়ন) ইনভোকেশনে $০.২০ (অর্থাৎ প্রতি ইনভোকেশন $০.০০০০০০২), আর একটি সবসময়-চালু VM-এর দাম ঘণ্টাপ্রতি $০.০২ — মাসে (৩০ দিন × ২৪ ঘণ্টা) মোট $১৪.৪০। নিচের কোডে বিভিন্ন মাসিক ইনভোকেশন সংখ্যায় দুটির খরচ তুলনা করে দেখা যাক ঠিক কোথায় সস্তা কোনটা বদলে যায়।

Python
# সার্ভারলেস (per-invocation) বনাম সবসময়-চালু VM (per-hour) — খরচ তুলনা (ইলাস্ট্রেটিভ সংখ্যা)
SERVERLESS_COST_PER_INVOCATION = 0.0000002   # $0.20 প্রতি ১০ লক্ষ (মিলিয়ন) ইনভোকেশন
VM_HOURLY_COST = 0.02                        # সবসময়-চালু VM, প্রতি ঘণ্টা
HOURS_PER_MONTH = 24 * 30
vm_monthly_cost = VM_HOURLY_COST * HOURS_PER_MONTH

monthly_invocation_counts = [10_000, 1_000_000, 10_000_000, 50_000_000, 72_000_000, 100_000_000, 200_000_000]

print(f"{'মাসিক ইনভোকেশন':>18}{'সার্ভারলেস খরচ ($)':>22}{'VM খরচ ($)':>14}   সস্তা কোনটা")
for n in monthly_invocation_counts:
    serverless_cost = n * SERVERLESS_COST_PER_INVOCATION
    if serverless_cost < vm_monthly_cost:
        cheaper = "সার্ভারলেস"
    elif serverless_cost > vm_monthly_cost:
        cheaper = "VM"
    else:
        cheaper = "সমান (ক্রসওভার)"
    print(f"{n:>18,}{serverless_cost:>22.2f}{vm_monthly_cost:>14.2f}   {cheaper}")

crossover_invocations = vm_monthly_cost / SERVERLESS_COST_PER_INVOCATION
print(f"\nক্রসওভার পয়েন্ট: প্রায় {crossover_invocations:,.0f} ইনভোকেশন/মাস")
print("এর নিচে সার্ভারলেস সস্তা, উপরে সবসময়-চালু VM সস্তা।")

    
লক্ষ্য করুন — মাসে ১০ হাজার থেকে ৫ কোটি ইনভোকেশন পর্যন্ত সার্ভারলেসই সস্তা (VM-এর নির্দিষ্ট $১৪.৪০-এর চেয়ে কম), কারণ VM-কে ব্যবহার না করলেও পুরো মাসের জন্য টাকা দিতে হয়। কিন্তু ৭ কোটি ২০ লক্ষ ইনভোকেশনে দুটোর খরচ ঠিক সমান হয়ে যায় ($১৪.৪০) — এটিই ক্রসওভার পয়েন্ট। এর বেশি সুষম, ক্রমাগত-উচ্চ ভলিউমে VM সস্তা হয়ে যায়, কারণ সার্ভারলেসের খরচ ইনভোকেশন সংখ্যার সাথে রৈখিকভাবে বাড়তেই থাকে, কিন্তু VM-এর খরচ নির্দিষ্ট থাকে।
মূল কথা · Key takeaway

সার্ভারলেস "সবসময়ই সস্তা" নয় — এটি বিক্ষিপ্ত/অনিয়মিত-ভলিউম ওয়ার্কলোডে খরচ ও অপারেশনাল বোঝা দুটোই কমায়, কিন্তু ক্রমাগত-উচ্চ ভলিউমে একটি সবসময়-চালু VM প্রায়ই সস্তা হয়ে যায়। সঠিক সিদ্ধান্তের জন্য আপনার আসল ট্রাফিক প্যাটার্ন জানা জরুরি — এই ফ্রেমওয়ার্ক আরও বিস্তারিতভাবে পরবর্তী পাঠ, L08-এ দেখব।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ "সার্ভারলেস"-এ যদি সার্ভার না-ই থাকে, তাহলে কোডটি আসলে কোথায় চলে?

সার্ভার আসলে অবশ্যই আছে — প্রোভাইডারের ডেটা সেন্টারে বাস্তব হার্ডওয়্যারেই কোড চলে। "সার্ভারলেস" নামটির অর্থ হলো আপনি সেই সার্ভার নিজে প্রভিশন, প্যাচ, বা স্কেল করেন না — এটি সম্পূর্ণ আপনার দৃষ্টির আড়ালে প্রোভাইডার সামলায়। নামটি "সার্ভার-ম্যানেজমেন্ট-বিহীন" অর্থে সঠিক, "সার্ভার-বিহীন" অর্থে নয়।

প্র ০২ কেন ক্রমাগত-উচ্চ-ট্রাফিক ওয়ার্কলোডে সার্ভারলেস একসময় VM-এর চেয়ে খরুচে হয়ে যায়?

সার্ভারলেসের খরচ প্রতি-ইনভোকেশন হিসেবে রৈখিকভাবে (linearly) বাড়ে — ইনভোকেশন দ্বিগুণ হলে খরচও দ্বিগুণ। কিন্তু একটি VM-এর খরচ নির্দিষ্ট (ব্যবহার যতই হোক, একই বিল)। তাই কম ভলিউমে VM-এর নির্দিষ্ট খরচ বেশি মনে হয় (কম ব্যবহার করেও পুরো বিল), কিন্তু ভলিউম যথেষ্ট বাড়লে একসময় সার্ভারলেসের ক্রমবর্ধমান রৈখিক খরচ VM-এর নির্দিষ্ট খরচকে ছাড়িয়ে যায় — এটিই ক্রসওভার পয়েন্টের গাণিতিক কারণ।

প্র ০৩ একটি ফাংশন যদি অনেকদিন কল না হয়, তারপর হঠাৎ কল হলে কী সমস্যা হতে পারে বলে মনে হয়?

যেহেতু প্রোভাইডার আইডল ফাংশনের জন্য কোনো পরিবেশ প্রস্তুত রাখে না, হঠাৎ কল আসলে নতুন করে একটি এক্সিকিউশন পরিবেশ শুরু করতে হয় (রানটাইম লোড, ডিপেন্ডেন্সি ইনিশিয়ালাইজেশন) — এতে সামান্য বাড়তি লেটেন্সি যোগ হয়। এই ঘটনাকে "কোল্ড স্টার্ট" বলা হয়, এবং এটি লেটেন্সি-সংবেদনশীল কাজে একটি গুরুত্বপূর্ণ বিবেচ্য বিষয় — M11/L46-এ এটি বিস্তারিত দেখব।

অনুশীলন

  1. চিন্তা করুন: একটি ওয়েবসাইটের "কন্টাক্ট ফর্ম সাবমিশন হ্যান্ডলার" — যা দিনে হয়তো কয়েকবার মাত্র কল হয় — এই কাজের জন্য একটি সবসময়-চালু VM নাকি সার্ভারলেস ফাংশন বেশি যুক্তিসঙ্গত মনে হয়?

    সার্ভারলেস অনেক বেশি যুক্তিসঙ্গত — দিনে মাত্র কয়েকবার কল হওয়া একটি কাজের জন্য একটি VM ২৪ ঘণ্টা চালু রাখা প্রায় সম্পূর্ণ অপচয় (প্রায় সবসময় আইডল থাকবে, তবুও পুরো বিল আসবে)। এই ধরনের বিক্ষিপ্ত, কম-ভলিউম, ইভেন্ট-ট্রিগারড কাজ ঠিক সেই ব্যবহারের ক্ষেত্র যেখানে সার্ভারলেস স্পষ্টভাবে জেতে।

  2. পরীক্ষা করুন: উপরের কোড সেলে SERVERLESS_COST_PER_INVOCATION-এর মান দ্বিগুণ করুন (অর্থাৎ $০.৪০ প্রতি মিলিয়ন) এবং দেখুন নতুন ক্রসওভার পয়েন্ট কত হয় — কেন এটি কমে গেল ব্যাখ্যা করুন।

    প্রতি-ইনভোকেশন দাম দ্বিগুণ হলে ক্রসওভার পয়েন্ট ঠিক অর্ধেক হয়ে যাবে (প্রায় ৩ কোটি ৬০ লক্ষ ইনভোকেশন/মাস) — কারণ VM-এর নির্দিষ্ট মাসিক খরচ ($১৪.৪০) অপরিবর্তিত থাকলেও, এখন প্রতিটি ইনভোকেশনের দাম বেশি হওয়ায় কম ইনভোকেশনেই সার্ভারলেসের মোট খরচ সেই একই সীমায় পৌঁছে যায়। এটি দেখায় ক্রসওভার পয়েন্ট সরাসরি প্রতি-ইনভোকেশন দামের উপর নির্ভরশীল — বাস্তব সিদ্ধান্ত নেওয়ার আগে সবসময় আসল মূল্য যাচাই করা জরুরি।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

আগের পাঠ
L06 · অটো-স্কেলিং ও লোড ব্যালেন্সিং ইন দ্য ক্লাউড