نمایش و توزیع محتوا از کش دارای مزایای شفافی است؛ اینکار عملکرد را بهبود بخشیده، بار سرور اصلی و هزینه های مرتبط با خروجی را بشدت کاهش می دهد. زمانی که هر محتوایی در سایت تان تنها چند بار درخواست شده اما جمع آن درخواست ها با حجم قابل توجهی از ترافیک همراه باشد، ممکن است رویکرد CDN های قدیمی دیگر کارآمد نباشد. به چنین محتواهایی که طول زیادی داشته و حجم درخواست را افزایش می دهد، به اصطلاح "Long tail" گویند.
آیا برای چنین محتواهایی نیز یک CDN می تواند تأثیرگذار بوده و مفید واقع شود؟
بله قطعاً؛ جواب این سوال در کش چندلایه یا Multilayer cache نهفته است.
راهکار افزایش سرعت لود صفحات سنگین
در یک مورد ایده آل، تقاضا برای داده های شما توزیع طبیعی مشخصی را پیش می برد، و می توانید به سادگی محتوایی که بارها تقاضا شده و محبوب است را کش کنید.
این گونه محتوا ها پس از مدتی تقاضای اولیه خود را از دست می دهند، و در نتیجه وارد بخش نزولی نمودار می شود؛ جایی که کش کردن آن دیگر معقول نیست.
ایجاد یک آستانه ی (threshold) معقول می تواند برای نرخ کش ( cache hit ratio ) بسیار کارآمد باشد.
محتوای طولانی ( long-tail) یا دم دراز
در خصوص محتواهای طولانی، تنظیم یک آستانه ی مفرد، بی معنی است. بیشتر قسمت های محتوای شما در چنین شرایطی به مرحله کش شدن نمی رسند؛ و اگر هم برسند، دیگر از سمت کش مجدداً توزیع نخواهند شد.
چراکه بلافاصله با محتوایی که پس از آن درخواست می شود، جایگزین خواهد شد. این موضوع hit ratio یا نرخ کش را بسیار کاهش می دهد.
برای مثال، یک پلتفرم آموزشی را در نظر بگیرید، که دارای موضوعات بسیار گسترده و متنوعی است. اینگونه سایت ها ترافیک بسیار بالایی دارند؛ اما یک محتوای بسیار خوب که برای اکثر کاربران ایجاد شده باشد، وجود ندارد؛ در عوض، کاربران هر آنچه در آن لحظه نیاز داشته باشند را از یک آرشیو بزرگ انتخاب خواهند کرد.
نبود یک محتوای همه پسند، یک اتفاق متداول است، اما این تنها سناریویی نیست که long-tail یا دم دراز را رقم می زند.
برخی از پلتفرم های VOD نیز باید با Long-tail درگیر شوند؛ حتی اگر بتوانند محتوایی را که بیشتر پخش شده، شناسایی کنند.
مشکل از ذات ABR یا پخش با بیت ریت منعطف نشات می گیرد؛ آدرس های کیفیت های مختلف با یکدیگر متفاوت هستند. پس محتوا باید به اندازه کافی درخواست شود تا از آستانه ی کش عبور کند. یعنی برای هر کیفیت و به طور مجزا.
فرض کنید HLS و DASH را با چهار کیفیت منعطف و مختلف ارائه می دهید. پس با 8 نسخه کپی از هر بخش محتوا مواجه خواهید شد. اکثر اوقات افراد بخش های مختلفی از یک ویدیو را درخواست می کنند.
این بخش بندی می تواند تأثیری منفی بر عملکرد CDN شما داشته باشد.
راه حل این مشکل چالش بر انگیز، در واقع انچنان هم دشوار نیست! در چنین شرایطی می توانیم از کش چند لایه استفاده کنیم؛ که در نهایت، برای اکثر محتوای ذخیره شده بر روی سرور Origin یک نقطه تلاقی محسوب خواهد شد.
کش چند لایه ( Multilayer cache )
هر لایه از کش با یک آستانه ی مجزا کار می کند. لایه اول (L0) شامل انبوهی از سرورهای لبه است که در پاپ های ارائه دهنده ( برای مثال میزبان کلود ) مستقر شده اند.
این لایه در نزدیک ترین موقعیت به کاربر بوده و محتوای همه پسند سایت شما را ذخیره می کند. فرض کنید محتوایی را در آن کش می کنید که حداقل 10 بار درخواست شده باشد.
لایه دوم (L1) بر روی برخی از دیتاسنترهای بزرگ تر توزیع می شود، که به POP مسئول و کاربر نزدیک تر است. این لایه نیز شامل چند سرور بوده و درخواست ها را به طور منظم از لایه L0 دریافت می کند. مثلاً برای این لایه می توان یک آستانه ی 5 درخواسته در نظر گرفت.
و در نهایت، لایه سوم (L2). سرورهای این لایه محتوای اصلی Long tail یا طولانی را ذخیره می کنند. این یعنی شما باید هر چیزی حتی با یک درخواست را در اینجا کش کنید.
این سرورها به سرور اصلی نزدیک تر بوده و بجای سرور اصلی، بیشتر محتواها را با نسخه کپی به دست مخاطب می رسانند.
اگر فایلی درون کش وجود نداشته باشد، تنها در چنین شرایطی است که درخواست به سمت سرور اصلی ارجاع داده می شود. این رویکرد هزینه های مرتبط با خروجی ها را بسیار کاهش خواهد داد.
مطمئناً یک سایز دقیق برای همه کیس ها وجود ندارد. راهکاری که در یک منطقه خوب جواب دهد، لزوماً در ناحیه دیگر موفق نخواهد بود. برای مثال، ممکن است شما برای L2 به 6 موقعیت مختلف در یک قاره نیاز داشته باشید، و در قاره ی دیگر فقط 2 موقعیت برایتان کافی باشد.
باید این توپولوژی را برای تمام لایه ها به بهینه ترین حالت عملکردی رساند (در تمام لوکیشن ها).
نرخ Hit در چنین تنظیماتی، تجمعی است. یعنی می توانید انتظار نرخ پایینی در سرورهای لبه داشته باشید. با این حال هر لایه به طور تدریجی بهتر از قبلی عمل خواهد کرد. L0+L1 با هم می توانند به محتوای همه پسند و پر طرفدار پاسخ دهند، به طوری که L2 بیشتر ِمحتوای Long-tail را در خود ذخیره دارد.
شاید تصور کنید که برای بالا نگه داشتن hit ratio ، L2 باید تقریباً تمام داده های سرور اصلی را در خود نگه دارد؛ اما این کار لازم نیست. زمانی که آدرسی (URL) به اندازه کافی درخواست شود که کش کردن فایل در موقعیتی نزدیک به کاربر را تضمین کند، از لایه ای به لایه ی بعد، تعداد درخواست ها را کاهش می دهد.
پس از مدتی، این آدرس با محتوایی که کمتر درخواست شده و تازه تر است، جایگزین خواهد شد.
این به شما کمک می کند تا فایل ها را به طور مساوی بین لایه ها توزیع کنید و از فضای موجود بدون کپی های اضافی در کش، بسیار موثر تر استفاده کنید.
جمع بندی
تولید محتوای long-tail می تواند از جنبه های سئو برای وبسایت شما جذاب باشد، و شاید بارها در این زمینه از متخصصین شنیده باشید که محتوای skyscraper یا آسمان خراش، که 10 برابر از محتواهای موجود در صفحه اول سرچ گوگل بهتر باشد، می تواند رتبه شما را افزایش داده و ترافیک زیادی را به سمت مقاله شما هدایت کند.
اما آیا به این فکر کرده اید که این محتوا که ممکن است شامل تصاویر، متن، ویدیو و حتی پادکست باشد، باید با هر بار بازدید مخاطب درخواستی عظیم را به سمت سرورهای اصلی و لبه شما ارسال کند؟ در این مطلب مشکل کش کردن و ارائه محتوا های طولانی و دم دراز با بررسی کرده و برای آن راهکاری ایده آل ارائه کردیم؛ امیدواریم این مطلب نیز برای شما مفید واقع شده باشد.
ارائه دهنده خدمات زیرساخت یکپارچه ابری