CDN ও এজ ক্যাশিং

CDN & edge caching

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

এক নজরে · TL;DR

CDN মানে বিশ্বজুড়ে ছড়িয়ে থাকা এজ সার্ভারের একটি নেটওয়ার্ক যা স্ট্যাটিক কন্টেন্ট (ছবি, ভিডিও, CSS/JS) ইউজারের কাছাকাছি ক্যাশ করে রাখে — L19-এর ক্যাশিং ধারণাকেই ভৌগোলিকভাবে ছড়িয়ে দেওয়া।
কাজের ধরন: DNS/anycast ইউজারকে সবচেয়ে কাছের এজ সার্ভারে রাউট করে; সেই এজ যদি ইতিমধ্যে কন্টেন্ট ক্যাশ করা থাকে (hit) সরাসরি সার্ভ করে, নাহলে অরিজিন থেকে টেনে ক্যাশ করে (miss, "cold" এজ)।
Pull CDN (প্রথম রিকোয়েস্টে টেনে আনে, বেশি প্রচলিত) বনাম Push CDN (আগে থেকেই আপলোড করে রাখা হয়)।
Python সিমুলেশনে দেখব — অরিজিন-অনলি বনাম CDN-এজ, বিভিন্ন অঞ্চলের ইউজারের গড় লেটেন্সি কতটা কমে যায়।

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

CDN কী এবং কেন স্ট্যাটিক কন্টেন্টের জন্য এটি প্রায় সবসময় ব্যবহার করা হয়
DNS/anycast কীভাবে ইউজারকে নিকটতম এজে রাউট করে এবং cache hit/miss কীভাবে কাজ করে
Push CDN বনাম Pull CDN-এর পার্থক্য
Python দিয়ে অঞ্চলভিত্তিক লেটেন্সি সিমুলেশন — CDN কতটা গড় লেটেন্সি কমায় তা যাচাই

১ · CDN কী এবং কেন দরকার

L19-এ আমরা ক্যাশিং শিখেছি — একটি অ্যাপ সার্ভারের পাশে একটি ক্যাশ রাখা। কিন্তু যদি আপনার ইউজার ঢাকা, লন্ডন, নিউ ইয়র্ক, টোকিও — সব জায়গায় থাকে, আর আপনার অরিজিন সার্ভার শুধু একটি অঞ্চলে (ধরুন সিঙ্গাপুরে) বসানো, তাহলে দূরের ইউজারদের জন্য প্রতিটি রিকোয়েস্ট একটি দীর্ঘ ক্রস-কন্টিনেন্টাল রাউন্ড ট্রিপ (L03-এ আমরা দেখেছিলাম, ~১৫০ms) পার হয়ে আসতে হয় — শুধু একটি ছবি বা CSS ফাইল আনতে। CDNContent Delivery Networkবিশ্বজুড়ে ছড়িয়ে থাকা এজ সার্ভারের একটি নেটওয়ার্ক যা স্ট্যাটিক (এবং কখনো কখনো ডাইনামিক) কন্টেন্ট ইউজারের ভৌগোলিকভাবে কাছাকাছি একটি সার্ভারে ক্যাশ করে রাখে। এই সমস্যার সমাধান করে — কন্টেন্টের কপি ইউজারের কাছাকাছি এজ সার্ভারEdge ServerCDN নেটওয়ার্কের একটি সার্ভার, যা মূল অরিজিন সার্ভার থেকে ভৌগোলিকভাবে দূরে কিন্তু ইউজারের কাছাকাছি বসানো থাকে, এবং কন্টেন্টের একটি ক্যাশড কপি ধরে রাখে। -এ রেখে দেয়, ফলে অধিকাংশ রিকোয়েস্ট এখন অরিজিন সার্ভারOrigin Serverকন্টেন্টের আসল/মূল উৎস সার্ভার — CDN-এর এজ সার্ভারগুলো যেখান থেকে প্রথমবার কন্টেন্ট টেনে আনে। পর্যন্ত যাওয়ারই দরকার পড়ে না।

২ · কীভাবে কাজ করে — DNS/Anycast Routing ও Hit/Miss

ইউজার একটি CDN-চালিত ডোমেইনে রিকোয়েস্ট পাঠালে, DNS/anycast রাউটিং (L05-এর DNS ধারণার একটি বর্ধিত রূপ) স্বয়ংক্রিয়ভাবে ইউজারকে ভৌগোলিকভাবে নিকটতম এজ সার্ভারে পাঠায় — একই ডোমেইনে ভিন্ন অঞ্চলের ইউজার ভিন্ন এজ সার্ভারে পৌঁছায়।

Cache Hit
এজ সার্ভারে কন্টেন্টের কপি ইতিমধ্যে আছে — সরাসরি সার্ভ করে, অরিজিন পর্যন্ত কোনো ট্রিপ লাগে না। দ্রুততম ও সবচেয়ে সাধারণ কেস।

Cache Miss ("Cold" Edge)
এজ সার্ভারে কন্টেন্ট নেই (প্রথম রিকোয়েস্ট বা TTL শেষ হয়ে গেছে) — এজ নিজে অরিজিন থেকে কন্টেন্ট টেনে আনে, ইউজারকে সার্ভ করে, এবং ভবিষ্যতের জন্য নিজে ক্যাশ করে রাখে।

৩ · Push CDN বনাম Pull CDN

Push CDN
কন্টেন্ট আগে থেকেই সক্রিয়ভাবে সব এজ সার্ভারে আপলোড/ছড়িয়ে দেওয়া হয়, প্রথম রিকোয়েস্টের অপেক্ষা না করেই। ছোট, কম পরিবর্তনশীল কন্টেন্ট সেটের জন্য ভালো, কিন্তু ম্যানুয়াল ব্যবস্থাপনা প্রয়োজন।

Pull CDN
কন্টেন্ট শুধু তখনই এজে আসে যখন কোনো ইউজার প্রথমবার সেটি চায় (lazy loading-এর CDN সংস্করণ, L19-এর cache-aside-এর মতোই যুক্তি) — এরপর সেটি সেই এজে ক্যাশড থাকে। বেশি প্রচলিত, কারণ এটি স্বয়ংক্রিয় ও কম ব্যবস্থাপনা লাগে।

Cache miss-এ এজ সার্ভার নিজেই অরিজিন থেকে কন্টেন্ট টেনে ভবিষ্যতের জন্য ক্যাশ করে রাখে — পরের রিকোয়েস্ট থেকে সেটি hit হবে।

৪ · Python-এ লেটেন্সি হ্রাস সিমুলেশন

নিচের কোডে বিভিন্ন অঞ্চলের ইউজারের জন্য "অরিজিন-অনলি" বনাম "CDN-এজ" লেটেন্সি তুলনা করা হয়েছে — যত দূরে অরিজিন, CDN-এর সুবিধা তত বেশি প্রকট।

Python

origin_latency = {   # অরিজিন সার্ভার (ধরুন সিঙ্গাপুরে) পর্যন্ত সরাসরি রাউন্ড-ট্রিপ, ms
    "Dhaka": 180,
    "London": 40,
    "New York": 120,
    "Tokyo": 90,
    "Sydney": 160,
}

cdn_latency = {   # নিকটতম CDN এজ সার্ভার পর্যন্ত রাউন্ড-ট্রিপ, ms
    "Dhaka": 25,
    "London": 8,
    "New York": 12,
    "Tokyo": 10,
    "Sydney": 18,
}

regions = list(origin_latency.keys())

print("অঞ্চল ভিত্তিক লেটেন্সি (ms):")
for r in regions:
    print(f"  {r:10s} Origin-only = {origin_latency[r]:3d}ms   CDN-edge = {cdn_latency[r]:3d}ms")

avg_origin = sum(origin_latency[r] for r in regions) / len(regions)
avg_cdn = sum(cdn_latency[r] for r in regions) / len(regions)
improvement_pct = (1 - avg_cdn / avg_origin) * 100

print(f"\nগড় লেটেন্সি (Origin-only): {avg_origin:.1f}ms")
print(f"গড় লেটেন্সি (CDN-edge):    {avg_cdn:.1f}ms")
print(f"গড় উন্নতি: {improvement_pct:.1f}%")

Run চাপলে দেখবেন গড় লেটেন্সি ১১৮.০ms থেকে কমে ১৪.৬ms-এ নেমে এসেছে — প্রায় ৮৭.৬% উন্নতি। ঢাকার মতো দূরের অঞ্চলের জন্য উন্নতি সবচেয়ে বেশি (১৮০ms → ২৫ms), কারণ CDN ঠিক সেই দূরত্বের সমস্যাটিই সমাধান করে।

মূল কথা · Key takeaway

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

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

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

প্র ০১ Push CDN-এর চেয়ে Pull CDN কেন বাস্তবে বেশি প্রচলিত?

কারণ Pull CDN স্বয়ংক্রিয় — কোন কন্টেন্ট কোথায় জনপ্রিয় হবে তা আগে থেকে অনুমান করে ম্যানুয়ালি আপলোড করার দরকার নেই। এজ সার্ভার নিজেই প্রথম রিকোয়েস্টে কন্টেন্ট টেনে নেয় এবং শুধু যা আসলে চাওয়া হয়েছে তাই ক্যাশ করে — Push CDN-এর মতো অপ্রয়োজনীয় কন্টেন্ট সব এজে ছড়িয়ে রাখার স্টোরেজ অপচয় হয় না। নতুন কন্টেন্ট যোগ করাও সহজ — নতুন ফাইল আপলোডের সাথে সাথেই এজ থেকে পাওয়া যায়, কোনো আলাদা "push" ধাপ ছাড়াই।

প্র ০২ একটি "cold" এজ সার্ভারে প্রথম রিকোয়েস্ট আসলে ঠিক কী ঘটে, এবং সেই প্রথম ইউজারের অভিজ্ঞতা কেমন হয়?

প্রথম রিকোয়েস্টটি একটি cache miss — এজ সার্ভার নিজে অরিজিন সার্ভার পর্যন্ত গিয়ে কন্টেন্ট আনে, তারপর ইউজারকে সার্ভ করে এবং একটি কপি নিজের কাছে রেখে দেয়। তাই সেই প্রথম ইউজার একটি সম্পূর্ণ origin round-trip-এর সমান লেটেন্সি অনুভব করে (CDN-এর সুবিধা তখনও পায়নি) — কিন্তু ওই একই অঞ্চলের পরবর্তী প্রতিটি ইউজার এখন cache hit পাবে এবং দ্রুত সার্ভিস পাবে। এই কারণে খুব কম-ট্রাফিক অঞ্চলে CDN-এর সুবিধা তুলনামূলক কম প্রকট হতে পারে।

প্র ০৩ একটি নিউজ ওয়েবসাইট যদি একটি আর্টিকেল আপডেট করে, কিন্তু সেটি ইতিমধ্যে বিশ্বের ৫০টি এজ সার্ভারে ক্যাশড আছে — এখানে কী সমস্যা তৈরি হতে পারে?

প্রতিটি এজ সার্ভার তার নিজের কপি নিয়ে স্বাধীনভাবে কাজ করে — অরিজিনে পরিবর্তন হলে সেই পরিবর্তন স্বয়ংক্রিয়ভাবে সব ৫০টি এজে পৌঁছায় না। ফলে ভিন্ন ভিন্ন অঞ্চলের ইউজার একই মুহূর্তে ভিন্ন ভিন্ন (কিছু পুরনো, কিছু নতুন) সংস্করণ দেখতে পারে, যতক্ষণ না সেই এজের TTL শেষ হয় বা একটি explicit "cache purge/invalidation" কমান্ড পাঠানো হয় — এটাই ঠিক পরের পাঠের (L21) মূল বিষয়: বিতরণকৃত ক্যাশ জুড়ে invalidation ব্যবস্থাপনা কেন কঠিন।

অনুশীলন

কোড বদলান: উপরের কোড সেলে একটি নতুন অঞ্চল "Dubai" যোগ করুন যার origin latency ১০০ms এবং CDN latency ১৫ms — নতুন গড় লেটেন্সি ও উন্নতির শতাংশ হিসাব করুন।

নতুন origin গড় = (১৮০+৪০+১২০+৯০+১৬০+১০০)/৬ = ৬৯০/৬ ≈ ১১৫.০ms। নতুন CDN গড় = (২৫+৮+১২+১০+১৮+১৫)/৬ = ৮৮/৬ ≈ ১৪.৭ms। উন্নতি ≈ (১ - ১৪.৭/১১৫.০) × ১০০ ≈ ৮৭.২% — দুটি ডিকশনারিতে এন্ট্রি যোগ করে কোড সেলে চালিয়ে মিলিয়ে দেখুন।
সিদ্ধান্ত নিন: একটি ভিডিও স্ট্রিমিং প্ল্যাটফর্মের (L48) জন্য CDN ব্যবহার না করলে কী হতো — ব্যান্ডউইথ, লেটেন্সি ও অরিজিন সার্ভারের লোডের উপর প্রভাব বর্ণনা করুন।

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