CDN কি কি ডেলিভারি করবে তা নির্ধারণ করুন
ইনভেন্টরি দিয়ে শুরু করুন। ইমেজ, স্টাইলশীট, স্ক্রিপ্ট, ফন্ট, ডাউনলোডের মতো ভার্শন করা অ্যাসেটগুলোকে HTML, API, অ্যাকাউন্ট পেজ, চেকআউট, এবং অ্যাডমিনিস্ট্রেশন থেকে আলাদা করুন। CDNs প্রায়ই অন-ডিমান্ড ক্যাশ পূরণ করে: প্রথম অনুরোধ অরিজিনে পৌঁছাতে পারে, যেখানে পরবর্তী মিলে যাওয়া অনুরোধগুলো এজে সার্ভ করা যেতে পারে। কাছাকাছি এজ এবং একটি ক্যাশ হিট দুইটি আলাদা সুবিধা।
প্রতিটি পাথ সরবরাহকারী হোস্ট, অ্যাপ্লিকেশন, স্টোরেজ বালতি (storage bucket), বা লোড ব্যালান্সার রেকর্ড করুন; ক্যাশ মিস ঘটলে এটি উত্তর দিতে সক্ষম হতে হবে।
প্রতিটি ভিজিটরের জন্যই একই এমন এবং নির্দিষ্ট লাইফটাইম শেষ না হওয়া পর্যন্ত নিরাপদে উপলব্ধ থাকা যায় এমন অ্যাসেট দিয়ে শুরু করুন।
পারসোনালাইজড ড্যাশবোর্ড, সেশন-বন্ধ পেজ, বা কাস্টমার ডেটা শেয়ার করবেন না যদি না একজন যোগ্য ইঞ্জিনিয়ার আলাদা করণ নকশা করে পরীক্ষা করে থাকে।
কনটেন্ট আচরণের ভিত্তিতে ক্যাশ নীতি সেট করুন
HTTP রেসপন্স হেডারগুলো ক্যাশ আচরণ প্রকাশ করে। Cache-Control বলে একটি রেসপন্স সংরক্ষণ করা যাবে কিনা এবং কতদিন তা তাজা থাকবে; TTL (time to live) হল সেই তাজাতা সময়কাল। একটি ব্রাউজার একটি প্রাইভেট ক্যাশ, যেখানে একটি CDN সাধারণত শেয়াড (shared) ক্যাশ। স্পষ্ট হেডার ব্যবহার করুন। HTTP স্ট্যান্ডার্ড s-maxage কে শেয়ার করা ক্যাশের লাইফটাইম আলাদাভাবে নির্ধারণ করার অনুমতি দেয় যা max-age থেকে আলাদা হতে পারে।
কনটেন্ট পরিবর্তন হলে একটি নতুন URL প্রকাশ করুন, যেমন কনটেন্ট-হ্যাশ করা ফাইলনেম, তারপর অপরিবর্তনীয় ভার্সনকে একটি দীর্ঘ নির্দিষ্ট লাইফটাইম দিন।
স্টেইল কনটেন্টের খরচের উপর ভিত্তি করে একটি স্বল্প লাইফটাইম বা ভ্যালিডেশন আচরণ নির্বাচন করুন; দাম, ইনভেন্টরি, বা অ্যাকাউন্ট স্টেটের জন্য একটি অ্যাসেট রুল পুনরায় ব্যবহার করবেন না।
একজন ব্যবহারকারীর জন্য উদ্দেশ্যপ্রণোদিত রেসপন্সের জন্য private ব্যবহার করুন। কুকি থাকলেই একটি রেসপন্স শেয়ারড ক্যাশের জন্য সুরক্ষিত বলে বিবেচিত হয় না।
ইনভ্যালিডেশনকে ব্যপক রিলিজ প্ল্যান বানান না
ইনভ্যালিডেশন বা পার্জিং পরিচালিত CDN-কে সাধারণ মেয়াদ শেষের আগে নির্দিষ্ট সংরক্ষিত অবজেক্টগুলো ফেলে দিতে বলে। তা সংশোধনের জন্য ব্যবহার করুন, প্রতিটি ডেপ্লয়ের জন্য নয়। পার্জ করার আগে নিশ্চিত করুন যে অরিজিন ইতিমধ্যেই প্রতিস্থাপনটি ফেরত দিচ্ছে; নতুবা একটি রিফিল খারাপ রেসপন্স বজায় রাখতে পারে। ব্রাউজার ক্যাশগুলো CDN-এর পার্জ নিয়ন্ত্রণের বাইরে, তাই বদল হওয়া ফাইলগুলির জন্য URL ভার্সনিং নির্ভরযোগ্য থাকে।
সমগ্র সাইট পার্জ করার পরিবর্তে একটি নির্দিষ্ট পাথ, রিলিজ গ্রুপ, বা প্রোভাইডার-সমর্থিত ক্যাশ ট্যাগ বেছে নিন; বিস্তৃত মিস হঠাৎ অরিজিন লোড করতে পারে।
একটি বিতরণকৃত পার্জ সব এজে একসাথে পৌঁছাবে এমনটি নয়। প্রোভাইডারের কমপ্লিশন সেমান্টিক্স চেক করুন এবং একটি প্রতিনিধিত্বকারী URL পরীক্ষা করুন।
পুরানো ও নতুন URL, ক্যাশ রুল, পার্জ স্কোপ, প্রত্যাশিত ফলাফল, এবং উলটানোর ধাপ রেকর্ড করুন।
অরিজিনকে ডেলিভারি লেয়ারের পেছনে রাখতে হবে
ডাইরেক্ট অরিজিন অ্যাক্সেস CDN ক্যাশিং ও এজ কন্ট্রোলগুলো বাইপাস করতে পারে। এটি সীমিত করুন যাতে CDN এবং কেবলই প্রত্যাশিত পাথগুলো এটি অ্যাক্সেস করতে পারে। আপনার স্ট্যাক অনুসারে, ক্লাউড-অরিজিন অ্যাক্সেস কন্ট্রোল, ডকুমেন্টেড CDN ইগ্রেস রেঞ্জসহ ফায়ারওয়াল রুল, প্রাইভেট নেটওয়ার্কিং, সাইনড অরিজিন অনুরোধ, অথবা mTLS (যেখানে উভয় পক্ষ সার্টিফিকেট দিয়ে প্রমাণীকরণ করে) ব্যবহার করুন।
একটি অনুমোদিত টেস্ট লোকেশন থেকে নিশ্চিত করুন যে অরিজিন সাধারণ পাবলিক অনুরোধগুলো বাতিল করছে আর CDN হোস্টনেম কাজ করছে।
হেলথ চেক, ডিপ্লয়মেন্ট টুল, এবং ইন্টারনাল অ্যাক্সেসকে ব্রড পাবলিক রুল না রেখে আইডেন্টিটি ও নেটওয়ার্ক অনুযায়ী স্কোপ করুন।
অরিজিন অথেনটিকেশন CDN ও অরিজিন অনুযায়ী আলাদা। বর্তমান প্রোভাইডার সেটআপ নির্দেশনা ও সিকিউরিটি রিভিউ ব্যবহার করুন।
TLS-কে দুইটি কানেকশনের মতো বিবেচনা করুন
এজে HTTPS ভিজিটর-টু-CDN সংযোগকে সুরক্ষিত করে, কিন্তু CDN-টু-অরিজিন কানেকশনটিকেও সুরক্ষার প্রয়োজন। দুইটি লেগেই এনক্রিপশন বাধ্যতামূলক করুন, CDN মোডের জন্য অরিজিন সার্টিফিকেট ভ্যালিডেট করুন, এবং হোস্টনেম ও রিনিউয়াল দায়িত্ব নির্ধারণ করুন। OWASP ডিফল্ট হিসেবে TLS 1.3 সুপারিশ করে এবং সামঞ্জস্যতার জন্য TLS 1.2 অনুমোদন করে; TLS 1.0 ও 1.1 অক্ষম করার নির্দেশ দেয়। নিয়ন্ত্রিত ডেটা, পেমেন্ট ফ্লো, বা অনন্য ক্লায়েন্ট সামঞ্জস্যতার জন্য যোগ্য পর্যালোচনা নিন।
এজ ও অরিজিন সার্টিফিকেট মালিক, রিনিউয়াল পথ, এবং ব্যর্থতার প্রতিক্রিয়া তালিকাভুক্ত করুন।
HTTP-থেকে-HTTPS, ক্যানোনিক্যাল-হোস্ট, এবং ডিপ-লিংক রিডাইরেক্টগুলো লুপ বা পথ হারানোর জন্য পরীক্ষা করুন।
এনক্রিপশন একটি রেসপন্সকে ক্যাশের জন্য নিরাপদ করে না; অথেনটিকেটেড, পারসোনাল, এবং পেমেন্ট-সংলগ্ন পেজগুলোর জন্য আলাদা ক্যাশ রুল সেট করুন।
ট্রাফিক পরিবর্তনের আগে প্রকৃত ডেলিভারি পাথ পরীক্ষা করুন
স্টেজিং হোস্টনেম বা সংকীর্ণ প্রোডাক্শন পাথ দিয়ে শুরু করুন, তারপর CDN হোস্টনেম পরীক্ষা করুন, কেবল অরিজিন নয়। Chrome DevTools Network অনুরোধের স্ট্যাটাস, ডোমেইন, টায়মিং, সাইজ, ও হেডার দেখায়। প্রথম ভিজিট অনুকরণ করতে একটি খালি-ক্যাশ হাড রিলোড পরীক্ষা করুন, তারপর পুনরাবৃত্ত ভিজিট করে পুনরায় ব্যবহার পরিদর্শন করুন। কেবল দ্রুত দেখানো পেজ নয়, প্রত্যাশিত হেডার ও কনটেন্ট তুলনা করুন। দর্শক বিতরণ বিস্তৃত হলে প্রতিনিধিত্বকারী অঞ্চল থেকে পুনরাবৃত্তি করুন।
Cache-Control এবং প্রোভাইডার cache-status হেডারগুলো পরিদর্শন করুন। পাবলিক অ্যাসেট রিইউজ নিশ্চিত করুন ও সংবেদনশীল পেজগুলো অনাকাঙ্ক্ষিতভাবে শেয়ার হচ্ছে না তা যাচাই করুন।
একটি মিস, স্টেইল-কনটেন্ট করেকশন, অরিজিন ত্রুটি, এবং এক অ্যাসেট বা রুটের রোলব্যাক বিস্তৃত লঞ্চের আগে অনুশীলন করুন।
পরীক্ষিত URL, হেডার ক্যাপচার, রুট-রুল ভার্সন, এবং পরিবর্তনের রেকর্ডসহ আগে-এবং-পরের টাইমিং সংরক্ষণ করুন।
অপারেটিং প্রয়োজনীয়তার ভিত্তিতে CDN নির্বাচন করুন, তারপর প্রমাণ করুন
শুধু পয়েন্ট-অফ-প্রেজেন্স সংখ্যা বা সাধারণ স্পিড দাবি দেখে CDN নির্বাচন করবেন না। পারফরম্যান্স ভৌগলিক, সময়, ট্র্যাফিক ডিস্ট্রিবিউশন, রাউটিং, এবং ক্যাশ হিট রেশিও অনুযায়ী পরিবর্তিত হয়। প্রতিনিধিত্বকারী রুট, অ্যাসেট, ও অঞ্চলগুলোতে প্রার্থীদের তুলনা করুন। জিজ্ঞাসা করুন প্রত্যেকটি আপনার প্রয়োজনীয় ক্যাশ কন্ট্রোল, টার্গেটেড ইনভ্যালিডেশন, অরিজিন সীমাবদ্ধতা, সার্টিফিকেট ওয়ার্কফ্লো, লগ, অ্যাক্সেস রোল, মূল্য, সাপোর্ট, ও পরিবর্তন প্রক্রিয়া সমর্থন করে কিনা।
প্রার্থীদের জন্য এক্সাকটলি একই ক্যাশ হেডার, অরিজিন আচরণ, এবং পেজ ব্যবহার করুন; প্রথম-ভিজিট ও পুনরাবৃত্ত-ভিজিট ফলাফল আলাদাভাবে রেকর্ড করুন।
অনুরোধ, ট্রান্সফার, ইনভ্যালিডেশন, লগিং, এবং সাপোর্ট খরচ, সঙ্গে একটি ক্যাশ-মিস সার্জ পর্যালোচনা করুন। মূল্য ও কন্ট্রোল প্ল্যান অনুযায়ী ভিন্ন হতে পারে।
নির্বাচনের আগে এক্সপোর্টযোগ্য কনফিগারেশন, লিস্ট-অফ-প্রিভিলেজ, পরীক্ষিত রোলব্যাক, এবং পরিষ্কার মালিকানা দাবি করুন বিশেষভাবে গুরুত্বপূর্ণ রুট ঢাকতে।