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

অটো-স্কেলিং ও লোড ব্যালেন্সিং ইন দ্য ক্লাউড

Auto-scaling & load balancing in the cloud
৮ মিনিট পড়া শুরু · Beginner Python কোডসহ সম্পূর্ণ বাংলায়

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

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

১ · অটো-স্কেলিং গ্রুপ — ম্যানুয়াল হস্তক্ষেপ ছাড়াই ভেরিয়েবল লোড সামলানো

L05-এ আমরা দেখেছি হরাইজন্টাল স্কেলিং মানে একই সাইজের আরও ইনস্ট্যান্স যোগ করা। কিন্তু বাস্তব ট্রাফিক প্রতিনিয়ত ওঠানামা করে — ম্যানুয়ালি প্রতিবার ইনস্ট্যান্স যোগ/সরানো অবাস্তব। অটো-স্কেলিং গ্রুপAuto-Scaling Groupএকটি নির্ধারিত মেট্রিক (যেমন CPU ব্যবহার)-এর উপর ভিত্তি করে স্বয়ংক্রিয়ভাবে ইনস্ট্যান্স যোগ বা সরানোর একটি ক্লাউড সার্ভিস — নির্ধারিত সর্বনিম্ন ও সর্বোচ্চ সীমার মধ্যে। এই সমস্যার সমাধান — এটি ক্রমাগত একটি নির্ধারিত মেট্রিক (সাধারণত CPU ব্যবহার) পর্যবেক্ষণ করে এবং প্রয়োজন অনুযায়ী ইনস্ট্যান্স যোগ বা সরায়, সবসময় একটি নির্ধারিত সর্বনিম্ন (min) ও সর্বোচ্চ (max) সীমার মধ্যে থেকে — যাতে খরচ নিয়ন্ত্রণে থাকে (সীমাহীন স্কেল-আপ না হয়) এবং সার্ভিস কখনও সম্পূর্ণ বন্ধ না হয়ে যায় (min-এর নিচে না নামে)।

২ · স্কেলিং পলিসি — কখন, কীভাবে স্কেল করা হবে

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

৩ · লোড ব্যালেন্সার — অটো-স্কেলিং গ্রুপের সঙ্গী

অটো-স্কেলিং গ্রুপ ইনস্ট্যান্স যোগ/সরালেও, ক্লায়েন্ট ট্রাফিক কীভাবে সঠিক, বর্তমানে-সুস্থ ইনস্ট্যান্সে পৌঁছাবে? এই কাজটি করে লোড ব্যালেন্সারLoad Balancerবর্তমান সুস্থ ইনস্ট্যান্স পুলের মধ্যে ইনকামিং ট্রাফিক বিতরণ করা একটি সার্ভিস — অটো-স্কেলিং গ্রুপের সাথে ক্রমাগত সিঙ্কে থাকে। — এটি ক্রমাগত অটো-স্কেলিং গ্রুপের বর্তমান, সুস্থ ইনস্ট্যান্স পুলের একটি লিস্ট রাখে এবং শুধুমাত্র সেই ইনস্ট্যান্সগুলোতে ট্রাফিক পাঠায়। System Design কোর্সে লোড ব্যালেন্সিং-এর অ্যালগরিদম (রাউন্ড-রবিন, লিস্ট-কানেকশন ইত্যাদি) বিস্তারিত কভার করা হয়েছে — এখানে আমাদের মূল ফোকাস ক্লাউড-নির্দিষ্ট কোণ থেকে: লোড ব্যালেন্সার ও অটো-স্কেলিং গ্রুপ একটি জুটি হিসেবে কাজ করে — একটি ক্যাপাসিটি ঠিক করে, অন্যটি সেই ক্যাপাসিটির মধ্যে ট্রাফিক ভাগ করে।

ক্লায়েন্ট ট্রাফিক লোড ব্যালেন্সার ইনস্ট্যান্স ১ ইনস্ট্যান্স ২ ইনস্ট্যান্স N (ASG নিয়ন্ত্রিত)
লোড ব্যালেন্সার ক্লায়েন্ট ট্রাফিক ভাগ করে, অটো-স্কেলিং গ্রুপ (ASG) ডানের ইনস্ট্যান্স পুলের আকার নিয়ন্ত্রণ করে — দুটো ক্রমাগত সিঙ্কে থাকে।

৪ · অটো-স্কেলিং সিদ্ধান্ত সিমুলেশন — Python উদাহরণ

নিচের কোড সেলে আমরা একটি সরল টার্গেট-ট্র্যাকিং স্কেলিং সিদ্ধান্ত ফাংশন লিখব এবং সিমুলেটেড CPU রিডিংয়ের একটি সিরিজের উপর প্রয়োগ করব — দেখব কীভাবে এটি ৬০% টার্গেট CPU-এর কাছাকাছি থাকার চেষ্টা করে।

Python
# সরল টার্গেট-ট্র্যাকিং অটো-স্কেলিং সিদ্ধান্ত সিমুলেশন

def decide_scaling_action(current_instances, cpu_pct, target=60, min_i=2, max_i=10):
    """CPU ব্যবহার টার্গেটের তুলনায় বেশি/কম হলে স্কেল-আপ/ডাউন সিদ্ধান্ত নেয়।"""
    if cpu_pct > target + 15 and current_instances < max_i:
        new_count = min(current_instances + 1, max_i)
        return "scale-up", new_count
    elif cpu_pct < target - 15 and current_instances > min_i:
        new_count = max(current_instances - 1, min_i)
        return "scale-down", new_count
    else:
        return "no-change", current_instances

# সিমুলেটেড CPU রিডিং সময়ের সাথে (illustrative)
cpu_readings = [45, 55, 78, 85, 90, 82, 65, 50, 35, 30, 55, 62]

instances = 3
print(f"{'সময়':6}{'CPU%':8}{'সিদ্ধান্ত':14}{'নতুন ইনস্ট্যান্স সংখ্যা'}")
for tick, cpu in enumerate(cpu_readings):
    action, instances = decide_scaling_action(instances, cpu)
    print(f"{tick:<6}{cpu:<8}{action:14}{instances}")

    
লক্ষ্য করুন — যখন CPU ৭৫%-এর উপরে যায় (৬০% টার্গেট + ১৫% মার্জিন), ফাংশনটি স্কেল-আপ সিদ্ধান্ত নেয়; যখন CPU ৪৫%-এর নিচে নামে, স্কেল-ডাউন হয়; মাঝামাঝি রেঞ্জে কোনো পরিবর্তন হয় না (অপ্রয়োজনীয় "flapping" এড়াতে একটি মার্জিন/বাফার রাখা জরুরি)। এই একই মৌলিক লজিক (একটি মেট্রিক পর্যবেক্ষণ করে সিদ্ধান্ত নেওয়া) M7-এর Kubernetes reconciliation loop-এও (L27) আবার দেখা যাবে।
মূল কথা · Key takeaway

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

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

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

প্র ০১ একটি স্কেলিং পলিসিতে "মার্জিন" বা "বাফার" (যেমন টার্গেট ± ১৫%) না রাখলে কী সমস্যা হতে পারে?

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

প্র ০২ কেন অটো-স্কেলিং গ্রুপে সর্বনিম্ন (min) সংখ্যক ইনস্ট্যান্স রাখা বাধ্যতামূলক, শূন্যে নামতে দেওয়া হয় না?

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

প্র ০৩ শিডিউলড স্কেলিং কেন টার্গেট-ট্র্যাকিং স্কেলিংয়ের চেয়ে কিছু পরিস্থিতিতে বেশি কার্যকর হতে পারে?

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

অনুশীলন

  1. চিন্তা করুন: একটি অনলাইন পরীক্ষার প্ল্যাটফর্ম যেখানে ঠিক জানা সময়ে (যেমন সকাল ১০টায়) হাজার হাজার শিক্ষার্থী একসাথে লগইন করে — কোন স্কেলিং পলিসি (বা পলিসির মিশ্রণ) সবচেয়ে উপযুক্ত হবে বলে মনে করেন?

    শিডিউলড স্কেলিং সবচেয়ে উপযুক্ত হবে প্রাথমিক প্রস্তুতির জন্য (ঠিক পরীক্ষা শুরুর সময়ের আগেই ইনস্ট্যান্স বাড়িয়ে রাখা, যাতে হাজার হাজার লগইনের সময় ক্ষমতার ঘাটতি না হয়), পাশাপাশি টার্গেট-ট্র্যাকিং একটি সেফটি-নেট হিসেবে রাখা যেতে পারে যদি প্রকৃত ট্রাফিক প্রত্যাশার চেয়ে বেশি হয়।

  2. পরীক্ষা করুন: উপরের কোড সেলে `target=60`-কে `target=40`-এ পরিবর্তন করে আবার চালান — সিদ্ধান্তগুলো কীভাবে পরিবর্তিত হয় দেখুন।

    টার্গেট কমালে স্কেল-আপ থ্রেশহোল্ড (target + 15 = 55%) ও স্কেল-ডাউন থ্রেশহোল্ড (target - 15 = 25%) দুটোই নিচে নেমে আসবে — ফলে একই CPU রিডিং সিরিজে আগের চেয়ে বেশিবার স্কেল-আপ সিদ্ধান্ত আসবে, কারণ সিস্টেম এখন কম CPU ব্যবহারেই বাড়তি ক্ষমতা চাইছে — এটি দেখায় টার্গেট ভ্যালু নির্বাচন সরাসরি খরচ ও পারফরম্যান্সের মধ্যে একটি ট্রেড-অফ।

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

আগের পাঠ
ভার্চুয়াল মেশিন ও ইনস্ট্যান্স টাইপ