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

ক্লাউডে DNS ও সার্ভিস ডিসকভারি

DNS & service discovery in the cloud
৭ মিনিট পড়া শুরু · Beginner Python কোডসহ সম্পূর্ণ বাংলায়

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

  • ম্যানেজড DNS সার্ভিসের উন্নত রাউটিং ফিচারগুলো — স্বাস্থ্য-চেক ফেইলওভার, লেটেন্সি-বেসড, ওয়েটেড রাউটিং
  • প্রাইভেট/ইন্টারনাল DNS কীভাবে ক্লাউড-নেটিভ সার্ভিস ডিসকভারি সম্ভব করে
  • ওয়েটেড রাউটিং কীভাবে ক্যানারি রিলিজের ভিত্তি তৈরি করে
  • Python দিয়ে একটি ওয়েটেড DNS রাউটিং সিমুলেশন এবং বিতরণ যাচাই

১ · ম্যানেজড DNS সার্ভিস — শুধু রেকর্ড হোস্টিং নয়

একটি ম্যানেজড DNS সার্ভিসManaged DNS Serviceএকটি ক্লাউড-হোস্টেড DNS সার্ভিস যা ডোমেইন রেকর্ড হোস্টিং ছাড়াও উন্নত রাউটিং ফিচার দেয় — স্বাস্থ্য-চেক ফেইলওভার, লেটেন্সি-বেসড ও ওয়েটেড রাউটিং। আপনার ডোমেইনের DNS রেকর্ড হোস্ট করে, কিন্তু আধুনিক ক্লাউড DNS সার্ভিস এর চেয়ে অনেক বেশি কিছু দেয় —

স্বাস্থ্য-চেক ফেইলওভার
একটি এন্ডপয়েন্ট অসুস্থ হলে স্বয়ংক্রিয়ভাবে DNS রেসপন্স আরেকটি সুস্থ এন্ডপয়েন্টে পাল্টে যায়।
লেটেন্সি-বেসড রাউটিং
ব্যবহারকারীকে ভৌগোলিকভাবে সবচেয়ে কাছের রিজিয়নে রাউট করে সর্বনিম্ন ল্যাটেন্সি নিশ্চিত করে।
ওয়েটেড রাউটিং
নির্দিষ্ট শতাংশ ট্রাফিক ভিন্ন ভিন্ন ব্যাকএন্ড ভার্সনে পাঠায় — ক্যানারি রিলিজের DNS-স্তরের বাস্তবায়ন (ties to L37)।

২ · প্রাইভেট/ইন্টারনাল DNS — ক্লাউড-নেটিভ সার্ভিস ডিসকভারি

একটি VPC-এর ভেতরে, ইনস্ট্যান্স বা পড ক্রমাগত তৈরি ও ধ্বংস হতে পারে — প্রতিবার তাদের নতুন IP অ্যাড্রেস হার্ডকোড করে অন্য সার্ভিসকে জানানো অবাস্তব। প্রাইভেট/ইন্টারনাল DNS সার্ভিসগুলোকে নাম দিয়ে একে অপরকে খুঁজে পেতে দেয় — একটি সার্ভিস "order-service" নামে অন্য সার্ভিসকে কল করে, তার আসল IP কী তা জানার প্রয়োজন নেই। এটিই M7-এ দেখা Kubernetes-এর নিজস্ব অভ্যন্তরীণ DNS-এর ভিত্তি ধারণা।

কেন এটি ডাইনামিক পরিবেশে জরুরি

ঐতিহ্যবাহী স্ট্যাটিক ইনফ্রাস্ট্রাকচারে সার্ভারের IP মাসের পর মাস অপরিবর্তিত থাকতে পারত। ক্লাউডে অটো-স্কেলিং (L06) ও কন্টেইনার অর্কেস্ট্রেশনের (M7) কারণে ইনস্ট্যান্স/পড প্রতিনিয়ত তৈরি ও ধ্বংস হয় — প্রতিটির নতুন IP থাকে। নাম-ভিত্তিক ডিসকভারি ছাড়া এই ডাইনামিক পরিবেশে কাজ করা কার্যত অসম্ভব হতো।

৩ · সিমুলেশন — ওয়েটেড DNS রাউটিং

নিচে একটি ওয়েটেড রাউটিং সিমুলেশন — তিনটি ব্যাকএন্ড, প্রতিটির একটি নির্দিষ্ট ওয়েট (percentage weight)। একটি ফিক্সড-সিড random generator বহুবার চালিয়ে দেখা যায় প্রকৃত বিতরণ কনফিগার্ড ওয়েটের কতটা কাছাকাছি আসে।

Python
# ওয়েটেড DNS রাউটিং সিমুলেশন (ফিক্সড সিড — reproducible ফলাফল)
import random

backends = [
    ("10.0.1.10", 70),   # স্থিতিশীল ভার্সন — ৭০% ট্রাফিক
    ("10.0.1.20", 20),   # ক্যানারি ভার্সন — ২০% ট্রাফিক
    ("10.0.1.30", 10),   # পরীক্ষামূলক ভার্সন — ১০% ট্রাফিক
]

def weighted_choice(backends, rng):
    total_weight = sum(weight for _, weight in backends)
    pick = rng.uniform(0, total_weight)
    cumulative = 0
    for ip, weight in backends:
        cumulative += weight
        if pick <= cumulative:
            return ip
    return backends[-1][0]

rng = random.Random(42)   # ফিক্সড সিড, কখনো unseeded random নয়
counts = {ip: 0 for ip, _ in backends}
trials = 10_000

for _ in range(trials):
    chosen = weighted_choice(backends, rng)
    counts[chosen] += 1

print(f"{'ব্যাকএন্ড IP':16}{'কনফিগার্ড ওয়েট':18}{'প্রকৃত বিতরণ'}")
for ip, weight in backends:
    pct = counts[ip] / trials * 100
    print(f"{ip:16}{weight:<18}{pct:.1f}%")

    
১০,০০০ বার চালানোর পর প্রতিটি ব্যাকএন্ডের প্রকৃত বিতরণ কনফিগার্ড ওয়েটের (৭০%/২০%/১০%) খুব কাছাকাছি আসে — এটিই নিশ্চিত করে ওয়েটেড রাউটিং লজিক সঠিকভাবে কাজ করছে। বাস্তবে একই কৌশল ব্যবহার করে একটি ক্যানারি রিলিজে ধীরে ধীরে ওয়েট বাড়ানো হয় (L37-এর ক্যানারি ডিপ্লয়মেন্ট স্ট্র্যাটেজি)।

৪ · Kubernetes ও System Design কোর্সের সাথে সম্পর্ক

এই পাঠের ইন্টারনাল DNS ধারণাটি M7-এ Kubernetes-এর নিজস্ব সার্ভিস ডিসকভারি প্রক্রিয়ায় সরাসরি পুনরায় ব্যবহৃত হবে, আর লেটেন্সি-বেসড রাউটিং ও ফেইলওভারের গভীর স্থাপত্যগত আলোচনা System Design কোর্সে আছে।

মূল কথা · Key takeaway

ক্লাউড DNS শুধু ডোমেইন রেজোলিউশনের চেয়ে অনেক বেশি — এটি স্বাস্থ্য-সচেতন ফেইলওভার, ভৌগোলিক রাউটিং ও ক্যানারি রিলিজের হাতিয়ার হয়ে ওঠে, আর প্রাইভেট DNS ডাইনামিক ক্লাউড পরিবেশে সার্ভিসগুলোকে একে অপরকে নাম দিয়ে খুঁজে পেতে দেয়, হার্ডকোডেড IP-এর ভঙ্গুরতা ছাড়াই।

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

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

প্র ০১ ওয়েটেড DNS রাউটিং ব্যবহার করে একটি ৫% ক্যানারি রিলিজ শুরু করলে, নতুন ভার্সনে সমস্যা পাওয়া গেলে কীভাবে দ্রুত প্রতিক্রিয়া জানানো যায়?

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

প্র ০২ একটি গ্লোবাল অ্যাপ্লিকেশনের জন্য লেটেন্সি-বেসড রাউটিং ছাড়া শুধু একটি সিঙ্গেল-রিজিয়ন ডিপ্লয়মেন্ট রাখলে কী সমস্যা হতে পারে?

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

প্র ০৩ প্রাইভেট DNS ছাড়া, একটি Kubernetes-এর মতো ডাইনামিক পরিবেশে সার্ভিসগুলো কীভাবে একে অপরকে খুঁজে পেত (এবং কেন সেটি সমস্যাযুক্ত হতো)?

হার্ডকোডেড IP অ্যাড্রেসের একটি তালিকা রাখতে হতো, যা প্রতিবার একটি পড রিস্টার্ট বা রিশিডিউল হলে (নতুন IP পেয়ে) অকেজো হয়ে যেত — কনফিগারেশন ম্যানুয়ালি আপডেট করতে হতো প্রতিটি পরিবর্তনে, যা ডাইনামিক, ক্রমাগত-পরিবর্তনশীল পরিবেশে কার্যত অচল একটি পদ্ধতি।

অনুশীলন

  1. চিন্তা করুন: একটি অ্যাপ্লিকেশনের কোন পরিস্থিতিতে ওয়েটেড রাউটিং, লেটেন্সি-বেসড রাউটিং, এবং স্বাস্থ্য-চেক ফেইলওভার — এই তিনটির মধ্যে কোনটি সবচেয়ে বেশি প্রাসঙ্গিক হবে বলে মনে হয়?

    একটি নতুন ফিচার ধীরে ধীরে রোলআউট করার সময় ওয়েটেড রাউটিং প্রাসঙ্গিক; একটি গ্লোবাল ব্যবহারকারী বেস থাকা অ্যাপ্লিকেশনের জন্য লেটেন্সি-বেসড রাউটিং প্রাসঙ্গিক; আর একটি প্রাইমারি/ব্যাকআপ ডেটা সেন্টার আর্কিটেকচারের জন্য স্বাস্থ্য-চেক ফেইলওভার প্রাসঙ্গিক — বাস্তবে একটি পরিণত সিস্টেম প্রায়ই তিনটিই একসাথে ব্যবহার করে।

  2. পরীক্ষা করুন: উপরের কোড সেলে backends তালিকার ওয়েট পরিবর্তন করে (50, 30, 20) করুন এবং trials সংখ্যা 1000-এ নামিয়ে ফলাফল দেখুন।

    প্রকৃত বিতরণ নতুন কনফিগার্ড ওয়েট (৫০%/৩০%/২০%) অনুসরণ করবে, কিন্তু কম trials সংখ্যার (১০০০ বনাম ১০,০০০) কারণে প্রতিটি পারসেন্টেজে সামান্য বেশি ওঠানামা দেখা যাবে — এটি দেখায় বড় স্যাম্পল সাইজ কেন কনফিগার্ড ওয়েটের কাছাকাছি, আরও স্থিতিশীল ফলাফল দেয়।

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

আগের পাঠ
ক্লাউডে লোড ব্যালেন্সার ও CDN