পাঠ ৪৮ · ৫৭-এর মধ্যে · মডিউল ১১
Home / Courses / Cloud Computing & DevOps / সার্ভারলেস CI/CD

সার্ভারলেস CI/CD ও ডিপ্লয়মেন্ট ফ্রেমওয়ার্ক

Serverless CI/CD & deployment frameworks
৭ মিনিট পড়া মধ্যম · Intermediate Python কোডসহ সম্পূর্ণ বাংলায়

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

  • সার্ভারলেস ডিপ্লয়মেন্ট ফ্রেমওয়ার্কগুলো (Serverless Framework/SAM/CDK-স্টাইল) কী সমস্যা সমাধান করে
  • ফাইন-গ্রেইনড পার-ফাংশন পাইপলাইনের সুবিধা ও ট্রেড-অফ
  • ফাংশন ভার্সন ও অ্যালিয়াসের মাধ্যমে ফাংশন-লেভেলে ক্যানারি ডিপ্লয়মেন্ট কীভাবে কাজ করে
  • Python দিয়ে অ্যালিয়াস-ভিত্তিক ক্যানারি ট্রাফিক-শিফট সিমুলেট করা

১ · সার্ভারলেস ডিপ্লয়মেন্ট টুলিং — একই IaC নীতি, ভিন্ন লক্ষ্যবস্তু

সার্ভারলেস অ্যাপ্লিকেশন ডিপ্লয় করারও নিজস্ব টুলিং প্যাটার্ন আছে (উদাহরণ হিসেবে Serverless Framework, AWS SAM, বা CDK-স্টাইল টুল — প্রোভাইডার-নির্দিষ্ট নাম শুধু উদাহরণ, ধারণাটি সার্বজনীন) — এগুলো M5-এর Infrastructure as CodeIaCইনফ্রাস্ট্রাকচার ম্যানুয়ালি ক্লিক করে না বানিয়ে মেশিন-রিডেবল কনফিগারেশন ফাইলে ডিক্লেয়ার করা — ভার্সন-কন্ট্রোলযোগ্য, রিপিটেবল। নীতিই অনুসরণ করে (ঘোষণামূলক কনফিগারেশন, Git-এ ভার্সন-কন্ট্রোলড, L36-এর GitOps ওয়ার্কফ্লোর সাথে সামঞ্জস্যপূর্ণ) — শুধু লক্ষ্যবস্তু ভিন্ন: পুরো VM/কন্টেইনার নয়, বরং একটি নির্দিষ্ট ফাংশন এবং তার ইভেন্ট-ট্রিগার (HTTP রুট, কিউ সাবস্ক্রিপশন, শিডিউল) কনফিগার করা।

২ · ফাইন-গ্রেইনড পাইপলাইন — সুবিধা ও লুকানো খরচ

যেহেতু একটি একক ফাংশন ছোট, দ্রুত বিল্ড ও ডিপ্লয় হয়, তাই টিমগুলো প্রায়ই পুরো অ্যাপ্লিকেশনের জন্য একটি বড় পাইপলাইনের বদলে প্রতিটি ফাংশনের জন্য আলাদা, স্বাধীন CI/CD পাইপলাইন রাখে — একটি ফাংশন বদলালে শুধু সেটাই রিবিল্ড/রিডিপ্লয় হয়, বাকি অ্যাপ্লিকেশন অপ্রভাবিত থাকে।

সুবিধা
দ্রুত, স্বাধীন ডিপ্লয় — একটি ফাংশনের পরিবর্তন পুরো অ্যাপ রিবিল্ড করতে বাধ্য করে না।
ট্রেড-অফ
শত শত ছোট ফাংশন মানে শত শত পাইপলাইন রক্ষণাবেক্ষণ করতে হতে পারে — অপারেশনাল জটিলতা বাড়ে।

৩ · ভার্সনিং ও অ্যালিয়াস — ফাংশন-লেভেলে ক্যানারি

বেশিরভাগ সার্ভারলেস প্ল্যাটফর্মে একটি ফাংশনের অপরিবর্তনীয় (immutable) ভার্সন প্রকাশ করা যায় (v1, v2...) এবং একটি অ্যালিয়াস (যেমন "production") একটি নির্দিষ্ট ভার্সনের দিকে নির্দেশ করে — প্রকৃত ট্রাফিক সবসময় অ্যালিয়াসে যায়, সরাসরি কোনো ভার্সনে নয়। অ্যালিয়াসকে ধীরে ধীরে v1 থেকে v2-এর দিকে শিফট করলে L37-এর ঠিক একই ক্যানারি/ব্লু-গ্রিন প্যাটার্ন পাওয়া যায় — কিন্তু পুরো সার্ভিসের বদলে একটি একক ফাংশনের গ্রানুলারিটিতে।

Python
# ফাংশন-লেভেল ক্যানারি অ্যালিয়াস সিমুলেশন (illustrative, কোনো real serverless platform নয়)
import random

function_versions = {
    "v1": "স্থিতিশীল বর্তমান ভার্সন",
    "v2": "নতুন ক্যানারি ভার্সন",
}

def route_by_alias(request_id, canary_pct, seed=42):
    # request_id-নির্ভর ডিটারমিনিস্টিক rng, যাতে একই request সবসময় একই ফলাফল দেয়
    rng = random.Random(f"{seed}-{request_id}")
    roll = rng.uniform(0, 100)
    return "v2" if roll < canary_pct else "v1"

def simulate_alias_shift(canary_pct, num_requests=2000, seed=42):
    counts = {"v1": 0, "v2": 0}
    for i in range(num_requests):
        version = route_by_alias(i, canary_pct, seed=seed)
        counts[version] += 1
    return counts

# ধীরে ধীরে অ্যালিয়াস v1 থেকে v2-এর দিকে শিফট করার সিমুলেশন
for pct in [0, 5, 25, 100]:
    result = simulate_alias_shift(pct)
    total = result["v1"] + result["v2"]
    v2_actual_pct = result["v2"] / total * 100
    print(f"অ্যালিয়াস কনফিগ v2={pct:>3}% → প্রকৃত বিতরণ: v1={result['v1']:>4}, v2={result['v2']:>4} ({v2_actual_pct:.1f}%)")

    
লক্ষ্য করুন কনফিগার করা প্রতিটি শতাংশের (০%, ৫%, ২৫%, ১০০%) জন্য প্রকৃত বিতরণ প্রায় সেই শতাংশেই মিলে যায় — একই ডিটারমিনিস্টিক-হ্যাশ পদ্ধতি যা L37-এর ক্যানারি ট্রাফিক-স্প্লিটে ব্যবহৃত হয়েছিল, শুধু এখানে প্রয়োগ করা হচ্ছে একটি নির্দিষ্ট ফাংশনের দুটি ভার্সনের মধ্যে, পুরো সার্ভিসের মধ্যে নয়।
মূল কথা · Key takeaway

সার্ভারলেস ডিপ্লয়মেন্ট এই কোর্সের আগের মডিউলের কোনো নতুন নীতি আবিষ্কার করে না — একই IaC (M5), GitOps (M8/L36) ও ক্যানারি ডিপ্লয়মেন্ট (M8/L37) নীতিগুলোই প্রযোজ্য, শুধু ফাইন-গ্রেইনড ফাংশন-লেভেল গ্রানুলারিটিতে প্রয়োগ করা হয়, যা নিজস্ব স্কেলের অপারেশনাল ট্রেড-অফ নিয়ে আসে।

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

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

প্র ০১ প্রতিটি ফাংশনের জন্য আলাদা CI/CD পাইপলাইন রাখা কেন বাস্তবে একটি সংস্থার জন্য বাড়তি অপারেশনাল বোঝা তৈরি করতে পারে?

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

প্র ০২ ফাংশন-লেভেল অ্যালিয়াস-ভিত্তিক ক্যানারি (এই পাঠ) এবং L37-এর সম্পূর্ণ-সার্ভিস ক্যানারি — এই দুটোর মূল মিল ও পার্থক্য কী?

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

প্র ০৩ সার্ভারলেস IaC কনফিগারেশন কেন অ্যাপ্লিকেশন কোডের মতোই Git-এ ভার্সন-কন্ট্রোলড থাকা উচিত?

M5/L17-L21-এর IaC নীতি অনুযায়ী, ইনফ্রাস্ট্রাকচার/ডিপ্লয়মেন্ট কনফিগারেশন Git-এ থাকলে প্রতিটি পরিবর্তন রিভিউযোগ্য (পুল রিকোয়েস্ট), অডিটেবল (Git হিস্ট্রি), এবং প্রয়োজনে রিভার্টযোগ্য হয়। কেউ যদি সরাসরি কনসোল থেকে একটি ফাংশনের অ্যালিয়াস বা ট্রিগার ম্যানুয়ালি বদলায়, সেটা L20-এর কনফিগারেশন ড্রিফট তৈরি করে — পরবর্তী IaC apply-তে অপ্রত্যাশিতভাবে রিভার্ট বা কনফ্লিক্ট হতে পারে।

অনুশীলন

  1. পরিবর্তন করুন: কোড সেলে ক্যানারি শতাংশের তালিকা [0, 5, 25, 100]-কে [0, 10, 50, 90, 100]-এ বদলান এবং আবার চালান — প্রতিটি ধাপে প্রকৃত বিতরণ কনফিগার করা শতাংশের কতটা কাছাকাছি থাকে লক্ষ্য করুন।

    num_requests=২০০০ যথেষ্ট বড় নমুনা হওয়ায়, প্রতিটি নতুন শতাংশের জন্যও প্রকৃত বিতরণ কনফিগার করা শতাংশের সাথে খুব কাছাকাছি (সাধারণত ১ শতাংশ পয়েন্টের মধ্যে) মিলবে — এটি দেখায় ডিটারমিনিস্টিক-হ্যাশ পদ্ধতিটি যেকোনো শতাংশ মানের জন্যই নির্ভরযোগ্যভাবে কাজ করে, শুধু নির্দিষ্ট কিছু মানের জন্য নয়।

  2. চিন্তা করুন: ক্যানারি চলাকালীন v2-তে error rate হঠাৎ বেড়ে গেলে canary_pct নিয়ে পরবর্তী যুক্তিসঙ্গত পদক্ষেপ কী হওয়া উচিত?

    অ্যালিয়াসকে অবিলম্বে canary_pct=0 (v1-এ ১০০% ট্রাফিক) এ ফিরিয়ে নেওয়া উচিত — এটিই এই প্যাটার্নের বড় সুবিধা, একটি সাধারণ কনফিগারেশন মান বদলে তাৎক্ষণিক রোলব্যাক সম্ভব, নতুন কোড রিডিপ্লয় করার প্রয়োজন নেই। এই সিদ্ধান্তটি M10-এর মনিটরিং/অ্যালার্টিং-এর সাথে স্বয়ংক্রিয়ভাবেও যুক্ত করা যায়।

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

পূর্ববর্তী পাঠ
ইভেন্ট-ড্রিভেন DevOps — মেসেজ কিউ ও ইভেন্ট বাস