گزارش پایانی پروژه درس: معماري نرم‌افزار Netflix و Airbnb

در اين مطلب به معماري نرم‌افزار شركت‌هاي Netflix و Airbnb مي‌پردازيم.

چكيده

معماری نرم‌افزار به سادگی سازماندهی یک سیستم است. این سازمان شامل تمامی اجزا، نحوه تعامل آن‌ها با یکدیگر، محیطی که در آن فعالیت می‌کنند و اصولی که برای طراحی نرم‌افزار به کار می‌رود، می‌باشد. در بسیاری از موارد، می‌تواند شامل تکامل نرم‌افزار به آینده نیز باشد. شركت‌هايي كه در اين تحقيق در مورد ان‌ها صحبت شده است، شركت‌هايي هستند كه تعداد زياد كاربران ان‌ها زبانزد است و براي همگان مهم است كه از چه فناوري‌ها، ابزارها و متدهايي براي براورده كردن نيازهاي اين تعداد كاربر استفاده شده است.

واژگان كليدي: معماري نرم‌افزار، Netflix، Airbnb

1-مقدمه

الگوی معماری مناسب برای سیستم IT شما به عوامل متعددی از جمله چارچوب زمانی پروژه، بودجه و مجموعه مهارت های توسعه دهندگان درگیر بستگی دارد. همچنین در صورت نیاز امکان ترکیب چندین الگوی مختلف وجود دارد. هیچ الگو یا راه حلی وجود ندارد که در همه جا کار کند، و به همین دلیل است که معماران نرم افزار می توانند در شروع یک پروژه این تصمیمات را به دست آورند. تعیین دقیق «معماری نرم افزار» می تواند کار دشواری باشد. رالف ای جانسون، دانشمند مشهور کامپیوتر، زمانی آن را چنین توصیف کرد: «معماری در مورد چیزهای مهم است. هر چه که باشد.» در حالی که هیچ تعریف دقیق پذیرفته شده جهانی از معنای معماری نرم افزار وجود ندارد، اکثر آنها می توانند بر روی اصول اساسی آن توافق داشته باشند. در ابتدایی ترین شکل آن، می توان آن را طراحی و ساختار سیستم های پیچیده فناوری اطلاعات توصیف کرد. این طرحی است برای اینکه چگونه اجزای نرم افزار فردی باید سازماندهی و در یک سیستم ساختاری قوی که نیازهای تجاری را برآورده می کند، سازماندهی و متصل شوند. درست مانند یک پروژه ساخت و ساز ساختمان، تصمیمات معماری نرم افزار معمولاً انتخاب های طراحی سطح بالا هستند - از چه ابزارها، استانداردها و چارچوب هایی باید استفاده کرد و چگونه همه عناصر با یکدیگر تعامل خواهند داشت. این تصمیمات در شروع یک پروژه گرفته می شود و برای موفقیت آن بسیار مهم است. به هر حال، روشی که در آن سیستم‌های نرم‌افزاری طراحی و کنار هم قرار می‌گیرند، بر عملکرد، امنیت، قابلیت اطمینان و مقیاس‌پذیری تأثیر می‌گذارد. نقش یک معمار نرم افزار گاهی اوقات می تواند با نقش یک مهندس یا توسعه دهنده محو شود، به خصوص زمانی که روی سیستم های کوچکتر و از نظر ساختاری ساده کار می کند. با این حال، چند تمایز مهم وجود دارد: در همان ابتدای چرخه عمر توسعه نرم‌افزار، یک معمار نرم‌افزار باید بتواند بفهمد چه عناصری اساسی هستند و چگونه باید مستقر شوند، متصل شوند و کنترل شوند. چشم انداز معمار، که مهندسان و توسعه دهندگان نرم افزار را راهنمایی می کند، راه حل های طراحی بهینه را برای نیازهای یک کسب و کار (عملکرد، عملکرد و غیره) طرح ریزی می کند، در حالی که تمام محدودیت های مربوطه (زمان، بودجه، زیرساخت های موجود) را در نظر می گیرد. برای انجام موفقیت آمیز این کار، یک معمار نرم افزار باید درک دقیقی از این که چگونه ابزارهای مختلف موجود در آن زمان می توانند مشکلاتی را که با آنها برخورد می کنند را به کارآمدترین و مؤثرترین روش حل کنند، داشته باشد. این شامل دانستن زمانی است که جدیدترین و قدرتمندترین فناوری برای استفاده در یک سیستم خاص مناسب نیست.

در اینجا سه ​​دلیل اصلی وجود دارد که چرا یک معماری نرم افزار خوب در هنگام توسعه بسیار مهم است:
1. مبنایی برای ارتباط
معماری نرم افزار نوعی طرح از سیستم است و برای درک، مذاکره و ارتباط بین همه ذینفعان (سمت کاربر، مشتری، مدیریت و غیره) اولیه است. درک کل سیستم را آسان تر می کند و فرآیند تصمیم گیری را کارآمدتر می کند.
2. اولین تصمیمات
اولین تصمیمات در این مرحله گرفته می شود. آن تصمیمات اولیه اهمیت زیادی در بقیه پروژه دارند و هر چه بیشتر در فرآیند پیشرفت کنیم، تغییر آنها بسیار دشوار می شود.
3. قابلیت انتقال مدل
معماری نرم افزار مدل نرم افزار و نحوه عملکرد آن را تعریف می کند. وجود آن امکان استفاده مجدد از این مدل را برای سایر نرم افزارها فراهم می کند. کد می تواند مورد استفاده مجدد قرار گیرد و همچنین الزامات. تمام تجربیاتی که در حین انجام معماری به دست می آوریم نیز منتقل می شود. این بدان معناست که ما می‌دانیم و می‌توانیم از عواقب تصمیمات اولیه که در وهله اول گرفته‌ایم استفاده مجدد کنیم.
به عبارت دیگر، معماری مشکلاتی را که ممکن است هنگام پیاده سازی با آن مواجه شوید را مشخص می کند. همچنین ساختار سازمانی را نشان می دهد و تصمیم گیری و مدیریت انواع تغییرات را بسیار آسان تر می کند. همچنین به ما این امکان را می دهد که تخمین بهتری از زمان و هزینه یک پروژه داشته باشیم. در اینجا سه ​​دلیل اصلی وجود دارد که چرا یک معماری نرم افزار خوب در هنگام توسعه بسیار مهم است.

2- روش تحقيق

رويكرد تركيبي پژوهشي و صنعتي: در این پروژه به بررسی تکنولوژی‌های استفاده شده در این معماری‌ها و چالش‌هایی که با طراحی‌های متفاوت حل شده‌اند، می‌پردازیم.

3- شركت Netflix

3-1- معرفي

همه ما با خدمات نتفلیکس آشنا هستیم. دسته‌های بزرگی از فیلم‌ها و محتوای تلویزیونی را مدیریت می‌کند و کاربران اجاره ماهانه برای دسترسی به این محتواها را پرداخت می‌کنند. نتفلیکس بيش از 180 میلیون مشترک در بيش از 200 کشور دارد.

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

3-2- معماري

نتفلیکس ابر AWS را برای انتقال زیرساخت‌های فناوری اطلاعات خود انتخاب کرده بود زیرا AWS می‌توانست پایگاه‌های داده بسیار قابل اعتماد، فضای ذخیره‌سازی ابری در مقیاس بزرگ و مراکز داده متعدد در سراسر جهان ارائه دهد. نتفلیکس با استفاده از زیرساخت ابری که توسط AWS ساخته و نگهداری می‌شود، کارهای سنگین غیرمتمایز ساخت مراکز داده را انجام نداد، بلکه بیشتر بر کسب‌وکار اصلی خود یعنی ارائه تجربه کاربر پخش ویدئو با کیفیت بالا تمرکز کرد. حتی با وجود اینکه مجبور است کل فناوری را بازسازی کند تا اجازه دهد به راحتی روی ابر AWS اجرا شود، بهبود مقیاس پذیری و در دسترس بودن سرویس نتفلیکس در ازای آن به طور قابل توجهی افزایش یافته است[4].
نتفلیکس همچنین یکی از اولین محرک های اصلی معماری میکروسرویس ها است. Microservices مشکلات طراحی نرم‌افزار یکپارچه را با تشویق جداسازی نگرانی‌ها [11] هدف قرار می‌دهد که در آن برنامه‌های بزرگ با ماژولار بودن با کپسوله‌سازی داده‌ها به تنهایی به اجزای نرم‌افزار کوچک‌تر تقسیم می‌شوند. Microservices همچنین به افزایش مقیاس پذیری از طریق مقیاس افقی و پارتیشن بندی حجم کار کمک می کند. مهندسان نتفلیکس با پذیرش میکروسرویس ها به راحتی هر سرویسی را تغییر می دهند که منجر به استقرار سریعتر می شود. مهمتر از آن، آنها می توانند عملکرد هر سرویس را ردیابی کنند و به سرعت مشکلات آن را از سایر سرویس های در حال اجرا جدا کنند.
در این مطالعه، من علاقه مند به درک معماری ابری Netflix و عملکرد آن تحت بارهای کاری مختلف و محدودیت های شبکه هستم. به طور خاص، من می‌خواهم طراحی سیستم را از نظر در دسترس بودن، تأخیر، مقیاس‌پذیری و انعطاف‌پذیری در برابر خرابی‌های شبکه یا قطعی سیستم تجزیه و تحلیل کنم. این مطالعه به شرح زیر سازماندهی شده است. بخش 2 یک معماری احتمالی سیستم Netflix که از منابع مختلف آنلاین آموخته شده است را شرح خواهد داد. سپس در بخش 3، اجزای سیستم با جزئیات بیشتر مورد بحث قرار خواهد گرفت. در بخش 4، 5، 6، 7، سیستم را با توجه به اهداف طراحی فوق تجزیه و تحلیل خواهم کرد. در نهایت، آنچه را که از این تجزیه و تحلیل آموخته‌ایم نتیجه می‌گیرم و گام‌های بعدی احتمالی باید برای بهبود برداشته شود.

نتفلیکس بر اساس خدمات محاسبات ابری آمازون (AWS) و Open Connect، شبکه تحویل محتوای داخلی آن [1] عمل می کند. هر دو سیستم باید به طور یکپارچه با هم کار کنند تا خدمات پخش ویدیو با کیفیت بالا را در سطح جهانی ارائه دهند. از نقطه نظر معماری نرم افزار، نتفلیکس شامل سه بخش اصلی است: Client، Backend و Content Delivery Network (CDN).
Client هر مرورگر پشتیبانی شده در لپ تاپ یا دسکتاپ یا برنامه Netflix در تلفن های هوشمند یا تلویزیون های هوشمند است. نتفلیکس برنامه های iOS و Android خود را توسعه می دهد تا بهترین تجربه مشاهده را برای هر مشتری و دستگاه ارائه دهد. نتفلیکس با کنترل برنامه‌ها و سایر دستگاه‌های خود از طریق SDK خود، می‌تواند خدمات استریم خود را تحت شرایط خاصی مانند شبکه‌های کند یا سرورهای پربار، به طور شفاف تطبیق دهد.
Backend شامل سرویس‌ها، پایگاه‌های داده، ذخیره‌سازی‌هایی است که به طور کامل بر روی ابر AWS اجرا می‌شوند. Backend اساساً همه چیزهایی را که شامل پخش ویدیوها نمی شود کنترل می کند. برخی از اجزای Backend با خدمات AWS مربوطه خود به شرح زیر فهرست شده اند:
- نمونه های محاسباتی مقیاس پذیر (AWS EC2)
- فضای ذخیره سازی مقیاس پذیر (AWS S3)
- ریزسرویس‌های منطق تجاری (فریم‌ورک‌های هدفمند توسط نتفلیکس)
- پایگاه داده های توزیع شده مقیاس پذیر (AWS DynamoDB، Cassandra)
- کارهای پردازش و تجزیه و تحلیل داده های بزرگ (AWS EMR، Hadoop، Spark، Flink، Kafka و سایر ابزارهای هدفمند ساخته شده توسط Netflix)
- پردازش و رمزگذاری ویدیو (ابزارهای هدفمند توسط نتفلیکس)
Open Connect CDN شبکه ای از سرورها به نام Open Connect Appliances (OCAs) است که برای ذخیره و پخش ویدیوهای بزرگ بهینه شده است. این سرورهای OCA در شبکه های ارائه دهندگان خدمات اینترنتی (ISP) و مکان های تبادل اینترنتی (IXP) در سراسر جهان قرار می گیرند. OCA ها مسئول پخش مستقیم ویدیوها به مشتریان هستند.
در بخش‌های بعدی، من مرجعی از معماری ابری نتفلیکس را شرح می‌دهم که این 3 بخش بالا را شامل می‌شود. یک معماری کلی می‌تواند پس از کلیک روی دکمه Play روی برنامه‌هایش، ویدیوها را پخش کند که معماری پخش نامیده می‌شود. سپس در بخش بعدي، یک معماری میکروسرویس دقیق تر از Backend توضیح داده می شود تا نشان دهد چگونه Netflix در دسترس بودن و مقیاس پذیری را در مقیاس جهانی مدیریت می کند.

3-2-1- معماري Playback

وقتی مشترکین روی دکمه Play در برنامه‌ها یا دستگاه‌های خود کلیک می‌کنند، Client با Backend در AWS و OCAs در Netflix CDN صحبت می‌کند تا ویدیوها را پخش کند [7]. نمودار زیر نحوه عملکرد فرآیند پخش را نشان می دهد:

1- بخش OCAها دائماً گزارش‌های سلامتی درباره وضعیت بار کاری، قابلیت مسیریابی و ویدیوهای موجود خود را به سرویس Cache Control در حال اجرا در AWS EC2 ارسال می‌کنند تا برنامه‌های Playback آخرین OCA‌های سالم را به مشتریان به‌روزرسانی کنند.
2- یک درخواست Play از دستگاه مشتری به سرویس برنامه‌های پخش Netflix که در AWS EC2 اجرا می‌شود ارسال می‌شود تا آدرس‌های اینترنتی برای پخش ویدیوها دریافت شود.
3- سرویس Playback Apps باید مشخص کند که درخواست Play برای مشاهده ویدیوی خاص معتبر است. چنین اعتبار سنجی هایی طرح مشترک، مجوز ویدیو در کشورهای مختلف و غیره را بررسی می کند.
4- سرویس Playback Apps با سرویس Steering نیز در AWS EC2 اجرا می‌شود تا لیست سرورهای OCA مناسب ویدیوی درخواستی را دریافت کند. سرویس Steering از آدرس IP مشتری و اطلاعات ISPها برای شناسایی مجموعه ای از OCA های مناسب برای آن مشتری استفاده می کند.
5- از لیست 10 سرور OCA مختلف که توسط سرویس Playback Apps بازگردانده شده است، مشتری کیفیت اتصالات شبکه به این OCA ها را آزمایش می کند و سریع ترین و مطمئن ترین OCA را برای درخواست فایل های ویدیویی برای پخش انتخاب می کند.
6- سرور OCA انتخاب شده درخواست های مشتری را می پذیرد و پخش ویدیوها را شروع می کند.

در نمودار بالا، خدمات Playback Apps، Steering Service و Cache Control به طور کامل در فضای ابری AWS بر اساس معماری میکروسرویس اجرا می شوند. در بخش بعدی، من مرجعی از معماری میکروسرویس های نتفلیکس باطن را توضیح خواهم داد که در دسترس بودن و مقیاس پذیری سرویس های در حال اجرا را افزایش می دهد.

همانطور که در بخش‌های قبلی توضیح داده‌ام، Backend تقریباً همه چیز را کنترل می‌کند، از ثبت‌نام، ورود به سیستم، صورت‌حساب گرفته تا وظایف پردازشی پیچیده‌تر مانند رمزگذاری ویدیو و توصیه‌های شخصی‌شده. نتفلیکس به منظور پشتیبانی از بارهای کاری سبک و سنگین که بر روی یک زیرساخت اساسی اجرا می شوند، معماری میکروسرویس ها را برای سیستم مبتنی بر ابر خود انتخاب کرده است. نمودار در شکل 2 یک معماری میکروسرویس ممکن را در Netflix نشان می دهد که من از چندین منبع آنلاین استخراج کرده ام[11، 13، 14].

3-2-2- معماري Backend

1- کلاینت یک درخواست Play به Backend در حال اجرا در AWS ارسال می کند. این درخواست توسط متعادل کننده بار AWS (ELB) رسیدگی می شود.
2- AWS ELB آن درخواست را به API Gateway Service در حال اجرا بر روی نمونه های AWS EC2 ارسال می کند. این مؤلفه که Zuul نام دارد توسط تیم نتفلیکس ساخته شده است تا امکان مسیریابی پویا، نظارت بر ترافیک و امنیت، انعطاف پذیری در برابر خرابی ها در لبه استقرار ابر را فراهم کند. این درخواست برای برخی از فیلترهای از پیش تعریف شده مربوط به منطق تجاری اعمال می شود، سپس برای رسیدگی بیشتر به API Application ارسال می شود.
3- جزء API Application منطق اصلی کسب و کار پشت عملیات Netflix است. انواع مختلفی از API مربوط به فعالیت های مختلف کاربر مانند Signup API، Recommendation API برای بازیابی توصیه های ویدیویی وجود دارد. در این سناریو، درخواست ارسال شده از API Gateway Service توسط Play API مدیریت می شود.
4- Play API یک میکروسرویس یا دنباله ای از میکروسرویس ها را برای انجام درخواست فراخوانی می کند. سرویس Playback Apps، سرویس Steering و سرویس Cache Control در شکل 1 به عنوان یک میکروسرویس در این نمودار دیده می شود.
5- میکروسرویس ها عمدتاً برنامه های کوچک بدون تابعیت هستند و می توانند با یکدیگر تماس بگیرند. برای کنترل خرابی آبشاری و فعال کردن انعطاف‌پذیری، هر میکروسرویس توسط Hystrix از فرآیندهای تماس گیرنده جدا می‌شود. نتیجه آن پس از اجرا می‌تواند در یک کش مبتنی بر حافظه ذخیره شود تا امکان دسترسی سریع‌تر برای درخواست‌های با تأخیر کم حیاتی فراهم شود.
6- میکروسرویس ها می توانند داده ها را در یک فروشگاه داده در طول فرآیند ذخیره کنند یا از آن دریافت کنند.
7- میکروسرویس‌ها می‌توانند رویدادهایی را برای ردیابی فعالیت‌های کاربر یا سایر داده‌ها به خط لوله پردازش جریان برای پردازش بلادرنگ توصیه‌های شخصی یا پردازش دسته‌ای وظایف هوش تجاری ارسال کنند.
8- داده‌هایی که از خط لوله پردازش جریان خارج می‌شوند می‌توانند برای سایر فروشگاه‌های داده مانند AWS S3، Hadoop HDFS، Cassandra و غیره پایدار باشند.
معماری‌های توصیف‌شده به ما کمک می‌کنند تا درکی کلی از نحوه سازمان‌دهی و کار با هم قطعات مختلف برای پخش جریانی ویدیوها به دست آوریم. با این حال، برای تجزیه و تحلیل در دسترس بودن و مقیاس پذیری معماری ها، باید بیشتر به هر جزء مهم بپردازیم تا ببینیم که چگونه تحت بارهای کاری مختلف عمل می کند. که در بخش بعدی به آن پرداخته خواهد شد.

3-2-3- مولفه ها

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

3-2-3-1- كلاينت

تیم‌های فنی نتفلیکس تلاش زیادی برای توسعه برنامه‌های مشتری سریع‌تر و هوشمندتر انجام داده‌اند که بر روی لپ‌تاپ، دسکتاپ یا دستگاه‌های تلفن همراه اجرا می‌شوند. حتی در برخی از تلویزیون‌های هوشمند که Netflix در آنها کلاینت تخصصی ایجاد نمی‌کند، Netflix همچنان عملکرد خود را از طریق SDK ارائه شده کنترل می‌کند. در واقع، هر محیط دستگاهی نیاز به نصب Netflix Ready Device Platform (NRDP) دارد تا بتواند بهترین تجربه مشاهده Netflix را ممکن کند. یک جزء ساختاری مشتری معمولی [11] در شکل 3 نشان داده شده است.

نرم افزار كلاينت نوع اتصال را به Backend برای کشف و پخش محتوا جدا می کند. کلاینت از پروتکل NTBA [15] برای درخواست‌های پخش استفاده می‌کند تا از امنیت بیشتر مکان‌های سرور OCA خود اطمینان حاصل کند و تأخیر ناشی از یک دست دادن SSL/TLS برای اتصالات جدید را حذف کند.
در حین پخش ویدیوها، برنامه Client به طور هوشمند کیفیت ویدیو را کاهش می دهد یا اگر اتصالات شبکه بیش از حد بارگیری شده باشد یا دارای خطا باشد، به سرورهای OCA مختلف [1] سوئیچ می کند. حتی اگر OCA متصل بیش از حد بارگیری شود یا ناموفق باشد، Client App می‌تواند به راحتی به سرور OCA دیگری برای تجربه مشاهده بهتر تغییر کند. همه اینها را می توان به این دلیل به دست آورد که SDK پلتفرم Netflix در Client آخرین OCA های سالم بازیابی شده از سرویس Playback Apps را ردیابی می کند (شکل 1).

3-2-3-2- معماري Backend

3-2-3-2-1- سرويس API Gateway

مؤلفه API Gateway Service با AWS Load Balancer ارتباط برقرار می کند تا تمام درخواست های مشتریان را حل کند. این مؤلفه را می توان در چندین نمونه AWS EC2 در مناطق مختلف مستقر کرد تا در دسترس بودن سرویس Netflix را افزایش دهد. نمودار در شکل 4 یک Zuul منبع باز را نشان می دهد، پیاده سازی API Gateway که توسط تیم Netflix ایجاد شده است.

1- فیلترهای ورودی را می توان برای احراز هویت، مسیریابی و تزئین درخواست استفاده کرد.
2- از فیلتر نقطه پایانی می توان برای بازگرداندن منابع استاتیک یا مسیریابی درخواست به مبدا یا API مناسب برای پردازش بیشتر استفاده کرد.
3- فیلترهای خروجی را می توان برای ردیابی معیارها، تزئین پاسخ به کاربر یا اضافه کردن هدرهای سفارشی استفاده کرد.
4- Zuul قادر است API API جدید را با ادغام با سرویس کشف Eureka کشف کند.
5- Zuul به طور گسترده برای مسیریابی ترافیک برای اهداف مختلف مانند نصب API برنامه جدید، تست بارگذاری، مسیریابی به نقاط پایانی خدمات مختلف تحت بارهای کاری زیاد استفاده می شود.

3-2-3-2-2- قسمت API Application

قسمت API نقش یک لایه ارکستراسیون [18] را برای میکروسرویس های Netflix ایفا می کند. API منطقی از ایجاد فراخوانی برای میکروسرویس های زیربنایی به ترتیب مورد نیاز، همراه با داده های اضافی از سایر ذخیره های داده برای ایجاد پاسخ های مناسب، ارائه می دهد. تیم نتفلیکس زمان زیادی را صرف طراحی مولفه Application API کرده است زیرا با عملکردهای اصلی کسب و کار Netflix مطابقت دارد. همچنین باید مقیاس پذیر باشد و در حجم درخواست بالا بسیار در دسترس باشد. در حال حاضر، APIهای برنامه تحت سه دسته تعریف می‌شوند: Signup API برای درخواست‌های غیرعضو مانند ثبت‌نام، صورت‌حساب، آزمایش رایگان و غیره، Discovery API برای جستجو، درخواست‌های توصیه و Play API برای پخش، مشاهده درخواست‌های مجوز. نمودار اجزای ساختاری دقیق Application API در شکل 5 ارائه شده است.

در به‌روزرسانی اخیر اجرای Play API، پروتکل شبکه بین Play API و میکروسرویس‌ها gRPC/HTTP2 است که به روش‌ها و موجودیت‌های RPC اجازه می‌دهد از طریق بافرهای پروتکل تعریف شوند، و کتابخانه‌های کلاینت/SDK به طور خودکار در زبان‌های مختلف تولید می‌شوند [ 13]. این تغییر به Application API اجازه می‌دهد تا از طریق ارتباط دو جهته با کلاینت‌های تولید شده به‌طور خودکار یکپارچه شود و استفاده مجدد از کد را در مرزهای سرویس به حداقل برساند.
Application API همچنین یک مکانیسم انعطاف پذیر مشترک بر اساس دستورات Hystrix برای محافظت از میکروسرویس های زیرین خود ارائه می دهد.
از آنجایی که Application API باید با حجم عظیمی از درخواست ها سر و کار داشته باشد و پاسخ های مناسب بسازد، پردازش داخلی آن باید به طور موازی اجرا شود. تیم نتفلیکس ترکیبی از اجرای همزمان و ورودی/خروجی ناهمزمان [13] را رویکرد مناسبی برای ادامه یافته است.

هر درخواست از API Gateway Service برای پردازش در حلقه رویداد شبکه برنامه API قرار می گیرد.
هر درخواست توسط یک کنترلر رشته اختصاصی مسدود می شود که دستورات Hystrix مانند getCustomerInfo، getDeviceInfo و غیره را در حلقه رویداد خروجی قرار می دهد. این حلقه رویداد خروجی به ازای هر مشتری تنظیم می‌شود و با ورودی/خروجی غیرمسدود اجرا می‌شود. هنگامی که میکروسرویس های فراخوانی به پایان می رسند یا به پایان می رسند، رشته اختصاصی پاسخ های مربوطه را ایجاد می کند.

3-2-3-3- ميكروسرويس ها

طبق تعریف مارتین فاولر، «سرویس‌های میکرو مجموعه‌ای از سرویس‌های کوچک هستند که هر یک در فرآیند خاص خود اجرا می‌شوند و با مکانیسم‌های سبک‌وزن ارتباط برقرار می‌کنند». این برنامه های کوچک به طور مستقل با توجه به دیگران قابل اجرا یا ارتقا هستند و داده های کپسوله شده خود را دارند. اجرای مولفه میکروسرویس در نتفلیکس [11] در شکل 7 نشان داده شده است.

یک میکروسرویس می‌تواند به تنهایی کار کند یا از طریق REST یا gRPC با میکروسرویس‌های دیگر تماس بگیرد.
پیاده‌سازی میکروسرویس می‌تواند مشابه Application API باشد که در شکل 6 توضیح داده شده است که در آن درخواست‌ها در حلقه رویداد شبکه قرار می‌گیرند و نتایج سایر ریزسرویس‌های نامیده شده در صف نتیجه در I/O غیرمسدود ناهمزمان قرار می‌گیرند.
هر میکروسرویس می‌تواند دیتا استور مخصوص به خود و برخی از حافظه‌های کش در حافظه نتایج اخیر را داشته باشد. EVCache یک انتخاب اصلی برای کش کردن میکروسرویس ها در Netflix است.

3-2-3-4- ذخيره ي داده

هنگام انتقال زیرساخت خود به ابر AWS، نتفلیکس از فروشگاه های داده مختلف (شکل 8)، هم SQL و هم NoSQL، برای اهداف مختلف استفاده کرد [6].

پایگاه داده MySQL برای مدیریت عنوان فیلم و اهداف تراکنش/صورتحساب استفاده می شود.
Hadoop برای پردازش کلان داده ها بر اساس گزارش های کاربر استفاده می شود.
ElasticSearch عناوین جستجو برای برنامه های Netflix را تقویت کرده است.
Cassandra یک فروشگاه داده NoSQL مبتنی بر ستون توزیع شده برای رسیدگی به حجم زیادی از درخواست‌های خواندنی بدون هیچ نقطه‌ای از شکست است. برای بهینه‌سازی تأخیر در درخواست‌های نوشتن بزرگ، از Cassandra به دلیل توانایی در نهایت ثابت آن استفاده می‌شود.

3-2-3-5- خط لوله ي پردازش جريان

خط لوله پردازش جریان داده [14، 3] به ستون فقرات داده نتفلیکس برای تجزیه و تحلیل تجاری و وظایف توصیه شخصی تبدیل شده است. مسئولیت تولید، جمع‌آوری، پردازش، جمع‌آوری و انتقال همه رویدادهای میکروسرویس به سایر پردازشگرهای داده در زمان واقعی را بر عهده دارد. شکل 9 قطعات مختلف سکو را نشان می دهد.

پلتفرم پردازش استریم روزانه تریلیون ها رویداد و پتابایت داده را پردازش می کند. همچنین با افزایش تعداد مشترکین، به طور خودکار مقیاس خواهد شد.
ماژول روتر مسیریابی به سینک های داده یا برنامه های کاربردی مختلف را امکان پذیر می کند در حالی که کافکا مسئول مسیریابی پیام ها و همچنین بافر برای سیستم های پایین دست است.
پردازش جریان به عنوان یک سرویس (SPaaS) به مهندسان داده اجازه می دهد تا برنامه های پردازش جریان مدیریت شده سفارشی خود را بسازند و نظارت کنند در حالی که پلت فرم از مقیاس پذیری و عملیات مراقبت می کند.

3-2-4- قسمت Open Connect

قسمت Open Connect یک شبکه جهانی تحویل محتوا (CDN) است که مسئول ذخیره و ارائه نمایش‌ها و فیلم‌های تلویزیونی نتفلیکس به مشترکان خود در سراسر جهان است. نتفلیکس با نزدیک کردن محتوایی که مردم می‌خواهند تماشا کنند، Open Connect را تا حد امکان به جایی که می‌خواهند تماشا کنند، ساخته و به‌طور کارآمد اجرا کرده است. به منظور بومی سازی ترافیک تماشای ویدیوهای نتفلیکس به شبکه مشتریان، نتفلیکس با ارائه دهندگان خدمات اینترنت (ISP) و نقاط تبادل اینترنت (IX یا IXP) در سراسر جهان برای استقرار دستگاه های تخصصی به نام Open Connect Appliances (OCAs) همکاری کرده است. در داخل شبکه آنها [7].

قسمت OCA ها سرورهایی هستند که برای ذخیره و پخش فایل های ویدئویی بزرگ از سایت های IX یا ISP به طور مستقیم به خانه مشترکان بهینه شده اند. این سرورها به‌طور دوره‌ای مسیرهای بهینه معیارهای سلامتی را که از شبکه‌های IXP/ISP آموخته‌اند و چه ویدیوهایی را روی دیسک‌های SSD خود ذخیره می‌کنند تا خدمات Open Connect Control Plane در AWS گزارش کنند. در عوض، خدمات صفحه کنترل چنین داده‌هایی را برای هدایت خودکار دستگاه‌های کلاینت به بهینه‌ترین OCA با توجه به در دسترس بودن فایل، سلامت سرور و نزدیکی شبکه به کلاینت‌ها می‌برد.
خدمات صفحه کنترل همچنین رفتار پر کردن اضافه کردن فایل‌های جدید یا به‌روزرسانی فایل‌ها در OCA‌ها را هر شب کنترل می‌کند. رفتارهای پر کردن [8،9] در شکل 11 نشان داده شده است.
وقتی فایل‌های ویدیویی جدید با موفقیت رمزگذاری شدند و در AWS S3 ذخیره شدند، سرویس‌های صفحه کنترل در AWS این فایل‌ها را به سرورهای OCAs در سایت‌های IXP منتقل می‌کنند. این سرورهای OCA، حافظه پنهان را برای انتقال این فایل‌ها به سرورهای OCA در سایت‌های ISP تحت شبکه‌های فرعی خود اعمال می‌کنند.
هنگامی که یک سرور OCA با موفقیت فایل‌های ویدیویی را ذخیره کرد، می‌تواند در صورت نیاز، فایل‌های همتا را برای کپی کردن این فایل‌ها در سایر سرورهای OCA در همان سایت شروع کند.
بین 2 سایت مختلف که می توانند آدرس های IP یکدیگر را ببینند، OCA ها می توانند فرآیند پر کردن ردیف را به جای پر کردن کش معمولی اعمال کنند.

3-3- الگوهاي طراحي

در بخش‌های قبلی، معماری ابر و اجزای آن را که به کسب و کار پخش ویدیوی نتفلیکس نیرو می‌دهند، با جزئیات شرح داده‌ام. در این بخش و بخش‌های بعدی، می‌خواهم به تحلیل این معماری طراحی عمیق‌تر بپردازم. فهرستی از مهمترین اهداف طراحی را به شرح زیر شروع می کنم:
- از در دسترس بودن بالا برای خدمات پخش در مقیاس جهانی اطمینان حاصل کنید.
- با قابلیت ارتجاعی با خرابی های شبکه و قطعی سیستم مقابله کنید.
- تأخیر جریان را برای هر دستگاه پشتیبانی شده تحت شرایط شبکه مختلف به حداقل برسانید.
- پشتیبانی از مقیاس پذیری در صورت حجم درخواست بالا.
- در بخش‌های فرعی، من قصد دارم در دسترس بودن سرویس پخش و تأخیر بهینه مربوط به آن را تجزیه و تحلیل کنم. بخش 6 به تجزیه و تحلیل عمیق تر در مورد مکانیسم های انعطاف پذیری مانند مهندسی آشوب می پردازد در حالی که بخش 7 مقیاس پذیری سرویس های پخش را پوشش می دهد.
1- در دسترس بودن بالا
طبق تعریف، در دسترس بودن یک سیستم بر حسب تعداد دفعاتی که یک پاسخ برای یک درخواست در یک بازه زمانی مشخص می شود، بدون تضمین اینکه حاوی آخرین نسخه اطلاعات است، اندازه گیری می شود. در طراحی سیستم ما، در دسترس بودن سرویس‌های استریم بستگی به در دسترس بودن سرویس‌های Backend و سرورهای OCA دارد که فایل‌های ویدئویی جریانی را نگه می‌دارند.
هدف خدمات Backend دریافت لیستی از نزدیکترین OCAهای سالم به یک کلاینت خاص، چه از حافظه پنهان یا با اجرای برخی از ریزسرویسها است. بنابراین، در دسترس بودن آن به مؤلفه‌های مختلف مربوط به درخواست پخش بستگی دارد: متعادل‌کننده‌های بار (AWS ELB)، سرورهای پروکسی (سرویس دروازه API)، Play API، اجرای میکروسرویس‌ها، ذخیره‌های کش (EVCache) و ذخیره‌سازی داده (Cassandra).

متعادل‌کننده‌های بار می‌توانند با مسیریابی ترافیک به سرورهای پراکسی مختلف دسترسی را بهبود بخشند تا از بار کاری بیش از حد جلوگیری شود.
Play API اجرای میکروسرویس‌ها را با مهلت زمانی از طریق دستورات Hystrix کنترل می‌کند که می‌تواند به جلوگیری از خرابی‌های آبشاری در سرویس‌های بعدی کمک کند.
میکروسرویس‌ها می‌توانند با داده‌های موجود در حافظه پنهان به Play AI پاسخ دهند، در صورتی که تماس با سرویس‌های خارجی یا فروشگاه‌های داده بیشتر از حد انتظار طول بکشد.
کش برای دسترسی سریع‌تر تکرار می‌شود.
هنگام دریافت لیست سرورهای OCA از Backend، سرویس گیرنده شبکه را به این OCA ها بررسی می کند و بهترین OCA ها را برای اتصال انتخاب می کند. اگر آن OCA بیش از حد بارگیری شود یا در طول فرآیند پخش ناموفق باشد، مشتری به یکی دیگر از موارد خوب تغییر می کند یا پلتفرم SDK OCA های دیگری را درخواست می کند. بنابراین در دسترس بودن آن با در دسترس بودن همه OCA های موجود در ISP یا IXP آن ارتباط زیادی دارد.
در دسترس بودن بالای خدمات پخش Netflix به قیمت عملیات و خدمات پیچیده AWS چند منطقه ای و همچنین افزونگی سرورهای OCA است.
2- تاخیر کم
تأخیر سرویس‌های پخش بیشتر به این بستگی دارد که API Play چقدر می‌تواند فهرست OCA‌های سالم را حل کند و ارتباط مشتری با سرور OCA انتخابی چقدر است.
همانطور که در بخش Application API توضیح داده‌ام، Play API برای همیشه منتظر اجرای میکروسرویس نمی‌ماند، زیرا از دستورات Hystrix برای کنترل مدت زمانی استفاده می‌کند که می‌خواهد برای نتیجه منتظر بماند تا داده‌های به‌روز نشده را دریافت کند. حافظه پنهان انجام این کار می تواند تأخیر قابل قبول را کنترل کند و همچنین خرابی های آبشاری برای خدمات بعدی را متوقف کند.
اگر شبکه سرور OCA انتخابی فعلی خراب شود یا سرور بیش از حد بارگیری شود، کلاینت بلافاصله به سایر سرورهای OCA نزدیک با قابل اطمینان ترین اتصال شبکه سوئیچ می کند. همچنین می‌تواند کیفیت ویدیو را برای مطابقت با کیفیت شبکه کاهش دهد تا در صورت مشاهده کاهش در اتصال شبکه.

4- شركت Airbnb

4-1- معرفي

شركت Airbnb وب سایتی است که یک بازار آنلاین و خدمات مهمان نوازی را برای افراد برای اجاره یا اجاره مسکن کوتاه مدت ارائه می دهد. چالش های تیم مهندسی شامل دسترسی بالا، مقیاس پذیری سریع و ... است.

4-2- معماري

جسيكا تاي يكي از مديران اين شركت مي گويد: در ابتدای Airbnb، معماری ما واقعا ساده بود. این یک برنامه یکپارچه Ruby on Rails بود که به عنوان monorail شناخته می شد. بیایید معماری خود را به عنوان یک طناب نشان دهیم. اگر آن را تصور کنید، یک طناب است که به راحتی می توان آن را دنبال کرد و به راحتی باز می شود. با این حال، زمانی که توسعه دهندگان در طول سالیان متمادی کد را به مونوریل اضافه می کردند، این طناب ساده به زودی به یک گره پیچیده تبدیل شد. فهمیدن مونوریل سخت شد و مولد بودن در آن سخت شد. مهندسان وقتی مجبور به تغییر و استقرار مونوریل می شدند ناله می کردند. واضح بود که باید دریابیم که چگونه این آشفتگی اسپاگتی را باز کنیم. راه حلی که به آن رسیدیم مهاجرت به معماری سرویس گرا یا SOA بود. SOA این گره مونوریل عظیم را در خدمات محصور شده جداگانه سازماندهی کرد که در اینجا به صورت تکه های طناب مختلف نشان داده شده است. اولین نسخه ما از SOA بسیار شبیه به نمای مدل در لایه های کنترل کننده مونوریل به نظر می رسید و به ما کمک کرد تا از دردسرهای رو به رشد آن زمان عبور کنیم. با این حال، در نهایت، زیرا ما صدها سرویس را توسعه داده بودیم، چالش های جدیدی ظاهر شد. چیزی که قبلا ماژول و تمیز به نظر می رسید، اکنون دوباره شروع به یک سری پیچ و تاب و گره پیچیده می کند[22].

شركت Airbnb از خدمات AWS استفاده می‌کند. از نمونه‌های EC2 برای برنامه‌های کاربردی، حافظه پنهان و سرورهای جستجو استفاده می‌کند. از RDS به عنوان پایگاه داده اصلی MySQL استفاده می‌کند. از ELB برای متعادل کردن بار ترافیکی استفاده کرد. از EMR برای پردازش و تجزیه و تحلیل روزانه داده‌ها استفاده می‌کند. از S3 برای پشتیبان‌گیری و فایل‌های ثابت، از جمله تصاویر کاربر استفاده می‌کند. از Amazon CloudWatch برای نظارت بر دارایی‌های ES2 استفاده می‌کند[28].

متعادل‌کننده بار: Charon، متعادل‌کننده بار جلوی Airbnb است. قبلاً ELB آمازون بود. این تصمیم مبتنی بر این واقعیت است که ELB درهم و برهم بود و برای عیب‌یابی کمتر مفید بود[29].

پایگاه داده: Airbnb از Amazon RDS به عنوان پایگاه داده اصلی MySQL استفاده می‌کند. پایگاه‌های داده در چند AZ (منطقه در دسترس) مستقر شده‌اند. چندین نوع پایگاه داده برای سناریوهای مختلف وجود دارد، به عنوان مثال، تقویم، پیام، و غیره[30].

پایگاه داده تحلیلی: زیرساخت داده‌های Airbnb معیارها را مدیریت می‌کند، مدل‌های یادگیری ماشینی را آموزش می‌دهد و تجزیه و تحلیل‌های تجاری و غیره را اجرا می‌کند.

از خدمات زیر AWS استفاده می کند[23]:
- از نمونه های EC2 برای برنامه های کاربردی، حافظه پنهان و سرورهای جستجو استفاده می کند.
- از RDS به عنوان پایگاه داده اصلی MySQL استفاده می کند.
- از ELB برای تعادل بار ترافیکی استفاده کرد (توجه: به نظر می رسد دیگر استفاده نمی شود، بخش Load Balancer را در زیر بررسی کنید.).
- از EMR برای پردازش و تجزیه و تحلیل روزانه داده ها استفاده می کند (توجه: به نظر می رسد تا حدودی قدیمی است، بخش انبار داده را در زیر بررسی کنید).
- از S3 برای پشتیبان گیری و فایل های ثابت، از جمله تصاویر کاربر استفاده می کند.
- از Amazon CloudWatch برای نظارت بر دارایی های ES2 استفاده می کند.
4-3- کشف خدمات[24]
SmartStack یک چارچوب کشف سرویس OSS است. دو جزء دارد: عصب و سیناپس به Zookeeper برای ذخیره داده های کشف و همچنین HAProxy برای مسیریابی متکی است. Nerve چرخه زندگی میکروسرویس ها را بر اساس بررسی های سلامت مدیریت می کند. Synapse نمونه های میکروسرویس را جستجو می کند و پیکربندی HAProxy را به طور خودکار به روز می کند. Zookeeper znode را برای نام سرویس‌ها ذخیره می‌کند و نمونه‌های میکروسرویس تغییر را از طریق ساعت‌های Zookeeper ارائه می‌کند.

4-4- پايگاه داده
Airbnb از Amazon RDS به عنوان پایگاه داده اصلی MySQL استفاده می کند. پایگاه های داده در چند AZ (منطقه در دسترس) مستقر شده اند. معماری 3 لایه زیر الگوی اصلی را منعکس می کند. توجه داشته باشید که چندین نوع پایگاه داده برای سناریوهای مختلف وجود دارد، به عنوان مثال، airmaster، تقویم، پیام، و غیره. بنابراین، بیش از دوجین dbproxy وجود دارد و صدها نمونه پایگاه داده مستقر می شوند.

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

4-5- پایگاه داده تحلیلی
زیرساخت داده‌های Airbnb معیارها را مدیریت می‌کند، مدل‌های یادگیری ماشینی را آموزش می‌دهد و تجزیه و تحلیل‌های تجاری و غیره را اجرا می‌کند[27].

- کافکا به عنوان یک واسطه برای گزارش رویدادها عمل می کند.
- Sqoop به عنوان یک کارگزار برای تخلیه پایگاه داده تولید عمل می کند.
- خوشه Gold and Silver Hive سینک های داده هستند. خوشه Gold Hive داده ها را به نقره تقلید می کند.
خوشه Gold Hive دارای ضمانت SLA بالاتری است.
- یک Spark Cluster بر روی یادگیری ماشینی برای پردازش جریانی کار می کند.
- یک خوشه Presto برای پرس و جوی موقت است.
- یک برنامه Airflow در جلو برای برنامه ریزی کار اجرا می شود.
- S3 یک راه حل بلند مدت برای داده های HDFS است.

4-6- میکروسرویس ها
شركت Airbnb از Dropwizard استفاده می کند. چارچوب سرویس، و یک سرویس Thrift IDL را سفارشی کرد.
توسعه دهندگان می توانند بین JSON-over-http و Thrift-over-http یکی را انتخاب کنند.
سرویس های پایین دستی باید کلاینت های RPC تولید شده را از بالادست نصب کنند.
سرویس‌های پایین‌دستی همچنین نیاز به اعمال زمان استاندارد، امتحان مجدد و منطق قطع کننده مدار دارند.
این چارچوب معیارهای درخواست و پاسخ را هم در سمت سرویس و هم در سمت مشتری اضافه می کند.
چارچوب، زمینه درخواست‌ها، از جمله شناسه درخواست را به تمام درخواست‌های خدمات اساسی اضافه می‌کند.
این چارچوب از افزودن هشدارها بر اساس معیارهایی مانند p95_latency، p99_latency و غیره پشتیبانی می‌کند[25].

4-7- سرويس جست و جو

سرويس Nebula یک سرویس ذخیره داده بدون طرح و نسخه است که هم دسترسی تصادفی به داده ها در زمان واقعی و هم مدیریت داده های دسته ای آفلاین دارد. جریان جستجو فقط مقداری منطق نمایه سازی جستجو را به این سیستم اضافه می کند. عکس فوری روزانه به عنوان بخشی از ادغام داده های آفلاین تولید می شود. فهرست جستجو از روی عکس فوری ساخته شده و سپس برای جستجوی دوره ای به عنوان یک استقرار باینری معمولی استفاده می شود[26].

5- مقايسه‌ي دو معماري

استفاده از سرويس هاي ابري آمازون، معماري ميكروسرويس، MySQL و NoSQL بين معاري اين دو شركت مشترك است. اما با توجه به اهداف پياده سازي مانند ميزان در درس بودن سيستم استفاده از تكنولوژي هاي براي اين معماري ها متفاوت است.

6- جمع بندي

این مطالعه کل معماری ابری خدمات استریم در Netflix و Airbnb را تشریح کرده است. همچنین اهداف طراحی مختلف را از نظر در دسترس بودن، تأخیر، مقیاس پذیری و انعطاف پذیری در برابر خرابی های شبکه یا قطع سیستم تجزیه و تحلیل کرد. به طور خلاصه، معماری ابری نتفلیکس، که توسط سیستم تولید آن ثابت شده است که به میلیون‌ها مشترکی که روی هزاران سرور مجازی کار می‌کنند، ارائه می‌کند، در دسترس بودن بالا با تأخیر بهینه، مقیاس‌پذیری قوی از طریق ادغام با سرویس‌های ابری AWS و قابلیت انعطاف‌پذیری در برابر خرابی‌های شبکه و قطعی سیستم نشان داده است. در مقیاس جهانی بیشتر معماری و اجزای مشتق شده از طریق منابع قابل اعتماد آنلاین موجود آموخته می شود. اگرچه منابع مستقیم زیادی برای توصیف پیاده‌سازی داخلی میکروسرویس‌ها و همچنین ابزارها و سیستم‌ها برای نظارت بر عملکرد آنها وجود ندارد، این مطالعه می‌تواند به عنوان یک پیاده‌سازی مرجع برای چگونگی ساخت یک سیستم تولید معمولی عمل کند.
این فرآیند ما را به توسعه سیستم زبان طراحی جدید (یا DLS) و همچنین مجموعه‌ای از ابزارهای داخلی و شخص ثالث هدایت کرد که به تیم‌های ما اجازه می‌دهد نه تنها هوشمندانه‌تر، بلکه نزدیک‌تر کار کنند. DLS مجموعه ای از مؤلفه ها است که با اصول و الگوهای مشترک تعریف شده اند. این امکان تکرار سریع با استفاده از واژگان مشترک در طراحی، مهندسی و سایر رشته ها را فراهم می کند. ساختار DLS ساده و منسجم است و ارتباط بین تیم ها را آسان می کند.

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

منابع

1. Netflix: What Happens When You Press Play? By Todd Hoff on Dec 11, 2017. Link
2. High Quality Video Encoding at Scale. By Anne Aaron and David Ronca on HighScalability. Dec 9, 2015. Link
3. Building and Scaling Data Lineage at Netflix to Improve Data Infrastructure Reliability, and Efficiency. By Di Lin, Girish Lingappa, Jitender Aswani on The Netflix Tech Blog. Mar 25, 2019. Link
4. Ten years on: How Netflix completed a historic cloud migration with AWS. By Tom Macaulay on Computerworld. Sep 10, 2018. Link
5. The Netflix Simian Army. By Yury Izrailevsky and Ariel Tseitlin on The Netflix Tech Blog. Link
6. Globally Cloud Distributed Applications at Netflix. By Adrian Cockcroft. Oct 2012. Link
7. Open Connect Overview. By Netflix. Link
8. Open Connect Deployment Guide. By Netflix. Link
9. Netflix and Fill. By Michael Costello and Ellen Livengood. Aug 11, 2016. Link
10. Automating Operations of a Global CDN. By Robert Fernandes at Strange Loop. Sep 14, 2019. Link
11. Mastering Chaos — A Netflix Guide to Microservices. By Josh Evans at QCon. Dec 07, 2016. Link
12. Netflix Revenue and Usage Statistics. By Mansoor Iqbal on BusinessofApps. March 6, 2020. Link
13. Netflix Play API — Why we build an Evolutionary Architecture. By Suudhan Rangarajan at QCon 2018. Dec 12, 2018. Link
14. Keystone Real-time Stream Processing Platform. By Zhenzhong Xu on The Netflix Tech Blog. Sep 10, 2018. Link
15. Netflix Releases Open Source Message Security Layer. By Chris Swan on InfoQ. Nov 24th, 2014. Link
16. Netflix Open Source. Link
17. Titus, the Netflix container management platform, is now open source. By Amit Joshi and others. Link
18. Engineering Trade-Offs and The Netflix API Re-Architecture. By Katharina Probst and Justin Becker on The Netflix Tech Blog. Aug 23, 2016. Link
19. Kafka Inside Keystone Pipeline. By Real-Time Data Infrastructure Team. April 27, 2016. Link
20. Open Sourcing Zuul 2. By Arthur Gonigberg and others on The Netflix Tech Blog. May 21, 2018. Link
21. Performance Vs Scalability. By Beekums. Aug 19, 2017. Link
22. Data Infrastructure at Airbnb
23. Scaling Airbnb's Experimentation Platform
24. What is the Airbnb Software Architecture
25. Airbnb Case Study
26. BinaryAlert: Real-time Serverless Malware Detection
27. Alerting Framework at Airbnb
28. Scaling Airbnb Payment Platform
29. Measuring Transactional Integrity in Airbnb's Distributed Payment Ecosystem
30. Tracking the Money - Scaling Financial Reporting at Airbnb