بررسی معماری نرم‌افزار Netflix و Spotify

همه ما با خدماتی که Netflix ارائه می‌دهد، آشنا هستیم. فیلم‌هایی در دسته‌بندی‌های بزرگ و متنوع و همین‌طور محتوای تلویزیونی را این نرم‌افزار مدیریت می‌کند. Netflix در ازای پرداخت هزینه‌ی ماهانه از طرف کاربران، اجازه دسترسی به این محتواها را می‌دهد. Netflix بیش از 180 میلیون کاربر در بیش از 200 کشور جهان دارد. Netflix روی دو ابر AWS و Open Connect کار می‌کند. این دو ابر به عنوان ستون فقرات Netflix با هم کار می‌کنند و هر دو مسئولیت بالایی در ارائه بهترین ویدیو به کاربران دارند. در شکل زیر معماری این نرم‌افزار محبوب را در سطح بالا مشاهده می‌کنید.

Client :

رابط کاربری که برای پخش ویدیوهای Netflix استفاده می‌شود. مانند تلویزیون، XBOX، لپ‌تاپ یا تلفن همراه.

OC or Netflix Content delivery network(CDN) :

شبکه‌ای از سرورهای توزیع شده در مکان‌های جغرافیایی مختلف است وOpen Connect ، CDN جهانی سفارشی خود Netflix است. OC، همه چیزهایی را که مستلزم پخش ویدئو است را مدیریت می‌کند. در مکان‌های مختلف توزیع می‌شود و با فشار دادن دکمه پخش توسط کاربر، ویدیو از این مؤلفه در دستگاه کاربر نمایش داده می‌شود. بنابراین برای مثال اگر می‌خواهید ویدیو را در آفریقای شمالی پخش کنید، ویدیو از نزدیک‌ترین OC (یا سرور) به جای سرور اصلی (به علت پاسخ سریع‌تر از نزدیک‌ترین سرور) ارائه می‌شود.

Database :

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

حال وقت آن رسیده به مولفه‌ها و نحوه کار Netflix بپردازیم.

چگونه Netflix یک فیلم را نمایش می‌دهد؟

ویدیوها و محتوای بسیار باکیفیتی را از تولیدکنندگان دریافت می‌کند و نمایش می‌دهد، بنابراین قبل از ارائه ویدیوها به کاربران، پیش پردازش‌هایی را قاعدتا انجام می‌دهد. Netflix از بیش از 2200 دستگاه پشتیبانی می‌کند و هر یک از آنها به وضوح تصویر و فرمت‌های متفاوتی نیاز دارند. برای اینکه ویدیوها در دستگاه‌های مختلف قابل مشاهده باشند، Netflix رمزگذاری را انجام می‌دهد، که شامل یافتن خطاها و تبدیل ویدیوی اصلی به فرمت‌ها و وضوح‌های تصویر مختلف است. Netflix بهینه‌سازی فایل را برای سرعت های مختلف شبکه ایجاد می‌کند. کیفیت یک ویدیو زمانی خوب است که ویدیو را با سرعت بالای شبکه تماشا می‌کنید. Netflix چندین کپی برای یک فیلم با وضوح های مختلف ایجاد می‌کند. این کپی‌ها نیاز به رمزگذاری و پیش پردازش زیادی دارند. Netflix ویدیوی اصلی را به تکه‌های کوچک‌تر تقسیم می‌کند و با استفاده از کارگران موازی در AWS، این تکه‌ها را به فرمت‌های مختلف (مانند mp4، gp3 و غیره) در وضوح‌های تصویر مختلف (مانند 4k، 1080p و غیره) تبدیل می‌کند. پس از رمزگذاری، فایل‌های ‌کپی‌ ساخته شده، به تمام سرورهای مختلف که در مکان‌های جغرافیایی متفاوت توزیع شده‌اند منتقل می‌شوند.

هنگامی که کاربر، Netflix را روی دستگاه خود اجرا می‌کند، ابتدا نمونه های AWS نمایش داده می‌شوند که برخی از وظایف مانند ورود به سیستم، جستجو، سابقه کاربر، صفحه اصلی، صورت‌حساب، پشتیبانی مشتری و غیره را انجام می‌دهند. پس از آن، زمانی که کاربر دکمه پخش را روی یک ویدیو می‌زند، Netflix سرعت شبکه یا ثبات اتصال را تجزیه و تحلیل می‌کند و سپس بهترین سرور Open Connect را در نزدیکی کاربر تشخیص می‌دهد. بسته به اندازه دستگاه و صفحه نمایش، فرمت ویدیویی مناسب در دستگاه کاربر پخش می‌شود. در حین تماشای یک ویدیو، ممکن است ویدیو به صورت نقطه‌ای به نظر برسد و پس از مدتی به حالت HD باز می‌گردد. این به این دلیل اتفاق می‌افتد که برنامه بهترین سرور اتصال باز جریان را بررسی می‌کند و در صورت نیاز بین فرمت‌ها (برای بهترین تجربه مشاهده) جابجا می‌شود.

داده‌های کاربر مانند جستجوها، مشاهده ‌شده‌ها، مکان، دستگاه مورد استفاده، بررسی‌ها و موارد پسندیده شده در AWS ذخیره می‌شوند، Netflix از آن برای ایجاد پیشنهاد فیلم برای کاربرانی که از مدل یادگیری ماشین یا Hadoop استفاده می‌کنند، استفاده می‌کند. شاید برای شما سوال باشد Hadoop چیست؟

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

نقاط مثبت Open connect :

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

حال نوبت آن رسیده یک مقدار وارد جزئیات ابزار و برنامه‌های مورد استفاده در Netflix شویم.

Elastic Load Balancing (ELB) :

به طور خودکار ترافیک ورودی برنامه را در چندین هدف، در یک یا چند منطقه در دسترس توزیع می‌کند. بر سلامت نقاط هدف ثبت شده خود نظارت می‌کند و ترافیک را فقط به نقاط هدف سالم هدایت می‌کند. در Netflix مسئول مسیریابی ترافیک است. ELB یک طرح تعادل بار دو لایه را انجام می‌دهد که در آن بار ابتدا بر روی مناطق در دسترس و سپس نمونه‌ها (سرورها) متعادل می‌شود.

• سطح اول شامل متعادل سازی با الگوریتم Round Robin پایه مبتنی بر DNS است. هنگامی که درخواست در اولین بار متعادل کننده فرود می‌آید (شکل را ببینید)، در یکی از مناطق (با استفاده از الگوریتم دور چرخشی) که ELB شما برای استفاده از آن پیکربندی شده است (z1 to z3)، متعادل می شود.
• سطح یا لایه دوم آرایه‌ای از نمونه‌های متعادل‌کننده بار است و باز هم الگوریتم Round Robin را برای توزیع درخواست در بین نمونه‌هایی که پشت آن در همان منطقه یکسان هستند، انجام می‌دهد.

ZULL :

یک سرویس gateway است که مسیریابی پویا، نظارت، انعطاف پذیری و امنیت را فراهم می کند. ZULL مسیریابی آسانی را، بر اساس پارامترهای پرس و جو، URL و مسیر فراهم می‌کند. حال بیایید عملکرد قسمت های مختلف آن را تحلیل کنیم.

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

مزایای ZULL:

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

Hystrix :

در یک سیستم توزیع شده پیچیده، یک سرور x، ممکن است به پاسخ سرور y متکی باشد. وابستگی‌های بین این سرورها می‌تواند تأخیر ایجاد کند و اگر یکی از سرورها به ناچار در نقطه‌ای از کار بیفتد، کل سیستم ممکن است از کار بیفتد. برای حل این مشکل می‌توان برنامه میزبان را از این خرابی‌های خارجی جدا کنیم. کتابخانه Hystrix برای انجام این کار طراحی شده است. این به شما کمک می کند تا تعاملات بین این سرویس های توزیع شده را با افزودن منطق تحمل تاخیر و تحمل خطا کنترل کنید. Hystrix این کار را با جداسازی نقاط دسترسی بین سرویس‌ها، سیستم از راه دور و کتابخانه‌های دیگر انجام می‌دهد.

این کتابخانه در موارد زیر کمک می‌کند:

• ذخیره‌سازی درخواست با آگاهی همزمان. دسته‌بندی خودکار از طریق جمع‌کردن درخواست
• برگشتی و در صورت امکان به زیبایی تنزل دهید.
• سریع شکست بخورد و به سرعت بهبود یابد.
• خرابی های آبشاری را در یک سیستم توزیع پیچیده متوقف کنید.
• کنترل تأخیر و شکست ناشی از وابستگی های قابل دسترسی (معمولاً از طریق شبکه) از طریق کتابخانه‌های مشتری شخص ثالث.

معماری میکروسرویس Netflix

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

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

EV Cache :

در اکثر برنامه‌ها، مقداری از داده‌ها اغلب استفاده می‌شود. برای پاسخ سریع‌تر، این داده‌ها را می‌توان در بسیاری از نقاط پایانی کش کرد و می‌توان آن ها را به جای سرور اصلی از حافظه پنهان واکشی کرد. این باعث کاهش بار سرور اصلی می‌شود، اما مشکل این است که اگر گره پایین بیاید، تمام حافظه پنهان پایین می‌آید و این می‌تواند به عملکرد برنامه ضربه بزند. برای حل این مشکل Netflix لایه کش سفارشی خود را به نام کش EV ساخته است. کش EV بر اساس Memcached است و در واقع یک بسته بندی در اطراف Memcached است. نتفلیکس خوشه‌های زیادی را در تعدادی از نمونه‌های AWS EC2 مستقر کرده‌است و این خوشه‌ها دارای گره‌های Memcached زیادی هستند و همچنین کلاینت‌های کش دارند. داده‌ها در سراسر خوشه در همان منطقه به اشتراک گذاشته می‌شوند و چندین نسخه از کش در گره‌های خرد‌ شده ذخیره می‌شوند. هر بار که write برای client اتفاق می‌افتد، تمام گره‌ها در همه خوشه‌ها به‌روزرسانی می‌شوند، اما زمانی که read برای حافظه پنهان اتفاق می‌افتد، فقط به نزدیک‌ترین خوشه (نه همه خوشه‌ها و گره‌ها) و گره‌های آن ارسال می‌شود. در صورتی که یک گره در دسترس نباشد، از یک گره موجود دیگر خوانده شود. این رویکرد عملکرد، در دسترس بودن و بحث قابلیت اطمینان را افزایش می‌دهد.

Database :

نتفلیکس از دو پایگاه داده متفاوت یعنی MySQL (RDBMS) و Cassandra (NoSQL) برای اهداف و دلایل مختلف استفاده می‌کند. MySQL، EC2 را مستقر کرد: Netflix داده‌هایی مانند اطلاعات صورت‌حساب، اطلاعات کاربر و اطلاعات تراکنش‌ها را در MySQL ذخیره می‌کند زیرا نیاز به انطباق با خواص ACID دارد. Netflix یک تنظیمات master-master برای MySQL دارد و در نمونه‌های بزرگ EC2 آمازون با استفاده از InnoDB مستقر شده است.

این تنظیمات از «پروتکل تکرار همزمان» پیروی می‌کند که در آن اگر نویسنده گره اصلی master باشد، به گره master دیگری نیز کپی می‌شود. تأیید فقط در صورتی ارسال می‌شود که نوشتن گره اصلی و از راه دور master تأیید شده باشد. این در دسترس بودن بالای داده‌ها را تضمین می‌کند.

نتفلیکس نسخه خواندنی را برای هر گره (محلی و همچنین بین منطقه‌ای) تنظیم کرده است. این امر در دسترس بودن و مقیاس پذیری بالا را تضمین می‌کند. تمام query های read به کپی‌های خوانده شده هدایت می‌شوند و فقط query های write به گره‌های اصلی هدایت می‌شوند. در صورت خرابی اصلی MySQL، گره اصلی ثانویه نقش اصلی را بر عهده خواهد گرفت و ورودی route53 (پیکربندی DNS) برای پایگاه داده به این گره اصلی جدید تغییر خواهد کرد. این همچنین موجب می‌شود query های write را به این گره اصلی master جدید هدایت شوند.

Cassandra :

یک پایگاه داده NoSQL است که می‌تواند حجم زیادی از داده‌ها را مدیریت کند و همچنین می‌تواند نوشتن و خواندن سنگین را انجام دهد. هنگامی که Netflix شروع به جذب کاربران بیشتری کرد، مشاهده داده‌های سابقه برای هر عضو نیز شروع به افزایش کرد. این تعداد کل مشاهده داده‌های سابقه را افزایش می‌دهد و مدیریت این حجم عظیم داده برای Netflix چالش برانگیز می‌شود. Netflix ذخیره‌سازی تاریخچه مشاهده داده‌ها را افزایش داده و دو هدف اصلی را در ذهن خود نگه می‌دارد:

• فضای ذخیره سازی کوچکتر
• عملکرد خواندن/نوشتن ثابت با افزایش مشاهده به ازای هر عضو (نسبت نوشتن به خواندن داده‌های تاریخ مشاهده در Cassandra حدود 9 به 1 است).

در ابتدا، تاریخچه مشاهده در cassandra در یک ردیف ذخیره می‌شد. هنگامی که کاربران شروع به افزایش در Netflix کردند، اندازه ردیف و همچنین اندازه کلی داده افزایش یافت. این منجر به ذخیره‌سازی بالا، هزینه عملیاتی بیشتر و عملکرد کند برنامه شد. راه حل این مشکل فشرده‌سازی ردیف‌های قدیمی بود، که در نتیجه آن Netflix داده ها را به دو قسمت تقسیم کرد:

• تاریخچه مشاهده زنده (LiveVH): این بخش شامل تعداد کمی از داده‌های تاریخی مشاهده اخیر کاربران با به روزرسانی‌های مکرر است. داده ها اغلب برای کارهای ETL استفاده می‌شوند و به صورت فشرده نشده ذخیره می‌شوند.
• تاریخچه مشاهده فشرده (CompressedVH): تعداد زیادی از رکوردهای مشاهده قدیمی با به روز‌رسانی‌های نادر در این بخش دسته‌بندی شده است. داده‌ها در یک ستون در هر کلید ردیف، همچنین به صورت فشرده برای کاهش ذخیره‌سازی ذخیره می‌شوند

پردازش داده در Netflix به کمک Kafka و Apache Chukwa

فرض کنید آرش امروز وارد حساب کاربری خود در Netflix شده‌است، هنگامی که روی یک ویدیو کلیک می‌کند، Netflix شروع به پردازش داده‌ها در شرایط مختلف می‌کند و این عمل را در کمتر از یک نانو ثانیه طول می‌کشد. پس بیایید در مورد نحوه عملکرد خط لوله تکامل در Netflix بحث کنیم.

نتفلیکس از Kafka و Apache Chukwe برای دریافت داده‌هایی که در بخش‌های مختلف سیستم تولید می‌شوند استفاده می‌کند. نتفلیکس تقریباً 500 میلیارد رویداد داده با مصرف 1.3 پتابایت در روز و 8 میلیون رویداد داده با مصرف 24 گیگابایت در ثانیه در زمان اوج مصرف ارائه می‌دهد. این رویدادها شامل اطلاعاتی از جمله:

• گزارش‌های خطا
• فعالیت‌های رابط کاربری
• رویدادهای اجرایی
• فعالیت‌های مشاهده ویدیو
• تشخیص و عیب‌یابی رویدادها

می‌باشد.

Apache Chukwe :

یک سیستم جمع‌آوری داده متن باز، برای جمع‌آوری گزارش‌ها یا رویدادها از یک سیستم توزیع شده‌است. این بر روی HDFS و Map-reduce ساخته شده‌است. دارای ویژگی‌های مقیاس‌پذیری و استحکام Hadoop است. همچنین، شامل بسیاری از ابزارهای قدرتمند و انعطاف‌پذیر برای نمایش، نظارت و تجزیه و تحلیل نتیجه است. Chukwe رویدادها را از قسمت های مختلف سیستم جمع‌آوری می‌کند و می‌توان نظارت و تجزیه و تحلیل را به کمکش انجام داد یا اینکه می‌توان از داشبورد برای مشاهده رویدادها استفاده کنید. Chukwe رویداد را در قالب توالی فایل Hadoop (S3) می‌نویسد. پس از آن تیم Big Data این فایل های S3 Hadoop را پردازش می‌کند و Hive را در قالب داده Parquet می‌نویسد. این فرآیند پردازش دسته ای نامیده می‌شود که اساساً کل داده‌ها را در فرکانس ساعتی یا روزانه اسکن می‌کند.

برای آپلود رویدادهای آنلاین در EMR/S3، Chukwa همچنین ترافیکی را برای کافکا (دروازه اصلی در پردازش بی‌درنگ داده) فراهم می‌کند. کافکا مسئول انتقال داده‌ها از جلوی کافکا به حفره‌های مختلف است: S3، Elasticsearch و Secondary kafka. مسیریابی این پیام‌ها با استفاده از Apache Samja انجام می‌شود. ترافیک ارسال شده توسط Chukwe می‌تواند جریان‌های کامل یا فیلتر شده باشد، بنابراین گاهی اوقات ممکن است مجبور شوید فیلترهای بیشتری را در جریان‌های kafka اعمال کنید.

Elastic Search :

در سال های اخیر رشد گسترده‌ای در استفاده از Elasticsearch در Netflix مشاهده شده‌است. Netflix تقریباً 150 خوشه جستجوی الاستیک و 3500 میزبان با نمونه اجرا می‌کند. نتفلیکس از جستجوی الاستیک برای نمایش داده‌ها، پشتیبانی از مشتری و برای تشخیص برخی خطاها در سیستم استفاده می‌کند. به عنوان مثال، اگر مشتری نتواند ویدیو را پخش کند، مدیر خدمات مشتری این مشکل را با استفاده از جستجوی الاستیک حل می‌کند. تیم پخش به جستجوی الاستیک می‌رود و کاربر را جستجو می‌کند تا بداند چرا ویدیو در دستگاه کاربر پخش نمی‌شود. آنها با تمام اطلاعات و رویدادهایی که برای آن کاربر خاص اتفاق می‌افتد آشنا می‌شوند، و متوجه می‌شوند که چه چیزی باعث خطا در جریان ویدیو شده‌است. جستجوی الاستیک نیز توسط مدیر برای پیگیری برخی اطلاعات استفاده می‌شود. همچنین برای پیگیری استفاده از منابع و شناسایی مشکلات ثبت نام یا ورود مورد استفاده قرار می‌گیرد.

استفاده از Apache Spark جهت پیشنهاد فیلم

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

در Netflix ، Apache Spark برای توصیه‌های محتوا و شخصی‌سازی استفاده می‌شود. اکثر خطوط لوله یادگیری ماشین بر روی این خوشه‌های spark بزرگ اجرا می‌شوند. سپس از این خطوط لوله برای انتخاب ردیف، مرتب‌سازی، رتبه‌بندی ارتباط عنوان و شخصی‌سازی آثار هنری در میان سایر موارد استفاده می‌شود.

شخصی‌سازی Artwork

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

سیستم پیشنهاد فیلم

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

• تعامل کاربر با سرویس (مشاهده سابقه و نحوه امتیازدهی کاربر به عناوین دیگر)
• سایر اعضا با سلایق و ترجیحات مشابه
• اطلاعات فراداده از ویدیوهای قبلاً تماشا شده برای یک کاربر مانند عناوین، ژانر، دسته‌ها، بازیگران، سال انتشار و غیره
• دستگاه کاربر، در چه زمانی کاربر فعال تر است و برای چه مدت کاربر فعال است

نتفلیکس از دو الگوریتم مختلف برای ساخت یک سیستم توصیه استفاده می‌کند:

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

بررسی معماری نرم‌افزار Spotify

کوین گولداسمیت مدیر ارشد فناوری اسبق Spotify باور دارد برای یک نرم‌افزار مقیاس وسیع ویژگی‌های زیر باید وجود داشته باشد:

• امکان مقیاس‌پذیری تا میلیون‌ها کاربر
• پشتیبانی از چندین پلتفرم
• توانایی مدیریت قوانین پیچیده تجارتی
• توانایی ادامه در رقابت بازار جهانی

واکنش سریع

نوآوری کردن

تخمینی از مقیاس

• بیش از 365 میلیون کاربر فعال (2021)
• ساخت 8 میلیون آهنگ در سال
• اضافه شدن 60000 آهنگ در روز
• پشتیبانی بیش از 30 زبان
• 8 هزار هنرمند فعال
• قوانین به شدت پیچیده تجاری
• حجم بالای رقبا

نیازمندی‌های غیر‌ وظیفه‌مندی Spotify :

• قابلیت استفاده (usability)
• قابلیت اطمینان (reliability)
• کارایی (performance)
• تاخیر کم (Low latency)

Load Balancer :

برای نگهداری و مدیریت ترافیک ورودی به سرور زمانی که یک کاربر یک آهنگ را درخواست می‌کند، درخواست به LB می‌رود. تکنیکی که در اینجا استفاده می‌شود، تعادل بار Round Robin برای توزیع درخواست‌ها به سرور با کمترین ترافیک برای رسیدن به تاخیر کم است.

The recommendation algorithm :

سیستم توصیه‌گر شباهت عناصر (کاربر، موسیقی، فرکانس) را با استفاده از فیلتر مشارکتی ضمنی بر اساس مدل‌های عامل پنهان(Latent factor model, ) شناسایی می‌کند. بنابراین، آهنگ های مشابه به لیست پخش کاربران ارسال می شود.

Autonomous full-stack teams :

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

چرا میکروسرویس، مزایا:

• مقیاس‌پذیری راحت با توجه به مشکلات و گلوگاه‌های دنیای واقعی
• آزمون و تست ساده‌تر
• پیاده‌سازی راحت‌تر(کوچک‌ترند)
• نظارت ساده‌تر(نمونه‌های کوچک و کارکرد مشخص)
• به طور مستقل و جداگانه نسخه‌سازی شوند
• خطاها و شکست‌های کوچک

مشکلات میکروسرویس:

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

Apollo Framework :

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

در ادامه بحث معماری نرم‌افزار به موفقیت و محبوبیت Spotify که همه را شگفت‌زده کرده است می‌پردازیم. بله، از صنعت موسیقی و سرگرمی گرفته تا دنیای فناوری و تجارت.

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

اسپاتیفای برای مقابله با تهدید فزاینده دزدی در آهنگ‌ها راه‌اندازی شد. تخمین زده می‌شود که 30 تا 40 درصد از درآمدهای تولید شده توسط صنعت موسیقی به دلیل دزدی از بین رفته‌است و هنرمندانی که موسیقی اصیل خلق می‌کنند نتوانسته‌اند به طور عادلانه‌ای برای هنر خود به حقوق خود دست یابند. با درک این مشکلات، Daniel Ek و Martin Lorentzon از سوئد، Spotify را در سال 2006 راه‌اندازی کردند و بلافاصله به محبوب‌ترین سرویس پخش موسیقی در جهان تبدیل شدند. Spotify با بیش از 422 میلیون کاربر فعال و 182 میلیون کاربر پولی، در صدر جدول صنعت پخش موسیقی قرار گرفته‌است و در حال حاضر یکی از محبوب‌ترین و رایج‌ترین پلتفرم‌ها برای دسترسی آسان و یکپارچه به انواع موسیقی است.

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

اسپاتیفای کاملاً بر اساس معماری Microservices است که توسط Kevin Goldsmith که مدیر ارشد فناوری قبلی در Spotify بود تأیید و توضیح داده شده‌است. اما شاید سوالی پیش بیاید که اصلا چرا معماری میکروسرویس؟ معماری نرم‌افزار Spotify به شدت به سرویس‌ها وابسته است و به همین دلیل است که معماری مبتنی بر میکروسرویس برای Spotify نهایی شد و می‌توان گفت به خوبی کار کرد.

در بطن Spotify، به صدها سرویس نیاز دارد که اکثر آنها کوچک و ساده هستند، اما باید در زمان اجرا و بدون هیچ تاخیری سرویس‌ بدهند.

برای ارائه خدمات به این صدها سرویس، تیم فنی Spotify یک معماری مبتنی بر میکروسرویس‌ها را به کار گرفته‌است، جایی که در آن برای رفع یک نیاز به سرویس در یک زمان خدمت می‌کند: برای مثال بازیابی یک آهنگ، به اشتراک‌گذاری توصیه‌ها، جستجو، یا مثالی ساده مانند تأیید یک کاربر (برای مدل رایگان و پولی).

سرویس‌ها چگونه کار می‌کنند و پاسخ می‌دهند؟

سرویس‌ها معمولاً به زبان پایتون و یا جاوا نوشته می‌شوند. و آن‌ها از طریق پروتکل Hermes با یکدیگر ارتباط برقرار می‌کنند که Spotify از ابتدا با استفاده از ZeroMQ و Protobuf توسعه داده است. با این حال، برخی از سرویس‌های قدیمی ایجاد شده در ابتدا هنوز از HTTP و XML/JSON برای ارتباط استفاده می‌کنند.

برای سرویس‌های مبتنی بر پایگاه داده و ذخیره‌سازی، PostgreSQL و Cassandra توسط Spotify استفاده می‌شود. Cassandra برای خدمات مبتنی بر محتوا مانند جستجوی آهنگ‌ها یا بازیابی ابرداده آهنگ‌ها در زمان اجرا ترجیح داده می‌شود.

یک سرویس پشتیبان بسیار تخصصی به نام «نقطه دسترسی» وجود دارد که برای ارتباط سریع و دقیق، دائماً با client های مختلف در تماس است. پروتکلی که ارتباط یکپارچه بین مشتریان و «نقطه دسترسی» را امکان‌پذیر می‌سازد نیز توسط مهندسان Spotify ساخته شده‌است و به صورت عمومی منتشر نشده‌است.

زیرساخت نرم‌افزار در Spotify به شدت به Debian وابسته است، در حالی که نرم‌افزار متن‌باز برای فعالیت‌های مختلف ترجیح داده می‌شود.

راز پخش سریع موسیقی در Spotify

در معماری مبتنی بر Microservices، صدها توسعه‌دهنده نرم‌افزار به طور همزمان مشغول به کار هستند که انواع مختلف خدمات و ارتباطات آنها را مدیریت می‌کنند. حال، راز این نرم‌افزار این است که هر یک از این توسعه‌دهندگان نرم‌افزار در یک قلمرو بسته، با قابلیت‌ها و ماموریت‌های خاص کار می‌کنند. هر میکروسرویس فقط یک مسئولیت و هدف دارد و اکثریت این میکروسرویس‌ها پایگاه داده خصوصی خود را با منطق خاص خود دارند و دیگر پایگاه‌داده‌های میکروسرویس‌های دیگر نمی‌توانند در آن‌ها دخالت کنند. به همین دلیل است که Spotify بسیار سریع و دقیق است و نیازهای کاربر نهایی را به سرعت برآورده می‌کند. هنگامی که یک درخواست برای هر کار خاص ارسال شد، برنامه به سرعت پاسخ می‌دهد، سرویس‌های مختلف را در ماشین‌های مختلف مستقر می‌کند، و بسته به سرویس خاصی که فراخوانی می‌شود، پارامترهای عملکرد شخصی‌سازی شده و سفارشی‌سازی شده دارد.

مدیریت تغییر بدون درز منطق

حال، اگر توسعه‌دهنده نرم‌افزار نیاز به تغییر منطق هر feature داشته باشد، چه؟ هیچ مشکلی برای تاخیر زمانی یا اختلال در کل برنامه وجود ندارد، زیرا هر میکروسرویس منطق خاص خود را دارد و اجرای تغییرات بسیار آسان است. سرویس خاصی که با این ویژگی مرتبط است باید روی آن کار شود، ویرایش‌ها انجام می‌شود و سپس فقط آن سرویس آزمایش می‌شود و سپس فوراً مستقر می‌شود. از این رو، آن سرویس اکنون تغییر کرده است، منطق تغییر کرده است و این ویژگی اکنون عملکرد جدیدی خواهد داشت. این سرویس پس از اتمام استقرار با برنامه شروع به برقراری ارتباط می‌کند و مطلقاً نیازی به آزمایش مجدد و استقرار مجدد کل برنامه نیست. این ویژگی مدیریت تغییر میکروسرویس‌ها که به عنوان معماری نرم‌افزار Spotify مورد استفاده قرار می‌گیرد، یکی از قدرتمندترین قابلیت هاست که Spotify را سریع و کاربر پسند می‌کند.

جالب اینجاست که معماری نرم‌افزار Spotify به گونه‌ای توسعه یافته است که همه مشتریان ممکن برنامه: موبایل، دسکتاپ(pc)/لپ‌تاپ، و libspotify (کتابخانه قابل جاسازی Spotify)، همه یک پایگاه کد مشترک دارند. با استفاده از این پایه کد مشترک، توسعه دهندگان می‌توانند عملکرد مشتری را تغییر داده یا ارتقا دهند و یک رابط کاربری منحصر به فرد برای کاربران نهایی ارائه دهند. از آنجایی که این پایه، یک کد به زبان C++ است، تغییرات و ویرایش‌ها در رابط کاربری اصلی نیز آسان و بدون درز است. پذیرش‌های پلتفرم خاص به زبان‌های مخصوص پلتفرم نوشته شده‌اند، به عنوان مثال، ObjC برای iOS.

Hadoop :

تجزیه و تحلیل log را با استفاده از Hadoop انجام می‌شود که به فرآیند توصیف شده قبلی باز می‌گردد. به عنوان مثال، محبوبیت آهنگ برای سنجش نتایج جستجو و صدر لیست‌ برتر استفاده می‌شود.

این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهید بهشتی است.