3.15 ক্যাশিং ও কন্টেন্ট ডেলিভারি

পরিচিতি ও প্রেরণা

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

এই অধ্যায় ক্যাশিং কৌশলে গভীরে যায়। অধ্যায় 3.4 (ডেটা স্থাপত্য ও সংরক্ষণ) ক্যাশ ও কন্টেন্ট ডেলিভারি নেটওয়ার্ককে অনেক সংরক্ষণ উদ্বেগের একটি হিসেবে পরিচয় করায়, এবং অধ্যায় 3.13 (নেটওয়ার্কিং ও সংযোগ) যে নেটওয়ার্ক পথে তারা চলে তা কভার করে। এখানে আপনি পান সিদ্ধান্ত: একটি ক্যাশ কোথায় বসাবেন, কীভাবে কী করবেন, কখন অকার্যকর করবেন, লোডের অধীনে কীভাবে রক্ষা করবেন, এবং গতির বিনিময়ে যে বাসিভাব দিচ্ছেন তা নিয়ে কীভাবে যুক্তি করবেন। ক্যাশিং ছোঁয় পারফরম্যান্স প্রকৌশল (অধ্যায় 2.16), স্কেলেবিলিটি ও স্থিতিস্থাপকতা (অধ্যায় 3.5), বিতরিত সিস্টেমের আংশিক-ব্যর্থতা বাস্তবতা (অধ্যায় 3.3), এবং যেহেতু একটি বিষাক্ত ক্যাশ হাজার ব্যবহারকারীকে আক্রমণ সেবা দিতে পারে, অ্যাপ্লিকেশন নিরাপত্তা (অধ্যায় 4.2)।

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

মূল নীতিসমূহ

• লেটেন্সি, লোড ও খরচ কাটতে ক্যাশ করুন, এবং জানুন আপনি কোনটি কিনছেন।
• ক্যাশ শ্রেণিবিন্যাসের সঠিক স্তরে রাখুন, যেখানে সবচেয়ে বেশি সাহায্য করে তার সবচেয়ে কাছে।
• অকার্যকরকরণকে কঠিন অংশ গণ্য করুন; ক্যাশ করার আগে কী ও জীবনকাল নকশা করুন।
• সংযুক্তি, জিটার ও স্ট্যাম্পিড প্রতিরক্ষা দিয়ে লোডের অধীনে ক্যাশ রক্ষা করুন।
• লেখার প্যাটার্ন সুচিন্তিতভাবে বাছুন: সামঞ্জস্য ও গতি পরস্পরের বিরুদ্ধে টানে।
• হিট রেট, বাসিভাব ও অরিজিন লোড মাপুন; অমাপা ক্যাশ একটি দায়।
• ক্যাশ করা কন্টেন্টকে আক্রমণ-পৃষ্ঠ গণ্য করুন; একটি বিষাক্ত ক্যাশ সবাইকে সেবা দেয়।

সুপারিশ

ক্যাশ শ্রেণিবিন্যাস বুঝুন

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

প্রতিটি স্তর ভিন্ন কাজ করে: ক্লায়েন্ট ক্যাশ অনুরোধই বাতিল করে, CDN বৈশ্বিক পড়ার ট্রাফিক শোষণ করে, রিভার্স প্রক্সি আপনার অরিজিনকে পুনরাবৃত্ত অভিন্ন কাজ থেকে ঢাকে, অ্যাপ্লিকেশন ক্যাশ পুনঃগণনা বাঁচায়, এবং ডেটাবেস ক্যাশ স্টোরকে সাড়াদায়ী রাখে। একটি অনুরোধ যা প্রতিটি স্তরে মিস করে ডেটাবেসে পৌঁছায় তা আপনার সবচেয়ে ধীর, সবচেয়ে ব্যয়বহুল পথ, তাই শ্রেণিবিন্যাসের উদ্দেশ্য আপনি নিরাপদে যতদূর সম্ভব ওপরে ও বাইরে উত্তর দেওয়া। একে সিস্টেম হিসেবে নকশা করুন, কারণ অ্যাপ্লিকেশন স্তরে একটি ক্যাশ করা খণ্ড এবং তার ওপরের একটি বাসি CDN কপি এমনভাবে দ্বিমত করতে পারে যা ব্যবহারকারীদের বিভ্রান্ত করে।

অকার্যকরকরণকে কঠিন সমস্যা গণ্য করুন

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

বেশিরভাগ প্রকৃত সিস্টেম এগুলো মেশায়: যে ডেটা প্রায়ই বদলায় এবং সেকেন্ডের বাসিভাব সহ্য করে তার জন্য ছোট TTL, যে ডেটা কদাচিৎ বদলায় কিন্তু বদলালে সঠিক হতে হবে তার জন্য দীর্ঘ TTL ও সুস্পষ্ট পার্জ, এবং প্রকাশের পরে অপরিবর্তনীয় কন্টেন্টের জন্য সংস্করণযুক্ত ক্যাশ কী। সংস্করণযুক্ত-কী কৌশল আত্মস্থ করার যোগ্য: অকার্যকর করার বদলে আপনি কী বদলান। app.v187.css হিসেবে সেবা পাওয়া একটি স্টাইলশিট কখনো পার্জ করতে হয় না, কারণ একটি নতুন সংস্করণ একটি নতুন কী এবং পুরোনোটি কেবল অনুরোধ হওয়া বন্ধ করে। যখনই একটি অকার্যকরকরণ সমস্যাকে নামকরণ সমস্যায় পরিণত করতে পারেন, তা করুন।

ক্যাশ কী ও TTL সুচিন্তিতভাবে নকশা করুন

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

TTL একই চিন্তা প্রাপ্য। TTL হলো আপনি সর্বোচ্চ যে বাসিভাব সেবা দেবেন সে সম্পর্কে একটি প্রতিশ্রুতি, তাই কেউ আন্দাজ করা একটি গোল সংখ্যা নয়, ডেটার প্রকৃত সহনশীলতা থেকে ঠিক করুন: একটি স্টক টিকার সেকেন্ড সহ্য করে, একটি পণ্য ক্যাটালগ মিনিট, একটি প্রকাশিত বিধি ঘণ্টা বা একটি সংস্করণযুক্ত কী এবং কোনো মেয়াদই নয়। একটি ছোট এলোমেলো ছড়ানো, যাকে জিটার বলে, যোগ করুন যাতে একসঙ্গে লেখা এন্ট্রির একটি ব্যাচ সবই একই মুহূর্তে মেয়াদোত্তীর্ণ হয়ে অরিজিনে স্ট্যাম্পিড না করে। এই পছন্দ লিখে রাখুন, কারণ যুক্তিহীন একটি TTL এমন সংখ্যা যা পরবর্তী ইঞ্জিনিয়ার বদলাতে ভয় পাবেন।

স্ট্যাম্পিড থেকে রক্ষা করুন এবং অনুরোধ সংযুক্ত করুন

একটি জনপ্রিয় ক্যাশ করা এন্ট্রি মেয়াদোত্তীর্ণ হলে যে প্রতিটি অনুরোধ তা চেয়েছিল একসঙ্গে মিস করে এবং একসঙ্গে অরিজিনে ছুটে যায়। এটি ক্যাশ স্ট্যাম্পিড, থান্ডারিং হার্ডও বলা হয়, এবং ক্যাশ যে ডেটাবেস রক্ষা করছিল সেটিকেই উল্টে ফেলতে পারে। প্রতিরক্ষা একবার গড়ুন এবং সর্বত্র পুনর্ব্যবহার করুন। অনুরোধ সংযুক্তি (সিঙ্গল-ফ্লাইট) একটি অনুপস্থিত কী-র জন্য শুধু প্রথম অনুরোধকে মান পুনঃগণনা করতে দেয় আর অন্যরা তার ফলের জন্য অপেক্ষা করে, তাই এক হাজার একযোগ মিস একটি অরিজিন কল ঘটায়। সম্ভাব্যতা-ভিত্তিক আগাম পুনঃগণনা একটি গরম এন্ট্রি মেয়াদোত্তীর্ণ হওয়ার সামান্য আগে এলোমেলোভাবে রিফ্রেশ করে, যাতে ভিড় একটি মিস দেখার আগে একটি ব্যাকগ্রাউন্ড অনুরোধ তা নবায়ন করে। একটি stale-while-revalidate নীতি সামান্য বাসি কপি তাৎক্ষণিক সেবা দেয় এবং অ্যাসিনক্রোনাসভাবে রিফ্রেশ করে, তাই ব্যবহারকারীরা মিসের জন্য কখনো অপেক্ষা করে না।

এই প্যাটার্ন সবচেয়ে গুরুত্বপূর্ণ ঠিক যখন আপনার ক্যাশ সবচেয়ে বেশি দরকার, সর্বোচ্চ লোডে, তাই বাস্তবসম্মত পরিসরে সেগুলো যাচাই করুন: দশজন ব্যবহারকারীতে কাজ করা প্রতিরক্ষা দশ হাজারে তবু ব্যর্থ হতে পারে। এগুলো অধ্যায় 3.5-এর স্থিতিস্থাপকতা প্যাটার্নের সঙ্গে জোড়ুন, বিশেষত টাইমআউট ও সার্কিট ব্রেকার, যাতে অরিজিন সত্যিই ধীর হলে আপনার ক্যাশ স্তর তার ওপর জমে না গিয়ে তাকে ঢাকে। লক্ষ্য এমন একটি ক্যাশ যা চাপের মধ্যে সবচেয়ে ভালো আচরণ করে, এমন নয় যা একটি স্পাইককে বিভ্রাটে বাড়ায়।

লেখার প্যাটার্ন সুচিন্তিতভাবে বাছুন

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

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

আপনার অ্যাক্সেস প্যাটার্নের সঙ্গে উচ্ছেদ নীতি মেলান

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

নীতি আপনার ডেটা কীভাবে অ্যাক্সেস হয় তার সঙ্গে মেলান: কদাচিৎ সরা ছোট গরম সেটের জন্য LFU বা ফ্রিকোয়েন্সি-সচেতন নীতি, যেখানে জনপ্রিয়তা সময়ের সঙ্গে সরে, যেমন সংবাদ বা ট্রেন্ডিং কন্টেন্ট, সেখানে LRU। যা-ই বাছুন, ক্যাশের আকার এমন করুন যাতে গরম সেট ধরে, কারণ কর্মরত সেট ধরে রাখতে অক্ষম খুব ছোট ক্যাশ থ্র্যাশ করে, ঠিক আবার দরকার হওয়ার আগে এন্ট্রি উচ্ছেদ করে। উচ্ছেদ হার প্রথম-শ্রেণির মেট্রিক হিসেবে দেখুন, কারণ আকস্মিক বৃদ্ধি সাধারণত মানে ক্যাশ অতিক্ষুদ্র বা কী বিস্ফোরণ একে খণ্ডিত করছে।

HTTP ক্যাশিং শব্দার্থ সঠিকভাবে ব্যবহার করুন

ওয়েবের একটি পরিণত, প্রমিত ক্যাশিং মডেল HTTP-তে গাঁথা, এবং তা ভালোভাবে ব্যবহার আপনাকে বিনামূল্যে ক্লায়েন্ট ও CDN ক্যাশিং দেয়। Cache-Control হেডার নিয়ন্ত্রণ পৃষ্ঠ: max-age সতেজতা জীবনকাল ঠিক করে, public ও private বলে ভাগ করা ক্যাশ সাড়া সংরক্ষণ করতে পারবে কি না, no-store ক্যাশিং নিষিদ্ধ করে, এবং stale-while-revalidate রিফ্রেশ করার সময় একটি বাসি কপি সেবা দিতে দেয়। যাচাইকরণ একটি ক্যাশকে বডি পুনরায় না এনে সস্তায় সতেজতা পরীক্ষা করতে দেয়। একটি ETag (এন্টিটি ট্যাগ) হলো সার্ভারের সাড়ায় জুড়ে দেওয়া একটি অস্বচ্ছ সংস্করণ শনাক্তকারী; ক্লায়েন্ট তা If-None-Match হেডারে ফেরত পাঠায়, এবং কিছু না বদলালে সার্ভার বডি ছাড়া 304 Not Modified দিয়ে উত্তর দেয়। Last-Modified সঙ্গে If-Modified-Since টাইমস্ট্যাম্প দিয়ে একই করে।

ব্যবহারিক শৃঙ্খলা হলো সুস্পষ্ট থাকা। ক্যাশকে হিউরিস্টিক দিয়ে আন্দাজ করতে না দিয়ে প্রতিটি সাড়ায় Cache-Control ঠিক করুন। ব্যক্তিগত, প্রতি-ব্যবহারকারী সাড়াকে private বা no-store চিহ্নিত করুন যাতে ভাগ করা প্রক্সি কখনো সেগুলো সংরক্ষণ না করে, একটি সাধারণ ও বিপজ্জনক ভুল। স্থির সম্পদের জন্য দীর্ঘ max-age ও immutable নির্দেশসহ সংস্করণযুক্ত URL, এবং অপ্রত্যাশিতভাবে বদলানো কন্টেন্টের জন্য ETag-সহ যাচাইকরণ ব্যবহার করুন। এই হেডার ঠিক করা পুরো ক্লায়েন্ট ও CDN স্তরকে একটি সঠিক, মান-ভিত্তিক ক্যাশে পরিণত করে যা আপনাকে গড়তে হয়নি।

CDN ও এজ কম্পিউটিং দিয়ে কাজ প্রান্তে ঠেলুন

একটি CDN শুরু হয়েছিল ব্যবহারকারীদের কাছে স্থির ফাইল ক্যাশ করার উপায় হিসেবে, এবং তা এখনো চমৎকারভাবে করে: দূরের অরিজিনের বদলে মিলিসেকেন্ড দূরের এজ অবস্থান থেকে সেবা পাওয়া ছবি, স্ক্রিপ্ট, ভিডিও ও ডাউনলোড। আধুনিক CDN আরও এগোয়। এগুলো সূক্ষ্ম-কণা কী দিয়ে গতিশীল ও ব্যক্তিগতকৃত কন্টেন্ট ক্যাশ করে, প্রান্তে TLS টার্মিনেট করে, ট্রাফিক স্পাইক ও বিতরিত পরিষেবা-অস্বীকার আক্রমণ শোষণ করে, এবং ক্রমশ আপনার কোড চালায়। এজ কম্পিউটিং যুক্তি এজ অবস্থানেই নির্বাহ করে, তাই আপনি কেন্দ্রীয় অঞ্চলে রাউন্ড ট্রিপ ছাড়াই একটি সাড়া ব্যক্তিগতকৃত করতে, অনুমোদন পরীক্ষা করতে বা পাতার খণ্ড জোড়া দিতে পারেন।

বেশিরভাগ সিস্টেমে প্রাধান্য পাওয়া পড়ার জন্য এর ওপর ভর করুন। স্থির সম্পদ দীর্ঘ-জীবনের সংস্করণযুক্ত URL সহ CDN-এর পেছনে রাখুন, যেখানে সতেজতা অনুমতি দেয় সেখানে এজে API সাড়া ক্যাশ করুন (সাবধানে কী করে যাতে ব্যক্তিগতকরণ ফাঁস না হয়), এবং ব্যবহারকারীদের কাছে লেটেন্সি-সংবেদনশীল, হালকা যুক্তির জন্য এজ কম্পিউট ব্যবহার করুন। বিনিময় হলো পৌঁছ বনাম নিয়ন্ত্রণ: এজ দ্রুত ও কাছে কিন্তু আপনার ডেটা থেকে দূরে ও ডিবাগ করা কঠিনতর, তাই শক্তিশালী সামঞ্জস্য বা সতেজ কর্তৃত্বপূর্ণ অবস্থা দরকার এমন যেকোনো কিছু অরিজিনে রাখুন এবং এজকে বিশাল, ক্যাশযোগ্য পড়ার ট্রাফিক সামলাতে দিন।

ক্যাশকে আক্রমণ-পৃষ্ঠ গণ্য করুন

একটি ক্যাশ অনেক ব্যবহারকারীকে একই সংরক্ষিত সাড়া সেবা দেয়, যা এটিকে লক্ষ্যবস্তু করে। ক্যাশ বিষক্রিয়া এমন আক্রমণ যেখানে একটি অনুরোধ এমনভাবে কৌশলে বানানো হয় যে ক্যাশ একটি ক্ষতিকর বা আক্রমণকারী-নিয়ন্ত্রিত সাড়া সংরক্ষণ করে এবং তারপর যে-ই আসে তাকে সেবা দেয়। এটি সাধারণত একটি অকী-করা ইনপুট কাজে লাগায়: একটি হেডার যা অ্যাপ্লিকেশন সাড়ায় প্রতিফলিত করে কিন্তু ক্যাশ কী গড়ার সময় উপেক্ষা করে। সম্পর্কিত ওয়েব ক্যাশ প্রতারণা আক্রমণ একটি ক্যাশকে ভুলিয়ে একজন শিকারের ব্যক্তিগত সাড়া একটি পাবলিক URL-এর অধীনে সংরক্ষণ করায়। দুটিই কী-করণ ও ইনপুটে বিশ্বাসের ব্যর্থতা, অধ্যায় 4.2-এ আরও বিস্তৃতভাবে কভার করা।

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

ক্যাশ আচরণ পর্যবেক্ষণযোগ্য করুন

যে ক্যাশ দেখতে পান না তা পরিচালনা করতে পারেন না। শিরোনাম মেট্রিক হলো হিট রেট: অরিজিনের বদলে ক্যাশ থেকে সেবা পাওয়া অনুরোধের ভগ্নাংশ। নিঃশব্দে ৯৫ থেকে ৭০ শতাংশে নামা একটি হিট রেট অরিজিন লোড কয়েক গুণ করতে এবং বিভ্রাটের আগে ঘটতে পারে, এবং আপনি তা আগে ধরবেন কেবল যদি লক্ষ্য রাখেন। প্রতিটি স্তর আলাদাভাবে যন্ত্রসজ্জা করুন, কারণ একটি সুস্থ CDN হিট রেট নিচের ভেঙে পড়া অ্যাপ্লিকেশন-ক্যাশ হিট রেট লুকাতে পারে। এটি অধ্যায় 9.2-এর অবজার্ভেবিলিটি চর্চার ক্যাশিং-নির্দিষ্ট মুখ।

হিটের বাইরেও অনুসরণ করুন: অতিক্ষুদ্রতা ধরতে উচ্ছেদ হার ও মেমরি চাপ, ক্যাশ আসলে দ্রুত তা নিশ্চিত করতে প্রতিটি স্তরে লেটেন্সি, ক্যাশ কতটা লোড শোষণ করে দেখতে অরিজিন অনুরোধ হার, এবং আপনি সতেজতা প্রতিশ্রুতি মানছেন নিশ্চিত করতে বাসিভাব (সেবা করা এন্ট্রি কত পুরোনো)। যে অনুপাত ঝামেলার পূর্বাভাস দেয়, বিশেষত পড়ন্ত হিট রেট বা বাড়ন্ত উচ্ছেদ হার, তাতে অ্যালার্ট দিন যাতে আপনি অবনত ক্যাশ সম্পর্কে ব্যবহারকারীদের থেকে নয়, একটি ড্যাশবোর্ড থেকে জানেন। পর্যবেক্ষিত ক্যাশ এমন সম্পদ যা আপনি টিউন করতে পারেন; অপর্যবেক্ষিতটি চমকে দেওয়ার অপেক্ষায় থাকা লুকানো নির্ভরতা।

ট্রেড-অফ: সুবিধা ও অসুবিধা

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

পছন্দ	সুবিধা	অসুবিধা
ক্যাশ-অ্যাসাইড	সরল; কেবল যা পড়া হয় তা ক্যাশ করে	প্রথম পড়া সবসময় মিস করে; লেখার পরে সংক্ষিপ্ত বাসিভাবের ঝুঁকি
রাইট-থ্রু	লেখায় ক্যাশ সবসময় বর্তমান	ধীরতর লেখা; কখনো না-পড়া ডেটা ক্যাশ করে
রাইট-ব্যাক	অত্যন্ত দ্রুত লেখা; বিস্ফোরণ শোষণ করে	ফ্লাশের আগে ক্যাশ ব্যর্থ হলে ডেটা হারানোর ঝুঁকি
রাইট-অ্যারাউন্ড	লেখা-ভারী ডেটায় ক্যাশ মন্থন এড়ায়	প্রথম পড়ায় নিশ্চিত মিস
ছোট TTL	সীমিত, ছোট বাসিভাব	কম হিট রেট; বেশি অরিজিন লোড
দীর্ঘ TTL / সংস্করণযুক্ত কী	উচ্চ হিট রেট; কম অরিজিন লোড	অকার্যকর না করলে বাসিভাব; শৃঙ্খলাবদ্ধ কী লাগে
CDN ও এজ	বৈশ্বিক কম লেটেন্সি; স্পাইক শোষণ করে	ডেটা থেকে দূরে; ডিবাগ ও অকার্যকর করা কঠিনতর
LRU উচ্ছেদ	বদলানো জনপ্রিয়তার সঙ্গে খাপ খায়	স্ক্যান-ভারী লোডে স্থিতিশীল গরম সেট উচ্ছেদ করতে পারে
LFU উচ্ছেদ	স্থিতিশীল গরম সেট রক্ষা করে	খাপ খেতে ধীর; আগে গরম এন্ট্রি আঁকড়ে ধরে

পুনরাবৃত্ত টানাপোড়েন সামঞ্জস্য বনাম পারফরম্যান্স। দীর্ঘ TTL ও উচ্চ হিট রেটের ক্যাশ দ্রুত ও সস্তা এবং বাসি ডেটা দিতে পারে; ছোট TTL ও আক্রমণাত্মক অকার্যকরকরণের ক্যাশ সতেজ ও সঠিক এবং অরিজিনকে বেশি খাটায়। কোনো সর্বজনীন সঠিক উত্তর নেই, কেবল ডেটার প্রতিটি অংশের জন্য সঠিক উত্তর, যা বাসিভাবের প্রতি তার প্রকৃত সহনশীলতা দিয়ে ঠিক। দ্বিতীয় টানাপোড়েন সরলতা বনাম পৌঁছ: একটি অ্যাপ্লিকেশন ক্যাশ আপনার ডেটার কাছে ও যুক্তি করা সহজ, আর এজ দূরে, দ্রুত ও অকার্যকর করা কঠিনতর। ডেটাকে সতেজতা প্রয়োজন ও পড়ার ভলিউম দিয়ে শ্রেণিবদ্ধ করে এবং প্রতিটি শ্রেণি সুচিন্তিতভাবে বসিয়ে ও কনফিগার করে দুটিই সমাধান করুন।

আপনার দলের সঙ্গে আলোচনার প্রশ্ন

1. আমরা যে ধরনের ডেটা ক্যাশ করি তার প্রতিটির প্রকৃত বাসিভাব সহনশীলতা কী, এবং আমরা কি TTL ও অকার্যকরকরণ অভ্যাসের বদলে সেই সহনশীলতা থেকে ঠিক করেছি? বেশিরভাগ দল কেউ একবার বাছা, কখনো পুনর্বিবেচনা না করা TTL দিয়ে ক্যাশ করে, তাই কিছু ডেটা ব্যবসা গ্রহণ করতে পারে তার চেয়ে বাসিভাবে সেবা পায় আর অন্য ডেটা এতটা আক্রমণাত্মকভাবে মেয়াদোত্তীর্ণ হয় যে ক্যাশ খুব কমই সাহায্য করে। আপনার শীর্ষ দশটি ক্যাশ করা সম্পদ আনুন এবং প্রতিটির জন্য সেই ডেটার মালিকদের জিজ্ঞেস করুন এটি নিরাপদে কতটা বাসি হতে পারে: সেকেন্ড, মিনিট, ঘণ্টা বা প্রকাশের পর কখনোই নয়। আপনি সাধারণত দেখবেন উত্তর ব্যাপকভাবে ভিন্ন এবং আপনার বর্তমান TTL সেগুলোর সঙ্গে মেলে না। আপনি যে ফল চান তা হলো একটি সংক্ষিপ্ত সতেজতা শ্রেণিবিন্যাস, প্রতিটি শ্রেণি একটি পদ্ধতিতে (ছোট TTL, দীর্ঘ TTL ও পার্জ, বা সংস্করণযুক্ত অপরিবর্তনীয় কী) মেলানো, যাতে ক্যাশিং সিদ্ধান্ত আন্দাজের বদলে ডেটার অর্থ থেকে আসে।

2. আমাদের সবচেয়ে জনপ্রিয় ক্যাশ এন্ট্রি এখনই সর্বোচ্চ ট্রাফিকে মেয়াদোত্তীর্ণ হলে অরিজিনের কী হত? এই প্রশ্ন প্রকাশ করে আপনার প্রকৃত স্ট্যাম্পিড সুরক্ষা আছে নাকি কেবল আশা। অনেক সিস্টেম ঠিকঠাক চলে যতক্ষণ না একটি গরম কী ট্রাফিক শীর্ষে মেয়াদোত্তীর্ণ হয় এবং প্রতিটি অনুরোধ একসঙ্গে ডেটাবেসে ছুটে যায়, ক্যাশকে ঢাল থেকে ট্রিগারে পরিণত করে। আপনার ব্যস্ততম এন্ডপয়েন্টের জন্য পথ সুনির্দিষ্টভাবে হাঁটুন: কি অনুরোধ সংযুক্তি আছে যাতে কেবল একটি মিস অরিজিনে পৌঁছায়, জিটার আছে যাতে এন্ট্রি লকস্টেপে মেয়াদোত্তীর্ণ হয় না, stale-while-revalidate নীতি আছে যাতে ব্যবহারকারীরা রিফিলের জন্য কখনো অপেক্ষা করে না? অন্তর্দৃষ্টি নয়, লোড-টেস্ট প্রমাণ আনুন, কারণ দশজন ব্যবহারকারীতে টেকা স্ট্যাম্পিড প্রতিরক্ষা দশ হাজারে তবু ভেঙে পড়তে পারে। আপনি আত্মবিশ্বাসে উত্তর দিতে না পারলে আপনার পরবর্তী স্থিতিস্থাপকতা বিনিয়োগ এইমাত্র আপনাকে খুঁজে পেল।

3. আমরা কি নিশ্চিত যে কোনো ভাগ করা ক্যাশ কখনো একজন ব্যবহারকারীর ব্যক্তিগত ডেটা এমন কী-র অধীনে সংরক্ষণ করে না যা অন্য ব্যবহারকারী আঘাত করতে পারে? এটি সেই ক্যাশিং ভুল যা নিরাপত্তা ঘটনা ও শিরোনাম হয়ে ওঠে। এটি ঘটে যখন একটি ব্যক্তিগতকৃত বা প্রমাণীকৃত সাড়া এমন কী-র অধীনে ক্যাশ হয় যা ব্যবহারকারী পরিচয় বাদ দেয়, বা সাড়া ব্যক্তিগত রাখতে চাওয়া একটি Cache-Control হেডার অনুপস্থিত থাকে, ফলে একটি ভাগ করা প্রক্সি বা CDN তা সংরক্ষণ করে এবং পরের ব্যক্তিকে সেবা দেয়। নিরীক্ষা করুন কোন সাড়া ভাগ করা স্তরে ক্যাশযোগ্য, নিশ্চিত করুন প্রতিটি প্রতি-ব্যবহারকারী সাড়া private বা no-store চিহ্নিত, এবং নিশ্চিত করুন প্রতিটি ক্যাশ কী সাড়া বদলানো প্রতিটি ইনপুট ধরে। এটিকে নিরাপত্তা পর্যালোচনা গণ্য করুন, কারণ ক্ষতির পরিসর প্রতিটি নিম্নধারা ব্যবহারকারী, এবং অধ্যায় 4.2-এর চর্চার সঙ্গে যুক্ত করুন।

4. আমাদের প্রতিটি ক্যাশ আসলে কোন লেখার প্যাটার্ন ব্যবহার করে, এবং কেউ কি ইচ্ছা করে তা বেছেছে? ক্যাশ-অ্যাসাইড, রাইট-থ্রু, রাইট-ব্যাক ও রাইট-অ্যারাউন্ড সতেজতা এবং ক্যাশ ব্যর্থ হলে আপনি কী হারান সে সম্পর্কে বিপরীত প্রতিশ্রুতি দেয়, তবু বেশিরভাগ কোডবেসে প্যাটার্ন হলো প্রথম রচয়িতা যা নকল করেছেন। একটি বড় দলের জন্য এটি গুরুত্বপূর্ণ কারণ ক্যাশ-অ্যাসাইড সতেজতা ধরে নেওয়া একটি সার্ভিস যখন অন্যটি নিঃশব্দে রাইট-ব্যাক চালায়, তা এমন ডেটা তৈরি করতে পারে যা বিকৃত দেখায় কিন্তু কেবল বাসি, এবং অন-কল ইঞ্জিনিয়ার ভূত তাড়া করে ঘণ্টা নষ্ট করেন। একটি প্রতি-ক্যাশ তালিকা আনুন: লেখার প্যাটার্ন, সে যে সতেজতা নিশ্চিত করে, এবং প্রসেস মরলে অফ্লাশ করা লেখার কী হয়। যেখানে কোনো ক্যাশ রাইট-ব্যাক ব্যবহার করে সেখানে তাকে সমর্থন করা স্থায়িত্ব গল্প আনুন। আর্থিক বা রেকর্ড ডেটা সামলানো এন্টারপ্রাইজ ও সরকারি সিস্টেমে সমর্থন নিশ্চয়তা ছাড়া রাইট-ব্যাক ক্যাশ ঘটার অপেক্ষায় একটি নিরীক্ষা পর্যবেক্ষণ, তাই আলোচনা প্রতিটি ক্যাশের প্যাটার্ন নামকরা, যুক্তিযুক্ত ও লিখিত হয়ে শেষ হওয়া উচিত।

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

6. আমরা কি ক্যাশিংকে ভাগ করা প্ল্যাটফর্ম অবকাঠামো গণ্য করছি, নাকি প্রতিটি দল নিজে কী, অকার্যকরকরণ ও স্ট্যাম্পিড সুরক্ষা পুনরাবিষ্কার করছে? ভালোভাবে করা ক্যাশিং একবার সমাধান করা অল্প কিছু কঠিন সমস্যা: নরমালাইজ করা কী, ইভেন্ট-চালিত অকার্যকরকরণ, অনুরোধ সংযুক্তি, সঠিক HTTP শব্দার্থ, এবং প্রতি-স্তর অবজার্ভেবিলিটি। প্রতিটি দল এগুলো উদ্ভাবন করলে একটি বড় প্রতিষ্ঠান একই ভুলের জন্য বারবার দাম দেয়, এবং একটি সার্ভিসে সারানো বিষক্রিয়া ত্রুটি বা ব্যক্তিগত-ডেটা ফাঁস অন্য দশটিতে নিঃশব্দে টিকে থাকে। আজ ক্যাশিং রীতির মালিক কে এবং সার্ভিস জুড়ে কতটা নকল ক্যাশিং কোড আছে তার একটি সৎ মানচিত্র আনুন। প্রতিদ্বন্দ্বী বিবেচনা স্বায়ত্তশাসন: দল বাধ্যতামূলক ভাগ করা লাইব্রেরিকে প্রতিরোধ করে, তাই গ্রহণ করা সহজ একটি পাকা-পথ ডিফল্ট এবং প্রয়োগ করা কঠিন মান ওজন করুন। একটি এন্টারপ্রাইজ বা সরকারি প্ল্যাটফর্ম গোষ্ঠীর জন্য একটি ভাগ করা, ভালো-পরীক্ষিত ক্যাশিং সামর্থ্য নিরাপত্তা ও নিরীক্ষা প্রয়োজন সমানভাবে ধরে রাখার সবচেয়ে সস্তা উপায়ও, তাই আলোচনা ঠিক করা উচিত কী ভাগ করা অবকাঠামো হয় এবং কে তার অর্থায়ন করে।

খাতভেদে দৃষ্টিভঙ্গি

স্টার্টআপ। ক্যাশিং হলো আপনি এখনো স্কেল করতে সামর্থ্য রাখেন না এমন ট্রাফিক স্পাইক টিকে থাকার সবচেয়ে সস্তা পথ, তাই আপনার অল্প সময় কয়েকটি উচ্চ-লিভারেজ স্থাপনে ব্যয় করুন: স্থির সম্পদের জন্য সংস্করণযুক্ত URL সহ একটি CDN, এবং আপনার সবচেয়ে গরম কোয়েরির সামনে ছোট TTL ও জিটারসহ একটি একক ক্যাশ-অ্যাসাইড স্তর। নিজে চালানোর বদলে ম্যানেজড CDN ও ক্যাশ সেবার ওপর ভর করুন, এবং অনুরোধ সংযুক্তি আগে যোগ করুন, কারণ একটি ছোট ডেটাবেসের বিরুদ্ধে লঞ্চ-দিবসের স্ট্যাম্পিড একটি ভালো দিন খারাপভাবে শেষ করার সম্ভাব্যতম ব্যর্থতা। ডেটা আপনাকে বলার আগে বিস্তৃত অকার্যকরকরণ পরিকল্পনা এড়ান।

ছোট ব্যবসা। কোনো ক্যাশিং বিশেষজ্ঞ নেই আর বাজেট কম, তাই আপনি ইতিমধ্যে চালানো টুলের ভেতরে বিনামূল্যে পাওয়া ক্যাশিং কেনা পছন্দ করুন: আপনার হোস্টিংয়ের সঙ্গে বান্ডেল করা একটি CDN, আপনার ওয়েব ফ্রেমওয়ার্কের সাড়ায় HTTP Cache-Control হেডার, এবং আপনার ডেটাবেসের ইনবিল্ট কোয়েরি ক্যাশ। কেনা-বনাম-বানানোর ডাক এখানে প্রায় সবসময় কেনার পক্ষে, কারণ একজন গ্রাহকের ডেটা অন্যকে ফাঁস করা একটি ভুল-কী ক্যাশ আপনার এড়ানো ম্যানেজড সেবার চেয়ে অনেক বেশি খরচ করে। দুটি সস্তা জয় ঠিক করুন, সঠিক HTTP হেডার এবং ভাগ করা স্তরে প্রমাণীকৃত পাতা কখনো ক্যাশ না করা, এবং বিদেশি প্যাটার্ন একা ছাড়ুন।

এন্টারপ্রাইজ। অনেক দল জুড়ে পরিসরে ঝুঁকি কোনো একক ক্যাশ থেকে সেগুলোর মধ্যকার অসামঞ্জস্যে সরে: ভিন্ন কী পরিকল্পনা, অসম অকার্যকরকরণ, এবং এক সার্ভিসে দেখা দিয়ে অন্যটিতে না থাকা ব্যক্তিগত-ডেটা ফাঁস। কী, অকার্যকরকরণ, স্ট্যাম্পিড সুরক্ষা ও প্রতি-স্তর অবজার্ভেবিলিটির পাকা-পথ ডিফল্টসহ ক্যাশিংকে ভাগ করা প্ল্যাটফর্ম অবকাঠামো হিসেবে দিন, যাতে হিট রেট, উচ্ছেদ ও বাসিভাব এক জায়গায় দৃশ্যমান ও অভিন্নভাবে শাসিত হয়। ক্যাশ কনফিগারেশন নিরাপত্তা-সংবেদনশীল কোড হিসেবে পর্যালোচনাযোগ্য করুন, এবং অঞ্চল জুড়ে অকার্যকরকরণকে প্রতি-দলের রানবুকের বদলে প্রথম-শ্রেণির নকশা সমস্যা গণ্য করুন।

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

উদাহরণ

স্টার্টআপ। একটি ছোট ভোক্তা অ্যাপ তার পণ্য ক্যাটালগ একটি ইন-মেমরি স্টোর দ্বারা সমর্থিত ক্যাশ-অ্যাসাইড স্তরের মধ্য দিয়ে চালায়, ৬০ সেকেন্ডের TTL ও জিটারসহ যাতে এন্ট্রি একসঙ্গে মেয়াদোত্তীর্ণ হয় না। স্থির সম্পদ সংস্করণযুক্ত ফাইলনাম ও এক বছরের max-age সহ একটি CDN-এ যায়, তাই একটি স্টাইলশিট বদলানো ডিপ্লয় একটি নতুন URL সেবা দেয় এবং কখনো পার্জ দরকার হয় না। একটি জনপ্রিয় পডকাস্টে লঞ্চ ট্রাফিক স্পাইক পাঠালে সিঙ্গল-ফ্লাইট সংযুক্তি মানে হাজার হাজার একযোগ হোমপেজ মিস একটি ডেটাবেস পড়া ঘটায়, হাজার হাজার নয়। প্রতিষ্ঠাতারা ক্যাশিংয়ে প্রায় কিছুই খরচ করেন না তবু এমন একটি স্পাইক সামলান যা তাঁদের ছোট ডেটাবেস গলিয়ে দিত, কারণ তাঁরা কয়েকটি সুবাছাই ক্যাশ ইচ্ছাকৃতভাবে বসিয়েছেন।

এন্টারপ্রাইজ। একটি বৈশ্বিক খুচরা বিক্রেতা একটি স্তরিত ক্যাশের মাধ্যমে লক্ষ লক্ষ ক্রেতাকে সেবা দেয়: ছবি ও ক্যাশযোগ্য API সাড়ার জন্য একটি CDN, প্রতিটি অঞ্চলে একটি ভাগ করা রিভার্স-প্রক্সি ক্যাশ, এবং গণনা করা মূল্য ও ইনভেন্টরি খণ্ডের জন্য একটি অ্যাপ্লিকেশন ক্যাশ। ক্যাশ কী নরমালাইজ করা এবং মুদ্রা, ভাষা ও ডিভাইস শ্রেণি ধরে, তাই ব্যক্তিগতকরণ কখনো ফাঁস করে না এবং হিট রেট উঁচু থাকে। পণ্য ডেটা ইভেন্ট-চালিত অকার্যকরকরণসহ ছোট TTL ব্যবহার করে, তাই একটি মূল্য পরিবর্তন একটি মেসেজ বাসে প্রকাশ করে যা সেকেন্ডের মধ্যে অঞ্চল জুড়ে প্রভাবিত কী পার্জ করে। প্রতিটি স্তর অধ্যায় 9.2-এর অবজার্ভেবিলিটি প্ল্যাটফর্মে হিট রেট, উচ্ছেদ হার ও বাসিভাব জানায়, এবং পড়ন্ত হিট রেটে একটি অ্যালার্ট একবার একটি অতিক্ষুদ্র ক্যাশকে চেকআউট বিভ্রাট হওয়ার আগে ধরেছিল।

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

ব্যবসায়িক যুক্তি: প্রেরণা, ROI ও TCO

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

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

অ্যান্টি-প্যাটার্ন ও ফাঁদ

• অকার্যকরকরণ ছাড়া ক্যাশিং: পার্জ করার উপায় ছাড়া দীর্ঘ TTL ঠিক করা, তাই সংশোধিত মান ঘণ্টার পর ঘণ্টা ভুল থাকে।
• খুব মোটা কী: ব্যক্তিগতকৃত সাড়া ভাগ করা কী-র অধীনে ক্যাশ করা, একজন ব্যবহারকারীর ডেটা অন্যকে ফাঁস করা।
• খুব সূক্ষ্ম কী: কী-তে অস্থির ইনপুট রাখা যাতে দুটি অনুরোধ কখনো মেলে না এবং হিট রেট ভেঙে পড়ে।
• স্ট্যাম্পিড সুরক্ষা নেই: একটি গরম কী লোডে মেয়াদোত্তীর্ণ হয় এবং প্রতিটি অনুরোধ একসঙ্গে অরিজিনে ছুটে।
• সমলয় মেয়াদ: একসঙ্গে লেখা এন্ট্রির একটি ব্যাচ জিটার ছাড়া একই মুহূর্তে মেয়াদোত্তীর্ণ হয়, পর্যায়ক্রমিক থান্ডারিং হার্ড ঘটায়।
• ভাগ করা স্তরে ব্যক্তিগত ডেটা ক্যাশ: Cache-Control: private বা no-store অনুপস্থিত, তাই একটি প্রক্সি বা CDN প্রমাণীকৃত সাড়া সংরক্ষণ করে।
• অকী-করা ইনপুট উপেক্ষা: একটি হেডার সাড়ার বডিতে প্রতিফলিত কিন্তু কী থেকে বাদ, ক্যাশ বিষক্রিয়ার দরজা খোলা।
• অতিক্ষুদ্র ক্যাশ: কর্মরত সেট ধরে রাখতে খুব ছোট ক্যাশ থ্র্যাশ করে এবং আবার দরকার হওয়ার ঠিক আগে এন্ট্রি উচ্ছেদ করে।
• অমাপা ক্যাশ: হিট-রেট বা উচ্ছেদ মেট্রিক নেই, তাই অবনত ক্যাশ বিভ্রাট না হওয়া পর্যন্ত অদৃশ্য।
• স্থায়িত্ব ছাড়া রাইট-ব্যাক: ফ্লাশের আগে ক্যাশ মরলে উধাও হওয়া দ্রুত লেখা, কোনো সমর্থন নিশ্চয়তা ছাড়া।

পরিপক্বতা মডেল

• স্তর ১, সূচনা: ক্যাশিং অ্যাড হক ও প্রতি-ডেভেলপার, কিছু ধীর মনে হলে প্রতিক্রিয়ায় যোগ করা। TTL আন্দাজ করা, কী অসঙ্গত, অকার্যকরকরণ হাতে-করা বা অনুপস্থিত, এবং বাসি ডেটা ও রহস্যময় ত্রুটি সাধারণ। কেউ হিট রেট অনুসরণ করে না, এবং ক্যাশের শোষণ করার কথা ট্রাফিক স্পাইক তার বদলে বিভ্রাট ঘটায়।
• স্তর ২, বিকাশ: দলগুলো স্পষ্ট জায়গায় ক্যাশ করে এবং স্থির সম্পদের জন্য CDN ব্যবহার করে। মৌলিক TTL ও ক্যাশ-অ্যাসাইড দেখা দেয়, কিন্তু রীতি সার্ভিস থেকে সার্ভিসে ভিন্ন, অকার্যকরকরণ অসঙ্গত, স্ট্যাম্পিড সুরক্ষা অনুপস্থিত, ব্যক্তিগত-বনাম-ভাগ করা ক্যাশিং নিয়ম অনানুষ্ঠানিক, এবং অবজার্ভেবিলিটি মাঝেমধ্যের স্পট পরীক্ষায় সীমিত।
• স্তর ৩, মানসম্মতকরণ: একটি ক্যাশিং কৌশল প্রতিষ্ঠান জুড়ে নথিবদ্ধ ও প্রয়োগ করা। ক্যাশ কী নরমালাইজ করা, TTL একটি ভাগ করা সতেজতা শ্রেণিবিন্যাস অনুসরণ করে, যেখানে গুরুত্বপূর্ণ সেখানে অকার্যকরকরণ ইভেন্ট-চালিত, স্ট্যাম্পিড সুরক্ষা ও সঠিক HTTP শব্দার্থ মান, ব্যক্তিগত ডেটা কখনো ভাগ করা স্তরে ক্যাশ হয় না, এবং প্রতিটি স্তর একটি সাধারণ অবজার্ভেবিলিটি পাইপলাইনে হিট রেট ও উচ্ছেদ জানায়।
• স্তর ৪, ব্যবস্থাপনা: ক্যাশিং ভিত্তিরেখার বিপরীতে মাপা ও নিয়ন্ত্রিত। প্রতিটি স্তরের লক্ষ্য হিট রেট, বাসিভাব বাজেট ও উচ্ছেদ সীমা আছে, এবং হিট রেট পড়লে বা উচ্ছেদ হার তার ভিত্তিরেখার ওপরে উঠলে ড্যাশবোর্ড অ্যালার্ট দেয়। স্ট্যাম্পিড প্রতিরক্ষা সর্বোচ্চ পরিসরে লোড-টেস্ট করা, প্রতি ক্যাশে অরিজিন-লোড হ্রাস পরিমাণ করা, TTL ও উচ্ছেদ নীতি মাপা অ্যাক্সেস প্যাটার্ন থেকে টিউন করা, এবং ক্যাশ কনফিগারেশন রিলিজের আগে নিরাপত্তা-সংবেদনশীল কোড হিসেবে পর্যালোচিত।
• স্তর ৫, সমন্বয়: ক্যাশিং নিরন্তর উন্নত এবং প্রতিষ্ঠান জুড়ে একীভূত। স্থাপনা, কী ও TTL বদলানো ট্রাফিকের সঙ্গে খাপ খায়, এজ কম্পিউট ব্যবহৃত হয় যেখানে নিজের জায়গা অর্জন করে, সক্ষমতা পরিকল্পনা ও খরচ মডেল ক্যাশ মেট্রিক থেকে টানে, এবং এক দলের ঘটনা থেকে শিক্ষা ভাগ করা রীতিতে জোগান দেয়। প্রতিষ্ঠান ক্যাশিংকে স্থানীয় হ্যাকের সংগ্রহের বদলে নকশা করা, মাপা, খাপ-খাওয়ানো সামর্থ্য গণ্য করে।

আলোচনার ভাবনা

1. আপনার সিস্টেমের কোন একক ক্যাশ, এখনই ঠান্ডা হয়ে গেলে, আপনার অরিজিনকে সবচেয়ে বিপদে ফেলত, এবং তাকে কী রক্ষা করে?
2. আপনার ক্যাশ শ্রেণিবিন্যাসের প্রতিটি স্তরের জন্য আপনি কি স্মৃতি থেকে তার বর্তমান হিট রেট বলতে পারেন, এবং না পারলে তা আপনাকে কী বলে?
3. সংস্করণযুক্ত কী দিয়ে আপনি কোথায় একটি অকার্যকরকরণ সমস্যাকে নামকরণ সমস্যায় পরিণত করেছেন, এবং কোথায় এখনো করতে পারতেন?
4. আপনার কোন লেখার পথ ক্যাশ-অ্যাসাইড, রাইট-থ্রু, রাইট-ব্যাক বা রাইট-অ্যারাউন্ড ব্যবহার করে, এবং প্রতিটি কি ইচ্ছা করে বাছা?
5. একজন আক্রমণকারী একটি অনুরোধ হেডার নিয়ন্ত্রণ করলে সে কি আপনার ব্যবহারকারীরা ভাগ করা কোনো ক্যাশ করা সাড়া বিষাক্ত করতে পারত?
6. আপনার হিট রেট নিঃশব্দে বিশ পয়েন্ট নেমে গেছে, তা আপনি মিনিটের মধ্যে কীভাবে জানতেন?

প্রধান শিক্ষা

• ক্যাশিং লেটেন্সি, লোড ও খরচ কাটে, এবং ক্যাশ শ্রেণিবিন্যাস (ক্লায়েন্ট, CDN ও এজ, রিভার্স প্রক্সি, অ্যাপ্লিকেশন, ডেটাবেস) আপনাকে নিরাপদে যতদূর সম্ভব ওপরে ও বাইরে উত্তর দিতে দেয়।
• অকার্যকরকরণ কঠিন অংশ; ক্যাশ কী ও TTL সুচিন্তিতভাবে নকশা করুন, এবং যেখানে পারেন সংস্করণযুক্ত কী দিয়ে অকার্যকরকরণ সমস্যাকে নামকরণ সমস্যায় পরিণত করুন।
• অনুরোধ সংযুক্তি, জিটার ও stale-while-revalidate দিয়ে লোডের অধীনে ক্যাশ রক্ষা করুন, কারণ একটি স্ট্যাম্পিড যা ভাঙতে পারে ঠিক সেই সময়ই ক্যাশ সবচেয়ে বেশি দরকার।
• ওয়ার্কলোড ধরে লেখার প্যাটার্ন ও উচ্ছেদ নীতি বাছুন, এবং ক্যাশকে আন্দাজ করতে না দিয়ে HTTP ক্যাশিং শব্দার্থ (Cache-Control, ETag, যাচাইকরণ) সুস্পষ্টভাবে ব্যবহার করুন।
• ক্যাশ করা কন্টেন্টকে আক্রমণ-পৃষ্ঠ গণ্য করুন এবং হিট রেট, উচ্ছেদ ও বাসিভাব মাপুন, কারণ অপর্যবেক্ষিত বা ভুল-কী করা ক্যাশ একটি লুকানো দায়, সম্পদ নয়।

তথ্যসূত্র ও আরও পড়ার জন্য

• Martin Kleppmann, Designing Data-Intensive Applications
• Andrew S. Tanenbaum ও Herbert Bos, Modern Operating Systems
• John L. Hennessy ও David A. Patterson, Computer Architecture: A Quantitative Approach
• Roy T. Fielding ও Julian Reschke, “Hypertext Transfer Protocol (HTTP/1.1): Caching,” RFC 7234, IETF
• Mark Nottingham, “Caching Tutorial for Web Authors and Webmasters”
• James Kettle, “Practical Web Cache Poisoning,” PortSwigger Research
• Betsy Beyer, Chris Jones, Jennifer Petoff ও Niall Richard Murphy (সম্পা.), Site Reliability Engineering: How Google Runs Production Systems
• Michael T. Nygard, Release It! Design and Deploy Production-Ready Software