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

রাইট-সাইজিং ও রিসোর্স অপ্টিমাইজেশন

Rightsizing & resource optimization
৭ মিনিট পড়া মধ্যম · Intermediate Python কোডসহ সম্পূর্ণ বাংলায়

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

  • রাইট-সাইজিং কী এবং কেন এটি সবচেয়ে সহজ কস্ট-অপ্টিমাইজেশন লিভারগুলোর একটি
  • রাইট-সাইজিং-এর জন্য পর্যবেক্ষণ-তুলনা-সিদ্ধান্ত প্রক্রিয়া কীভাবে কাজ করে
  • Python দিয়ে একটি রুল-বেসড রাইট-সাইজিং রেকমেন্ডেশন ফাংশন লেখা
  • রাইট-সাইজিং কীভাবে L11-এর স্টোরেজ টায়ারিং ও L49-এর রিজার্ভড-ক্যাপাসিটি সিদ্ধান্তের সাথে যুক্ত

১ · রাইট-সাইজিং কী এবং কেন এটি এত গুরুত্বপূর্ণ

রাইট-সাইজিংRight-sizingপ্রভিশন করা রিসোর্স (ইনস্ট্যান্স সাইজ, মেমরি, স্টোরেজ) কে প্রকৃত পর্যবেক্ষিত ব্যবহারের সাথে মেলানো — অনুমানভিত্তিক বা অতিরিক্ত-সতর্ক প্রাথমিক প্রভিশনিং সিদ্ধান্তের বদলে। দলগুলো প্রায়ই "নিরাপদ থাকার জন্য" প্রয়োজনের চেয়ে বড় ইনস্ট্যান্স বেছে নেয় — এবং পরে সেই সিদ্ধান্ত আর কখনো পুনর্বিবেচনা করা হয় না। ফলাফল: এমন রিসোর্স যেগুলোর জন্য প্রতি মাসে টাকা দেওয়া হচ্ছে, কিন্তু ব্যবহার হচ্ছে তার সামান্য অংশ — বিনা কারণে, বিনা সুবিধায় খরচ। এই কারণেই রাইট-সাইজিং একক সবচেয়ে সহজ ও সবচেয়ে বড় কস্ট-অপ্টিমাইজেশন লিভারগুলোর একটি হিসেবে বিবেচিত হয়।

২ · প্রক্রিয়া — পর্যবেক্ষণ, তুলনা, সিদ্ধান্ত

পর্যবেক্ষণ করুন
একটি প্রতিনিধিত্বশীল সময়কাল ধরে প্রকৃত ব্যবহার (CPU, মেমরি) মনিটর করুন — L41-এর মেট্রিক্স পুনর্ব্যবহার করে।
তুলনা করুন
পর্যবেক্ষিত পিক ব্যবহারকে প্রভিশন করা ক্যাপাসিটির সাথে তুলনা করুন।
সিদ্ধান্ত নিন
ব্যাপকভাবে আন্ডার-ইউটিলাইজড হলে ডাউনসাইজ করুন, সত্যিই ঝুঁকিপূর্ণভাবে সীমার কাছাকাছি হলে আপসাইজ করুন।
একটি একক মুহূর্তের রিডিং যথেষ্ট নয় — একটি সংক্ষিপ্ত স্পাইক দেখে ভুলভাবে "উচ্চ ব্যবহার" মনে করা যেতে পারে, অথবা একটি সাময়িক শান্ত সময় দেখে ভুলভাবে "আন্ডার-ইউটিলাইজড" মনে হতে পারে। একটি প্রতিনিধিত্বশীল সময়কাল (যেমন কয়েক সপ্তাহ, ব্যবসায়িক চক্র সহ) ধরে পর্যবেক্ষণ করাই নির্ভরযোগ্য সিদ্ধান্তের ভিত্তি।

৩ · রুল-বেসড রাইট-সাইজিং রেকমেন্ডেশন

নিচের কোড সেলে একটি সাধারণ নিয়ম প্রয়োগ করা হয়েছে — যদি একটি রিসোর্সের পিক ব্যবহার লক্ষ্য মাত্রার তুলনায় অনেক কম হয় (অর্ধেকেরও কম), সেটি ডাউনসাইজের জন্য চিহ্নিত করা হয়; যদি পিক ব্যবহার ৯০% বা তার বেশি হয় (ক্র্যাশ/ পারফরম্যান্স ডিগ্রেডেশনের ঝুঁকি), সেটি আপসাইজের জন্য চিহ্নিত করা হয়; বাকিগুলো যথাযথভাবে সাইজড বলে গণ্য হয়।

Python
# রুল-বেসড রাইট-সাইজিং রেকমেন্ডেশন (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]}")

    
web-server-1 (২২% পিক) ব্যাপকভাবে আন্ডার-ইউটিলাইজড হওয়ায় ডাউনসাইজের সুপারিশ পায়, batch-worker-1 (৯৫% পিক) বিপজ্জনকভাবে সীমার কাছাকাছি হওয়ায় আপসাইজের সুপারিশ পায়, আর web-server-2 (৬৮%) ও cache-node-1 (৭১%) দুটোই যুক্তিসঙ্গত রেঞ্জে থাকায় "ঠিক আছে" হিসেবে চিহ্নিত হয় — কোনো একক থ্রেশহোল্ড নয়, বরং দুই প্রান্তের মাঝের একটি "স্বাস্থ্যকর জোন" শনাক্ত করাই আসল কাজ।

৪ · রাইট-সাইজিং শুধু কম্পিউট নয় — স্টোরেজ ও কমিটমেন্টেও প্রযোজ্য

একই নীতি L11-এর স্টোরেজ টায়ারিং-এও প্রযোজ্য (কম-অ্যাক্সেস করা ডেটা কেন সবসময় ব্যয়বহুল "হট" টায়ারে রাখা উচিত নয়), এবং L49-এর রিজার্ভড-ক্যাপাসিটি কমিটমেন্টেও — আপনার প্রকৃত, পর্যবেক্ষিত স্থিতিশীল বেসলাইনের চেয়ে বেশি কখনো রিজার্ভ করা উচিত নয়, নাহলে সেই অতিরিক্ত রিজার্ভড ক্যাপাসিটির জন্যও অকারণে টাকা যাবে।

মূল কথা · Key takeaway

রাইট-সাইজিং একটি এককালীন কাজ নয় — একটি চলমান অনুশীলন। ওয়ার্কলোড সময়ের সাথে বদলায়, তাই নিয়মিত পর্যবেক্ষণ ও পুনর্মূল্যায়ন (M12/L51-এর FinOps রিভিউ সাইকেলের অংশ হিসেবে) ছাড়া আজকের সঠিক সাইজিং কয়েক মাস পরে আবার ভুল হয়ে যেতে পারে।

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

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

প্র ০১ "নিরাপদ থাকার জন্য" বড় ইনস্ট্যান্স প্রভিশন করার প্রবণতা ক্র্যাশ প্রতিরোধ করলেও কেন এখনও একটি সমস্যা?

ক্র্যাশ এড়ানোর ইচ্ছা যুক্তিসঙ্গত, কিন্তু "কখনো ব্যবহার না হওয়া অতিরিক্ত ক্যাপাসিটি"-র জন্য প্রতি মাসে টাকা দেওয়া সরাসরি অপচয় — কোনো ঝুঁকি কমানো ছাড়াই শুধু খরচ বাড়ে। সমাধান ক্র্যাশ-ঝুঁকি নেওয়া নয়, বরং প্রকৃত ডেটা (মনিটরিং মেট্রিক্স) দিয়ে সঠিক সাইজ নির্ধারণ করা — যাতে প্রয়োজনীয় নিরাপত্তা মার্জিন বজায় থাকে কিন্তু অকারণ অতিরিক্ত খরচ না হয়।

প্র ০২ শুধু একদিনের বা একটি মুহূর্তের ব্যবহারের ডেটা দেখে রাইট-সাইজিং সিদ্ধান্ত নেওয়া কেন বিপজ্জনক হতে পারে?

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

প্র ০৩ রাইট-সাইজিং সিদ্ধান্ত কীভাবে L49-এর রিজার্ভড-ইনস্ট্যান্স কমিটমেন্ট সিদ্ধান্তের আগে নেওয়া উচিত, পরে নয়?

রিজার্ভড কমিটমেন্ট ১-৩ বছরের জন্য একটি নির্দিষ্ট ক্যাপাসিটিতে আটকে দেয় — যদি সেই ক্যাপাসিটি রাইট-সাইজিং ছাড়া অনুমানভিত্তিকভাবে বেছে নেওয়া হয় এবং পরে দেখা যায় সেটি ওভার-প্রভিশনড ছিল, তাহলে পুরো কমিটমেন্ট মেয়াদ জুড়ে অতিরিক্ত অব্যবহৃত ক্যাপাসিটির জন্য টাকা দিতে হবে — যা সহজে বদলানো যায় না। তাই আগে রাইট-সাইজিং দিয়ে প্রকৃত বেসলাইন নির্ধারণ করে, তারপর সেই সঠিক সাইজে রিজার্ভ করা উচিত।

অনুশীলন

  1. পরিবর্তন করুন: কোড সেলে target_utilization_pct-কে ৭০ থেকে ৮০-এ বদলান এবং আবার চালান। cache-node-1 (৭১% পিক)-এর সুপারিশ কি বদলায়?

    ডাউনসাইজের থ্রেশহোল্ড এখন ৮০ × ০.৫ = ৪০% — cache-node-1-এর পিক (৭১%) এখনও ৪০%-এর বেশি, তাই এখনও "ঠিক আছে" থাকবে। কিন্তু target_utilization_pct আরও বাড়ালে (যেমন ১৪০+ — যদিও অবাস্তব) থ্রেশহোল্ড বদলে যেতে পারে। এই অনুশীলন দেখায় "লক্ষ্য মাত্রা" নির্বাচন নিজেই একটি গুরুত্বপূর্ণ, দলের ঝুঁকি-সহনশীলতা প্রতিফলিত করা সিদ্ধান্ত।

  2. যোগ করুন: resources ডিকশনারিতে একটি নতুন এন্ট্রি "idle-test-server" যোগ করুন যার observed_peak_utilization_pct মাত্র ৫। এটি কী সুপারিশ পায়?

    ৫% পিক ব্যবহার লক্ষ্য মাত্রার ৫০% থ্রেশহোল্ডের অনেক নিচে, তাই এটি "ডাউনসাইজ করুন" সুপারিশ পাবে। বাস্তবে এত কম ব্যবহার (৫%) প্রায়ই ইঙ্গিত দেয় রিসোর্সটি সম্পূর্ণভাবে বন্ধ বা মুছে ফেলার যোগ্য কিনা তাও পরীক্ষা করা উচিত — শুধু ছোট করা নয়, প্রয়োজনই আছে কিনা তাও প্রশ্ন করা উচিত।

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

পূর্ববর্তী পাঠ
ক্লাউড বিলিং মডেল — অন-ডিমান্ড, রিজার্ভড, স্পট