ذخیره‌سازی و CDN در VOD دو بخش از یک مسیر تحویل هستند؛ مسیری که باید فایل درست را در زمان مناسب، با مجوز معتبر و هزینه قابل‌کنترل به Player برساند. Storage نسخه پایدار دارایی‌های رسانه‌ای را نگه می‌دارد، Cache از دریافت تکراری محتوا جلوگیری می‌کند و CDN تحویل را میان نقاط مختلف شبکه توزیع می‌کند. Origin نیز مبدأ پاسخ‌گویی به درخواست‌هایی است که در لایه‌های کش پاسخ ندارند.
برای تیم دواپس، مسئله فقط انتخاب دیسک یا فعال‌کردن CDN نیست. یک Cache Key اشتباه می‌تواند هزاران نسخه تکراری ایجاد کند؛ انتقال زودهنگام فایل به آرشیو می‌تواند پخش محتوای کم‌بازدید را متوقف کند؛ و انتشار ناقص Manifest ممکن است به درخواست Segmentهای ناموجود منجر شود. این مقاله تصمیم‌های طراحی، ظرفیت‌سنجی، امنیت و عملیات این مسیر را بررسی می‌کند.
اگر ابتدا به نمای کامل سامانه، از دریافت فایل تا Transcoding و Player نیاز دارید، راهنمای معماری زیرساخت VOD و پخش پایدار ویدئو را بخوانید. تمرکز این مطلب بر لایه نگهداری و تحویل فایل پس از آماده‌شدن خروجی رسانه است.
Storage، Origin، Cache و CDN چه تفاوتی دارند؟
این مفاهیم ممکن است روی تجهیزات مشترک اجرا شوند، اما مسئولیت یکسانی ندارند. Cache یک سازوکار نگهداری موقت پاسخ است؛ CDN شبکه‌ای برای تحویل محتواست که معمولاً از همین سازوکار استفاده می‌کند. Origin می‌تواند یک وب‌سرور، درگاه Object Storage یا سرویس Packaging باشد.
| لایه | مسئولیت اصلی | معیار طراحی | برداشت اشتباه رایج |
|---|---|---|---|
| Storage | نگهداری فایل منبع و خروجی‌های قابل انتشار | دوام، دسترس‌پذیری، ظرفیت و بازیابی | وجود Replica به معنی داشتن بکاپ مستقل است |
| Origin | پاسخ‌گویی به درخواست‌های بالادست CDN | Throughput، زمان پاسخ و رفتار در پیک | با فعال‌شدن CDN دیگر ظرفیت Origin مهم نیست |
| Cache | استفاده مجدد از پاسخ قابل‌کش | Cache Key، تازگی و سیاست حذف | هر فایل تا پایان TTL حتماً در کش می‌ماند |
| CDN | تحویل توزیع‌شده محتوا به مخاطبان | کیفیت مسیر شبکه، پوشش و هزینه | CDN جایگزین آرشیو یا نسخه پشتیبان است |
در مسیر معمول، Player ابتدا Manifest را دریافت می‌کند و سپس Segmentهای کیفیت انتخاب‌شده را درخواست می‌دهد. Edge در صورت داشتن نسخه معتبر، پاسخ را از کش می‌دهد؛ در غیر این صورت درخواست به لایه میانی یا Origin می‌رسد. فایل‌های رسانه‌ای در HLS از طریق Playlist معرفی می‌شوند و Playlist از نوع VOD پس از انتشار نباید تغییر کند؛ این ویژگی برای طراحی محتوای نسخه‌دار مفید است.
طراحی ذخیره‌سازی در VOD: چه چیزی را کجا نگه داریم؟
فایل منبع، خروجی انتشار و داده عملیاتی را جدا کنید
فایل منبع برای بازتولید خروجی، تغییر Codec یا ساخت کیفیت جدید اهمیت دارد. Segmentها و Manifestها برای خواندن پرتکرار آماده می‌شوند. Log، Metadata، صف پردازش و وضعیت انتشار نیز الگوی دسترسی متفاوتی دارند. جداسازی منطقی آن‌ها، سیاست دسترسی، حذف و بازیابی را دقیق‌تر می‌کند.
برای هر دارایی حداقل شناسه محتوا، نسخه خروجی، پروفایل Encoding، Checksum، زمان انتشار و وضعیت آماده‌بودن را ثبت کنید. مسیر فایل باید نسخه را مشخص کند؛ برای مثال /vod/asset-42/v3/video/720p/seg-001.m4s. این ساختار نمونه است و باید با نام‌گذاری واقعی سامانه هماهنگ شود.
Object Storage، فایل‌سیستم یا Block Storage؟
برای کتابخانه‌ای از فایل‌های رسانه‌ای که با کلید مشخص و HTTP خوانده می‌شوند، Object Storage معمولاً گزینه قابل‌بررسی است. فایل‌سیستم مشترک زمانی اهمیت پیدا می‌کند که ابزارهای پردازش به رفتار POSIX یا عملیات فایل وابسته باشند. Block Storage بیشتر در لایه دیسک ماشین‌ها و فضای کاری سرویس‌ها مطرح است و به‌تنهایی سرویس توزیع شیء نیست.
انتخاب را با آزمون الگوی واقعی انجام دهید: تعداد و اندازه فایل‌ها، خواندن هم‌زمان، محدودیت درخواست، سرعت بازیابی پس از خرابی و هزینه خروج داده. سازگاری با API نیز به‌تنهایی تضمین‌کننده یکسان‌بودن کارایی یا رفتار همه پیاده‌سازی‌ها نیست.
چرخه عمر محتوا باید با تعهد پخش سازگار باشد
فایل‌های آماده پخش باید در رده‌ای باشند که زمان دسترسی آن با انتظار کاربر سازگار است. نسخه منبع یا دارایی خارج از کاتالوگ می‌تواند طبق سیاست مشخص به رده ارزان‌تر منتقل شود. در سرویس‌هایی مانند S3، قواعد Lifecycle امکان انتقال بین رده‌ها یا حذف پس از شرایط تعریف‌شده را فراهم می‌کنند. زمان بازیابی، هزینه Retrieval و حداقل مدت نگهداری هر رده را پیش از فعال‌سازی بررسی کنید.
کم‌بازدیدبودن یک فیلم به معنی قابل‌تأخیربودن پخش آن نیست. اگر هنوز در کاتالوگ عمومی است، تصمیم انتقال باید پاسخ‌گوی نخستین درخواست پس از یک دوره بی‌مصرفی هم باشد.
ظرفیت ذخیره‌سازی و CDN در VOD چگونه محاسبه می‌شود؟
حجم خروجی را با مجموع Bitrate نسخه‌های ذخیره‌شده بسنجید
برای برآورد اولیه، حجم همه Trackهایی را جمع کنید که واقعاً ذخیره می‌شوند. صوت مشترک میان چند کیفیت را یک بار حساب کنید؛ اگر در هر خروجی تکرار می‌شود، همان تکرار باید در محاسبه دیده شود.
Output size (GB) ≈ Duration (seconds) × Sum of stored bitrates (Mbps) ÷ ۸۰۰۰
مثال فرضی: برای یک ساعت محتوا، چهار خروجی ویدئویی با Bitrateهای ۰٫۸، ۱٫۵، ۳ و ۵ مگابیت‌برثانیه و یک Track صوتی مشترک ۰٫۱۲۸ مگابیت‌برثانیه داریم. مجموع ۱۰٫۴۲۸ مگابیت‌برثانیه است؛ بنابراین خروجی حدود ۴٫۶۹ گیگابایت ده‌دهی می‌شود. برای هزار ساعت، حدود ۴٫۶۹ ترابایت به دست می‌آید.
این عدد شامل فایل منبع، نسخه‌های Codec دیگر، سربار Container، تصاویر، زیرنویس، بکاپ و فضای نسخه‌های قبلی نیست. در Encoding با Bitrate متغیر نیز اندازه خروجی واقعی معیار نهایی است. برای مبانی محاسبه، مقاله محاسبه Bitrate و پهنای باند استریم ویدئو مکمل این بخش است.
پهنای باند بیننده با پهنای باند Origin یکسان نیست
Viewer traffic (Gbps) ≈ Concurrent viewers × Average delivered bitrate (Mbps) ÷ ۱۰۰۰
اگر ۲۰۰۰ کاربر هم‌زمان با میانگین مجموع صوت و تصویر ۳ مگابیت‌برثانیه تماشا کنند، بار تحویل حدود ۶ گیگابیت‌برثانیه است. با فرض ساده‌شده Byte Hit Ratio برابر ۹۵ درصد در یک لایه کش، ترافیک Miss حدود ۰٫۳ گیگابیت‌برثانیه خواهد بود. این تخمین برای ظرفیت‌گذاری نهایی کافی نیست: پرشدن کش، Retry، Range Request، الگوی جغرافیایی و کش میانی نتیجه را تغییر می‌دهند.
Request Hit Ratio سهم تعداد درخواست‌های پاسخ‌گرفته از کش است؛ Byte Hit Ratio سهم بایت‌های تحویل‌شده از کش. برای برآورد بار داده، نسبت بایتی کاربردی‌تر است. تعداد زیاد درخواست Manifest کوچک می‌تواند نسبت درخواستی را مطلوب نشان دهد، در حالی که Segmentهای بزرگ همچنان از Origin خوانده شوند.
برای تعیین سناریوی پیک، نرخ رشد و حاشیه ظرفیت، به راهنمای محاسبه ظرفیت کاربران هم‌زمان در VOD مراجعه کنید.
تعداد درخواست‌ها را جدا از حجم ترافیک محاسبه کنید
در یک مدل ساده با Segmentهای شش‌ثانیه‌ای و Track صوتی و تصویری جدا، هر کاربر به‌طور متوسط دو درخواست رسانه در شش ثانیه ایجاد می‌کند. برای ۲۰۰۰ کاربر، حدود ۶۶۷ درخواست در ثانیه داریم؛ بدون احتساب Manifest، زیرنویس، Seek، Retry و دریافت‌های آغاز پخش. کوتاه‌کردن Segment می‌تواند تعداد درخواست‌ها و هزینه پردازش درخواست را افزایش دهد، حتی اگر حجم کل ویدئو تغییر محسوسی نکند.
طراحی Cache در VOD: کلید کش و TTL
Cache Key باید هویت محتوا را نشان دهد
اگر پاسخ یکسان است، افزودن پارامترهای بی‌اثر مانند شناسه کمپین یا Session به Cache Key ممکن است همان فایل را به چند ورودی تبدیل کند. در مقابل، حذف پارامتری که واقعاً خروجی را تغییر می‌دهد می‌تواند نسخه نادرست را به کاربر برساند. مسیر، Query String، Header و Cookie باید با شناخت رفتار برنامه انتخاب شوند؛ سیاست Cache Key در CDNها قابل تنظیم است.
برای هر پارامتر یک پرسش عملی ثبت کنید: «آیا تغییر این مقدار، بایت‌های پاسخ یا مجوز دسترسی را تغییر می‌دهد؟» پارامترهای انتخاب زبان، نسخه و کیفیت را با پارامترهای گزارش‌گیری یکسان در نظر نگیرید. تنظیماتی که برای یک Segment مشترک مناسب است، الزاماً برای Manifest شخصی‌سازی‌شده مناسب نیست.
برای همه مسیرها یک TTL واحد نگذارید
| نوع پاسخ | رویکرد پیشنهادی | شرط مهم |
|---|---|---|
| Segment نسخه‌دار و ثابت | کش طولانی‌تر | محتوا با همان URL بازنویسی نشود |
| Manifest نهایی و نسخه‌دار VOD | کش متناسب با ثابت‌بودن نسخه | همه فایل‌های ارجاع‌شده آماده باشند |
| Manifest شخصی‌سازی‌شده | سیاست جدا، جداسازی دقیق یا عدم کش مشترک | پاسخ یک کاربر به دیگری نرسد |
| API مجوز و پاسخ حساس | جلوگیری از ذخیره نامناسب | تنظیمات CDN با سیاست امنیتی تعارض نداشته باشد |
| خطای موقت ۴۰۴ یا 5xx | TTL خطا بر اساس سناریوی خرابی | خطای گذرا پس از رفع مشکل ماندگار نشود |
در HTTP، max-age عمر تازگی پاسخ و s-maxage سیاست مربوط به کش مشترک را مشخص می‌کند. no-cache به معنی ممنوعیت ذخیره نیست؛ استفاده مجدد به اعتبارسنجی نیاز دارد. no-store دستور عدم ذخیره است. این تفاوت در APIهای مجوز و پاسخ‌های حساس اهمیت دارد.
نمونه زیر صرفاً نقطه شروع آزمایش برای Segment عمومی، ثابت و نسخه‌دار است؛ تنظیم آماده استفاده برای محتوای محافظت‌شده نیست:
Cache-Control: public, max-age=3600, s-maxage=86400
در این مثال تازگی برای کش مشترک یک روز است، اما ماندن فیزیکی فایل در کش تضمین نمی‌شود. CDN می‌تواند فایل را زودتر حذف کند. همچنین محدودیت‌های Minimum و Maximum TTL ارائه‌دهنده بر رفتار نهایی اثر دارند؛ مثلاً در CloudFront، Minimum TTL مثبت می‌تواند حتی در حضور برخی دستورهای منع کش، پاسخ را برای مدت حداقل نگه دارد. تنظیم مسیرهای حساس را با پاسخ واقعی آزمایش کنید.
چگونه فشار روی Origin و خطاهای انتشار را کنترل کنیم؟
آزمون کش سرد را بخشی از ظرفیت‌سنجی کنید
زمان انتشار یک عنوان محبوب، Edgeهای مختلف ممکن است هم‌زمان همان فایل را بخواهند. کش میانی مانند Origin Shield می‌تواند تعداد مراجعه مستقیم را کاهش دهد؛ اما اثر آن به معماری و ارائه‌دهنده وابسته است. قابلیت Request Collapsing نیز درخواست‌های هم‌زمان یک شیء را تجمیع می‌کند و باید رفتار واقعی آن در پیک آزموده شود. برای نمونه، CloudFront این رفتار را در مستندات Origin توضیح می‌دهد.
سه سناریو را جدا تست کنید: محتوای محبوب با کش گرم، انتشار جدید با کش سرد و محتوای کم‌تقاضا با درخواست پراکنده. Pre-warm هدفمند Segmentهای آغازین می‌تواند موضوع یک آزمایش باشد؛ دانلود تمام کتابخانه برای گرم‌کردن کش، بدون اندازه‌گیری بازده، هزینه اضافه ایجاد می‌کند.
انتشار را با نسخه جدید انجام دهید، نه بازنویسی فایل فعال
- خروجی جدید را در مسیر نسخه مستقل بنویسید.
- سلامت Segmentها، زیرنویس و فایل‌های Initialization را بررسی کنید.
- وجود همه منابع ارجاع‌شده در Manifest را تأیید کنید.
- پس از آزمون پخش، ارجاع کاتالوگ یا API را به نسخه جدید تغییر دهید.
- نسخه قبلی را تا پایان پنجره بازگشت و نشست‌های لازم نگه دارید.
این ترتیب، احتمال مواجهه Player با Manifest جدید و فایل ناقص را کاهش می‌دهد. اگر فایل را با همان URL جایگزین کنید، ممکن است بعضی نقاط شبکه نسخه قدیمی و بعضی نسخه جدید را تحویل دهند. Invalidation برای حذف اضطراری مفید است، اما نباید تنها سازوکار روزمره انتشار باشد.
امنیت ذخیره‌سازی و CDN در VOD چگونه حفظ می‌شود؟
کنترل دسترسی باید هم مسیر کاربر به CDN و هم مسیر CDN به Origin را پوشش دهد. اگر لینک CDN امضا دارد اما Storage مستقیماً عمومی است، امکان دورزدن مسیر مجاز باقی می‌ماند. مجوز نوشتن و حذف Pipeline را نیز از دسترسی خواندن سرویس تحویل جدا کنید.
Signed URL یا Signed Cookie می‌تواند دسترسی زمان‌دار را کنترل کند. برای مجموعه فایل‌های یک ویدئو، Cookie امضاشده در پیاده‌سازی‌های پشتیبان آن می‌تواند استفاده از URLهای مشترک را ساده‌تر کند. اعتبار امضا باید پیش از تحویل محتوای محافظت‌شده، حتی در Cache Hit، بررسی شود. حذف Token از Cache Key بدون چنین کنترلی خطر افشای محتوا دارد.
زمان انقضای دسترسی را با طول نشست و سازوکار تمدید هماهنگ کنید. مجوز معتبر در آغاز پخش لزوماً درخواست‌های بعدی را پوشش نمی‌دهد. آزمون امنیت باید کاربر مجاز، Token منقضی، Token دست‌کاری‌شده و درخواست بدون مجوز برای فایلی که از قبل در کش است را شامل شود.
CORS را نیز برای دامنه Player و نوع درخواست واقعی تنظیم کنید؛ CORS جایگزین مجوز دسترسی نیست. در صورت استفاده از Range Request، Seek و پاسخ‌های ۲۰۶ را در مسیر کامل Player تا Storage بررسی کنید. DRM نیز مسئله حفاظت از مصرف محتوا را پوشش می‌دهد و جایگزین سیاست کش یا محدودکردن Origin نیست.
چه شاخص‌هایی را پایش کنیم؟
پایش ذخیره‌سازی و CDN در VOD باید کیفیت تجربه پخش را به رخدادهای زیرساخت متصل کند. میانگین کلی به‌تنهایی کافی نیست؛ داده‌ها را بر اساس منطقه، اپراتور، دستگاه، نسخه محتوا و نوع پاسخ تفکیک کنید.
| لایه | شاخص‌های پیشنهادی | کاربرد عملیاتی |
|---|---|---|
| Player | زمان شروع پخش، نرخ شکست شروع، نسبت بافر و خطای رسانه | تشخیص اثر واقعی اختلال بر مخاطب |
| CDN | Request و Byte Hit Ratio، زمان پاسخ، 4xx و 5xx | تفکیک خطای کش، دسترسی و تحویل |
| Origin | ترافیک خروجی، RPS، اتصال هم‌زمان، p95 و p99 تأخیر | تشخیص فشار Miss و اشباع |
| Storage | تأخیر خواندن، خطا، Throttling، ظرفیت و هزینه درخواست | تشخیص گلوگاه نگهداری یا بازیابی |
| Pipeline | خروجی ناقص، خطای کنترل کیفیت و زمان آماده‌شدن | جلوگیری از انتشار دارایی خراب |
آستانه هشدار را با SLO محصول تعیین کنید. برای مثال، افزایش خطای شروع پخش در یک اپراتور می‌تواند مهم‌تر از افت محدود Hit Ratio کل باشد. در تعریف نسبت بافر نیز مخرج را ثابت نگه دارید تا مقایسه نسخه‌های Player گمراه‌کننده نشود.
جدول عیب‌یابی خطاهای رایج Storage و CDN
| نشانه | فرضیه قابل بررسی | اولین بررسی |
|---|---|---|
| افت ناگهانی Hit Ratio | تغییر Query، Cookie، Header یا TTL | مقایسه درخواست‌های یک فایل پیش و پس از تغییر |
| ۴۰۴ پس از انتشار | Manifest زودتر از فایل‌ها منتشر شده یا خطا کش شده است | وجود شیء در Origin و عمر پاسخ خطا |
| قطع پخش پس از چند دقیقه | انقضای مجوز، خطای Segment یا تغییر مسیر | آخرین درخواست ناموفق و زمان اعتبار مجوز |
| Origin پرفشار با Hit Ratio ظاهراً خوب | تفاوت نسبت درخواستی و بایتی یا بار کش سرد | Byte Hit Ratio و اندازه پاسخ‌های Miss |
| Seek ناموفق | مشکل Range، فایل Initialization یا Packaging | پاسخ شبکه و Log خطای Player |
| نسخه قدیمی تصویر یا ویدئو | بازنویسی URL ثابت و کش‌های ناهمگام | نسخه مسیر، Headerهای پاسخ و وضعیت Invalidation |
این موارد فرضیه‌اند، نه تشخیص قطعی. برای هر Incident، شناسه محتوا، زمان، منطقه، نسخه Player، وضعیت پاسخ و شناسه درخواست را ثبت کنید؛ Token کامل و داده حساس را وارد Log عمومی نکنید.
هزینه کل و بازیابی را در طراحی لحاظ کنید
هزینه را به Storage محدود نکنید: حجم نسخه‌های خروجی، درخواست خواندن، بازیابی از آرشیو، ترافیک Origin، ترافیک CDN، خدمات کش میانی، Log و عملیات هم سهم دارند. برای مقایسه معماری‌ها، «هزینه به ازای ساعت تماشای موفق» را کنار «هزینه نگهداری هر ساعت محتوا» قرار دهید. یک طراحی ممکن است ذخیره‌سازی ارزان‌تری داشته باشد ولی هزینه تحویل یا خطای پخش بیشتری ایجاد کند.
کش را نسخه بازیابی فرض نکنید؛ ممکن است فقط بخشی از Segmentها در بعضی نقاط موجود باشند. بازیابی باید فایل منبع، Metadata، تنظیمات انتشار و دسترسی‌ها را پوشش دهد. مقاله قانون پشتیبان‌گیری ۳–۲–۱ مبنایی برای طراحی نسخه‌های مستقل است؛ زمان بازیابی آرشیو رسانه را نیز با آزمون واقعی مشخص کنید.
اگر Multi-CDN در نظر دارید، علاوه بر ظرفیت و پوشش، همسانی Token، سیاست Cache، Headerها و رفتار Failover را بسنجید. جابه‌جایی به CDN دوم می‌تواند با کش سرد همراه باشد؛ بنابراین موفقیت سوییچ را فقط با پاسخ ۲۰۰ نسنجید و شروع پخش و بافر را هم بررسی کنید.
چک‌لیست دواپس پیش از بهره‌برداری
- فایل منبع، خروجی انتشار و داده عملیاتی سیاست نگهداری جدا دارند.
- انتشار نسخه‌دار و بازگشت به نسخه قبل آزمایش شده است.
- Manifest به فایل ناقص یا ناموجود ارجاع نمی‌دهد.
- Cache Key، TTL و TTL خطا برای هر نوع مسیر مشخص است.
- درخواست بدون مجوز، حتی با کش گرم، به محتوای محافظت‌شده دسترسی ندارد.
- دسترسی مستقیم غیرمجاز به Origin و Storage محدود شده است.
- سناریوهای کش سرد، انتشار پرتقاضا، Seek و انقضای Token آزموده شده‌اند.
- ظرفیت RPS و ترافیک جداگانه اندازه‌گیری شده است.
- شاخص‌های Player، CDN و Origin در یک بازه زمانی قابل تطبیق‌اند.
- بازیابی، حذف اضطراری محتوا و بازگشت پس از Failover راهنمای اجرایی دارند.
پرسش‌های متداول ذخیره‌سازی و CDN در VOD
آیا CDN نیاز به Storage قوی را از بین می‌برد؟
خیر. فایل جدید، محتوای کم‌تقاضا و کش سرد همچنان به Origin و Storage وابسته‌اند. طراحی باید هم نگهداری پایدار و هم پاسخ‌گویی به این درخواست‌ها را پوشش دهد.
آیا Manifest همیشه باید TTL کوتاه داشته باشد؟
خیر. Manifest نهایی و نسخه‌دار VOD با Manifest زنده یا شخصی‌سازی‌شده یکسان نیست. سیاست را بر اساس تغییرپذیری، مجوز و نحوه انتشار تعیین کنید.
آیا Hit Ratio بالا نشانه قطعی کیفیت خوب است؟
خیر. پاسخ‌های کش‌شده هم ممکن است دیر برسند یا محتوای نادرست داشته باشند. Hit Ratio را همراه با زمان شروع پخش، بافر، خطا و پراکندگی جغرافیایی بخوانید.
برای شروع ارزیابی معماری چه اطلاعاتی لازم است؟
ساعات آرشیو و رشد آن، خروجی‌های Encoding، تعداد کاربران هم‌زمان، میانگین Bitrate تحویلی، جغرافیای مخاطب، الگوی محبوبیت، نیاز امنیتی و هدف بازیابی را جمع‌آوری کنید. سپس هزینه و ظرفیت را برای وضعیت عادی، پیک و خرابی مقایسه کنید.
طراحی مناسب ذخیره‌سازی و CDN در VOD زمانی قابل دفاع است که تیم بتواند مسیر هر دارایی را از ذخیره تا پخش ردیابی کند، اثر تغییر سیاست کش را بسنجد و در خرابی، نسخه سالم را با زمان مشخص بازیابی کند. این قابلیت‌ها را پیش از افزایش ظرفیت صرف، به معیار پذیرش معماری تبدیل کنید.