چگونه یک پلتفرم ویدیویی در مقیاس یوتیوب یا نتفلیکس را طراحی کنید؟

در یک مصاحبه از شما به عنوان یک تیم لید یا معمار نرم افزار خواسته می شود وب سایت مشابه یوتیوب را طراحی کنید.

راه حل این سوال را می توان برای سوالات مصاحبه دیگر نیز مانند طراحی یک پلتفرم اشتراک گذاری ویدیو مثل نتفلیکس و ... به کار برد. شکل زیر صفحه اصلی یوتیوب را نشان می دهد.

یوتیوب به نظر ساده می آید: تولیدکنندگان محتوا ویدیوها را آپلود می کنند و بینندگان روی دکمه پخش کلیک می کنند. اما واقعا انقدر ساده است؟

خیر، چنین نیست. زیر این سادگی ظاهری، فناوری های پیچیده ای نهفته است. بیایید به برخی آمار، اطلاعات جمعیت شناختی و حقایق جالب درباره یوتیوب در سال 2024 نگاهی بیندازیم:

• تعداد کاربران فعال ماهانه: حدود 2.5 میلیارد نفر (با توجه به رشد مداوم)

• تعداد ویدیوهای تماشا شده در روز: بیش از 6 میلیارد (افزایش نسبت به 2020)

• بیش از 80 درصد از بزرگسالان آمریکایی از یوتیوب استفاده می کنند (رشد کاربران)

• بیش از 70 میلیون تولیدکننده محتوا در یوتیوب (افزایش تعداد سازندگان)

• درآمد تبلیغاتی یوتیوب در سال 2023 بیش از 20 میلیارد دلار بود (رشد چشمگیر درآمد)

• یوتیوب مسئول بیش از 45 درصد از کل ترافیک اینترنت موبایل است (افزایش ترافیک موبایل)

• یوتیوب در بیش از 90 زبان در دسترس است (گسترش زبان ها)

این آمار نشان می دهد که یوتیوب در سال 2024 از رشد چشمگیری در کاربران، محتوا، درآمد و پوشش جهانی برخوردار شده است.از این آمار می فهمیم که یوتیوب بسیار عظیم، جهانی است و درآمد زیادی کسب می کند.

مرحله 1 - درک مسئله و تعیین محدوده طراحی

همانطور که می دانید علاوه بر تماشای ویدیو، می توانید در یوتیوب کارهای بیشتری انجام دهید. به عنوان مثال، نظر دادن، به اشتراک گذاشتن یا لایک کردن یک ویدیو، ذخیره ویدیو در لیست پخش، مشترک شدن در یک کانال و غیره. طراحی همه این ویژگی ها در یک مصاحبه 45 یا 60 دقیقه ای غیرممکن است. بنابراین، پرسیدن سوال برای محدود کردن محدوده طراحی مهم است.

کاندید: چه ویژگی هایی مهم هستند؟

مصاحبه کننده: قابلیت آپلود و تماشای ویدیو

کاندید: به چه نوع کلاینت هایی باید پشتیبانی کنیم؟

مصاحبه کننده: اپلیکیشن های موبایل، مرورگرهای وب و تلویزیون های هوشمند.

کاندید: چند کاربر فعال روزانه داریم؟

مصاحبه کننده: 5 میلیون

کاندید: میانگین زمان گذرانده شده روزانه در این محصول چقدر است؟

مصاحبه کننده: 30 دقیقه

کاندید: آیا نیاز است از کاربران بین المللی پشتیبانی کنیم؟

مصاحبه کننده: بله، درصد زیادی از کاربران، کاربران بین المللی هستند.

کاندید: رزولوشن های ویدیویی پشتیبانی شده چیست؟

مصاحبه کننده: سیستم اکثر رزولوشن ها و فرمت های ویدیویی را می پذیرد.

کاندید: آیا رمزگذاری مورد نیاز است؟

مصاحبه کننده: بله

کاندید: آیا محدودیتی برای اندازه فایل ویدیوها وجود دارد؟

مصاحبه کننده: پلتفرم ما روی ویدیوهای کوچک و متوسط تمرکز دارد. حداکثر اندازه مجاز ویدیو 1 گیگابایت است.

کاندید: آیا می توانیم از زیرساخت های ابری موجود از آمازون، گوگل یا مایکروسافت استفاده کنیم؟

مصاحبه کننده: این یک سوال عالی است. ساختن همه چیز از ابتدا برای اکثر شرکت ها غیرواقعی است. توصیه می شود از برخی سرویس های ابری موجود استفاده کنید.

پس روی طراحی یک سرویس استریم ویدیو با ویژگی های زیر تمرکز می کنیم:

• قابلیت آپلود سریع ویدیوها

• استریم روان ویدیو

• قابلیت تغییر کیفیت ویدیو

• هزینه زیرساخت پایین

• نیازمندی های قابلیت اطمینان، مقیاس پذیری و در دسترس بودن بالا

• کلاینت های پشتیبانی شده: اپلیکیشن های موبایل، مرورگر وب و تلویزیون هوشمند

برآورد تقریبی هزینه

برآوردهای زیر بر اساس فرضیات زیادی انجام شده اند، بنابراین ارتباط با مصاحبه کننده برای اطمینان از همسو بودن مهم است:

• فرض کنید محصول 5 میلیون کاربر فعال روزانه (DAU) دارد.

•کاربران در روز 5 ویدیو تماشا می کنند.

• 10 درصد کاربران در روز 1 ویدیو آپلود می کنند.

• فرض کنید اندازه متوسط هر ویدیو 300 مگابایت است.

• فضای ذخیره سازی روزانه مورد نیاز کل: 5 میلیون * 10% * 300 مگابایت = 150 ترابایت

· هزینه CDN

زمانی که CDN ابری یک ویدیو را سرویس می دهد، برای ترافیک خروجی از CDN هزینه می پردازید.

برای برآورد هزینه از CDN CloudFront آمازون استفاده می کنیم. فرض کنید 80% ترافیک از ایالات متحده و 20% از سایر نقاط جهان سرویس داده می شود. هزینه متوسط هر گیگابایت در ایالات متحده 0.015 دلار و در سایر مناطق 0.02 دلار است.

10 میلیون * 6 ویدیو * 0.4 گیگابایت * (0.80.015 + 0.20.02) دلار = 360,000 دلار در روز

با افزایش کاربران به 10 میلیون نفر در سال 2024 و میانگین 6 ویدیو در روز برای هر کاربر و اندازه متوسط 0.4 گیگابایت برای هر ویدیو، هزینه استریم از CDN برای پوشش جهانی به 360,000 دلار در روز می رسد.

مرحله 2 - ارائه طرح کلی و کسب تأیید

همانطور که قبلاً بحث شد، مصاحبه کننده توصیه کرد از سرویس های ابری موجود به جای ساختن همه چیز از ابتدا استفاده کنیم.

برخی خوانندگان ممکن است بپرسند چرا همه چیز را خودمان نمی سازیم؟ دلایل در زیر آمده است:

مصاحبه های طراحی سیستم درباره ساختن همه چیز از ابتدا نیست. در محدوده زمانی محدود، انتخاب فناوری مناسب برای انجام کار درست مهمتر از توضیح جزئیات نحوه کار فناوری است. به عنوان مثال، ذکر ذخیره سازی بلاب (Blob) برای ذخیره ویدیوهای منبع برای مصاحبه کافی است. صحبت درباره جزئیات طراحی ذخیره سازی بلاب می تواند زیاده روی باشد.

ساختن ذخیره سازی بلاب یا CDN مقیاس پذیر بسیار پیچیده و پرهزینه است. حتی شرکت های بزرگی مانند نتفلیکس یا فیسبوک همه چیز را خودشان نمی سازند. نتفلیکس از سرویس های ابری آمازون استفاده می کند و فیسبوک از CDN Akamai استفاده می کند.

در سطح کلی، سیستم شامل سه جزء است :

کلاینت(Client): می توانید یوتیوب را روی کامپیوتر، گوشی موبایل و تلویزیون هوشمند خود تماشا کنید.

سی دی ان (CDN) : ویدیوها در CDN (شبکه دلیوری محتوا) ذخیره می شوند. هنگامی که دکمه پخش را می زنید، یک ویدیو از CDN استریم (پخش) می شود.

سرورهای API: هر چیزی به جز پخش ویدیو، از طریق سرورهای APIانجام می گردد. این موارد شامل پیشنهاد فید، ایجاد لینک آپلود برای ویدیو، بروزرسانی پایگاه داده و کش متادیتا، ثبت نام کاربران و غیره است.

در جلسه پرسش و پاسخ، مصاحبه کننده به دو جریان کاری زیر علاقه نشان داد:

• جریان آپلود ویدیو

• جریان پخش ویدیو

ما طرح کلی را برای هر یک از این دو جریان کار بررسی خواهیم کرد.

طرح کلی جریان آپلود ویدیو

طرح کلی جریان آپلود ویدیو این جریان شامل اجزای زیر است:

یوزر User: یک کاربر یوتیوب را در دستگاه هایی مانند کامپیوتر، گوشی موبایل یا تلویزیون هوشمند تماشا می کند.

لود بالانسر Load balancer: یک لود بَلَنسر درخواست ها را به طور یکنواخت بین سرورهای API توزیع می کند.

ای پی ای سرور API servers: تمام درخواست های کاربران به جز پخش ویدیو، از طریق سرورهای API انجام می شود.

متا دیتا دی بی Metadata DB: متادیتای ویدیوها در پایگاه داده متادیتا ذخیره می شود. این پایگاه داده شاردشده و تکثیرشده است تا نیازمندی های عملکرد و قابلیت دسترسی بالا را برآورده کند.

متا کش Metadata cache: برای عملکرد بهتر، متادیتای ویدیو و اشیاء کاربر در کش نگهداری می شوند.

اورجین استوریچ Original storage: یک سیستم ذخیره سازی بلاب برای ذخیره ویدیوهای اصلی استفاده می شود. بر اساس گفته ای در ویکی پدیا: "یک بلاب شیء باینری بزرگ (BLOB) مجموعه ای از داده های باینری است که به عنوان یک موجودیت واحد در یک سیستم مدیریت پایگاه داده ذخیره می شود.

ترنسکدینگ Transcoding servers: ترنسکدینگ ویدیو همان کدگذاری ویدیو است. این فرآیند تبدیل یک فرمت ویدیو به فرمت های دیگر (MPEG، HLS و غیره) را شامل می شود تا بهترین استریم ویدیو برای دستگاه ها و ظرفیت های پهنای باند مختلف فراهم شود.

استوریج Transcoded storage: یک ذخیره سازی بلاب است که فایل های ویدیوی ترنسکدشده را ذخیره می کند.

سی دی ان CDN: ویدیوها در CDN(cache) می شوند. زمانی که دکمه پخش را می زنید، یک ویدیو از CDN استریم می شود.

صف پیام Completion queue: یک صف پیام است که اطلاعات مربوط به رویدادهای تکمیل ترنسکدینگ ویدیو را ذخیره می کند.

هندلر Completion handler: شامل یک مجموعه از مصرف کننده های صف (queue consumers) است که داده های رویداد را از صف تکمیل می خوانند و کش متادیتا و پایگاه داده را بروزرسانی می کنند.

اکنون که هر جزء را به طور جداگانه می شناسیم، بیایید ببینیم که چگونه جریان آپلود ویدیو کار می کند. این جریان به دو فرآیند موازی تقسیم می شود:

الف. آپلود ویدیوی واقعی

ب. بروزرسانی متادیتای ویدیو.

متادیتا شامل اطلاعاتی در مورد URLویدیو، اندازه، رزولوشن، فرمت، اطلاعات کاربر و غیره

چرخه آپلود ویدیوی:

1. ویدیوها روی سیستم ذخیره سازی اصلی آپلود می شوند.

2. سرورهای ترنسکدینگ ویدیوها را از ذخیره سازی اصلی می خوانند و شروع به ترنسکدینگ می کنند.

3. پس از اتمام ترنسکدینگ، دو مرحله زیر به صورت موازی اجرا می شوند:

الف. ویدیوهای ترنسکدشده به ذخیره سازی ترنسکدشده ارسال می شوند.

ب. رویدادهای اتمام ترنسکدینگ در صف تکمیل قرار می گیرند:

الف. ویدیوهای ترنسکدشده به CDNتوزیع می شوند.

ب.. هندلر تکمیل شامل مجموعه ای از مصرف کننده های صف است که به طور مداوم داده های رویداد را از صف می خوانند.

پس از اتمام ترنسکدینگ ویدیو بروزرسانی می کند.

4. ای پی ای API ها به کلاینت اطلاع می دهند که ویدیو با موفقیت آپلود شده و آماده پخش است.

بسیار خوب، جمله را با توضیح کامل تر در مورد "ذخیره سازی اصلی" می نویسم:

جریان ب: بروزرسانی متادیتا

در حالی که یک فایل ویدیوی اصلی در حال آپلود به سیستم ذخیره سازی بلاب (blob storage) اصلی است، کلاینت به موازات یک درخواست برای بروزرسانی متادیتای ویدیو ارسال می کند، همانطور که در شکل زیر نشان داده شده است. ذخیره سازی بلاب اصلی یک سرویس ابری برای ذخیره فایل های ویدیویی منبع با اندازه بزرگ و ساختار نامشخص است. این درخواست شامل متادیتای ویدیو از جمله نام فایل، اندازه، فرمت و غیره است. سرورهای API کش متادیتا و پایگاه داده را بر اساس اطلاعات ارسالی بروزرسانی می کنند.

جریان استریم ویدیو

هر زمان که شما یک ویدیو در یوتیوب را تماشا می کنید، معمولاً استریم بلافاصله شروع می شود و منتظر دانلود کامل ویدیو نمی مانید. دانلود به این معنی است که کل ویدیو به دستگاه شما کپی می شود، در حالی که استریم به این معنی است که دستگاه شما به طور مداوم جریان های ویدیویی را از منابع ویدیویی راه دور دریافت می کند. هنگام تماشای ویدیوهای استریم، کلاینت شما مقداری از داده را در هر بار بارگذاری می کند تا بتوانید ویدیوها را بلافاصله و بدون وقفه تماشا کنید.

قبل از اینکه جریان استریم ویدیو را بررسی کنیم، یک مفهوم مهم را مرور می کنیم: پروتکل استریم. این یک روش استاندارد برای کنترل انتقال داده برای استریم ویدیو است. پروتکل های استریم پرطرفدار عبارتند از:

•پروتکل MPEG-DASH. MPEG مخفف "گروه متخصصان تصاویر متحرک" و DASH مخفف "استریم تطبیقی پویا از طریق HTTP" است.

•پروتکل Apple HLS. HLS مخفف "استریم زنده از طریق HTTP" است.

•پروتکل Microsoft Smooth Streaming.

• پروتکل Adobe HTTP Dynamic Streaming (HDS).

شما نیازی ندارید که این نام های پروتکل استریم را کاملاً بفهمید یا حتی به خاطر بسپارید، زیرا آنها جزئیات سطح پایین هستند که نیازمند دانش تخصصی خاص در این حوزه است. نکته مهم در اینجا درک این است که پروتکل های استریم مختلف از کدگذاری های ویدیویی و پلیرهای پخش متفاوتی پشتیبانی می کنند. هنگام طراحی یک سرویس استریم ویدیو، باید پروتکل استریم مناسب را برای پشتیبانی از موارد استفاده خود انتخاب کنید. برای اطلاعات بیشتر در مورد پروتکل های استریم، اینجا یک مقاله عالی وجود دارد .

ویدیوها به طور مستقیم از CDN استریم می شوند. نزدیک ترین سرور به شما، ویدیو را ارائه خواهد کرد. بنابراین، تاخیر بسیار کمی وجود دارد.

عمیق‌تر شدن در طراحی

در طراحی سطح بالا، کل سیستم به دو بخش بارگذاری ویدیو و جریان پخش ویدیو تقسیم شده است. در این بخش، هر دو جریان را با بهینه سازی های مهم و معرفی مکانیزم های رفع خطا، تکمیل خواهیم کرد.

رمزگذاری مجدد ویدیو

زمانی که یک ویدیو را ضبط می کنید، دستگاه (معمولاً گوشی یا دوربین) به فایل ویدیو یک فرمت خاصی می دهد. اگر می خواهید ویدیو به صورت صاف روی دستگاه های دیگر پخش شود، باید ویدیو را به نرخ بیت و فرمت های سازگار رمزگذاری کنید. نرخ بیت میزان پردازش بیت در واحد زمان است. یک نرخ بیت بالاتر معمولاً به معنای کیفیت ویدیو بالاتر است. جریان های با نرخ بیت بالا نیازمند توان پردازش و سرعت اینترنت بالا هستند.

رمزگذاری مجدد ویدیو به دلایل زیر مهم است:

• ویدیوی خام حجم زیادی از فضای ذخیره سازی را اشغال می کند. یک ویدیوی تعریف بالا یک ساعته که با 60 فریم در ثانیه ضبط شده است، می تواند چندصد گیگابایت فضا اشغال کند.

• بسیاری از دستگاه ها و مرورگرها تنها پشتیبانی از انواع خاصی از فرمت ویدیو را دارند. بنابراین برای سازگاری، رمزگذاری ویدیو به فرمت های مختلف ضروری است.

• برای اطمینان از اینکه کاربران ویدیوهای با کیفیت بالا را تماشا می کنند و در عین حال پخش صاف را نیز تجربه می کنند،ارائه ویدیوی با رزولوشن بالاتر به کاربرانی که پهنای باند بالایی دارند و ویدیوی با رزولوشن پایین تر به کاربرانی که پهنای باند پایینی دارند، یک ایده خوب است.

• شرایط شبکه می تواند تغییر کند،به خصوص در دستگاه های تلفن همراه. برای اطمینان از پخش پیوسته ویدیو، امکان تغییر کیفیت ویدیو به صورت خودکار یا دستی بر اساس شرایط شبکه، برای تجربه کاربری صاف ضروری است.

انواع مختلفی از فرمت های رمزگذاری وجود دارد؛ اما بیشتر آنها شامل دو بخش هستند:

• کانتینر: این مانند یک سبد است که فایل ویدیو، صدا و متادیتا را در خود جای می دهد. می توانید فرمت کانتینر را از طریق پسوند فایل، مانند .avi، .mov یا .mp4تشخیص دهید.

• کدک ها: الگوریتم های فشرده سازی و فشرده گشایی هستند که هدفشان کاهش اندازه ویدیو در حالی که کیفیت ویدیو را حفظ می کنند. پرکاربردترین کدک های ویدیویی عبارتند از H.264، VP9 و HEVC.

مدل گراف بی چرخه جهت دار (DAG Directed acyclic graph)

رمزگذاری مجدد یک ویدیو بسیار پرهزینه از نظر محاسباتی و زمان گیر است. علاوه بر این، ممکن است سازندگان محتوا نیازمندی های مختلفی برای پردازش ویدیو داشته باشند. به عنوان مثال، برخی سازندگان محتوا ممکن است نیازمند درج واترمارک بر روی ویدیوهای خود باشند، برخی تصاویر کوچکی را کنار ویدیو خودشان آپلود می کنند در حالی که دیگران این کار را نمی کنند. برای پشتیبانی از خط پردازش ویدیوهای مختلف و حفظ موازی سازی بالا، ایجاد سطحی از انتزاع و اجازه دادن به برنامه نویسان برای تعریف کارهایی که باید اجرا شوند، مهم است. به عنوان مثال، موتور پخش ویدیوی فیس بوک از یک مدل برنامه نویسی گراف بی چرخه جهت دار (DAG) استفاده می کند که کارها را در مراحل مختلف تعریف می کند تا بتوانند به صورت متوالی یا موازی اجرا شوند .

در طراحی ما، ما نیز از یک مدل DAG مشابه برای دستیابی به انعطاف پذیری و موازی سازی استفاده می کنیم.

شکل زیر یک DAG برای رمزگذاری مجدد ویدیو را نشان می دهد.

در شکل زیر ، ویدیوی اصلی به ویدیو، صدا و متادیتا تقسیم می شود. برخی از کارهایی که می تواند بر روی یک فایل ویدیویی اعمال شود، عبارتند از:

• بازرسی: اطمینان از کیفیت خوب ویدیوها و عدم وجود اشکال در آنها.

• رمزگذاری ویدیو: ویدیوها برای پشتیبانی از رزولوشن های مختلف، کدک، نرخ بیت و غیره تبدیل می شوند.

• تصویر بندانگشتی: تصاویر بندانگشتی می توانند توسط کاربر بارگذاری شوند یا به طور خودکار توسط سیستم تولید شوند.

• واترمارک: یک تصویر روی ویدیوی شما که حاوی اطلاعات شناسایی در مورد ویدیوی شماست.

معماری رمزگذاری مجدد ویدیو

معماری پیشنهادی برای رمزگذاری مجدد ویدیو که از خدمات ابری بهره می برد، در شکل زیر نشان داده شده است.

این معماری شش جزء اصلی دارد: پیش پردازشگر، برنامه‌ریز DAG، مدیر منابع، نیروهای کاری، ذخیره‌سازی موقت و ویدیوی رمزگذاری شده به عنوان خروجی. بیایید نگاهی دقیق به هر یک از این اجزا بیندازیم.

پیش پردازشگر

پیش پردازشگر چهار مسئولیت اصلی دارد:

1. تقسیم ویدیو. جریان ویدیو به گروه های کوچکتر تصاویر (GOP) تقسیم یا تقسیم بندی بیشتر می شود. GOP یک گروه/بلوک از فریم هایی است که به ترتیب خاصی چیده شده اند. هر بلوک یک واحد قابل پخش مستقل است که معمولا چند ثانیه طول می کشد.

2. برخی از دستگاه های موبایل قدیمی یا مرورگرها ممکن است از تقسیم ویدیو پشتیبانی نکنند. پیش پردازشگر ویدیوها را با تراز GOP برای مشتریان قدیمی تقسیم می کند.

3. تولید DAG. پردازشگر براساس فایل های پیکربندی که برنامه نویسان می نویسند، DAG را تولید می کند.

4. پیش پردازنده یک حافظه نهان برای ویدیوهای تقسیم شده ایجاد می کند. برای افزایش قابلیت اطمینان، پیش پردازنده بخش‌های ویدیو (GOP) و اطلاعات توصیفی (متادیتا) را در یک فضای ذخیره‌سازی موقت نگهداری می‌کند. در صورت شکست در رمزگذاری ویدیو، سیستم می‌تواند از داده‌های ذخیره شده برای تلاش‌های مجدد استفاده کند.

برنامه‌ریز گراف DAG

گراف DAGوظایف واگذار شده رو تقسیم می‌کند و آنها را در صف وظایف به مدیر منابع می دهد

همانطور که در شکل زیر نشان داده شده است،

ویدیوی اصلی به سه بخش تقسیم می‌شود:

ویدیو، صدا و متادیتا

فایل ویدیو خودش به دو بخش دیگر رمزگذاری ویدیو و تصاویر بندانگشتی تقسیم می شود

فایل صوتی هم نیاز به رمزگذاری صدا به عنوان بخشی از وظایف دارد.

مدیر منابع

مدیر منابع مسئول مدیریت کارایی تخصیص منابع را دارد که شامل سه صف و یک برنامه‌ریز وظایف است،

1. صف وظایف (Task Queue): یک صف اولویت دار که شامل وظایف در انتظار اجرا می‌باشد.

2. صف پردازنده ها (Worker Queue): این یک صف با اولویت است که شامل اطلاعات استفاده از پردازنده ها می‌باشد.

3. صف در حال اجرا (Running Queue): این صف شامل اطلاعات مربوط به وظایف و پردازنده های در حال اجرا می‌باشد.

4. برنامه‌ریز وظایف (Task Scheduler): بهترین وظیفه/پردازنده را انتخاب می‌کند و به پردازنده انتخاب شده دستور اجرای کار را می‌دهد.

عملکرد مدیر منابع به این شرح است:

- برنامه‌ریز وظایف، وظیفه با بالاترین اولویت را از صف وظایف دریافت می‌کند.

- برنامه‌ریز وظایف، بهترین پردازنده را برای اجرای وظیفه از صف پردازنده ها را انتخاب می‌کند.

- برنامه‌ریز وظایف به پردازنده انتخاب شده دستور اجرای وظیفه را می‌دهد.

- برنامه‌ریز وظایف، اطلاعات وظیفه/پردازنده را پیوند می‌دهد و در صف در حال اجرا قرار می‌دهد.

- برنامه‌ریز وظایف، پس از اتمام کار، آن را از صف در حال اجرا حذف می‌کند.

ذخیره ساز موقت:

در این سیستم از چندین سیستم ذخیره سازی استفاده می شود. انتخاب سیستم ذخیره سازی بستگی به عواملی مانند نوع داده، اندازه داده، تناوب دسترسی، طول عمر داده و غیره دارد. به عنوان مثال، پردازنده ها به طور مکرر به متادیتا دسترسی دارند و معمولا اندازه داده ها کوچک است. بنابراین، ذخیره سازی متادیتا در حافظه ایده خوبی است. برای داده های ویدیویی یا صوتی، آنها را در ذخیره سازی Blobقرار می دهیم. داده های موجود در ذخیره ساز موقت، پس از تکمیل پردازش ویدیوی مربوطه، آزاد می شوند.

بهینه سازی سیستم: در این مرحله، شما باید درک خوبی از جریان آپلود ویدیو، جریان استریم ویدیو و کدگذاری مجدد ویدیو داشته باشید. در ادامه، با بهینه سازی هایی شامل سرعت، ایمنی و صرفه جویی در هزینه، سیستم را بهبود می بخشیم.

بهینه سازی سرعت: آپلود موازی ویدیو

آپلود یک ویدیو به صورت یکپارچه ناکارآمد است. می توانیم ویدیو را با تراز GOPبه قطعات کوچک تر تقسیم کنیم، همانطور که در شکل زیر نشان داده شده است. این امکان آپلود با قابلیت از سرگیری سریع را در صورت شکست آپلود قبلی فراهم می کند. وظیفه تقسیم فایل ویدیو با تراز GOP می تواند توسط کلاینت برای بهبود سرعت آپلود پیاده سازی شود،

بهینه سازی سرعت: قرار دادن مراکز آپلود نزدیک به کاربران

راه دیگر برای بهبود سرعت آپلود، ایجاد چندین مرکز آپلود در سراسر جهان است ، افراد در ایالات متحده می توانند ویدیوها را به مرکز آپلود آمریکای شمالی آپلود کنند و افراد در چین می توانند ویدیوها را به مرکز آپلود آسیایی آپلود کنند. برای انجام این کار، از CDN به عنوان مراکز آپلود استفاده می کنیم.

بهینه سازی سرعت: موازی سازی همه جانبه

دستیابی به تاخیر پایین نیازمند تلاش‌های جدی است. یک روش بهینه‌سازی دیگر، ایجاد یک سیستم گسسته و فعال‌سازی موازی‌سازی بالا است. طراحی ما نیازمند برخی تغییرات برای دستیابی به موازی‌سازی بالا است. بیایید به جریان انتقال یک ویدیو از فضای ذخیره‌سازی اصلی به CDN نزدیک‌تر شویم. این جریان در شکل زیر نشان داده شده است که خروجی بستگی به ورودی مرحله قبلی دارد. این وابستگی، موازی‌سازی را دشوار می‌کند. برای ایجاد یک سیستم گسسته‌تر، ما صف‌های پیام را همانطور که در شکل قبلی نشان داده شده است، معرفی کردیم.

بیایید با یک مثال توضیح دهیم که چگونه صف‌های پیام، سیستم را گسسته‌تر می‌کنند:

- قبل از معرفی صف پیام، ماژول رمزگذاری باید منتظر خروجی ماژول دانلود بماند.

- بعد از معرفی صف پیام، ماژول رمزگذاری دیگر نیازی به انتظار برای خروجی ماژول دانلود ندارد. اگر رویدادهایی در صف پیام وجود داشته باشد، ماژول رمزگذاری می‌تواند آن کارها را به صورت موازی اجرا کند.

بهینه سازی ایمنی: آدرس آپلود از پیش امضا شده

ایمنی یکی از مهمترین جنبه های هر محصول است. برای اطمینان از آپلود ویدیوها توسط کاربران مجاز در مکان درست، از آدرس های از پیش امضا شده استفاده می کنیم.

جریان آپلود به شرح زیر به روز شده است:

1. کلاینت یک درخواست HTTPبه سرورهای API برای دریافت آدرس از پیش امضا شده ارسال می کند که اجازه دسترسی به شیء شناسایی شده در آدرس را می دهد. اصطلاح آدرس از پیش امضا شده برای آپلود فایل ها به Amazon S3استفاده می شود. ارائه دهندگان دیگر سرویس ابری ممکن است از نام متفااتی استفاده کنند. به عنوان مثال، Microsoft Azure Blob Storageاز همین ویژگی با نام "Shared Access Signature" پشتیبانی می کند.

2. سرورهای API به آدرس از پیش امضا شده پاسخ می دهند.

3. پس از دریافت پاسخ، کلاینت ویدیو را با استفاده از آدرس از پیش امضا شده آپلود می کند.

بهینه سازی ایمنی: ویدیوهای خود را محافظت کنید

بسیاری از سازندگان محتوا از آپلود ویدیو های آنلاین واهمه دارند زیرا نگران سرقت ویدیوهای اصلی هستند. برای محافظت از ویدیوهای دارای کپی رایت، می توانیم یکی از سه گزینه ایمنی زیر را اعمال کنیم:

• سیستم های مدیریت حقوق دیجیتال (DRM):

سه سیستم DRM اصلی Apple FairPlay، Google Widevineو Microsoft PlayReady هستند.

• رمزگذاری AES: می توانید یک ویدیو را رمزگذاری کنید و یک سیاست احراز هویت پیکربندی کنید. ویدیوی رمزگذاری شده در زمان پخش رمزگشایی می شود. این امر اطمینان می دهد که فقط کاربران مجاز می توانند یک ویدیوی رمزگذاری شده را تماشا کنند.

• واترمارک تصویری: این یک تصویر روی ویدیوی شماست که حاوی اطلاعات شناسایی برای ویدیوی شماست. می تواند لوگو یا نام شرکت شما باشد.

بهینه سازی و صرفه جویی در هزینه

سی دی ان CDN یک جزء حیاتی سیستم ما است. که تحویل سریع ویدیو در مقیاس جهانی را تضمین می کند. اما از محاسبات سرانگشتی می دانیم که CDNگران است، به ویژه زمانی که اندازه داده بزرگ است. چگونه می توانیم هزینه را کاهش دهیم؟ تحقیقات قبلی نشان می دهد که جریان ویدیویی یوتیوب از توزیع دنباله بلند پیروی می کند. این بدان معناست که تعداد کمی از ویدیوهای محبوب به طور مکرر دسترسی می شوند اما بسیاری دیگر تعداد کم یا هیچ بیننده ای ندارند. بر اساس این مشاهده، چند بهینه سازی را پیاده می کنیم:

1. فقط ویدیوهای محبوب را از CDN ارائه کنید و سایر ویدیوها را از ظرفیت زیر ساخت خودمون استفاده کنیم.

2. برای محتوای با محبوبیت کمتر ، ممکن است نیازی به ذخیره نسخه های رمزگذاری شده متعدد ویدیو نباشد. ویدیوهای کوتاه می توانند در زمان درخواست رمزگذاری شوند.

3. برخی ویدیوها فقط در مناطق خاصی محبوب هستند. نیازی به توزیع این ویدیوها در سایر مناطق نیست.

4. مانند نتفلیکس، CDN خودتان را بسازید و با ارائه دهندگان خدمات اینترنت (ISP) همکاری کنید. ساخت CDN خود یک پروژه عظیم است؛ با این حال، این می تواند برای شرکت های بزرگ استریمینگ منطقی باشد. یک ISP می تواند Comcast، AT&T، Verizon یا ارائه دهندگان دیگر اینترنت باشد. ISP ها در سراسر جهان واقع شده اند و به کاربران نزدیک هستند. با مشارکت با ISP ها، می توانید تجربه تماشا را بهبود بخشید و هزینه پهنای باند را کاهش دهید.

تمام این بهینه سازی ها بر اساس محبوبیت محتوا، الگوی دسترسی کاربر، اندازه ویدیو و غیره است. قبل از انجام هر بهینه سازی، تجزیه و تحلیل الگوهای تماشای تاریخی مهم است.

پردازش خطا

برای یک سیستم در مقیاس بزرگ، خطاهای سیستمی اجتناب‌ناپذیر است. برای ایجاد یک سیستم با تحمل‌پذیری خطای بالا، باید خطاها را به نحو مناسب مدیریت کنیم و به سرعت بازیابی شویم.

در این سیستم با دو نوع خطا مواجه هستیم :

• خطای قابل بازیابی. برای خطاهای قابل بازیابی مانند شکست در رمزگذاری بخشی از ویدیو، ایده اصلی این است که عملیات را چندین بار تکرار کنیم. اگر وظیفه همچنان با شکست مواجه شود و سیستم معتقد باشد که قابل بازیابی نیست، کد خطای مناسب را به کلاینت برمی‌گرداند.

• خطای غیرقابل بازیابی. برای خطاهای غیرقابل بازیابی مانند فرمت ویدیوی نامناسب، سیستم وظایف در حال اجرای مرتبط با ویدیو را متوقف می‌کند و کد خطای مناسب را به کلاینت برمی‌گرداند.

خطاهای معمول برای هر جزء سیستم

• خطای آپلود: چندین بار تلاش کنید.

• خطای تقسیم ویدیو: اگر نسخه‌های قدیمی‌تر کلاینت نتوانند ویدیوها را با تراز GOP تقسیم کنند، کل ویدیو به سرور ارسال می‌شود. وظیفه تقسیم ویدیوها در سمت سرور انجام می‌شود.

• خطای رمزگذاری: تلاش مجدد.

• خطای پیش‌پردازنده: نمودار DAGرا دوباره ایجاد کنید.

• خطای برنامه‌ریز DAG: وظیفه را دوباره زمانبندی کنید.

• صف مدیر منابع از کار افتاد: از یک نسخه پشتیبان استفاده کنید.

• پردازنده وظیفه از کار افتاد: وظیفه را روی یک پردازنده جدید تکرار کنید.

• سرور API از کار افتاد: سرورهای API بدون وضعیت هستند، بنابراین درخواست‌ها به یک سرور APIدیگر هدایت می‌شوند.

• سرور کش متادیتا از کار افتاد: داده‌ها چندین بار تکثیر می‌شوند. اگر یک گره از کار بیفتد، می‌توانید از گره‌های دیگر برای دریافت داده‌ها استفاده کنید. می‌توانیم یک سرور کش جدید را برای جایگزینی سرور از کارافتاده راه‌اندازی کنیم.

• سرور پایگاه داده متادیتا از کار افتاد:

- اگر نود اصلی (primary) از کار بیفتد، یکی از نودهای پشتیبان (secondary) را به عنوان نود اصلی جدید ارتقا دهید.

- اگر یک نود پشتیبان از کار بیفتد، می توانید از یک نود پشتیبان دیگر برای خواندن داده استفاده کنید و یک سرور پایگاه داده جدید را به جای نود از کار افتاده راه اندازی نمایید.

جمع‌بندی

اگر در انتهای مصاحبه زمان اضافی باقی مانده باشد، اینجا چند نکته اضافی وجود دارد:

• مقیاس‌پذیری سطح API: از آنجایی که سرورهای APIبدون وضعیت هستند، مقیاس‌پذیری افقی سطح APIآسان است.

• مقیاس‌پذیری پایگاه داده: می‌توانید درباره تکثیر و شاردینگ پایگاه داده صحبت کنید.

• استریم زنده: به فرایند ضبط و پخش ویدیو در زمان واقعی اشاره دارد. اگرچه سیستم ما به طور خاص برای استریم زنده طراحی نشده است، استریم زنده و استریم غیرزنده شباهت‌هایی دارند: هر دو نیازمند آپلود، رمزگذاری و استریمینگ هستند. تفاوت‌های قابل توجه عبارتند از:

- استریم زنده نیاز به تاخیر کمتری دارد، بنابراین ممکن است نیازمند پروتکل استریمینگ متفاوتی باشد.

- استریم زنده نیاز به موازی‌سازی کمتری دارد، زیرا قطعات کوچک داده در زمان واقعی پردازش می‌شوند.

- استریم زنده نیازمند مجموعه‌های متفاوتی از پردازش خطا است. هر پردازش خطایی که زمان زیادی را می‌گیرد، قابل قبول نیست.

• حذف ویدیو: ویدیوهایی که حقوق مالکیت معنوی، مستهجن یا سایر اعمال غیرقانونی را نقض می‌کنند، باید حذف شوند. برخی از آنها ممکن است در طول فرایند آپلود توسط سیستم کشف شوند، در حالی که برخی دیگر ممکن است از طریق گزارش کاربران کشف شوند.