রাইট-সাইজিং ও রিসোর্স অপ্টিমাইজেশন
এই পাঠে যা শিখবেন
- রাইট-সাইজিং কী এবং কেন এটি সবচেয়ে সহজ কস্ট-অপ্টিমাইজেশন লিভারগুলোর একটি
- রাইট-সাইজিং-এর জন্য পর্যবেক্ষণ-তুলনা-সিদ্ধান্ত প্রক্রিয়া কীভাবে কাজ করে
- Python দিয়ে একটি রুল-বেসড রাইট-সাইজিং রেকমেন্ডেশন ফাংশন লেখা
- রাইট-সাইজিং কীভাবে L11-এর স্টোরেজ টায়ারিং ও L49-এর রিজার্ভড-ক্যাপাসিটি সিদ্ধান্তের সাথে যুক্ত
১ · রাইট-সাইজিং কী এবং কেন এটি এত গুরুত্বপূর্ণ
রাইট-সাইজিংRight-sizingপ্রভিশন করা রিসোর্স (ইনস্ট্যান্স সাইজ, মেমরি, স্টোরেজ) কে প্রকৃত পর্যবেক্ষিত ব্যবহারের সাথে মেলানো — অনুমানভিত্তিক বা অতিরিক্ত-সতর্ক প্রাথমিক প্রভিশনিং সিদ্ধান্তের বদলে। দলগুলো প্রায়ই "নিরাপদ থাকার জন্য" প্রয়োজনের চেয়ে বড় ইনস্ট্যান্স বেছে নেয় — এবং পরে সেই সিদ্ধান্ত আর কখনো পুনর্বিবেচনা করা হয় না। ফলাফল: এমন রিসোর্স যেগুলোর জন্য প্রতি মাসে টাকা দেওয়া হচ্ছে, কিন্তু ব্যবহার হচ্ছে তার সামান্য অংশ — বিনা কারণে, বিনা সুবিধায় খরচ। এই কারণেই রাইট-সাইজিং একক সবচেয়ে সহজ ও সবচেয়ে বড় কস্ট-অপ্টিমাইজেশন লিভারগুলোর একটি হিসেবে বিবেচিত হয়।
২ · প্রক্রিয়া — পর্যবেক্ষণ, তুলনা, সিদ্ধান্ত
একটি প্রতিনিধিত্বশীল সময়কাল ধরে প্রকৃত ব্যবহার (CPU, মেমরি) মনিটর করুন — L41-এর মেট্রিক্স পুনর্ব্যবহার করে।
পর্যবেক্ষিত পিক ব্যবহারকে প্রভিশন করা ক্যাপাসিটির সাথে তুলনা করুন।
ব্যাপকভাবে আন্ডার-ইউটিলাইজড হলে ডাউনসাইজ করুন, সত্যিই ঝুঁকিপূর্ণভাবে সীমার কাছাকাছি হলে আপসাইজ করুন।
৩ · রুল-বেসড রাইট-সাইজিং রেকমেন্ডেশন
নিচের কোড সেলে একটি সাধারণ নিয়ম প্রয়োগ করা হয়েছে — যদি একটি রিসোর্সের পিক ব্যবহার লক্ষ্য মাত্রার তুলনায় অনেক কম হয় (অর্ধেকেরও কম), সেটি ডাউনসাইজের জন্য চিহ্নিত করা হয়; যদি পিক ব্যবহার ৯০% বা তার বেশি হয় (ক্র্যাশ/ পারফরম্যান্স ডিগ্রেডেশনের ঝুঁকি), সেটি আপসাইজের জন্য চিহ্নিত করা হয়; বাকিগুলো যথাযথভাবে সাইজড বলে গণ্য হয়।
# রুল-বেসড রাইট-সাইজিং রেকমেন্ডেশন (illustrative, কোনো real monitoring API নয়)
resources = {
"web-server-1": {"provisioned_size": "large (8 vCPU)", "observed_peak_utilization_pct": 22},
"web-server-2": {"provisioned_size": "medium (4 vCPU)", "observed_peak_utilization_pct": 68},
"batch-worker-1": {"provisioned_size": "small (2 vCPU)", "observed_peak_utilization_pct": 95},
"cache-node-1": {"provisioned_size": "large (8 vCPU)", "observed_peak_utilization_pct": 71},
}
def recommend_rightsizing(resources, target_utilization_pct=70):
recommendations = {}
for name, info in resources.items():
peak = info["observed_peak_utilization_pct"]
if peak >= 90:
recommendations[name] = "আপসাইজ করুন — ঝুঁকিপূর্ণভাবে সীমার কাছাকাছি"
elif peak <= target_utilization_pct * 0.5:
recommendations[name] = "ডাউনসাইজ করুন — ব্যাপকভাবে আন্ডার-ইউটিলাইজড"
else:
recommendations[name] = "ঠিক আছে — পরিবর্তনের দরকার নেই"
return recommendations
report = recommend_rightsizing(resources, target_utilization_pct=70)
for name, info in resources.items():
print(f"{name:16}পিক ব্যবহার: {info['observed_peak_utilization_pct']:>3}% → {report[name]}")
৪ · রাইট-সাইজিং শুধু কম্পিউট নয় — স্টোরেজ ও কমিটমেন্টেও প্রযোজ্য
একই নীতি L11-এর স্টোরেজ টায়ারিং-এও প্রযোজ্য (কম-অ্যাক্সেস করা ডেটা কেন সবসময় ব্যয়বহুল "হট" টায়ারে রাখা উচিত নয়), এবং L49-এর রিজার্ভড-ক্যাপাসিটি কমিটমেন্টেও — আপনার প্রকৃত, পর্যবেক্ষিত স্থিতিশীল বেসলাইনের চেয়ে বেশি কখনো রিজার্ভ করা উচিত নয়, নাহলে সেই অতিরিক্ত রিজার্ভড ক্যাপাসিটির জন্যও অকারণে টাকা যাবে।
রাইট-সাইজিং একটি এককালীন কাজ নয় — একটি চলমান অনুশীলন। ওয়ার্কলোড সময়ের সাথে বদলায়, তাই নিয়মিত পর্যবেক্ষণ ও পুনর্মূল্যায়ন (M12/L51-এর FinOps রিভিউ সাইকেলের অংশ হিসেবে) ছাড়া আজকের সঠিক সাইজিং কয়েক মাস পরে আবার ভুল হয়ে যেতে পারে।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ "নিরাপদ থাকার জন্য" বড় ইনস্ট্যান্স প্রভিশন করার প্রবণতা ক্র্যাশ প্রতিরোধ করলেও কেন এখনও একটি সমস্যা?
ক্র্যাশ এড়ানোর ইচ্ছা যুক্তিসঙ্গত, কিন্তু "কখনো ব্যবহার না হওয়া অতিরিক্ত ক্যাপাসিটি"-র জন্য প্রতি মাসে টাকা দেওয়া সরাসরি অপচয় — কোনো ঝুঁকি কমানো ছাড়াই শুধু খরচ বাড়ে। সমাধান ক্র্যাশ-ঝুঁকি নেওয়া নয়, বরং প্রকৃত ডেটা (মনিটরিং মেট্রিক্স) দিয়ে সঠিক সাইজ নির্ধারণ করা — যাতে প্রয়োজনীয় নিরাপত্তা মার্জিন বজায় থাকে কিন্তু অকারণ অতিরিক্ত খরচ না হয়।
প্র ০২ শুধু একদিনের বা একটি মুহূর্তের ব্যবহারের ডেটা দেখে রাইট-সাইজিং সিদ্ধান্ত নেওয়া কেন বিপজ্জনক হতে পারে?
একটি একক মুহূর্ত বাস্তব প্যাটার্নের প্রতিনিধিত্ব নাও করতে পারে — হয়তো সেদিন একটি অস্বাভাবিক কম-ট্রাফিক দিন ছিল (ভুলভাবে ডাউনসাইজের সিদ্ধান্ত), অথবা একটি বিশেষ ইভেন্টের কারণে পিক ট্রাফিক ছিল (ভুলভাবে "যথেষ্ট বড়" মনে হওয়া)। একটি প্রতিনিধিত্বশীল সময়কাল — সাপ্তাহিক/মাসিক চক্র, ব্যবসায়িক পিক আওয়ার সহ — পর্যবেক্ষণ করলেই প্রকৃত বেসলাইন ও পিক দুটোই সঠিকভাবে ধরা পড়ে।
প্র ০৩ রাইট-সাইজিং সিদ্ধান্ত কীভাবে L49-এর রিজার্ভড-ইনস্ট্যান্স কমিটমেন্ট সিদ্ধান্তের আগে নেওয়া উচিত, পরে নয়?
রিজার্ভড কমিটমেন্ট ১-৩ বছরের জন্য একটি নির্দিষ্ট ক্যাপাসিটিতে আটকে দেয় — যদি সেই ক্যাপাসিটি রাইট-সাইজিং ছাড়া অনুমানভিত্তিকভাবে বেছে নেওয়া হয় এবং পরে দেখা যায় সেটি ওভার-প্রভিশনড ছিল, তাহলে পুরো কমিটমেন্ট মেয়াদ জুড়ে অতিরিক্ত অব্যবহৃত ক্যাপাসিটির জন্য টাকা দিতে হবে — যা সহজে বদলানো যায় না। তাই আগে রাইট-সাইজিং দিয়ে প্রকৃত বেসলাইন নির্ধারণ করে, তারপর সেই সঠিক সাইজে রিজার্ভ করা উচিত।
অনুশীলন
-
পরিবর্তন করুন: কোড সেলে
target_utilization_pct-কে ৭০ থেকে ৮০-এ বদলান এবং আবার চালান। cache-node-1 (৭১% পিক)-এর সুপারিশ কি বদলায়?ডাউনসাইজের থ্রেশহোল্ড এখন ৮০ × ০.৫ = ৪০% — cache-node-1-এর পিক (৭১%) এখনও ৪০%-এর বেশি, তাই এখনও "ঠিক আছে" থাকবে। কিন্তু target_utilization_pct আরও বাড়ালে (যেমন ১৪০+ — যদিও অবাস্তব) থ্রেশহোল্ড বদলে যেতে পারে। এই অনুশীলন দেখায় "লক্ষ্য মাত্রা" নির্বাচন নিজেই একটি গুরুত্বপূর্ণ, দলের ঝুঁকি-সহনশীলতা প্রতিফলিত করা সিদ্ধান্ত।
-
যোগ করুন:
resourcesডিকশনারিতে একটি নতুন এন্ট্রি"idle-test-server"যোগ করুন যারobserved_peak_utilization_pctমাত্র ৫। এটি কী সুপারিশ পায়?৫% পিক ব্যবহার লক্ষ্য মাত্রার ৫০% থ্রেশহোল্ডের অনেক নিচে, তাই এটি "ডাউনসাইজ করুন" সুপারিশ পাবে। বাস্তবে এত কম ব্যবহার (৫%) প্রায়ই ইঙ্গিত দেয় রিসোর্সটি সম্পূর্ণভাবে বন্ধ বা মুছে ফেলার যোগ্য কিনা তাও পরীক্ষা করা উচিত — শুধু ছোট করা নয়, প্রয়োজনই আছে কিনা তাও প্রশ্ন করা উচিত।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ পরবর্তী পাঠ — FinOps প্র্যাকটিস ও কস্ট মনিটরিং — দেখুন।
- মনিটরিং ও মেট্রিক্স বেসিকস L41 পুনরালোচনা রাইট-সাইজিং সিদ্ধান্তের ভিত্তি হওয়া মেট্রিক্স-সংগ্রহ প্রক্রিয়া আবার দেখুন।
- সব Courses দেখুন ABCL TECH C, C++, Python, Java, JavaScript, DSA, DBMS, Discrete Mathematics, System Design, Cybersecurity ও Cloud Computing & DevOps — সব এক জায়গায়।