ক্লাউড বিলিং মডেল — অন-ডিমান্ড, রিজার্ভড, স্পট
এই পাঠে যা শিখবেন
- অন-ডিমান্ড, রিজার্ভড ও স্পট প্রাইসিং মডেলের সংজ্ঞা এবং প্রতিটির উপযুক্ত ব্যবহার-ক্ষেত্র
- কেন স্পট ইনস্ট্যান্স শুধুমাত্র ফল্ট-টলারেন্ট, ইন্টারাপ্টযোগ্য ওয়ার্কলোডের জন্য উপযুক্ত, কখনোই ক্রিটিক্যাল/স্টেটফুল সার্ভিসের জন্য নয়
- Python দিয়ে একই ওয়ার্কলোডের জন্য তিনটি মডেলের প্রকৃত মাসিক খরচ গণনা করে তুলনা করা
- এই সিদ্ধান্তগুলো কীভাবে M12-এর FinOps ও রাইট-সাইজিং প্র্যাকটিসের ভিত্তি তৈরি করে
১ · অন-ডিমান্ড — সর্বোচ্চ ফ্লেক্সিবিলিটি, সর্বোচ্চ মূল্য
অন-ডিমান্ডOn-Demandকোনো আগাম কমিটমেন্ট ছাড়া প্রতি ঘণ্টা/সেকেন্ডের ব্যবহারের জন্য পূর্ণ তালিকাভুক্ত মূল্য পরিশোধ করা — যেকোনো সময় শুরু বা বন্ধ করা যায়। হলো সবচেয়ে সহজ ও ফ্লেক্সিবল মডেল — যতক্ষণ ব্যবহার করবেন ততক্ষণের জন্যই বিল হয়, কোনো দীর্ঘমেয়াদী প্রতিশ্রুতি লাগে না। কিন্তু এই ফ্লেক্সিবিলিটির বিনিময়ে ইউনিট-প্রতি (প্রতি ঘণ্টা) মূল্য সবচেয়ে বেশি — অনিশ্চিত বা স্বল্পমেয়াদী ওয়ার্কলোডের জন্য এটিই সঠিক বেছে নেওয়া, কিন্তু দীর্ঘমেয়াদী, স্থিতিশীল ওয়ার্কলোডে এটি সবচেয়ে ব্যয়বহুল বিকল্প।
২ · রিজার্ভড/কমিটেড-ইউজ — প্রতিশ্রুতির বিনিময়ে ছাড়
রিজার্ভড ইনস্ট্যান্সReserved / Committed-Use১-৩ বছরের জন্য একটি নির্দিষ্ট পরিমাণ ক্যাপাসিটি ব্যবহারের অগ্রিম প্রতিশ্রুতি — বিনিময়ে অন-ডিমান্ডের তুলনায় উল্লেখযোগ্য ছাড় (সাধারণত ৩০-৬০%+)। পাওয়া যায় যখন আপনি অগ্রিম প্রতিশ্রুতি দেন যে ১-৩ বছর ধরে একটি নির্দিষ্ট ক্যাপাসিটি ব্যবহার করবেন। এটি একটি ফ্ল্যাট, কমিটেড মাসিক রেট — যুক্তিসঙ্গত শুধু তখনই যখন আপনি নিশ্চিত জানেন একটি বেসলাইন ওয়ার্কলোড দীর্ঘ সময় ধরে অবিরাম চলবে (যেমন একটি প্রোডাকশন ডেটাবেস বা কোর API সার্ভার) — অপ্রত্যাশিত/স্পাইকি ট্রাফিকের জন্য নয়।
৩ · স্পট/প্রিএম্পটিবল — সর্বোচ্চ ছাড়, কিন্তু কোনো গ্যারান্টি নেই
স্পট ইনস্ট্যান্সSpot / Preemptibleপ্রোভাইডারের বর্তমানে-অব্যবহৃত ক্যাপাসিটিতে বিশাল ছাড়ে (প্রায়ই ৬০-৯০% অফ) বিড করা — কিন্তু প্রোভাইডার সেই ক্যাপাসিটি অন্য কারো প্রয়োজনে সামান্য নোটিসে ফিরিয়ে নিতে পারে (ইনস্ট্যান্স রিক্লেইম/টার্মিনেট হয়ে যায়)। সবচেয়ে সস্তা প্রতি-ঘণ্টা রেট দেয়, কিন্তু কোনো availability গ্যারান্টি নেই। তাই এটি শুধুমাত্র ফল্ট-টলারেন্ট, ইন্টারাপ্টযোগ্য ওয়ার্কলোডের জন্য উপযুক্ত — ব্যাচ প্রসেসিং, CI/CD বিল্ড রানার, স্টেটলেস ওয়ার্কার যারা সহজেই অন্য কোথাও রিট্রাই করতে পারে। কখনোই স্টেটফুল বা সবসময়-চালু-থাকা ক্রিটিক্যাল সার্ভিসের জন্য নয় — একটি স্পট ইনস্ট্যান্স হঠাৎ হারিয়ে গেলে এমন সার্ভিস downtime তৈরি করবে।
একটি নির্দিষ্ট প্রাইসিং মডেলের মাসিক খরচ মোটামুটি এভাবে হিসাব করা যায় — মাসিক খরচ $= r \times h \times (1 - d)$, যেখানে $r$ হলো অন-ডিমান্ড প্রতি-ঘণ্টা রেট, $h$ মাসিক ঘণ্টা সংখ্যা (প্রায় ৭৩০), আর $d$ সেই মডেলের ছাড়ের হার — স্পট-এর ক্ষেত্রে ইন্টারাপশনজনিত পুনরায়-শুরু/রিট্রাই ওভারহেডের কারণে বাড়তি কার্যকর ঘণ্টা যোগ করতে হয়।
৪ · একই ওয়ার্কলোডের জন্য তিনটি মডেল — খরচ গণনা
নিচের কোড সেলে একটি একক, কাল্পনিক ওয়ার্কলোড (একটি ব্যাচ-প্রসেসিং সার্ভার, মাসে গড়ে ৭৩০ ঘণ্টা চলে) তিনটি প্রাইসিং মডেলে চালানোর ইলাস্ট্রেটিভ খরচ গণনা করা হয়েছে। স্পট-এর ক্ষেত্রে ইন্টারাপশনের কারণে কাজ পুনরায় শুরু/রিট্রাই করতে অতিরিক্ত ১৫% কার্যকর সময় ধরা হয়েছে — বাস্তবে ইন্টারাপশন ওভারহেড ওয়ার্কলোডভেদে ভিন্ন হতে পারে, কিন্তু নীতিগতভাবে স্পট সবসময়ই কিছু বাড়তি ব্যবহারিক খরচ বহন করে যা কাঁচা প্রতি-ঘণ্টা ছাড়ের সংখ্যায় দেখা যায় না।
# একই ওয়ার্কলোডের জন্য অন-ডিমান্ড, রিজার্ভড ও স্পট প্রাইসিং তুলনা (illustrative, কোনো real cloud বিলিং API নয়)
hours_per_month = 730 # গড় মাসিক ঘণ্টা (২৪ × ৩০.৪২)
on_demand_hourly = 0.10 # $/ঘণ্টা, কোনো কমিটমেন্ট ছাড়া
reserved_discount_pct = 40 # ১-৩ বছরের কমিটমেন্টে ছাড়
spot_discount_pct = 75 # অব্যবহৃত ক্যাপাসিটিতে ছাড়
interruption_overhead_pct = 15 # ইন্টারাপশনের পর পুনরায় শুরু/রিট্রাই করার কারণে বাড়তি কার্যকর সময়
on_demand_monthly = on_demand_hourly * hours_per_month
reserved_hourly = on_demand_hourly * (1 - reserved_discount_pct / 100)
reserved_monthly = reserved_hourly * hours_per_month # ফ্ল্যাট, কমিটেড রেট
spot_hourly = on_demand_hourly * (1 - spot_discount_pct / 100)
effective_spot_hours = hours_per_month * (1 + interruption_overhead_pct / 100)
spot_monthly = spot_hourly * effective_spot_hours
def savings_pct(monthly):
return (on_demand_monthly - monthly) / on_demand_monthly * 100
print(f"{'মডেল':24}{'মাসিক খরচ ($)':16}{'অন-ডিমান্ডের তুলনায় সাশ্রয়'}")
print(f"{'অন-ডিমান্ড':24}{on_demand_monthly:<16.2f}{'—'}")
print(f"{'রিজার্ভড (কমিটেড)':24}{reserved_monthly:<16.2f}{savings_pct(reserved_monthly):.1f}%")
print(f"{'স্পট (ইন্টারাপশনসহ)':24}{spot_monthly:<16.2f}{savings_pct(spot_monthly):.1f}%")
৫ · সিদ্ধান্ত নেওয়ার সাধারণ নীতি
অনিশ্চিত, স্বল্পমেয়াদী, বা প্রথমবার পরীক্ষা করা হচ্ছে এমন ওয়ার্কলোড।
জানা, স্থিতিশীল বেসলাইন — যা আপনি নিশ্চিত জানেন মাসের পর মাস অবিরাম চলবে।
ফল্ট-টলারেন্ট, ইন্টারাপ্টযোগ্য ব্যাচ/CI-CD ওয়ার্কার — কখনোই স্টেটফুল ক্রিটিক্যাল সার্ভিস নয়।
তিনটি প্রাইসিং মডেলের কোনোটিই সর্বজনীনভাবে "সেরা" নয় — সঠিক পছন্দ নির্ভর করে ওয়ার্কলোডের পূর্বানুমানযোগ্যতা ও ইন্টারাপশন-সহনশীলতার ওপর। বাস্তব প্রোডাকশন সিস্টেম প্রায়ই তিনটির মিশ্রণ ব্যবহার করে — বেসলাইনের জন্য রিজার্ভড, বাড়তি/স্পাইক ক্যাপাসিটির জন্য অন-ডিমান্ড, আর ব্যাচ/CI ওয়ার্কলোডের জন্য স্পট।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ একটি টিম যদি তাদের পুরো প্রোডাকশন ডেটাবেস স্পট ইনস্ট্যান্সে চালানোর সিদ্ধান্ত নেয় শুধু খরচ কমানোর জন্য, এটি কেন একটি ঝুঁকিপূর্ণ সিদ্ধান্ত?
স্পট ইনস্ট্যান্স যেকোনো সময় সামান্য নোটিসে প্রোভাইডার ফিরিয়ে নিতে পারে — একটি স্টেটফুল ডেটাবেসের জন্য এর মানে হঠাৎ সার্ভিস বন্ধ হয়ে যাওয়া, সম্ভাব্য ডেটা কোরাপশন (যদি ঠিকমতো গ্রেসফুল শাটডাউন না হয়), এবং ব্যবহারকারীদের জন্য downtime। খরচ সাশ্রয় স্টেটলেস, সহজে-রিট্রাইযোগ্য ওয়ার্কলোডের জন্য যৌক্তিক, কিন্তু ক্রিটিক্যাল স্টেটফুল সার্ভিসের জন্য এই ঝুঁকি সাশ্রয়ের চেয়ে অনেক বেশি ব্যয়বহুল হতে পারে (একটি আউটেজের প্রকৃত ব্যবসায়িক খরচ প্রায়ই বাঁচানো ক্লাউড বিলের চেয়ে বহুগুণ বেশি)।
প্র ০২ একটি টিম ১-বছরের রিজার্ভড ইনস্ট্যান্সে কমিট করার আগে কী পরীক্ষা করা উচিত, যাতে তারা প্রয়োজনের চেয়ে বেশি রিজার্ভ না করে?
কমিট করার আগে ঐতিহাসিক ব্যবহারের ডেটা (কমপক্ষে কয়েক মাসের) দেখে প্রকৃত, ধারাবাহিক বেসলাইন লোড নির্ধারণ করা উচিত — শুধু বর্তমান পিক ক্যাপাসিটির ভিত্তিতে নয়। এটি সরাসরি L50-এর রাইট-সাইজিং প্র্যাকটিসের সাথে সম্পর্কিত — আপনার প্রকৃত স্থিতিশীল বেসলাইনের চেয়ে বেশি রিজার্ভ করলে অব্যবহৃত রিজার্ভড ক্যাপাসিটির জন্যও টাকা দিতে হবে, যা রিজার্ভড মডেলের পুরো সাশ্রয়ের সুবিধাকেই নষ্ট করে দিতে পারে।
প্র ০৩ স্পট ইনস্ট্যান্সের "কাঁচা ছাড়" (৭৫%) আর "প্রকৃত সাশ্রয়" (~৭১%, ইন্টারাপশন-ওভারহেড ধরে) — এই দুটোর মধ্যে পার্থক্য কেন গুরুত্বপূর্ণ?
শুধু কাঁচা ঘণ্টা-প্রতি ছাড়ের সংখ্যা দেখলে সাশ্রয়কে বাস্তবের চেয়ে বেশি আশাবাদী মনে হতে পারে — ইন্টারাপশনের কারণে কাজ পুনরায় শুরু করা, চেকপয়েন্ট থেকে রিজিউম করা, বা ব্যর্থ কাজ আবার চালানোর বাড়তি কম্পিউট-সময় বাস্তব খরচ যোগ করে। একজন FinOps-সচেতন ইঞ্জিনিয়ার সবসময় এই "কার্যকর ব্যবহারিক খরচ" হিসাব করেন, শুধু প্রোভাইডারের প্রকাশিত ছাড়ের শতাংশের ওপর নির্ভর করেন না।
অনুশীলন
-
পরিবর্তন করুন: কোড সেলে
interruption_overhead_pct-কে ১৫ থেকে ৪০-এ বদলান (একটি বেশি ইন্টারাপশন-প্রবণ ওয়ার্কলোড ধরে নিন) এবং আবার চালান। স্পট এখনও রিজার্ভডের চেয়ে সস্তা থাকে কি?overhead ৪০% করলে effective_spot_hours = ৭৩০ × ১.৪ = ১০২২ ঘণ্টা, আর spot_monthly = ০.০২৫ × ১০২২ = $২৫.৫৫ — এখনও রিজার্ভডের ($৪৩.৮০) চেয়ে সস্তা, কিন্তু আগের তুলনায় (২০.৯৯) ব্যবধান কমে গেছে। এটি দেখায় ইন্টারাপশন-ওভারহেড যথেষ্ট বেড়ে গেলে স্পটের সাশ্রয়ের সুবিধা কমতে থাকে — একটি নির্দিষ্ট overhead-এর পর রিজার্ভড আসলে সস্তা হয়ে যেতে পারে, তাই বাস্তব ওয়ার্কলোডের প্রকৃত ইন্টারাপশন-হার জানা গুরুত্বপূর্ণ।
-
চিন্তা করুন: একটি ওয়েবসাইটের ফ্রন্টএন্ড সার্ভার (যার ট্রাফিক দিনের বেলা বেশি, রাতে কম কিন্তু কখনো শূন্য নয়) — এর জন্য তিনটি মডেলের কী মিশ্রণ যুক্তিসঙ্গত মনে হয়?
যেহেতু ট্রাফিক কখনো শূন্য হয় না, একটি বেসলাইন ক্যাপাসিটি (রাতের সর্বনিম্ন লোড মেটানোর মতো) রিজার্ভড ইনস্ট্যান্সে রাখা যুক্তিসঙ্গত (নিশ্চিত সাশ্রয়), আর দিনের অতিরিক্ত/স্পাইক ট্রাফিক অন-ডিমান্ড (বা L06-এর অটো-স্কেলিং গ্রুপ) দিয়ে মেটানো যায়। স্পট এখানে ঝুঁকিপূর্ণ, কারণ ফ্রন্টএন্ড সার্ভার সরাসরি ব্যবহারকারীর রিকোয়েস্ট সার্ভ করে — হঠাৎ ইন্টারাপশন সরাসরি ব্যবহারকারীর অভিজ্ঞতা নষ্ট করবে।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ পরবর্তী পাঠ — রাইট-সাইজিং ও রিসোর্স অপ্টিমাইজেশন — দেখুন।
- ক্লাউড ইকোনমিক্স — CapEx বনাম OpEx L03 পুনরালোচনা অন-ডিমান্ড/OpEx মডেলের মৌলিক অর্থনীতি আবার দেখুন।
- সব Courses দেখুন ABCL TECH C, C++, Python, Java, JavaScript, DSA, DBMS, Discrete Mathematics, System Design, Cybersecurity ও Cloud Computing & DevOps — সব এক জায়গায়।